+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 <mord...@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 <e...@walmartlabs.com > > <mailto:e...@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.o...@rackspace.com > > <mailto:adrian.o...@rackspace.com><mailto:adrian.o...@rackspace.com > > <mailto:adrian.o...@rackspace.com>>> > > Reply-To: "OpenStack Development Mailing List (not for usage > > questions)" <openstack-dev@lists.openstack.org > > > > <mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org > > <mailto:openstack-dev@lists.openstack.org>>> > > Date: Tuesday, September 29, 2015 at 08:44 > > To: "OpenStack Development Mailing List (not for usage > > questions)" <openstack-dev@lists.openstack.org > > > > <mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org > > <mailto:openstack-dev@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) > > <daneh...@cisco.com > > <mailto:daneh...@cisco.com><mailto:daneh...@cisco.com > > <mailto:daneh...@cisco.com>>> wrote: > > > > > > +1 > > > > From: Tom Cammann <tom.camm...@hpe.com > > <mailto:tom.camm...@hpe.com><mailto:tom.camm...@hpe.com > > <mailto:tom.camm...@hpe.com>>> > > Reply-To: "openstack-dev@lists.openstack.org > > > > <mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org > > <mailto:openstack-dev@lists.openstack.org>>" > > <openstack-dev@lists.openstack.org > > > > <mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org > > <mailto:openstack-dev@lists.openstack.org>>> > > Date: Tuesday, September 29, 2015 at 2:22 AM > > To: "openstack-dev@lists.openstack.org > > > > <mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org > > <mailto:openstack-dev@lists.openstack.org>>" > > <openstack-dev@lists.openstack.org > > > > <mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org > > <mailto:openstack-dev@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 <e...@walmartlabs.com > > <mailto:e...@walmartlabs.com>><mailto:e...@walmartlabs.com > > <mailto:e...@walmartlabs.com>> > > To: "openstack-dev@lists.openstack.org > > > > <mailto:openstack-dev@lists.openstack.org>"<mailto:openstack-dev@lists.openstack.org > > <mailto:openstack-dev@lists.openstack.org>> > > <openstack-dev@lists.openstack.org > > > > <mailto:openstack-dev@lists.openstack.org>><mailto:openstack-dev@lists.openstack.org > > <mailto:openstack-dev@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.o...@rackspace.com > > <mailto:adrian.o...@rackspace.com><mailto:adrian.o...@rackspace.com > > <mailto:adrian.o...@rackspace.com>><mailto:adrian.o...@rackspace.com > > <mailto:adrian.o...@rackspace.com>>> > > Reply-To: "OpenStack Development Mailing List (not for usage > > questions)" <openstack-dev@lists.openstack.org > > > > <mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org > > > > <mailto:openstack-dev@lists.openstack.org>><mailto:openstack-dev@lists.openstack.org > > <mailto:openstack-dev@lists.openstack.org>>> > > Date: Monday, September 28, 2015 at 22:03 > > To: "OpenStack Development Mailing List (not for usage > > questions)" <openstack-dev@lists.openstack.org > > > > <mailto:openstack-dev@lists.openstack.org><mailto:openstack-dev@lists.openstack.org > > > > <mailto:openstack-dev@lists.openstack.org>><mailto:openstack-dev@lists.openstack.org > > <mailto:openstack-dev@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.hum...@gmail.com > > <mailto:wanghua.hum...@gmail.com><mailto:wanghua.hum...@gmail.com > > <mailto:wanghua.hum...@gmail.com>><mailto:wanghua.hum...@gmail.com > > <mailto:wanghua.hum...@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-requ...@lists.openstack.org > > > > <mailto:openstack-dev-requ...@lists.openstack.org><mailto:openstack-dev-requ...@lists.openstack.org > > > > <mailto:openstack-dev-requ...@lists.openstack.org>><mailto:openstack-dev-requ...@lists.openstack.org > > <mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > > > > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe><mailto:openstack-dev-requ...@lists.openstack.org > > <mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > > > > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe><mailto:openstack-dev-requ...@lists.openstack.org > > > > <mailto:openstack-dev-requ...@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-requ...@lists.openstack.org > > > > <mailto:openstack-dev-requ...@lists.openstack.org><mailto:openstack-dev-requ...@lists.openstack.org > > <mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > > <http://openstack-dev-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
