Robert Collins on Friday, September 26, 2014 3:33 PM wrote:
> On 27 September 2014 09:43, Jay Pipes <> wrote:
> > Hi James, thanks for the corrections/explanations. A comment inline
> (and a
> > further question) :)
> > Oh, good to know. Sorry, my information about Triple-O's undercloud
> setup is
> > clearly outdated. I thought that the undercloud was build from source
> > repositories devstack-style. Thanks for hitting me with a cluestick.
> :)
> Thats one installation strategy :).
> >> Even when not installing via a distribution, and either directly
> from
> >> trunk or the integrated release tarballs, I don't know that any
> >> TripleO opinion enters into it. TripleO uses the integrated projects
> >> of OpenStack to deploy an overcloud. In an overcloud, you may see
> >> support for some incubated projects, depending on if there's
> interest
> >> from the community for that support.
> >
> >
> > OK, interesting. So, in summary, Triple-O really doesn't offer much
> of a
> > "this is production-ready" stamp to anything based on whether it
> deploys a
> > project or not. So, operators who deploy with Triple-O would be in
> the
> > "you're on your own" camp from the bulleted list above. Would that be
> a fair
> > statement?
> TripleO upstream doesn't offer a production-ready stamp for the
> workload clouds; for deploy clouds we do - simply because you can't
> use non-production-ready services to do your deploy... some of our
> stamps have substantial caveats today (e.g. Heat) - but they are being
> worked on.
> But then Nova upstream doesn't offer production-ready stamps either.
> Are cells production ready? Instance groups? Or generally any new
> feature?
> *distributions* of TripleO offer production ready stamps.
> RDO offers one
> HP Helion offers one.
> In exactly the same way that distributions offer production stamps
> about Nova, distributions that use TripleO offer production stamps
> about Nova :).
> And I think this is James's point. Your category 2 above saying that
> TripleO is different is just confused: TripleO is a deployment
> architecture [evolving into a set of such], *not* a distribution
> channel. 1 and 3 are distribution channels.

[Rocky] I'd like to make a couple of points; first is how many "commercial 
deployers/operators" would consider any of OpenStack "production ready" and if 
they do, what would that subset actually be? ( a little snarky, but not really)

Second, I'd like to point out that Defcore is attempting to provide guidance 
along these lines, but may be considered a bit more "strict" than a "Production 
Ready" label.  Then again, it may be less strict, depending on test coverage;-)

Check out the scoring criteria here:

In principle, OpenStack functionality has to have been "production tested" with 
a fairly large distribution base, along with a number of other criteria.  As 
defined, it would definitely be a subset of "production ready" but it would be 
a reasonably safe subset that could then be built upon.

Beyond the DefCore criteria, RefStack is heading towards the point where any 
operator could run all of Tempest or any selection of Tempest tests against 
his/her installed cloud and view all the results.  They could even save them to 
do trend analysis.

But, this still begs the question of what is "production ready" especially for 
Open Source code.

Perhaps we need the release notes to be very specific on which APIs, features 
and/or projects are new/radically altered in a specific release. This could 
allow operators to install "Juno release/Icehouse functionality" which would 
theoretically be much better than "Icehouse Release" which is what a lot of 
shops would do, reasoning that Icehouse has been out six months, so the gotchas 
are known and patches have been released to fix the worst issues.  Whereas, I 
think that most people in QA and/or deep in the various projects would say that 
the functionality that was released in Icehouse that also is in Juno would be 
more performant and less buggy than the Icehouse release.

So really, the question might really be:  how do you get deployers who want 
greater stability to actually get it by deploying the current release with past 
release's functionality subset?  And how do you communicate that some of the 
past release's functionality is still not production ready?

Hard problem.  

> -Rob
> --
> Robert Collins <>
> Distinguished Technologist
> HP Converged Cloud
> _______________________________________________
> OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to