I agree with Tom to see Magnum as COEDaaS. k8s, swarm, mesos are so different in their architectures that magnum can not provide unified API to user. So I think we should focus on deployment.
Regards, Wanghua On Tue, Sep 29, 2015 at 5:22 PM, Tom Cammann <tom.camm...@hpe.com> wrote: > 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, > > [image: Inactive hide details for Egor Guz ---09/28/2015 10:20:02 > PM---Also I belive docker compose is just command line tool which doe]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> <e...@walmartlabs.com> > To: "openstack-dev@lists.openstack.org" > <openstack-dev@lists.openstack.org> <openstack-dev@lists.openstack.org> > <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 <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 > <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 > <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 <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 > <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:unsubscribehttp://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
