[Openstack-operators] A Hypervisor supporting containers

Narayan Desai narayan.desai at gmail.com
Sat May 3 21:48:37 UTC 2014

Hey Sean :)

On Fri, May 2, 2014 at 4:15 PM, Sean Dague <sean at dague.net> wrote:

> <snip>
> The immune response is there for a reason.

Agreed. There is good reason. And big downside risk to the project. The
cost of it is a suppression of contributions from people that aren't
incentivised to go the extra mile, operators being a prime example.

Tactically, I'm not sure that I think that functionally gating on
deployment capability in devstack, which is billed as opinionated is the
best idea though.

> At the same time I understand that people do want these things. So how
> do we find a way to keep the upstream code something that's maintained
> and working for people. Plenty of Fedora folks complain devstack is
> always broken on Fedora, and it is, because nothing automatically checks
> that code.
> > Case in point. In the absence of a budget, unit testing is better than
> > not, but integration testing ends up being more important in my
> > experience. The thing that trumps both of them is real experience in
> > actual large scale systems.
> I agree, with a caveat. The real experience captures the state of
> working today. Which is great. It doesn't, however, help us keep things
> working tomorrow.
> There are, currently, 391 patches up for review in Nova, right now. Any
> of those are capable of breaking OpenStack for everyone. Human eyes are
> good, but completely foulable. Human eyes + integration tests are much
> better.

That is fair.

> We should *definitely* also figure out how to get more large sale
> experience injected back in. I think it's clear Summit is not that
> venue, so the next question is where might that venue exist, if it's a
> physical place, or a virtual one. The Linux Foundation addressed this
> sort of issue around Linux with the End Users Summit as a completely
> different kind of gathering event mostly to bridge these divides.
> But maybe a real world event doesn't work well here. What about some
> better format to get operator stories back into the hands of the
> development community. I'd love nothing more than a regular voice/video
> presentation by various operators discussing their installations and
> major pain points, in a level of detail where we could start to figure
> out parts / pieces that can be tackled in the near term (current cycle).

I'm a bit jaded about user stories; I'm not sure it is possible extract the
right information without more of a discussion sort of format.

Lorin Hochstein had a great idea a while ago. He proposed a shadowing
program, where devs spend time with ops folks in person:

Through this discussion, I've started to appreciate the depth of the
(social) scalability challenges you guys are facing. It is pretty likely
that we're hitting amdahl's law one way or another here. What do you think
the limiting factor is?

People keep bringing up the linux kernel "mainline isn't for users"
approach. I think that one of the sticking points for us is that there
isn't any appropriate downstream integration point. We run the ubuntu
releases that we patch at our site. But I wouldn't consider trying to get
code integrated through that path. The reasonable limit for distros is
probably filing bugs, and probably only for bugs as opposed to feature
requests or patches, particularly if you aren't a paying customer.

This has actually a long term issue. We started running the anso packages,
back in the day, and have had this difficult process of picking which bits
to run for a long time. I wonder if it would help to have some set of
releases that are intended for users, with some ability (and effort
allocated from the project side) to triage issues more closely, or maybe
work operator relevant patches through the system. It might be worth a shot
to try building some activities explicitly with hybrid goals.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140503/dfd7dab9/attachment.html>

More information about the OpenStack-operators mailing list