Open Stack

Its not an "end user" facing thing, but it is an "operator" facing thing.

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.

Thanks,
Kevin
________________________________________
From: Jay Pipes [jaypipes at gmail.com]
Sent: Wednesday, July 27, 2016 12:02 PM
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 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
>

__________________________________________________________________________
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