Open Stack

Robert Collins on Friday, September 26, 2014 3:33 PM wrote:
> On 27 September 2014 09:43, Jay Pipes <jaypipes at gmail.com> 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:   https://wiki.openstack.org/wiki/Governance/CoreCriteria

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 <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev