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
