Open Stack

On Thu, Aug 9, 2018 at 2:43 PM, Mohammed Naser <mnaser at vexxhost.com> wrote:
> Hi Alex,
>
> I am very much in favour of what you're bringing up.  We do have
> multiple projects that leverage Ansible in different ways and we all
> end up doing the same thing at the end.  The duplication of work is
> not really beneficial for us as it takes away from our use-cases.
>
> I believe that there is a certain number of steps that we all share
> regardless of how we deploy, some of the things that come up to me
> right away are:
>
> - Configuring infrastructure services (i.e.: create vhosts for service
> in rabbitmq, create databases for services, configure users for
> rabbitmq, db, etc)
> - Configuring inter-OpenStack services (i.e. keystone_authtoken
> section, creating endpoints, etc and users for services)
> - Configuring actual OpenStack services (i.e.
> /etc/<service>/<service>.conf file with the ability of extending
> options)
> - Running CI/integration on a cloud (i.e. common role that literally
> gets an admin user, password and auth endpoint and creates all
> resources and does CI)
>
> This would deduplicate a lot of work, and especially the last one, it
> might be beneficial for more than Ansible-based projects, I can
> imagine Puppet OpenStack leveraging this as well inside Zuul CI
> (optionally)... However, I think that this something which we should
> discus further for the PTG.  I think that there will be a tiny bit
> upfront work as we all standarize but then it's a win for all involved
> communities.
>
> I would like to propose that deployment tools maybe sit down together
> at the PTG, all share how we use Ansible to accomplish these tasks and
> then perhaps we can work all together on abstracting some of these
> concepts together for us to all leverage.
>

I'm currently trying to get a spot on Tuesday morning to further
discuss some of this items.  In the mean time I've started an
etherpad[0] to start collecting ideas for things to discuss.  At the
moment I've got the tempest role collaboration and some basic ideas
for best practice items that we can discuss.  Feel free to add your
own and I'll update the etherpad with a time slot when I get one
nailed down.

Thanks,
-Alex

[0] https://etherpad.openstack.org/p/ansible-collaboration-denver-ptg

> I'll let others chime in as well.
>
> Regards,
> Mohammed
>
> On Thu, Aug 9, 2018 at 4:31 PM, Alex Schultz <aschultz at redhat.com> wrote:
>> Ahoy folks,
>>
>> I think it's time we come up with some basic rules/patterns on where
>> code lands when it comes to OpenStack related Ansible roles and as we
>> convert/export things. There was a recent proposal to create an
>> ansible-role-tempest[0] that would take what we use in
>> tripleo-quickstart-extras[1] and separate it for re-usability by
>> others.   So it was asked if we could work with the openstack-ansible
>> team and leverage the existing openstack-ansible-os_tempest[2].  It
>> turns out we have a few more already existing roles laying around as
>> well[3][4].
>>
>> What I would like to propose is that we as a community come together
>> to agree on specific patterns so that we can leverage the same roles
>> for some of the core configuration/deployment functionality while
>> still allowing for specific project specific customization.  What I've
>> noticed between all the project is that we have a few specific core
>> pieces of functionality that needs to be handled (or skipped as it may
>> be) for each service being deployed.
>>
>> 1) software installation
>> 2) configuration management
>> 3) service management
>> 4) misc service actions
>>
>> Depending on which flavor of the deployment you're using, the content
>> of each of these may be different.  Just about the only thing that is
>> shared between them all would be the configuration management part.
>> To that, I was wondering if there would be a benefit to establishing a
>> pattern within say openstack-ansible where we can disable items #1 and
>> #3 but reuse #2 in projects like kolla/tripleo where we need to do
>> some configuration generation.  If we can't establish a similar
>> pattern it'll make it harder to reuse and contribute between the
>> various projects.
>>
>> In tripleo we've recently created a bunch of ansible-role-tripleo-*
>> repositories which we were planning on moving the tripleo specific
>> tasks (for upgrades, etc) to and were hoping that we might be able to
>> reuse the upstream ansible roles similar to how we've previously
>> leverage the puppet openstack work for configurations.  So for us, it
>> would be beneficial if we could maybe help align/contribute/guide the
>> configuration management and maybe misc service action portions of the
>> openstack-ansible roles, but be able to disable the actual software
>> install/service management as that would be managed via our
>> ansible-role-tripleo-* roles.
>>
>> Is this something that would be beneficial to further discuss at the
>> PTG? Anyone have any additional suggestions/thoughts?
>>
>> My personal thoughts for tripleo would be that we'd have
>> tripleo-ansible calls openstack-ansible-<project> for core config but
>> package/service installation disabled and calls
>> ansible-role-tripleo-<project> for tripleo specific actions such as
>> opinionated packages/service configuration/upgrades.  Maybe this is
>> too complex? But at the same time, do we need to come up with 3
>> different ways to do this?
>>
>> Thanks,
>> -Alex
>>
>> [0] https://review.openstack.org/#/c/589133/
>> [1] http://git.openstack.org/cgit/openstack/tripleo-quickstart-extras/tree/roles/validate-tempest
>> [2] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest/
>> [3] http://git.openstack.org/cgit/openstack/kolla-ansible/tree/ansible/roles/tempest
>> [4] http://git.openstack.org/cgit/openstack/ansible-role-tripleo-tempest
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Mohammed Naser — vexxhost
> -----------------------------------------------------
> D. 514-316-8872
> D. 800-910-1726 ext. 200
> E. mnaser at vexxhost.com
> W. http://vexxhost.com
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev