Open Stack

On 05/12/2016 02:20 PM, Emilien Macchi wrote:
> 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.


Policy file distribution also ties in here, especially if we want to be 
able make different policy for different endpoints of the same service.

>
>
> 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.