[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