Open Stack

Jay,

Fair question. Native tools do not install bays, the Magnum tools do. Once a bay exists, you can use native tools for native operations to act on if you want. It would be awkward for having two different config defaults within Magnum that are similar, but different for setting up clustered bay types. We already have a solution for CoreOS, and I want the Swarm Bay solution to match that. From a configuration discovery perspective, Swarm and CoreOS are already equivalent. It's just a matter of making a control plane for that purpose that gives cloud operators the ability to not depend on internet based services.

Adrian

> On Apr 16, 2015, at 3:25 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