Thanks for the clarity Doug. Regards -steve
On 7/28/16, 8:37 AM, "Doug Hellmann" <d...@doughellmann.com> wrote: >Excerpts from Flavio Percoco's message of 2016-07-28 16:43:35 +0200: >> On 28/07/16 04:45 +0000, Steven Dake (stdake) wrote: >> > >> > >> >On 7/27/16, 2:12 PM, "Jay Pipes" <jaypi...@gmail.com> wrote: >> > >> >>On 07/27/2016 04:42 PM, Ed Leafe wrote: >> >>> On Jul 27, 2016, at 2:42 PM, Fox, Kevin M <kevin....@pnnl.gov> >>wrote: >> >>> >> >>>> Its not an "end user" facing thing, but it is an "operator" facing >> >>>>thing. >> >>> >> >>> Well, the end user for Kolla is an operator, no? >> >>> >> >>>> I deploy kolla containers today on non kolla managed systems in >> >>>>production, and rely on that api being consistent. >> >>>> >> >>>> I'm positive I'm not the only operator doing this either. This >>sounds >> >>>>like a consumable api to me. >> >>> >> >>> I don¹t think that an API has to be RESTful to be considered an >> >>>interface for we should avoid duplication. >> >> >> >>Application *Programming* Interface. There's nothing that is being >> >>*programmed* or *called* in Kolla's image definitions. >> >> >> >>What Kolla is/has is not an API. As Stephen said, it's more of an >> >>Application Binary Interface (ABI). It's not really an ABI, though, in >> >>the traditional sense of the term that I'm used to. >> >> >> >>It's an agreed set of package bases, installation >>procedures/directories >> >>and configuration recipes for OpenStack and infrastructure components. >> > >> >Jay, >> > >> >From my perspective, this isn't about ABI proliferation or competition. >> >This is about open public discourse. >> > >> >It is the responsibility of all community members to protect the four >> >opens. >> > >> >Given the intent of fuel-ccp to fully adopt K8S into Fuel described >>here: >> >>>https://techcrunch.com/2016/07/25/openstack-will-soon-be-able-to-run-on- >>>top >> >-of-kubernetes/ >> > >> > >> >It is hard to understand the arguments in the reviews related to "this >>is >> >an experimental project, so its not targeted towards big tent" yet >>Boris >> >wrote in that press release its Fuel's next big thing. >> > >> >I raised the objection early on that a mission statement change was >>needed >> >by Fuel if they wanted to proceed down this path, to which I was told >>K8S >> >support is not going into big tent. >> > >> >As a result of Mirantis's change in mind about fuel-ccp being NOT >> >experimental and being targeted for big tent, I'd like the record set >> >straight in the governance repository since the intentions are being >> >published in the press and the current intentions of this project are >> >public. >> >> If I can be honest, I think this whole thread is not going anywhere >>because it >> just started based on the wrong assumption, the wrong tone and with poor >> wording. I'd have asked for clarifications before demanding changes >>from anyone. >> To me, the way this thread started violates one of principles of our >>community, >> which is assuming good faith. I'll assume good faith now and interpret >>this >> thread as a hope to clarify the goals and intentions of this projects >>and not as >> a way to bluntly point fingers, which is how some people might have >>perceived >> it. > >+1 > >I'm not sure how/why this escalated so quickly. It seems there's some >history between these teams, though. If Kevin's summary of the issues on >the universal containers spec is correct, it seems like there's room for >compromise. That said, I agree with Russell and Flavio that there's also >plenty of room for different implementations in the deployment space, >whether are part of the big tent or not. > >> >> >I could see how people could perceive many violations of the four >>opens in >> >all of the activities related to the fuel-ccp project. We as a >>community >> >value open discourse because we are all intelligent human beings. We >> >value honesty and integrity because trust is the foundation of how our >> >community operates. I feel the best way for Fuel to repair the >>perceived >> >violations of the four opens going forward is to: >> >> I honestly don't see the violation. The fuel team added these repos and >> explicitly said they are not planning to join the tent right now. >>Adding new >> repos called `fuel-blah` won't make those deliverables official. >>Whenever the >> team decides to make these deliverables part of Fuel, they'll have to >>send a >> patch to the governance repo. >> >> So, again, where's the lack of openess? Is it just based on the content >>of the >> press release? I'm mostly asking because I don't personally read press >>releases >> when reviewing patches for the governance repo. I do see the >>inconsistency >> between the press release and what's in the repos/reviews but I in >>those cases, >> the governance repository is the source of truth not the press release. > >Please oh please, let's not start down the path of being driven to >assert that any contributor is being dishonest or lacks integrity >because of the content of press releases. > >> >> >1. Alter the mission statement of fuel to match the reality being >> >published by the press and Mirantis's executive team > >I don't think the mission statement needs to change to make it more >specific. I've tried to work with every team to help them craft a >broad statement that describes what they do without tying them to >implementation details. The current Fuel mission sounds like it is >still accurate, without worrying about whether the deployment is >delivered by system packages, containers, floppy disks, or punch >cards. > >> >2. Include these non-experimental repos in the projects.yaml governance >> >repository >> >> What would have happened if the project names would've been >> "my-super-openstack-container-project"? >> >> Flavio >> > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev