Hi, During the recent weeks, we've noticed that some features would have a common challenge to solve: How to share informations or files between nodes, during a multi-node deployment.
A few use-cases: * Deploying Keystone using Fernet tokens Adam Young started this topic a few weeks ago, we are investigating how to integrate Fernet in TripleO. The main challenge is that we want to generate keys periodically for security purposes. In multi-node environment, when using HAproxy, you need to make sure all Fernet keys are the same otherwise you expose the risk of an user connected to a Keystone server that won't be able to validate Token. We need a way to: 1) generate tokens periodically. It could be in puppet-keystone, we already have a crontab example: https://github.com/openstack/puppet-keystone/tree/master/manifests/cron 2) distribute the key from a node to other nodes <-- that is the challenge. note: I confirmed with ayoung, and there is no need to restart Keystone when we change a token. * Scaling down/up Swift cluster It's currently impossible to scale down/up a Swift cluster in TripleO because the ring is built during deployment and never updated afterwards. It makes Swift not really usable in production without manual intervention. Since we don't use a set of classes in puppet-swift that performs this action because they require PuppetDB, we need to find a way to redistribute the ring when we add or remove Swift nodes in a TripleO Cloud. Maybe we can investigate some Mistral actions or Heat, that would run the swift commands to re-distribute the ring. * Dynamic discovery An example of use-case is: https://review.openstack.org/#/c/304125/ We want to manage Keystone resources for services (ie: nova endpoints, etc) from the services roles (ie: nova-api), so we stop creating all endpoints from the keystone profile role. The current issue with composable services is that until now (tell me if I'm wrong), keystone role is not aware if whether or not we run gnocchi-api in our cloud so we don't know if we need to create the endpoints etc. On the review, please my (long) comment on Patch Set 12, where we expose our current challenges. I hope by this thread that we can boostrap some discussions around these challenges, because we'll keep having them with the complexity of OpenStack deployments. Feel free to comment / correct me / give any feedback on this initial e-mail, thanks for reading so far. -- Emilien Macchi __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
