[rdo-list] Packstack refactor and future ideas

[Ivan Chavero]

----- Original Message -----
> From: "David Moreau Simard" <dms at redhat.com>
> To: "Ivan Chavero" <ichavero at redhat.com>
> Cc: "Javier Pena" <javier.pena at redhat.com>, "rdo-list" <rdo-list at redhat.com>
> Sent: Wednesday, June 8, 2016 3:37:08 PM
> Subject: Re: [rdo-list] Packstack refactor and future ideas
> 
> On Wed, Jun 8, 2016 at 3:27 PM, Ivan Chavero <ichavero at redhat.com> wrote:
> > 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.
> 
> This would not pass CI and thus could not be merged.
> If there are separate commits, each must pass CI.

well, make it just one big commit if there's no way around this

> Otherwise, my opinion is that Packstack should focus on being a lean,
> simple and efficient single node installation tool that targets the
> same use case as DevStack but for the RHEL-derivatives and RDO/OSP
> population.
> A tool that is lightweight, simple (to an extent), easy to extend and
> add new projects in and focuses on developers and proof of concepts.

> I don't believe Packstack should be able to handle multi-node by itself.
> I don't think I am being pessimistic by saying there is too few
> resources contributing to Packstack to make multi-node a good story.
> We're not testing Packstack multi-node right now and testing it
> properly is really hard, just ask the whole teams of people focused on
> just testing TripleO.

So in your opinion we should drop features that packstack already has
because this are difficult to test.
I don't agree with this, we can set the untested features as "experimental"
or "unsupported"

 
> If Packstack is really good at installing things on one node, an
> advanced/experienced user could have Packstack install components on
> different servers if that is what he is looking for.
> 
> Pseudo-code:
> - Server 1: packstack --install-rabbitmq=y --install-mariadb=y
> - Server 2: packstack --install-keystone=y --rabbitmq-server=server1
> --database-server=server1
> - Server 3: packstack --install-glance=y --keystone-server=server2
> --database-server=server1 --rabbitmq-server=server1
> - Server 4: packstack --install-nova=y --keystone-server=server2
> --database-server=server1 --rabbitmq-server=server1
> (etc)

I can be wrong but right now Packstack can already do this stuff, 
more command line options are needed or it might need little tweaks to the
code but this is not far from current Packstack options.

> So in my concept, Packstack is not able to do multi node by itself but
> provides the necessary mechanisms to allow to be installed across
> different nodes.
> If an orchestration or wrapper mechanism is required, Ansible is a
> obvious choice but not the only one.
> Using Ansible would, notably, make it easy to rip out all the python
> code that's around executing things on servers over SSH.
> 


I think this refactor discussion should focus on a proper puppet usage and
optimizations instead of retiring stuff that already works.
Actually Packstack used to be able to install all the components in different
nodes and this feature was modified to the current limited multinode features.

We need a tool like Packstack so users can try RDO without the complexity of 
TripleO, imagine you're new to OpenStack and you want to test it in different
scenarios, not everybody has a spare machine with 16GB of ram just to test, not to 
mention the fact of understanding the concept of undercloud before understanding
the key concepts of OpenStack.

Cheers,
Ivan