[openstack-dev] So... why exactly? Was: [magnum] Discovery Mechanism For Swarm Bay

Davanum Srinivas davanum at gmail.com
Thu Apr 16 22:44:37 UTC 2015


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 :)


On Thu, Apr 16, 2015 at 6:21 PM, Jay Pipes <jaypipes at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Davanum Srinivas :: https://twitter.com/dims

More information about the OpenStack-dev mailing list