[OpenStack-Infra] Puppet 4, beaker jobs and the future of our config management

Colleen Murphy colleen at gazlene.net
Tue Jun 20 22:05:27 UTC 2017


On Tue, Jun 20, 2017 at 8:40 PM, Jeremy Stanley <fungi at yuggoth.org> wrote:

> A couple weeks ago during our June 6 Infra team meeting,
> discussion[1] about the state of our Ansible Puppet Apply spec[2]
> morphed into concerns over the languishing state of our Beaker-based
> Puppet module integration test jobs, work needed to prepare for
> Puppet 4 now that Puppet 3 is EOL upstream[3] for the past 6 months,
> and the emergence of several possibly competing/conflicting approved
> and proposed Infra specs:
>
>   * Puppet Module Functional Testing[4]
>   * Puppet 4 Preliminary Testing[5]
>   * Rename and expand Puppet 4 Preliminary Testing[6]
>   * Ansiblify control plane[7]
>
> As the discussion evolved, unanswered questions were raised:
>
>   1. What are we going to do to restore public reporting?
>
>   2. Should we push forward with the changes needed to address
>      bitrot on the nonvoting Beaker-based integration jobs so we can
>      start enforcing them on new changes to all our modules?
>
For what it's worth, good progress was made here recently. I was pleased
with how quickly the team was willing to review and merge fixes for this
accumulated bitrot. If anyone wants to help finish up the rest of them and
make these jobs voting I'd be happy to lend guidance.

To provide some context on these jobs, I recall one of the primary reasons
we chose to use beaker-rspec as our functional testing tool was that it was
consistent with what the rest of the puppet community and Puppet-OpenStack
was doing. It is definitely true that both teams have benefited from being
able to solve common problems together. But I don't think it has helped
attract other puppet contributors, and our existing team is less than
enthusiastic about diving into ruby and rspec when these tests are broken.
Luckily, these tests all have fixture manifests ready to go so it would be
reasonably easy to rip out beaker and replace it with something else.

>
>   3. Is the effort involved in upfitting our existing modules to
>      Puppet 4 worth the effort compared to trying to replace Puppet
>      with Ansible (a likely contentious debate lurking here) which
>      might attract more developer/reviewer focus and interest?
>
A total rewrite is a very costly shot in the dark. We have no way to
measure the potential benefits and detriments until after the work is done,
and it will certainly be a significant amount of work.

In this case, though, we have a lot of ansible experts on the team, and the
rising popularity of ansible in OpenStack and in the rest of the devops
world makes it likely to attract new contributors. Contrarily, while the
whole team is competent with puppet, the general attitude toward it has
been fairly negative, and very few people have any interest in the
ruby/rspec-based functional testing. The puppet experts who have so far
pushed the team from puppet 2 to 3 and to functional testing with
beaker-rspec are no longer dedicated full-time to the Infra team. If
sufficient personpower and enthusiasm can be focused toward a rewrite, that
is probably a good indication that it will be healthier and more
sustainable in the long run than our languishing puppet infrastructure.

>
> The meeting was neither long enough nor an appropriate venue for
> deciding these things, so I agreed to start a thread here on the ML
> where we might be able to hash out our position on them a little
> more effectively and inclusive of the wider community involved.
> Everyone with a vested interest is welcome to weigh in, of course.
>
It is really important to remember that the stakeholders here include not
only the upstream Infra team but also 3rd party CI operators and downstream
infrastructure-as-code consumers. If we move away from puppet, we must
provide these stakeholders with a migration plan. If that, on top of
migrating ourselves, proves to be too difficult, then we shouldn't do it.

I plan to keep putting work into the puppet modules and moving toward
puppet 4. I do honestly believe it is within reach and easier in the short
term than a rewrite. But as this is not part of my day job description,
it's not sustainable in the long term unless more volunteers step up. If we
get more momentum toward an ansible rewrite then I will completely support
it.

Colleen

>
> [1] http://eavesdrop.openstack.org/meetings/infra/2017/infra.
> 2017-06-06-19.03.log.html#l-24
> [2] http://specs.openstack.org/openstack-infra/infra-specs/
> specs/ansible_puppet_apply.html
> [3] https://voxpupuli.org/blog/2016/12/22/putting-down-puppet-3/
> [4] http://specs.openstack.org/openstack-infra/infra-specs/
> specs/puppet-module-functional-testing.html
> [5] http://specs.openstack.org/openstack-infra/infra-specs/
> specs/puppet_4_prelim_testing.html
> [6] https://review.openstack.org/449933
> [7] https://review.openstack.org/469983
> --
> Jeremy Stanley
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20170621/6f318a21/attachment-0001.html>


More information about the OpenStack-Infra mailing list