Open Stack

I just realized I booked the room and put it in the etherpad but
forgot to email out the time.

Time: Tuesday 09:00-10:45
Room: Big Thompson

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

Thanks,
-Alex

On Tue, Sep 4, 2018 at 1:03 PM, Alex Schultz <aschultz at redhat.com> wrote:
> 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