On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard <[email protected]> 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] __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
