Open Stack

On 11.9.2018 18:53, Alex Schultz wrote:
> Thanks everyone for coming and chatting.  From the meeting we've had a
> few items where we can collaborate together.
> 
> Here are some specific bullet points:
> 
> - TripleO folks should feel free to propose some minor structural
> changes if they make the integration easier.  TripleO is currently
> investigating what it would look like to pull the keystone ansible
> parts out of tripleo-heat-templates and put it into
> ansible-role-tripleo-keystone.  It would be beneficial to use this
> role as an example for how the os_keystone role can be consumed.

+1, please let's also focus on information flow towards Upgrades squad 
(and collab if needed) as ansible-role-tripleo-keystone is being 
implemented. It sounds like something that might potentially require 
rethinking how updates/upgrades work too. Maybe we could have a spec 
where the solution is described and we can assess/discuss the upgrades 
impact.

Thanks

Jirka

> - The openstack-ansible-tests has some good examples of ansible-lint
> rules that can be used to improve quality
> - Tags could be used to limit the scope of OpenStack Ansible roles,
> but it sounds like including tasks would be a better pattern.
> - Need to establish a pattern for disabling packaging/service
> configurations globally in OpenStack Ansible roles.
> - Shared roles are open for reuse/replacement if something better is
> available (upstream/elsewhere).
> 
> If anyone has any others, feel free to comment.
> 
> Thanks,
> -Alex
> 
> On Mon, Sep 10, 2018 at 10:58 AM, Alex Schultz <aschultz at redhat.com> wrote:
>> 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
> 
> __________________________________________________________________________
> 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
>