[Openstack-operators] A Hypervisor supporting containers

Michael Still mikal at stillhq.com
Fri May 2 20:42:49 UTC 2014

On Sat, May 3, 2014 at 6:11 AM, David Kranz <dkranz at redhat.com> wrote:

> As a former operator and current qa contributor I agree. Also, we should
> focus on the two issues that started this thread:

I agree. I don't really want to debate these issues for ages either --
I'm just trying to make my stance clear. I would remind people that I
also come from an ops background, having spent six years at Google as
an SRE. So... I really am trying to do what's right for ops people

> 1. What standard of testing should be required for code to be accepted into
> OpenStack?

I think this is where nova has fallen down in the past, and ultimately
what has caused operators pain. What I am hearing from this thread is
that removing features is painful for operators, even if we mark those
features as "less supported" or experimental in some way. I think the
docker driver is an example of this -- it doesn't support all the
tempest operations we expect a hypervisor driver to support, and it
lacked CI testing.

> 2. If existing code does not meet the current standard, should it be tossed
> out of the code base?

The nova PTL doesn't really have any power to compel people to work on
specific things. So, instead, previous PTLs have chosen to remove code
when it doesn't meet our standards by a specified deadline. I think
that's the right response -- I'd much rather be honest with operators
about the quality of a piece of code than pretended everything is fine
when its not. I'm very confused by Matt's response to be honest. On
the one hand he says that removing docker caused him "massive
operational work", but on the other hand he says he wont avoid that
work by running a single command line on whatever host he builds his
local distribution on. I don't see a path forward there.

There's another point there -- the role of distributors is to ease
these transitions and be trusted counsellors to operators. I'm sure
distros are helping their customers who deployed docker with using the
stackforge version. People are more than welcome to avoid distros and
run the code from trunk, but you need to remember when you do that you
are effectively becoming the distro yourself and taking on the roles
traditionally filled by a distro.

Nova has been raising the quality bar we expect from our code. That
will continue to happen, because its the only way to ensure a good
outcome for operators. Sometimes there will be some transition pain,
but I think its worth it long term and we're doing all we can to help
operators through those transitions. Ultimately, I think it matters
that basic functionality doesn't work in all hypervisor drivers -- get
console output and live migration being just two examples. Another
specific example is database drivers -- IBM would like to see a DB2
database driver merge, but we're going to work out how to test such a
thing without access to DB2 servers first.

I think one of the predictable outcomes of all of this is that nova is
becoming more hesitant to merge code which is unproven as a result of
operator pushback when things change. You can therefore expect to see
new hypervisor drivers being required to spend a period of time in
stackforge before they merge with trunk. This is also why code reviews
are taking so long these days, we're holding the code to a much higher
standard than we used to.

Where to from here?

I've already signed up to run an ops session at the summit (reasonable
defaults), and I'm coming to the ops PTL meet and greet. Obviously the
summit is a pretty busy time for me, but I'm happy for people to grab
me in the hallway to chat if that will help, bearing in mind that
sometimes I'm going to be on my way to something and will have to
politely keep moving. There is also an operators session in the nova
track, which is an experiment... Hopefully one that will work out.

I understand that not all operators can come to the summit, so I read
this mailing list and will answer private emails and IRC pings as best
as I am able. If operators can think of other specific tangible ways I
can help I am all ears.


Rackspace Australia

More information about the OpenStack-operators mailing list