Open Stack

One correction inside:

On 7/27/16, 12:02 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:

>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

Not that I think this discussion is all that productive but it should be
based on facts.  Kolla container images do provide a standardized
consumable ABI and we have claimed such for over two cycles.

Regards
-steve

>
>> ________________________________________
>> 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-ope
>>>nstack/"
>>> 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