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 [jaypi...@gmail.com]
Sent: Wednesday, July 27, 2016 10:36 AM
To: openstack-dev@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 <harlo...@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-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
__________________________________________________________________________
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
