dgrove-oss commented on issue #2689: first stage of support for dynamic invoker id assignment URL: https://github.com/apache/incubator-openwhisk/pull/2689#issuecomment-330924558 For this PR, I would prefer to keep Redis as the persistent store. I think the Redis client API is a better match for the needed function than Zookeeper's. It might not be the final solution, but it allows us to make forward progress. Note that the persistent store is not dynamically used if the deployment provides suggested invokerIds (current default behavior). I've done some updates and squashed down to a single commit again. Since the approach has changed quite a bit during the review process, I'm inling the updated commit comment here to make it easier to see what this PR is actually doing now. ---- First stage of adding support for dynamic invoker id assignment Add a handshake between the invoker and controller during invoker startup to allow the controller an opportunity to dynamically assign the invokerId (the topic to which the invoker listens to accept work). The invoker provides an identifying name for itself and optionally a suggested invokerId to the controller via the invokerReg topic of the messaging provider. The controller responds with an assigned invokerID using a topic derived from the provided invoker name. After receiving its invokerId, the rest of invoker startup proceeds as before. To support different deployment scenarios, both the name and the suggested invokerId may be provided externally to the invoker. This supports two deployment modes: 1. A completely static assignment of invokerIds to invokers when the deployment specifies the suggested invokerId. This is the default option for this PR and matches the prior behavior of the system. 2. If the deployment provides an invoker name, but not a suggested invokerId, then we get a dynamically assigned but stable invokerIds. For example, the invoker name could be the IP address or hostname of the invoker's host or the nodeName of the kube worker node. A third option, in which the deployment provides neither the name nor the suggested invokerId is possible, but is currently trapped as a configuration error. This is treated as configuration error to avoid an explosion of invokerIds (topics) in the presence of frequent invoker instance restarts. Option 2 depends on persisting the state for the dynamic invoker id assignment protocol to support controller restarts and multiple controllers. For the purposes of this PR, we use the Redis instance stated for the apigateway as the persistent store since the Redis API is a good match for the needed operations. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
With regards, Apache Git Services
