[openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and Manage OpenStack using Kubernetes and Docker

Clint Byrum clint at fewbar.com
Wed Sep 24 07:57:01 UTC 2014


Excerpts from Jay Pipes's message of 2014-09-23 21:38:37 -0700:
> On 09/23/2014 10:29 PM, Steven Dake wrote:
> > There is a deployment program - tripleo is just one implementation.
> 
> Nope, that is not correct. Like it or not (I personally don't), Triple-O 
> is *the* Deployment Program for OpenStack:
> 
> http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml#n284
> 
> Saying Triple-O is just one implementation of a deployment program is 
> like saying Heat is just one implementation of an orchestration program. 
> It isn't. It's *the* implemenation of an orchestration program that has 
> been blessed by the TC:
> 
> http://git.openstack.org/cgit/openstack/governance/tree/reference/programs.yaml#n112
> 

That was written before we learned everything we've learned in the last
12 months. I think it is unfair to simply point to this and imply that
bending or even changing it is not open for discussion.

>  > We
> > went through this with Heat and various projects that want to extend
> > heat (eg Murano) and one big mistake I think Murano folks made was not
> > figuring out where there code would go prior to writing it.  I'm only
> > making a statement as to where I think it should belong.
> 
> Sorry, I have to call you to task on this.
> 
> You think it was a mistake for the Murano folks to "not figure out where 
> the code would go prior to writing it"? For the record, Murano existed 
> nearly 2 years ago, as a response to various customer requests. Having 
> the ability to properly deploy Windows applications like SQL Server and 
> Active Directory into an OpenStack cloud was more important to the 
> Murano developers than trying to predict what the whims of the OpenStack 
> developer and governance model would be months or years down the road.
> 
> Tell me, did any of Heat's code exist prior to deciding to propose it 
> for incubation? Saying that Murano developers should have thought about 
> where their code would live is holding them to a higher standard than 
> any of the other developer communities. Did folks working on 
> disk-image-builder pre-validate with the TC or the mailing list that the 
> dib code would "live in the triple-o program"? No, of course not. It was 
> developed naturally and then placed into the program that fit it best.
> 
> Murano was developed naturally in exactly the same way, and the Murano 
> developers have been nothing but accommodating to every request made of 
> them by the TC (and those requests have been entirely different over the 
> last 18 months, ranging from "split it out" to "just propose another 
> program") and by the PTLs for projects that requested they split various 
> parts of Murano out into existing programs.
> 
> The Murano developers have done no power grab, have deliberately tried 
> to be as community-focused and amenable to all requests as possible, and 
> yet they are treated with disdain by a number of folks in the core Heat 
> developer community, including yourself, Clint and Zane. And honestly, I 
> don't get it... all Murano is doing is generating Heat templates and 
> trying to fill in some pieces that Heat isn't interested in doing. I 
> don't see why there is so much animosity towards a project that has, to 
> my knowledge, acted in precisely the ways that we've asked projects to 
> act in the OpenStack community: with openness, transparency, and 
> community good will.

Disdain is hardly the right word. Disdain implies we don't have any
respect at all for Murano. I cannot speak for others, but I do have
respect. I'm just not interested in Murano.

FWIW, I think what Steven Dake is saying is that he does not want to
end up in the same position Murano is in. I think that is unlikely,
as we're seeing many projects hitting the same wall, which is the cause
for discussing changing how we include or exclude projects.



More information about the OpenStack-dev mailing list