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. - 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 <aschu...@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 <aschu...@redhat.com> wrote: >> On Thu, Aug 9, 2018 at 2:43 PM, Mohammed Naser <mna...@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 <aschu...@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-requ...@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. mna...@vexxhost.com >>> W. http://vexxhost.com >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
