Thanks for the feedback on the PR. I've revised it accordingly to support optional external assignment of invokerUUIDs and a stable mapping of UUIDs to assigned topics (invokerIds) to avoid churn on instance restarts. Please take another look if you are interested.
--dave "David P Grove" <[email protected]> wrote on 09/02/2017 08:17:45 PM: > > I prototyped one possible approach for supporting dynamic assignment > of invoker instance ids in [1]. This approach adds a round of messaging to > invoker startup where the invoker communicates with the controller(s) to be > assigned an instance id. It preserves the current dense numbering of > invokers, but adds a little latency to system startup. > I think it would be possible (with marginally more work) to instead > change invoker ids to be random UUIDs that the invokers could self > generate. This would eliminate the extra round of communication, but would > make invoker names more cumbersome to humans and would need some tweaks in > the load balancer to add a mapping between sparse UUIDs to a dense > numbering to be used during the hash-based assignment of incoming work to > invokers. > > The motivation for dynamic assignment of invoker instance ids is (a) > elasticity support (frequent resizing of invoker pool to match load) and > (b) making it easy to use DaemonSets instead of StatefulSets for invokers > when deploying openwhisk on kubernetes. > > If people have thoughts on the merits of the two possible approaches > or thoughts on other possible approaches, please comment on the PR or > discuss here on the dev list > > thanks, > > --dave > > [1] https://github.com/apache/incubator-openwhisk/pull/2689
