[Openstack-operators] A Hypervisor supporting containers

Chris Friesen chris.friesen at windriver.com
Fri May 2 21:51:50 UTC 2014


On 05/02/2014 02:42 PM, Michael Still wrote:
> On Sat, May 3, 2014 at 6:11 AM, David Kranz <dkranz at redhat.com> wrote:

>> 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.

I worked for a decade in the linux kernel, and one of the key rules was 
to not break userspace.  Here's a quote from Linus Torvalds:

"The biggest thing any program can do is not the technical details of 
the program itself; it’s how useful the program is to users.  So any 
time any program (like the kernel or any other project), breaks the user 
experience, to me, that’s the absolute worst failure that a software 
project can make."

And so you get things like the "dup" family of syscalls, where you have

int dup(int oldfd);
int dup2(int oldfd, int newfd);
int dup3(int oldfd, int newfd, int flags);

where they incrementally add new functionality, but they keep the old 
version around in order to not break userspace code that uses it.

And yes, that means that you need to think *really hard* before adding 
an API call because once it's in you're stuck with it.

On the other hand, internal APIs within the kernel got changed all the 
time.  This was painful for maintainers of out-of-tree code, but the 
linux developers didn't really care--the usual response was to submit it 
into the kernel and you'd get API updates "for free".

Chris



More information about the OpenStack-operators mailing list