[openstack-dev] [magnum]swarm + compose = k8s?
Ryan Rossiter
rlrossit at linux.vnet.ibm.com
Wed Sep 30 14:57:49 UTC 2015
On 9/29/2015 11:00 PM, Monty Taylor wrote:
> *waving hands wildly at details* ...
>
> I believe that the real win is if Magnum's control plan can integrate
> the network and storage fabrics that exist in an OpenStack with
> kube/mesos/swarm. Just deploying is VERY meh. I do not care - it's not
> interesting ... an ansible playbook can do that in 5 minutes. OTOH -
> deploying some kube into a cloud in such a way that it shares a tenant
> network with some VMs that are there - that's good stuff and I think
> actually provides significant value.
+1 on sharing the tenant network with VMs.
When I look at Magnum being an OpenStack project, I see it winning by
integrating itself with the other projects, and to make containers just
work in your cloud. Here's the scenario I would want a cloud with Magnum
to do (though it may be very pie-in-the-sky):
I want to take my container, replicate it across 3 container host VMs
(each of which lives on a different compute host), stick a Neutron LB in
front of it, and hook it up to the same network as my 5 other VMs.
This way, it handles my containers in a service, and integrates
beautifully with my existing OpenStack cloud.
>
> On 09/29/2015 10:57 PM, Jay Lau wrote:
>> +1 to Egor, I think that the final goal of Magnum is container as a
>> service but not coe deployment as a service. ;-)
>>
>> Especially we are also working on Magnum UI, the Magnum UI should export
>> some interfaces to enable end user can create container applications but
>> not only coe deployment.
>>
>> I hope that the Magnum can be treated as another "Nova" which is
>> focusing on container service. I know it is difficult to unify all of
>> the concepts in different coe (k8s has pod, service, rc, swarm only has
>> container, nova only has VM, PM with different hypervisors), but this
>> deserve some deep dive and thinking to see how can move forward.....
>>
>> On Wed, Sep 30, 2015 at 1:11 AM, Egor Guz <EGuz at walmartlabs.com
>> <mailto:EGuz at walmartlabs.com>> wrote:
>>
>> definitely ;), but the are some thoughts to Tom’s email.
>>
>> I agree that we shouldn't reinvent apis, but I don’t think Magnum
>> should only focus at deployment (I feel we will become another
>> Puppet/Chef/Ansible module if we do it ):)
>> I belive our goal should be seamlessly integrate Kub/Mesos/Swarm to
>> OpenStack ecosystem (Neutron/Cinder/Barbican/etc) even if we need to
>> step in to Kub/Mesos/Swarm communities for that.
>>
>> —
>> Egor
>>
>> From: Adrian Otto <adrian.otto at rackspace.com
>> <mailto:adrian.otto at rackspace.com><mailto:adrian.otto at rackspace.com
>> <mailto:adrian.otto at rackspace.com>>>
>> Reply-To: "OpenStack Development Mailing List (not for usage
>> questions)" <openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>>>
>> Date: Tuesday, September 29, 2015 at 08:44
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>>>
>> Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?
>>
>> This is definitely a topic we should cover in Tokyo.
>>
>> On Sep 29, 2015, at 8:28 AM, Daneyon Hansen (danehans)
>> <danehans at cisco.com
>> <mailto:danehans at cisco.com><mailto:danehans at cisco.com
>> <mailto:danehans at cisco.com>>> wrote:
>>
>>
>> +1
>>
>> From: Tom Cammann <tom.cammann at hpe.com
>> <mailto:tom.cammann at hpe.com><mailto:tom.cammann at hpe.com
>> <mailto:tom.cammann at hpe.com>>>
>> Reply-To: "openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>>"
>> <openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>>>
>> Date: Tuesday, September 29, 2015 at 2:22 AM
>> To: "openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>>"
>> <openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>>>
>> Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?
>>
>> This has been my thinking in the last couple of months to completely
>> deprecate the COE specific APIs such as pod/service/rc and
>> container.
>>
>> As we now support Mesos, Kubernetes and Docker Swarm its going to be
>> very difficult and probably a wasted effort trying to consolidate
>> their separate APIs under a single Magnum API.
>>
>> I'm starting to see Magnum as COEDaaS - Container Orchestration
>> Engine Deployment as a Service.
>>
>> On 29/09/15 06:30, Ton Ngo wrote:
>> Would it make sense to ask the opposite of Wanghua's question:
>> should pod/service/rc be deprecated if the user can easily get to
>> the k8s api?
>> Even if we want to orchestrate these in a Heat template, the
>> corresponding heat resources can just interface with k8s instead of
>> Magnum.
>> Ton Ngo,
>>
>> <ATT00001.gif>Egor Guz ---09/28/2015 10:20:02 PM---Also I belive
>> docker compose is just command line tool which doesn’t have any api
>> or scheduling feat
>>
>> From: Egor Guz <EGuz at walmartlabs.com
>> <mailto:EGuz at walmartlabs.com>><mailto:EGuz at walmartlabs.com
>> <mailto:EGuz at walmartlabs.com>>
>> To: "openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>"<mailto:openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>>
>> <openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>><mailto:openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>>
>> Date: 09/28/2015 10:20 PM
>> Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?
>> ________________________________
>>
>>
>>
>> Also I belive docker compose is just command line tool which doesn’t
>> have any api or scheduling features.
>> But during last Docker Conf hackathon PayPal folks implemented
>> docker compose executor for Mesos
>> (https://github.com/mohitsoni/compose-executor)
>> which can give you pod like experience.
>>
>> —
>> Egor
>>
>> From: Adrian Otto <adrian.otto at rackspace.com
>> <mailto:adrian.otto at rackspace.com><mailto:adrian.otto at rackspace.com
>> <mailto:adrian.otto at rackspace.com>><mailto:adrian.otto at rackspace.com
>> <mailto:adrian.otto at rackspace.com>>>
>> Reply-To: "OpenStack Development Mailing List (not for usage
>> questions)" <openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>><mailto:openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>>>
>> Date: Monday, September 28, 2015 at 22:03
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org><mailto:openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>><mailto:openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org>>>
>> Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?
>>
>> Wanghua,
>>
>> I do follow your logic, but docker-compose only needs the docker API
>> to operate. We are intentionally avoiding re-inventing the wheel.
>> Our goal is not to replace docker swarm (or other existing systems),
>> but to compliment it/them. We want to offer users of Docker the
>> richness of native APIs and supporting tools. This way they will not
>> need to compromise features or wait longer for us to implement each
>> new feature as it is added. Keep in mind that our pod, service, and
>> replication controller resources pre-date this philosophy. If we
>> started out with the current approach, those would not exist in
>> Magnum.
>>
>> Thanks,
>>
>> Adrian
>>
>> On Sep 28, 2015, at 8:32 PM, 王华 <wanghua.humble at gmail.com
>> <mailto:wanghua.humble at gmail.com><mailto:wanghua.humble at gmail.com
>> <mailto:wanghua.humble at gmail.com>><mailto:wanghua.humble at gmail.com
>> <mailto:wanghua.humble at gmail.com>>> wrote:
>>
>> Hi folks,
>>
>> Magnum now exposes service, pod, etc to users in kubernetes coe, but
>> exposes container in swarm coe. As I know, swarm is only a scheduler
>> of container, which is like nova in openstack. Docker compose is a
>> orchestration program which is like heat in openstack. k8s is the
>> combination of scheduler and orchestration. So I think it is better
>> to expose the apis in compose to users which are at the same level
>> as k8s.
>>
>>
>> Regards
>> Wanghua
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>> <mailto:OpenStack-dev-request at lists.openstack.org><mailto:OpenStack-dev-request at lists.openstack.org
>> <mailto:OpenStack-dev-request at lists.openstack.org>><mailto:OpenStack-dev-request at lists.openstack.org
>> <mailto:OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><mailto:OpenStack-dev-request at lists.openstack.org
>> <mailto:OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe><mailto:OpenStack-dev-request at lists.openstack.org
>> <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> <ATT00001.gif>__________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>> <mailto:OpenStack-dev-request at lists.openstack.org><mailto:OpenStack-dev-request at lists.openstack.org
>> <mailto:OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> --
>> Thanks,
>>
>> Jay Lau (Guangya Liu)
>>
>>
>> __________________________________________________________________________
>>
>> 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
>>
>
>
> __________________________________________________________________________
>
> 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
--
Thanks,
Ryan Rossiter (rlrossit)
More information about the OpenStack-dev
mailing list