One correction inside: On 7/27/16, 12:02 PM, "Jay Pipes" <jaypi...@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 [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-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-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 __________________________________________________________________________ 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
