[openstack-dev] Thoughts on OpenStack Layers and a Big Tent model

Clint Byrum clint at fewbar.com
Fri Sep 26 22:56:40 UTC 2014


Excerpts from Jay Pipes's message of 2014-09-26 14:43:40 -0700:
> Hi James, thanks for the corrections/explanations. A comment inline (and 
> a further question) :)
> 
> On 09/26/2014 05:35 PM, James Slagle wrote:
> > On Fri, Sep 26, 2014 at 4:50 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> >> 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)
> >
> > I'm not sure TripleO fits in this list. It is not just a collection of
> > prescriptive OpenStack bits used to do a deployment. TripleO is
> > tooling to build OpenStack to deploy OpenStack. You can use whatever
> > "source" (packages, distribution, released tarballs, straight from
> > git) you want to build that OpenStack. TripleO could deploy your first
> > or third bullet item.
> 
> OK, fair point, thanks for that added bit of description.
> 
> >> 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".
> >
> > FWIW, TripleO offers deploying using distributions, by installing from
> > packages from the RDO repositories. There's nothing RDO specific about
> > it though, any packaged OpenStack distribution could be installed with
> > the TripleO tooling. RDO is just likely the most well tested.
> 
> 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. :)
> 
> > 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?

The one thing that builds an overcloud in a prescriptive manner is called
'tripleo-incubator' precisely because we don't believe it is ready to be
called a release. It does focus on testing the integrated release only
though, and so is closer to your original #2. It's just important to
note that this is just our own distribution, and does not fully represent
the whole output of the program.



More information about the OpenStack-dev mailing list