Open Stack

On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard <clay.gerrard at gmail.com> wrote:
> Do you think this is an important topic for OpenStack right now?  I'd be
> really interested to hear any *new* insights from the previous PTL of *one*
> of OpenStack's installation automation projects?  What could or should be
> done to reduce the bias/reliance towards a devstack or an
> "openstack-all-in-one" deployment model?  Can or should the TC be the
> champion of the discussion around "how to install" OpenStack?  How much of
> an impact does choices made in *testing* effect the install-ability and
> ease-of-use of OpenStack in general?

I'll bounce on that too.

I think part of the problem is that the OpenStack projects develops
and tests against Devstack and if it works there, they mostly call it
a day.
Sort of exaggerating but I hope you understand.

The reality is that you don't go in production with Devstack.

Users and operators tend to go in production in one of three ways:
1) Manually (ouch) with documentation available on docs.o.o, usually
using packages provided by Debian, Ubuntu or RDO on CentOS
2) Purpose-built "home" made installation layer using high-level
configuration management modules (OSA, Puppet, Chef, etc.), that
install either from source or from distro packages
3) Using actual installers that often wrap around what is provided in
#2 but not exclusively (TripleO, Packstack, Kolla, Fuel, etc.)

The reason why "It worked in Devstack" has become a meme is because
historically, the developer community has not paid a lot of attention
to make sure #1 through #3 still work as a result of their changes.
I've been told numerous times as a maintainer/developer and user of #2
and #3 that I ought to keep up with the release notes if my stuff is
broken.

Thankfully, I think reception to issues/bugs has gotten better over
the course of Newton.
However, it still takes a considerable amount of time to track issues,
sometimes with projects we are not familiar with at all, and get the
required information to file a comprehensible report.

Sometimes the problem is in the project, sometimes in the
configuration management module (i.e, deprecation, non-backwards
compatible change, etc.), sometimes in packaging (RDO/UCA/Debian),
sometimes elsewhere.
This is all very complex.

I like to think we have an excellent test coverage matrix in
puppet-openstack [1] covering both RDO and UCA with multiple projects,
different backends, ipv6, SSL, etc.
We've started levering that coverage in Tempest already where Puppet
has 3 non-voting jobs to help provide input.

I think we could do better and I'm confident we /can/ do better.

[1]: https://github.com/openstack/puppet-openstack-integration#description

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]