-
Notifications
You must be signed in to change notification settings - Fork 1
2021 03 22 webex
#03/22/21 webex notes
Attending: Howard Pritchard, Martin Schreiber, Martin Schulz, Jan Fecht, Rolf Rabenseifner, Aurelien Bouteiller
- continue with process set versioning, mutability and Martin Schreiber's app
A bit of caching back in of things. Resume somewhat about rapidly changing membership in process sets. Too fast and there can't be a reliable consensus mechanism - back to the comm_create_from_process_set discussion. Martin Schreiber - going back to model where only 1 process would be looking up process sets to use. Dan points out that this doesn't really change the situation. May not be a better consensus algorithm. Could end up with a broken communicator since some processes may already have fallen out. Paxos, where are you when we need you!
Shouldn't design further sessions api for something where consensus can't be reached on which process set to use.
Categorize by frequency of change. What's extremely fast, slow, etc. Probably doesn't make sense to think of time-scale so simplistically. Larger system sizes means longer times for collective algorithms, and hence likely consensus algorithms, so what was slow on a smaller system could be fast on a larger system. Martin Schreiber added a slide capturing some of this discussion. Who initiates the change? We don't like applications trying too often to check for resource changes. App at regular intervals asks about resource changes - we have a model for this. Is there something fundamentally different for system initiated? How to notify the application about this? Back to the discussion we had a while ago about coercive vs cooperative. Fault scenario implies coercive.
How would Martin Schreiber's app handle coercive case. Loose two processes have to roll back and restart.
See slide for further discussion.
Next steps? Too many combinations on the slide. Look at the most likely (and hopefully useful) use cases!