[rdo-list] Packstack refactor and future ideas

[Javier Pena]

----- Original Message -----
> On Wed, Jun 8, 2016 at 6:33 PM, Ivan Chavero <ichavero at redhat.com> wrote:
> > 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.
> 
> Right now Packstack has a lot of code and logic to connect to
> additional nodes and do things.

To be honest, the amount of code is not that big (at least to me).

On a quick check over the refactored version, I see https://github.com/javierpena/packstack/blob/feature/manifest_refactor/packstack/plugins/prescript_000.py#L1277-L1363 could be simplified (maybe removed), then https://github.com/javierpena/packstack/blob/feature/manifest_refactor/packstack/plugins/puppet_950.py#L147-L246 would need to be rewritten, to support a single node. Everything else is small simplifications on the plugins to assume all hosts are the same.

> Packstack, itself, connects to compute hosts to install nova, same
> with the other kind of hosts.
> 
> What I am saying is that Packstack should only ever be able to install
> (efficiently) services on "localhost".
> 
> Hence, me, as a user (with Ansible or manually), could do something
> like I mentioned before:
> - Login to Server 1 and run "packstack --install-rabbitmq=y
> --install-mariadb=y"
> - Login to Server 2 and run "packstack --install-keystone=y
> --rabbitmq-server=server1 --database-server=server1"
> - Login to Server 3 and run "packstack --install-glance=y
> --keystone-server=server2 --database-server=server1
> --rabbitmq-server=server1"
> - Login to Server 4 and run "packstack --install-nova=y
> --keystone-server=server2 --database-server=server1
> --rabbitmq-server=server1"
> (etc)
> 
> This would work, allow multi node without having all the multi node
> logic embedded and handled by Packstack itself.

Doing this would require adding a similar layer of complexity, but in the puppet code instead of python. Right now, we assume that every API service is running on config['CONTROLLER_HOST'], with your proposal we should have the current host, and separate variables (and Hiera processing in python) to have a single variable per service. I think it's a good idea anyway, but I think it wouldn't reduce complexity or any associated CI coverage concerns.

We could take an easier way and assume we only have 3 roles, as in the current refactored code: controller, network, compute. The logic would then be:
  - By default we install everything, so all in one
  - If our host is not CONFIG_CONTROLLER_HOST but is part of CONFIG_NETWORK_HOSTS, we apply the network manifest
  - Same as above if our host is part of CONFIG_COMPUTE_HOSTS

Of course, the last two options would assume a first server is installed as controller.

This would allow us to reuse the same answer file on all runs (one per host as you proposed), eliminate the ssh code as we are always running locally, and make some assumptions in the python code, like expecting OPM to be deployed and such. A contributed ansible wrapper to automate the runs would be straightforward to create.

What do you think? Would it be worth the effort?

Regards,
Javier

> 
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
> 
> dmsimard = [irc, github, twitter]
>