5:33 p.m.
----- Original Message -----
From: "David Moreau Simard" <dms(a)redhat.com>
To: "Ivan Chavero" <ichavero(a)redhat.com>
Cc: "Javier Pena" <javier.pena(a)redhat.com>, "rdo-list"
<rdo-list(a)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(a)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