[openstack-dev] [magnum]swarm + compose = k8s?

Joshua Harlow harlowja at outlook.com
Wed Sep 30 06:52:14 UTC 2015


+1

Pretty please don't make it a deployment project; because really some
other project that just specializes in deployment (ansible, chef,
puppet...) can do that better. I do get how public clouds can find a
deployment project useful (it allows customers to try out these new
~fancy~ COE things), but I also tend to think it's short-term thinking
to believe that such a project will last.

Now an integrated COE <-> openstack (keystone, cinder, neutron...)
project I think really does provide value and has some really neat
possiblities to provide a unique value add to openstack; a project that
can deploy some other software, meh, not so much IMHO. Of course an
integrated COE <-> openstack project will of course be much harder,
especially as the COE projects are not openstack 'native' but nothing
worth doing is easy. I hope that it was known that COE projects are a
new (and rapidly shifting) landscape and the going wasn't going to be
easy when magnum was created; don't lose hope! (I'm cheering for you
guys/gals).

My 2 cents,

Josh

On Wed, 30 Sep 2015 00:00:17 -0400
Monty Taylor <mordred at inaugust.com> 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.
> 
> 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




More information about the OpenStack-dev mailing list