On Jun 8, 2016 11:33 PM, "Ivan Chavero" <ichavero@redhat.com> wrote:
>
>
>
> ----- Original Message -----
> > From: "David Moreau Simard" <dms@redhat.com>
> > To: "Ivan Chavero" <ichavero@redhat.com>
> > Cc: "Javier Pena" <javier.pena@redhat.com>, "rdo-list" <rdo-list@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@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?

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