Open Stack

Excerpts from Duncan Thomas's message of 2014-06-16 10:46:12 -0700:
> Hi Clint
> 
> This looks like a special pleading here - all OpenStack projects (or
> 'program' if you prefer - I'm honestly not seeing a difference) have
> bits that they've written quickly and would rather not have to
> maintain, but in order to allow people to make use of them downstream
> have to do that work. Ask the cinder team about how much I try to stay
> on top of any back-compat issues.
> 

I don't just prefer program. It is an entirely different thing:

https://wiki.openstack.org/wiki/Programs

https://wiki.openstack.org/wiki/Governance/NewProjects

> If TripleO is not ready to take up that burden, then IMO it shouldn't
> be an official project. If the bits that make it up are too immature
> to actually be maintained with reasonable guarantees that they won't
> just pull the rug out from any consumers, then their use needs to be
> re-thought. Currently, tripleO enjoys huge benefits from its official
> status, but isn't delivering to that standard. No other project has a
> hope of coming in as an official deployment tool while tripleO holds
> that niche. Despite this, tripleO is barely usable, and doesn't seem
> to be maturing towards taking up the responsibilities that other
> projects have had forced upon them. If it isn't ready for that, should
> it go back to incubation and give some other team or technology a fair
> chance to step up to the plate?
> 

TripleO _isn't_ an official project. It is a program to make OpenStack
deploy itself. This is the same as the infra program, which has a
mission to support development. We're not calling for Zuul to be
integrated into the release, we are just expecting it to keep supporting
the goals of the infra program and OpenStack in general.

What is the "official deployment tool" you mention? There isn't one.
The tool we've been debating is something that enables OpenStack to
be deployed using its own component, Heat, but that is sort of like
oslo-incubator.. it is driving a proof of concept for inclusion into an
official project.

Ironic was spun out very early on because it was clear there was a need
for an integrated project to manage baremetal. This is an example where
pieces used for TripleO have been pushed into the integrated release.

However, Heat already exists, and that is where the responsibility lies
to orchestrate applications. We are driving quite a bit into Heat right
now, with a massive refactor of the core to be more resilient to the
types of challenges a datacenter environment will present. The features
we get from the tripleo_heat_merge pre-processor that is in question
will be the next thing to go into Heat. Expecting us to commit resources
to both of those efforts doesn't make much sense. The program is driving
its mission, and the tools will be incubated and integrated when that
makes sense.

Meanwhile, it turns out OpenStack _is not_ currently able to deploy
itself. Users have to bolt things on, whether it is our tools, or
salt/puppet/chef/ansible artifacts, users cannot use just what is in
OpenStack to deploy OpenStack. But we need to be able to test from one
end to the other while we get things landed in OpenStack.. and so, we
use the pre-release model while we get to a releasable thing.

> I don't want to look like I'm specifically beating on tripleO here,
> but it is the first openstack component I've worked with that seems to
> have this little concern for downstream users *and* no apparent plans
> to fix it.
> 

Which component specifically are you referring to? Our plan, nay,
our mission, is to fix it by pushing the necessary features into the
relevant projects.

Also, we actually take on a _higher_ burden of backward compatibility with
some of our tools that we do want to release. They're not integrated, and
we intend to keep them working with all releases of OpenStack because we
intend to keep their interfaces stable for as long as those interfaces
are relevant. diskimage-builder, os-apply-config, os-collect-config,
os-refresh-config, are all stable, and don't need to be integrated into
the OpenStack release because they're not even OpenStack specific.

> That's without going into all of the other difficulties myself and
> fellow developers have had trying to get involved with tripleO, which
> I'll go into at some other point.
> 

I would be quite interested in any feedback you can give us on how
hard it might be to join the effort. It is a large effort, and I know
new contributors can often get lost in a sea of possibilities if we,
the long time contributors, aren't careful to get them bootstrapped.

> It is possible there are other places with similar problems, but this
> is the first I've run into - I'll call out any others I run into,
> since I think it is important, and discussing it publicly keeps
> everyone honest. If I've got the wrong expectations, I'd at least like
> to have the correction on record.

I do think that there is a misunderstanding that TripleO is some kind
of tool. It is not. It is a program that spans all of OpenStack. We will
be producing the tuskar UI to tie together the OpenStack specific items
for a more user friendly experience. However, AFAICT, everything else
is either intended to be small, stable tools that are forever backward
compatible, or independently useful components of OpenStack itself.