[openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off

Jay Pipes jaypipes at gmail.com
Wed Jul 27 19:02:07 UTC 2016


On 07/27/2016 01:59 PM, Fox, Kevin M wrote:
> Kolla is providing a public api for docker containers and kubernetes templates though. So its not just a deployment tool issue. Its not specifically rest, but does that matter?

Yes, it matters.

Kolla isn't providing a user-interfacing HTTP API for doing something in 
a cloud. Kolla is providing a prescriptive way of building Docker images 
from a set of Dockerfiles and various configuration file templates. That 
isn't a consumable API. That's a reference manual.

Best,
-jay

> ________________________________________
> From: Jay Pipes [jaypipes at gmail.com]
> Sent: Wednesday, July 27, 2016 10:36 AM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Kolla] [Fuel] [tc] Looks like Mirantis is getting Fuel CCP (docker/k8s) kicked off
>
> On 07/27/2016 10:10 AM, Chris Friesen wrote:
>> On 07/27/2016 09:59 AM, Ed Leafe wrote:
>>> On Jul 27, 2016, at 10:51 AM, Joshua Harlow <harlowja at fastmail.com>
>>> wrote:
>>>
>>>>> Whether to have competing projects in the big tent was debated by
>>>>> the TC
>>>>> at the time and my recollection is that we decided that was a good
>>>>> thing
>>>>> -- if someone wanted to develop a Nova replacement, then let them do it
>>>>> in public with the community. It would either win or lose based on its
>>>>> merits. Why is this not something which can happen here as well?
>>>>
>>>> For real, I (or someone) can start a nova replacement without getting
>>>> rejected (or yelled at or ...) by the TC saying it's a competing
>>>> project??? Wow, this is news to me...
>>>
>>> No, you can’t start a Nova replacement and still call yourself OpenStack.
>>>
>>> The sense I have gotten over the years from the TC is that gratuitous
>>> competition is strongly discouraged.
>>
>> I seem to recall that back during the "big tent" discussion people were
>> talking about allowing competing projects that performed the same task,
>> and letting natural selection decide which one survived.
>>
>> For example, at
>> "http://www.joinfu.com/2014/09/answering-the-existential-question-in-openstack/"
>> Jay Pipes said that being under the big tent should not mean that the
>> project is the only/best way to provide a specific function to OpenStack
>> users.
>>
>> On the other hand, the OpenStack new projects requirements *do*
>> explicitly state that "Where it makes sense, the project cooperates with
>> existing projects rather than gratuitously competing or reinventing the
>> wheel."
>>
>> Maybe it boils down to the definition of "gratuitous" competition.
>
> For the record I think I've always been clear that I don't see
> competition as a bad thing within the OpenStack ecosystem however I have
> always been a proponent of having a *single consistent REST API* for a
> particular service type. I think innovation should happen at the
> implementation layer, but the public HTTP APIs should be collated and
> reviewed for overlap and inconsistencies.
>
> This was why in the past I haven't raised a stink about multiple
> deployment tools, since there was no OpenStack HTTP API for deployment
> of OpenStack itself. But I have absolutely raised concerns over overlap
> of HTTP APIs, like is the case with Monasca and various Telemetry
> project APIs. Again, implementation diversity cool. Public HTTP API
> diversity, not cool.
>
> Best,
> -jay
>
> __________________________________________________________________________
> 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
>
> __________________________________________________________________________
> 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
>



More information about the OpenStack-dev mailing list