Re: [rdo-list] Packstack refactor and future ideas
----- Original Message -----
From: "Javier Pena" <javier.pena(a)redhat.com>
To: "rdo-list" <rdo-list(a)redhat.com>
Sent: Wednesday, June 8, 2016 11:29:54 AM
Subject: [rdo-list] Packstack refactor and future ideas
Hi RDO,
After some discussions about the way Packstack was (mis)using Puppet, and how
to improve it, I've been working on a refactor. Its current state is
available at
https://github.com/javierpena/packstack/tree/feature/manifest_refactor, and
as soon as it is polished it will go to Gerrit. It basically tries to reduce
the number of Puppet executions to one per server role (controller, network
node, compute), instead of multiple individual runs.
I think it can be reduced to a single manifest per node.
Also, when a review is created it would be easier to check if you create one
review for the python, puppet, tests and release notes.
While talking about the refactor, a second discussion about a deeper
change
was started. I'd like to summarize the current concerns and ideas in this
mail, so we can follow-up and make a decision:
- Currently, the Packstack CI is only testing single-node installs. Testing
multi-node installs upstream has been challenging, and multi-node may go
beyond the PoC target of Packstack. So, one proposal is to keep all-in-one
single node only, add Ansible wrapper (in unsupported contrib/ subfolder)
reading *_HOSTS parameters for backward compat.
I would like to have packstack to be multi node since the requirements for
TripleO are still to big for PoC.
- Another idea was to refactor the Packstack Python part around
Ansible,
summarized at https://etherpad.openstack.org/p/packstack-refactor-take2 .
This proposal aims at keeping multi-node support, since Ansible makes it
easy anyway.
Does it make sense to convert packstack to an ansible module?
Any other ideas/concerns? Pros and cons of each?
I started a refactor [1] as part of a manifest cleanup, unifcation and to
start de refactor discussion, i'm happy that Javier took the
puppet-openstack-integration
road.
Another idea around this refactor is to make packstack create manifests
that can be used even without packstack runs, installing them in the proper puppet
environment directories and setting the OPM path as part of the this OpenStack?
environment,
thus making packstack a puppet manifest generator...
Cheers,
Ivan
[1] https://review.openstack.org/#/c/307519/