Jay, In Paris, we had one spec and zero core.
By the time we hit Vancouver, we will have a few scenarios working with 3 milestones. Come vancouver, We'll definitely know for sure if there is appetite and interest in the community for this set of abstractions and packaging we have currently in progress/proposed in the developer/deployer community. Interesting times as they say :) Thanks, dims On Thu, Apr 16, 2015 at 6:21 PM, Jay Pipes <jaypi...@gmail.com> wrote: > On 04/16/2015 05:29 PM, Adrian Otto wrote: >> >> This approach addresses all three concerns laid out above. The same >> approach should apply both to CoreOS and Swarm Bay so the user >> experience is consistent. > > > So, the above comment got me thinking... why does the user experience need > to be consistent? It's not like developers are going to deploy stuff on > Docker Swarm *and* Fleet/CoreOS *and* Kubernetes. > > Developers who want to deploy on container clusters generally have already > picked one of them -- Mesos, Kubernetes, Docker Swarm, Fleet, etc. What is > the benefit of having an abstraction layer that tries to make the usage of > these different developer tools RESTful and consistent? Why wouldn't the > developer/deployer simply install Kubernetes or Mesos or Docker Swarm in one > or more VMs using Heat/Murano and use the native API of their container > cluster orchestration tool of choice? > > It's a bit like saying that we need to make a SQL-as-a-Service API endpoint > that installs multiple database servers into VMs and offers some ANSI SQL > via REST API service to communicate with multiple database servers. It just > doesn't make any logical sense to me. Database developers want to use the > native APIs of their preferred database server, not some > lowest-common-denominator SQL over REST interface. > > Can someone enlighten me please? > > 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 -- Davanum Srinivas :: https://twitter.com/dims __________________________________________________________________________ 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