Ready status override by multiple status replies

[MarshallBrinn]

When we have multiple status replies (for a stitched topology, say) we get in the 'green' from one status reply and then another status reply says 'unknown' and erases the green

We need to only use status from the authoritative AM.

Imported from trac ticket #1314, created by mbrinn on 02-18-2015 at 10:31, last modified: 02-22-2015 at 12:21

[ahelsing]

I produced this by drawing an RSpec:

• 2 sites, each with a single VM
• A link between those 2 VMs.
• Bind site 1 to GPO Exogeni
• Bind site 2 to University of Chicago IG

Then look at this slice on the slice-jacks page.

Trac comment by ahelsing on 02-18-2015 at 13:47

[MarshallBrinn]

I've diagnosed the problem and it is a tricky one. Basically, whenever we give Jacks a manifest, it creates a new topology, getting rid of the old stuff and recreating it. So any formatting I did (setting things green e.g.) whenever a manifest comes in after a status message.

This is what is happening in this case, and could happen. In general we run the manifest/status in parallel for each AM (that is, we ask for all manifests, then as each one comes in, we do a a 'modify-topolgy' and then request the statues for that AM.

But if one of the manifests comes in after the status, then we see this problem. The box for the node that we painted based on the status no longer exists.

There are a bunch of ways to solve this but I think the best one is to keep a list of all the current status replies and apply them ALL after we get ANY manifest.

Trac comment by mbrinn (github user: MarshallBrinn) on 02-21-2015 at 11:25

[MarshallBrinn]

I think this is all set. I fixed it by keeping a list of all current states and applying all of them whenever we apply ANY status. We clear out this mapping when we go to refresh all manifests. The (highly reproducible) case above now works.

Trac comment by mbrinn (github user: MarshallBrinn) on 02-22-2015 at 12:21