cluster: drop node updates that are old or about thisNode

[woodsaj]

fixes #947

[Dieterbe]

so this still allows a node to receive gossiped information about itself. is there ever a scenario where this makes sense? seems clearer if we would just discard all data about itself. then we know for sure we can't have the reported bug.

[Dieterbe]

can you add comments to the HTTPNode definition about what Updated and StateChange represent / how they are used? it's not clear how they differ

[woodsaj]

really? one is set when the httpNode is updated one is set when the httpNodes's state changes

[Dieterbe]

yes, really.
It's more about why things are implemented this way. i.e. the overarching design of the code.
there is a lot of information in your head that is not there for others reading your code.

for example:

• why is StateChange never read from in the code, is it only for inspection by admin?
• why does changing the State and StateChange fields not trigger a gossip broadcast whereas changing Update would? (error clause in MemberlistManager.NotifyUpdate)
• who is responsible for updating the fields: the local nodes emitting their state, or the peers receiving it? (seems to be both?)
• does "update" include an update to the state field? seems to be yes except in the above mentioned exception case?

documentation helps in answering these sort of questions.

BTW should SingleNodeManager.SetState not update StateChange ?

[Dieterbe]

@woodsaj

so this still allows a node to receive gossiped information about itself. is there ever a scenario where this makes sense? seems clearer if we would just discard all data about itself. then we know for sure we can't have the reported bug.

[Dieterbe]

awoods [11:28 AM]
I can't think of any reason why we would want gossiped messages to alter the state of thisNode

[Dieterbe]

i'll rebase this and get this ready again.

[Dieterbe]

@woodsaj how does this look

note that we should still clarify #948 (comment)

[woodsaj]

@Dieterbe LGTM