From: rdo-list-bounces redhat com <rdo-list-bounces redhat com> on behalf of Ivan Chavero <ichavero redhat com>
Sent: Wednesday, June 8, 2016 3:27 PM
To: Javier Pena
Subject: Re: [rdo-list] Packstack refactor and future ideas
----- Original Message -----
> From: "Javier Pena" <javier pena redhat com>
> To: "rdo-list" <rdo-list 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.
But it is :-
RDO Mitaka ML2&OVS&VXLAN (VLAN)
Just external OVS bridge on Controller/Network ( Network) has to be configured manually.
It works fine unless HA Controller(s) is a must.
Some posts to this thread sound like intend to drop features present and working all way long
in packstack. I hardly understand why working features should be dropped due to not passing through CI.
Yes , conversion system to DVR requires several updates after packstack pre-deployment,
but I would never compare Packstack with Devstack due to
1. Packstack installs different services on different nodes exactly as answer-file instructs it to do.
2. Devstack starts a bunch of non-restart able ( in meantime ) daemons on one or several nodes,
> - 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  as part of a manifest cleanup, unifcation and to
start de refactor discussion, i'm happy that Javier took the puppet-openstack-integration
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...
rdo-list mailing list
rdo-list redhat com
To unsubscribe: rdo-list-unsubscribe redhat com