Open Stack

@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
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_ves at hotmail.com>
To:	OpenStack Development Mailing List not for usage questions
            <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
To: 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>
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)

__________________________________________________________________________
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151119/5193aa9e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151119/5193aa9e/attachment.gif>