[Openstack-operators] A Hypervisor supporting containers

Fox, Kevin M Kevin.Fox at pnnl.gov
Fri May 2 22:58:24 UTC 2014

The question of "what" is production ready is what separates distro's. One distro feels the tradeoff should be X, another Y. Operators get to choose which distro to use/place their trust.

Also, once you start going down that path of trying make trunk "production ready" all the time, you will end up with (at least) two "trunks", the stable (distro) one, and the developer's trunk, and you're back to what I was talking about in the first place. If you care about stability, use a distro, if your developing, use trunk. I don't think "production trunk" will work for a huge, moving project like OpenStack. There are just too many players/tradeoffs to be made in a way everyone will be happy with just one solution.

From: Chris Friesen [chris.friesen at windriver.com]
Sent: Friday, May 02, 2014 3:38 PM
To: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] A Hypervisor supporting containers

On 05/02/2014 04:18 PM, Robert Collins wrote:

> I have and remain a huge advocate for trunk being *production ready*,
> because if its not, you're looking at *another* 3-6 months of work
> post release to fix things up. OpenStack is big, with many
> interactions, and if we let things get bad it gets bad very very fast.
> Bad like 'we can't deploy even 30 machines in a Heat cluster' (the
> latest case where something that wasn't tested blew out).

That raises the question of exactly *what* should be production ready.
Openstack has so many options, so many configuration parameters, so many

As an example, some people would argue that ceilometer is currently not
production ready.

I recently stumbled over some stuff because the nova unit tests use
sqlite and the regex matching is different from the "real" databases.
Tempest tests would have caught it, but there were no tempest tests for
that feature.

Has anyone considered having separate validation and release schedules
for each component?  That way someone making a change in nova wouldn't
be affected if someone broke cinder, and vice versa.  As it stands, I've
had trivial patches held up for a week because the automated testing
system was busted.


OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org

More information about the OpenStack-operators mailing list