[rdo-list] Packstack refactor and future ideas

Ivan Chavero ichavero at redhat.com
Wed Jun 8 19:27:52 UTC 2016



----- Original Message -----
> From: "Javier Pena" <javier.pena at redhat.com>
> To: "rdo-list" <rdo-list at 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/




More information about the dev mailing list