[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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.

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.

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)

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.

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]