Open Stack

Thanks for the clarity Doug.

Regards
-steve

On 7/28/16, 8:37 AM, "Doug Hellmann" <doug at 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" <jaypipes at 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.Fox at 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev