[rdo-list] Packstack refactor and future ideas

[Javier Pena]

----- Original Message ----- 

> On Jun 8, 2016 11:54 PM, "Ivan Chavero" < ichavero at redhat.com > wrote:
> >
> >
> >
> > ----- Original Message -----
> > > From: "Hugh Brock" < hbrock at redhat.com >
> > > To: "Ivan Chavero" < ichavero at redhat.com >
> > > Cc: "Javier Pena" < javier.pena at redhat.com >, "David Moreau Simard" <
> > > dms at redhat.com >, "rdo-list" < rdo-list at redhat.com >
> > > Sent: Wednesday, June 8, 2016 5:40:39 PM
> > > Subject: Re: [rdo-list] Packstack refactor and future ideas
> > >
> > > On Jun 8, 2016 11:33 PM, "Ivan Chavero" < ichavero at redhat.com > wrote:
> > > >
> > > >
> > > >
> > > > ----- 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
> > >
> > > Here's a possibly stupid question, indulge me....
> > >
> > > Seems like we're always going to need a simple (ish) tool that just
> > > installs the openstack services on a single machine, without any need for
> > > VMs.
> > >
> > > In fact, the tripleo installer - instack - is one such tool. Packstack is
> > > another, more flexible such tool. Should we consider merging or adapting
> > > them to be the same tool?
> >
> > I don't think this is supid at all, actually TripleO and Packstack are both
> > based on OpenStack Puppet Modules but i don't think you can make merge them
> > since the behaviour of both tools is very different, Packstack is not
> > focused on managing the hardware, it's just focused on installing OpenStack
> > and i'm not very familiar with TripleO inner workings but i think it would
> > be
> > very difficult to make it more like Packstack.
> >
> > Cheers,
> > Ivan
> No, sorry, I didn't mean merge packstack and tripleo, they are very different
> beasts. I meant merge the tripleo installer -- which is called "instack",
> and whose job it is to install an openstack undercloud on a single machine
> so that it can then install openstack -- with packstack, whose job it is to
> install openstack on a single machine, for whatever reason. Deployers who
> want a production install could then go on to deploy a full overcloud.

This could make a lot of sense. I'm not very aware of the instack internals, and I remember it had some code to create VMs for the overcloud on test environments, but it could make sense to use a specific Packstack profile for that.

Javier

> -Hugh