Open Stack

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_ves at 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.513 at gmail.com
> To: openstack-dev at 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 <EGuz at 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.otto at rackspace.com<mailto:
> adrian.otto at rackspace.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org
> >>
> Date: Thursday, November 19, 2015 at 10:36
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org<mailto:openstack-dev at 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_ves at hotmail.com<mailto:bharath_ves at 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 at lists.openstack.org<mailto:
> openstack-dev at lists.openstack.org>
> From: wkqwu at cn.ibm.com<mailto:wkqwu at 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: wkqwu at cn.ibm.com<mailto:wkqwu at 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--- at hongin, @adrian I agree with you. So can we go ahea]bharath
> thiruveedula ---19/11/2015 10:31:58 am--- at hongin, @adrian I agree with
> you. So can we go ahead with magnum container-create(delete) ... for
>
> From:  bharath thiruveedula <bharath_ves at hotmail.com<mailto:
> bharath_ves at hotmail.com>>
> To:  OpenStack Development Mailing List not for usage questions <
> openstack-dev at lists.openstack.org<mailto:openstack-dev at 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.513 at gmail.com<mailto:jay.lau.513 at gmail.com>
> To: openstack-dev at lists.openstack.org<mailto:
> openstack-dev at 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.otto at rackspace.com
> <mailto:adrian.otto at 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.lu at huawei.com<mailto:
> hongbin.lu at 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_ves at hotmail.com<mailto:
> bharath_ves at hotmail.com>]
> > Sent: November-18-15 1:20 PM
> > To: openstack-dev at lists.openstack.org<mailto:
> openstack-dev at 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-request at 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-request at 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-request at lists.openstack.org<mailto:
> OpenStack-dev-request at 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-request at lists.openstack.org<mailto:
> OpenStack-dev-request at 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-request at lists.openstack.org<mailto:
> OpenStack-dev-request at 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-request at lists.openstack.org<mailto:
> OpenStack-dev-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,

Jay Lau (Guangya Liu)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151203/bcec0183/attachment.html>