openstack team mailing list archive

[Duncan McGreggor <duncan@xxxxxxxxxxxxx>]

On 07 Dec 2011 - 08:22, Mark McLoughlin wrote:
> On Tue, 2011-12-06 at 10:11 -0800, Duncan McGreggor wrote:
> > On 06 Dec 2011 - 14:28, Thierry Carrez wrote:
> > > So the general consensus so far on this discussion seems to be:
> > >
> > > (0) The "2011.3 release" PPA bears false expectations and should be
> > > removed now. In the future, we should not provide such PPAs: 0-day
> > > packages for the release should be available from the "last milestone"
> > > PPA anyway.
> > >
> > > (1) OpenStack, as an upstream project, should focus on development
> > > rather than on providing a production-ready distribution.
> > >
> > > (2) We could provide "daily builds" from the stable/diablo branch for a
> > > variety of releases (much like what we do for the master branch), but
> > > those should be clearly marked "not for production use" and be
> > > best-effort only (like our master branch builds).
> > >
> > > (3) This should not prevent a group in the community from working on a
> > > project providing an "openstack on Lucid" production-ready distribution
> > > if they so wishes. This project would just be another distribution of
> > > OpenStack.
> >
> > This doesn't seem like enough to me. OpenStack isn't just a library;
> > it's a fairly substantial collection of software and services, intended
> > to be used as a product. If it can't be used as a product, what's the
> > use?
> >
> > Someone made the suggestion that a new OpenStack group be started, one
> > whose focus is on producing a production-ready, distribution-ready,
> > release of the software. So can we add one more (need some help with
> > wording, here...):
>
> This paragraph makes it sound like you think OpenStack upstream should
> produce production-ready binary packages?

Nope, just production-ready code. Doing the many things necessary so
that:
 1) when someone wants to build a binary package, they have everything
    that they need to do so;
 2) when the OpenStack components are installed from these packages,
    they run well;
 3) when someone wants to read the documentation for that release, it's
    available, up-to-date, and accurate;
 4) when the unit tests are run for a given release, they all pass on a
    properly configured system (which is documented, supporting #3
    above);
 5) when the next release is out, upgrading is a clear and
    straight-forward process.

The idea is not that these are *all* missing; rather, it appears to me
(and others on this list) that the activities outlined above are not
well-coordinated and/or prioritized.

> > (4) OpenStack will accept and foster a new project, one that is not
> > focused on development, but rather the distribution and it's general
> > stability. This distro project will be responsible for advocating on
> > behalf of various operating systems/distros/sponsoring vendors for bugs
> > that affect performance and stability of OpenStack, or prevent an
> > operating system from running OpenStack.
>
> This sounds like you want want OpenStack to focus more on the quality of
> its releases.

Agreed, but it's not just about QA -- there is a lot involved here. With
lots of different teams. My thought is that if there was an actual point
of contact (person or team) that was responsible for coordinating on the
specific set of areas that were agreed to have the most impact on
creating a production-ready product, operators/users, vendors, etc.,
would have much more confidence in OpenStack as a dependable platform
that business-critical systems could put their trust in.

> It also sounds like you want more co-ordination upstream between
> downstream distributions of OpenStack. I think there's already pretty
> good co-ordination. Is there any specific problem you've seen on that
> front?

I think that if we had something in place like the 5 numbered points
above (and other points that have been mentioned in this thread), such
that an operator could quickly and easily get from 0 to production-ready
in a few short steps, OpenStack would be truly unstoppable. And an
obvious choice for both those with no budget and those with big budgets.

d