Open Stack

Jesse Pretorius <jesse at odyssey4.me> writes:

> Hi everyone,
>
> I find myself wondering whether doing this in reverse would potentially be more useful and less disruptive.
>
> If devstack plugins in service repositories are converted from bash to ansible role(s), then there is potential for OSA to make use of that. This could potentially be a drop-in replacement for devstack by using a #!/bin/ansible (or whatever known path) shebang in a playbook file, or by changing the devstack entry point into a wrapper that runs ansible from a known path.
>
> Using this implementation process would allow a completely independent
> development process for the devstack conversion, and would allow OSA
> to retire its independent role repositories as and when the service’s
> ansible role is ready.

It depends on whether you want to delay the deprecation of devstack
itself until enough services have done that, or if you want to make
NewDevstack (someone should come up with a name for the OSA-based
devstack replacement) consume those existing plugins in parallel with
OSA.

> Using this method would also allow devstack, OSA, triple-o and
> kolla-ansible to consume those ansible roles in whatever way they see
> fit using playbooks which are tailored to their own deployment
> philosophy.

That would be useful.

>
> At the most recent PTG there was a discussion between OSA and kolla-ansible about something like this and the conversation for how that could be done would be to ensure that the roles have a clear set of inputs and outputs, with variables enabling the code paths to key outputs.
>
> My opinion is that the convergence of all Ansible-based deployment tools to use a common set of roles would be advantageous in many ways:
>
> 1. There will be more hands & eyeballs on the deployment code.
> 2. There will be more eyeballs on the reviews for service and deployment code.
> 3. There will be a convergence of developer and operator communities
> on the reviews.

That might make all of this worth it, even if there is no other benefit.

> 4. The deployment code will co-exist with the service code, so changes can be done together.
> 5. Ansible is more pythonic than bash, and using it can likely result in the removal of a bunch of devstack bash libs.
>
> As Doug suggested, this starts with putting together some requirements - for the wrapping frameworks, as well as the component roles. It may be useful to get some sort of representative sample service to put together a PoC on to help figure out these requirements.
>
> I think that this may be useful for the tripleo-ansible team to have a view on, I’ve added the tag to the subject of this email.
>
> Best regards,
>
> Jesse
> IRC: odyssey4me

-- 
Doug