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