Hi Bharath, Actually I have already filed a bp here: https://blueprints.launchpad.net/magnum/+spec/unify-coe-api ,sorry for the late notify.
We may need some discussion for this in next Week's meeting. I will attend next week's meeting and we can have discussion with team then, hope it is OK. ;-) Thanks! On Wed, Dec 2, 2015 at 8:48 AM, bharath thiruveedula < bharath_...@hotmail.com> wrote: > Hi, > > Sorry I was off for some days because of health issues. > > So I think the work items for this BP[1] are: > > 1)Add support to accept json file in container-create command > 2)Handle JSON input in docker_conductor > 3)Implement mesos conductor for container create,delete and list. > > Correct me if I am wrong. And let me know the process for implementing BP > in magnum. I think we need approval for this BP and then implementation? > > [1]https://blueprints.launchpad.net/magnum/+spec/mesos-conductor > > Regards > Bharath T(tbh) > > > ------------------------------ > Date: Fri, 20 Nov 2015 07:44:49 +0800 > From: jay.lau....@gmail.com > To: openstack-dev@lists.openstack.org > > Subject: Re: [openstack-dev] [magnum] Mesos Conductor > > It's great that we come to some agreement on unifying the client call ;-) > > As i proposed in previous thread, I think that "magnum app-create" may be > better than "magnum create", I want to use "magnum app-create" to > distinguish with "magnum container-create". The "app-create" may also not a > good name as the k8s also have concept of service which is actually not an > app. comments? > > I think we can file a bp for this and it will be a great feature in M > release! > > On Fri, Nov 20, 2015 at 4:59 AM, Egor Guz <e...@walmartlabs.com> wrote: > > +1, I found that 'kubectl create -f FILENAME’ ( > https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/kubectl/kubectl_create.md) > works very well for different type of objects and I think we should try to > use it. > > but I think we should support two use-cases > - 'magnum container-create’, with simple list of options which work for > Swarm/Mesos/Kub. it will be good option for users who just wants to try > containers. > - 'magnum create ’, with file which has Swarm/Mesos/Kub specific payload. > > — > Egor > > From: Adrian Otto <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 > >> > Date: Thursday, November 19, 2015 at 10:36 > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org > >> > Subject: Re: [openstack-dev] [magnum] Mesos Conductor > > I’m open to allowing magnum to pass a blob of data (such as a lump of JSON > or YAML) to the Bay's native API. That approach strikes a balance that’s > appropriate. > > Adrian > > On Nov 19, 2015, at 10:01 AM, bharath thiruveedula < > bharath_...@hotmail.com<mailto:bharath_...@hotmail.com>> wrote: > > Hi, > > At the present scenario, we can have mesos conductor with existing > attributes[1]. Or we can add extra options like 'portMappings', > 'instances', 'uris'[2]. And the other options is to take json file as input > to 'magnum container-create' and dispatch it to corresponding conductor. > And the conductor will handle the json input. Let me know your opinions. > > > Regards > Bharath T > > > > > [1]https://goo.gl/f46b4H > [2]https://mesosphere.github.io/marathon/docs/application-basics.html > ________________________________ > To: openstack-dev@lists.openstack.org<mailto: > openstack-dev@lists.openstack.org> > From: wk...@cn.ibm.com<mailto:wk...@cn.ibm.com> > Date: Thu, 19 Nov 2015 10:47:33 +0800 > Subject: Re: [openstack-dev] [magnum] Mesos Conductor > > @bharath, > > 1) actually, if you mean use container-create(delete) to do on mesos bay > for apps. I am not sure how different the interface between docker > interface and mesos interface. One point that when you introduce that > feature, please not make docker container interface more complicated than > now. I worried that because it would confuse end-users a lot than the > unified benefits. (maybe as optional parameter to pass one json file to > create containers in mesos) > > 2) For the unified interface, I think it need more thoughts, we need not > bring more trouble to end-users to learn new concepts or interfaces, except > we could have more clear interface, but different COES vary a lot. It is > very challenge. > > > > Thanks > > Best Wishes, > > -------------------------------------------------------------------------------- > Kai Qiang Wu (吴开强 Kennan) > IBM China System and Technology Lab, Beijing > > E-mail: wk...@cn.ibm.com<mailto:wk...@cn.ibm.com> > Tel: 86-10-82451647 > Address: Building 28(Ring Building), ZhongGuanCun Software Park, > No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 > > -------------------------------------------------------------------------------- > Follow your heart. You are miracle! > > [Inactive hide details for bharath thiruveedula ---19/11/2015 10:31:58 > am---@hongin, @adrian I agree with you. So can we go ahea]bharath > thiruveedula ---19/11/2015 10:31:58 am---@hongin, @adrian I agree with > you. So can we go ahead with magnum container-create(delete) ... for > > From: bharath thiruveedula <bharath_...@hotmail.com<mailto: > bharath_...@hotmail.com>> > To: OpenStack Development Mailing List not for usage questions < > openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org > >> > Date: 19/11/2015 10:31 am > Subject: Re: [openstack-dev] [magnum] Mesos Conductor > > ________________________________ > > > > @hongin, @adrian I agree with you. So can we go ahead with magnum > container-create(delete) ... for mesos bay (which actually create > mesos(marathon) app internally)? > > @jay, yes we multiple frameworks which are using mesos lib. But the mesos > bay we are creating uses marathon. And we had discussion in irc on this > topic, and I was asked to implement initial version for marathon. And agree > with you to have unified client interface for creating pod,app. > > Regards > Bharath T > > ________________________________ > Date: Thu, 19 Nov 2015 10:01:35 +0800 > From: jay.lau....@gmail.com<mailto:jay.lau....@gmail.com> > To: openstack-dev@lists.openstack.org<mailto: > openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [magnum] Mesos Conductor > > +1. > > One problem I want to mention is that for mesos integration, we cannot > limited to Marathon + Mesos as there are many frameworks can run on top of > Mesos, such as Chronos, Kubernetes etc, we may need to consider more for > Mesos integration as there is a huge eco-system build on top of Mesos. > > On Thu, Nov 19, 2015 at 8:26 AM, Adrian Otto <adrian.o...@rackspace.com > <mailto:adrian.o...@rackspace.com>> wrote: > > Bharath, > > I agree with Hongbin on this. Let’s not expand magnum to deal with apps or > appgroups in the near term. If there is a strong desire to add these > things, we could allow it by having a plugin/extensions interface for the > Magnum API to allow additional COE specific features. Honestly, it’s just > going to be a nuisance to keep up with the various upstreams until they > become completely stable from an API perspective, and no additional changes > are likely. All of our COE’s still have plenty of maturation ahead of them, > so this is the wrong time to wrap them. > > If someone really wants apps and appgroups, (s)he could add that to an > experimental branch of the magnum client, and have it interact with the > marathon API directly rather than trying to represent those resources in > Magnum. If that tool became popular, then we could revisit this topic for > further consideration. > > Adrian > > > On Nov 18, 2015, at 3:21 PM, Hongbin Lu <hongbin...@huawei.com<mailto: > hongbin...@huawei.com>> wrote: > > > > Hi Bharath, > > > > I agree the “container” part. We can implement “magnum container-create > ..” for mesos bay in the way you mentioned. Personally, I don’t like to > introduce “apps” and “appgroups” resources to Magnum, because they are > already provided by native tool [1]. I couldn’t see the benefits to > implement a wrapper API to offer what native tool already offers. However, > if you can point out a valid use case to wrap the API, I will give it more > thoughts. > > > > Best regards, > > Hongbin > > > > [1] https://docs.mesosphere.com/using/cli/marathonsyntax/ > > > > From: bharath thiruveedula [mailto:bharath_...@hotmail.com<mailto: > bharath_...@hotmail.com>] > > Sent: November-18-15 1:20 PM > > To: openstack-dev@lists.openstack.org<mailto: > openstack-dev@lists.openstack.org> > > Subject: [openstack-dev] [magnum] Mesos Conductor > > > > Hi all, > > > > I am working on the blueprint [1]. As per my understanding, we have two > resources/objects in mesos+marathon: > > > > 1)Apps: combination of instances/containers running on multiple hosts > representing a service.[2] > > 2)Application Groups: Group of apps, for example we can have database > application group which consists mongoDB app and MySQL App.[3] > > > > So I think we need to have two resources 'apps' and 'appgroups' in mesos > conductor like we have pod and rc for k8s. And regarding 'magnum container' > command, we can create, delete and retrieve container details as part of > mesos app itself(container = app with 1 instance). Though I think in mesos > case 'magnum app-create ..." and 'magnum container-create ...' will use the > same REST API for both cases. > > > > Let me know your opinion/comments on this and correct me if I am wrong > > > > [1]https://blueprints.launchpad.net/magnum/+spec/mesos-conductor. > > [2]https://mesosphere.github.io/marathon/docs/application-basics.html > > [3]https://mesosphere.github.io/marathon/docs/application-groups.html > > > > > > Regards > > Bharath T > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://lists.openstack.org?subject:unsubscribe>< > http://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?subject:unsubscribe>< > http://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<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<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<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<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://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 > > -- 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