[openstack-dev] [magnum] Mesos Conductor patch for review
Hi,As per the discussion in [1], I have pushed patchset [1]. Can you please review the patch. I want to take comments on this patch before I push test cases and container-list operation because there was a discussion on this topic whether to have this or not. (from my previous experience :) ). RegardsBharath T[1]http://lists.openstack.org/pipermail/openstack-dev/2015-December/081818.html[2]https://review.openstack.org/#/c/258860/ __ 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
Re: [openstack-dev] [magnum] Mesos Conductor
Hi Bharath, Sorry for late reply. Below is my opinions. For #1, I am not sure if it is a good idea. Currently, container-create is only supported in swarm bay. Its implementation doesn’t support json file (it supports accepting optional flags and mapping them to “docker create”). Therefore, adding support for json file might not be a good idea, since this behaviour is inconsistent with native tool. For #2, disagree for the same reason. For #3, agree that it is the direction, but disagree for the proposed json file implementation. To be clear, I like the idea of passing a blob of data to Bay’s native API (In particular, k8s/marathon API), but not through the “container” object. Maybe you can create a new action for that. For example: magnum create �Cf FILE (or something similar) Best regards, Hongbin From: bharath thiruveedula [mailto:bharath_...@hotmail.com] Sent: December-01-15 7:49 PM To: OpenStack Development Mailing List not for usage questions Subject: Re: [openstack-dev] [magnum] Mesos Conductor 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<mailto:jay.lau@gmail.com> To: openstack-dev@lists.openstack.org<mailto: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<mailto: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><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: 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><mailto: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><mailto: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><mailto:openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> From: wk...@cn.ibm.com<mailto:wk...@cn.ibm.com><mailto:wk...@cn.ibm.com<mailto:wk...@cn.ibm.com>> Date: Thu, 19 Nov
Re: [openstack-dev] [magnum] Mesos Conductor
Hi Jay, Sorry I just saw your mail. I have pushed the patches for json-file support for client[1] and backend[2]. If the team accepts the support the json file support for container-create, I can link the client patch to your blueprint and you can add patches for other features you mentioned, if you don't mind. And we can discuss about the backend support patch in the meeting. [1]https://review.openstack.org/#/c/252775/ [2]https://review.openstack.org/#/c/252789/ Regards Bharath T On Thu, Dec 3, 2015 at 9:38 AM, Jay Lau <jay.lau@gmail.com> wrote: > 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> adrian.o...@rackspace.com>> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org> 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> 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&g
Re: [openstack-dev] [magnum] Mesos Conductor
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 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 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
Re: [openstack-dev] [magnum] Mesos Conductor
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 command2)Handle JSON input in docker_conductor3)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 RegardsBharath 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
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
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 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 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 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 > >
Re: [openstack-dev] [magnum] Mesos Conductor
+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 e
Re: [openstack-dev] [magnum] Mesos Conductor
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. RegardsBharath T [1]https://goo.gl/f46b4H[2]https://mesosphere.github.io/marathon/docs/application-basics.html To: openstack-dev@lists.openstack.org From: 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 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! 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> To:OpenStack Development Mailing List not for usage questions <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 To: 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> 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> 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] > Sent: November-18-15 1:20 PM > To: open
[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.htmlRegardsBharath T __ 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
Re: [openstack-dev] [magnum] Mesos Conductor
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] Sent: November-18-15 1:20 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [magnum] Mesos Conductor Hi all, I am working on the blueprint [<https://blueprints.launchpad.net/magnum/+spec/mesos-conductor>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/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum] Mesos Conductor
Just want to input more for this topic, I was also thinking more for how we can unify the client interface for Magnum. Currently, the Kubernetes is using "kubectl create" to create all of k8s objects including pod, rc, service, pv, pvc, hpa etc using either yaml, json, yml, stdin file format; The marathon also using yaml, json file to create applications. In my understanding, it is difficult to unify the concept of all COEs but at least seems many COEs are trying to unify the input and output: all using same file format as input and getting same format output. It is a good signal for Magnum and the Magmum can leverage those features to unify the client interface for different COEs. i.e we can use "magnum app create" to create pod, rc, service, pv, pvc even marathon service etc. Just some early thinking from my side... Thanks! On Thu, Nov 19, 2015 at 10:01 AM, Jay Lau <jay.lau@gmail.com> wrote: > +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> > 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> 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] >> > Sent: November-18-15 1:20 PM >> > To: 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 >> > >> __ >> &g
Re: [openstack-dev] [magnum] Mesos Conductor
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> 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] > Sent: November-18-15 1:20 PM > To: 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/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
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. RegardsBharath T Date: Thu, 19 Nov 2015 10:01:35 +0800 From: jay.lau@gmail.com To: 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> 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> 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] > Sent: November-18-15 1:20 PM > To: 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/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
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 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! From: bharath thiruveedula <bharath_...@hotmail.com> To: OpenStack Development Mailing List not for usage questions <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 To: 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> 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> 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] > Sent: November-18-15 1:20 PM > To: 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'
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> 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> 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] > > Sent: November-18-15 1:20 PM > > To: 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/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
