Open Stack

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'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