Open Stack

+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>
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> 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]
> > Sent: November-18-15 1:20 PM
> > To: 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/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/20151119/eceff080/attachment.html>