[rdo-list] Packstack refactor and future ideas

Thu Jun 9 09:54:38 UTC 2016

On Thu, Jun 9, 2016 at 10:44 AM, Javier Pena <javier.pena at redhat.com> wrote:
> ----- 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.

Sounds good,  maybe we could work with someone knowing how instack
works to prototype how this could be done.

>
> Javier
>
>> -Hugh
>
> _______________________________________________
> rdo-list mailing list
> rdo-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rdo-list
>
> To unsubscribe: rdo-list-unsubscribe at redhat.com