Heh, I just got off the phone with Monty talking about this :) Comments
inline...
On 09/22/2014 03:11 PM, Tim Bell wrote:
The quality designation is really important for the operator
community who are trying to work out what we can give to our end
users.
So, I think it's important to point out here that there are three
different kinds of operators/deployers:
* Ones who use a distribution of OpenStack (RDO, UCA, MOS, Nebula,
Piston, etc)
* Ones who use Triple-O
* Ones who go it alone and install (via source, a mixture of source
and packages, via config management like Chef or Puppet, etc)
In reality, you are referring to the last group, since operators in the
first group are saying "we are relying on a distribution to make
informed choices about what is ready for prime time because we tested
these things together". Operators in the second group are really only HP
right now, AFAICT, and Triple-O's "opinion" on the production readiness
of the things it deploys in the undercloud are roughly equal to "all of
the integrated release that the TC defines".
I personally think that if an operator is choosing to be in the third
group, then they are taking on the responsibility of testing what they
deploy in a staging/test environment in order to validate that it meets
their own requirements. In other words, the onus of determining whether
something is production ready is on their own shoulders. If the operator
chose to deploy OpenStack on top of a vanilla/custom Linux distribution
instead of Red Hat, Ubuntu, OpenSUSE, or whatever, we would not complain
to the Linux kernel community that they have not made quality
designations available for all the pieces we decided to put in our
custom Linux distribution. Likewise, I think that is the role of
OpenStack distributions: the choices and options that the distributor
makes are a result of testing certain things together and the
distributor's opinion of quality. If a deployer of OpenStack chooses to
go it alone and not use an OpenStack distribution, that's totally cool,
but I don't believe it should be the OpenStack developer community's
responsibility to vouch for the production readiness of each component
of OpenStack.
Now, Monty has a big problem with this idea. I know, because he just
told me he does :) Monty thinks this attitude of relying on OpenStack
distributions to make choices about production quality of OpenStack
components leads inevitably to "open core" opportunities, with some
companies choosing to label a few upstream components as production
quality and others (the ones the company developed internally) as their
production quality choices.
I happen to doubt that relying on OpenStack distributions to make these
choices will lead to open core stuff.
Best,
-jay
Offering early helps to establish the real-life experience and give
good feedback on the designs. However, the operator then risks
leaving their users orphaned if the project does not get a
sustainable following or significant disruption if the APIs change.
The packaging teams are key here as well. When do Ubuntu and Red Hat
work out the chain of pre-reqs etc. to produce installable packages,
packstack/juju tool support ?
We do need to have some way to show that an layer #2 package is ready
for prime time production and associated criteria (packages
available, docs available, >1 company communities, models for HA and
scale, …)
Tim
_______________________________________________ OpenStack-dev mailing
list OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
