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. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
