Thanks everyone who has provided feedback on this thread. The good news is that most of what has been asked for from Magnum is actually in scope already, and some of it has already been implemented. We never aimed to be a COE deployment service. That happens to be a necessity to achieve our more ambitious goal: We want to provide a compelling Containers-as-a-Service solution for OpenStack clouds in a way that offers maximum leverage of what’s already in OpenStack, while giving end users the ability to use their favorite tools to interact with their COE of choice, with the multi-tenancy capability we expect from all OpenStack services, and simplified integration with a wealth of existing OpenStack services (Identity, Orchestration, Images, Networks, Storage, etc.).
The areas we have disagreement are whether the features offered for the k8s COE should be mirrored in other COE’s. We have not attempted to do that yet, and my suggestion is to continue resisting that temptation because it is not aligned with our vision. We are not here to re-invent container management as a hosted service. Instead, we aim to integrate prevailing technology, and make it work great with OpenStack. For example, adding docker-compose capability to Magnum is currently out-of-scope, and I think it should stay that way. With that said, I’m willing to have a discussion about this with the community at our upcoming Summit. An argument could be made for feature consistency among various COE options (Bay Types). I see this as a relatively low value pursuit. Basic features like integration with OpenStack Networking and OpenStack Storage services should be universal. Whether you can present a YAML file for a bay to perform internal orchestration is not important in my view, as long as there is a prevailing way of addressing that need. In the case of Docker Bays, you can simply point a docker-compose client at it, and that will work fine. Thanks, Adrian > On Sep 30, 2015, at 8:58 AM, Devdatta Kulkarni > <[email protected]> wrote: > > +1 Hongbin. > > From perspective of Solum, which hopes to use Magnum for its application > container scheduling > requirements, deep integration of COEs with OpenStack services like Keystone > will be useful. > Specifically, I am thinking that it will be good if Solum can depend on > Keystone tokens to deploy > and schedule containers on the Bay nodes instead of having to use COE > specific credentials. > That way, container resources will become first class components that can be > monitored > using Ceilometer, access controlled using Keystone, and managed from within > Horizon. > > Regards, > Devdatta > > > From: Hongbin Lu <[email protected]> > Sent: Wednesday, September 30, 2015 9:44 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? > > > +1 from me as well. > > I think what makes Magnum appealing is the promise to provide > container-as-a-service. I see coe deployment as a helper to achieve the > promise, instead of the main goal. > > Best regards, > Hongbin > > > From: Jay Lau [mailto:[email protected]] > Sent: September-29-15 10:57 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s? > > > > +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 <[email protected]> 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 > <[email protected]<mailto:[email protected]>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <[email protected]<mailto:[email protected]>> > Date: Tuesday, September 29, 2015 at 08:44 > To: "OpenStack Development Mailing List (not for usage questions)" > <[email protected]<mailto:[email protected]>> > 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) > <[email protected]<mailto:[email protected]>> wrote: > > > +1 > > From: Tom Cammann <[email protected]<mailto:[email protected]>> > Reply-To: > "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>> > Date: Tuesday, September 29, 2015 at 2:22 AM > To: > "[email protected]<mailto:[email protected]>" > <[email protected]<mailto:[email protected]>> > 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 <[email protected]><mailto:[email protected]> > To: > "[email protected]"<mailto:[email protected]> > <[email protected]><mailto:[email protected]> > 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 > <[email protected]<mailto:[email protected]><mailto:[email protected]>> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > <[email protected]<mailto:[email protected]><mailto:[email protected]>> > Date: Monday, September 28, 2015 at 22:03 > To: "OpenStack Development Mailing List (not for usage questions)" > <[email protected]<mailto:[email protected]><mailto:[email protected]>> > 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, 王华 > <[email protected]<mailto:[email protected]><mailto:[email protected]>> > 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: > [email protected]<mailto:[email protected]><mailto:[email protected]>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribe<mailto:[email protected]?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribe<mailto:[email protected]?subject:unsubscribe>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > <ATT00001.gif>__________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > > > Unsubscribe: > [email protected]<mailto:[email protected]>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
