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