[Openstack-operators] A Hypervisor supporting containers
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
> 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".
More information about the OpenStack-operators