<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    This has been my thinking in the last couple of months to completely
    deprecate the COE specific APIs such as pod/service/rc and
    container.<br>
    <br>
    As we now support Mesos, Kubernetes and Docker Swarm its going to be
    very difficult and probably a wasted effort trying to consolidate
    their separate APIs under a single Magnum API. <br>
    <br>
    I'm starting to see Magnum as COEDaaS - Container Orchestration
    Engine Deployment as a Service.<br>
    <br>
    <div class="moz-cite-prefix">On 29/09/15 06:30, Ton Ngo wrote:<br>
    </div>
    <blockquote
      cite="mid:201509290530.t8T5UHfm012967@d01av01.pok.ibm.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>Would it make sense to ask the opposite of Wanghua's question:
        should pod/service/rc be deprecated if the user can easily get
        to the k8s api? <br>
        Even if we want to orchestrate these in a Heat template, the
        corresponding heat resources can just interface with k8s instead
        of Magnum.<br>
        Ton Ngo,<br>
        <br>
        <img src="cid:part1.07020809.04090006@hpe.com" alt="Inactive
          hide details for Egor Guz ---09/28/2015 10:20:02 PM---Also I
          belive docker compose is just command line tool which doe"
          border="0" height="16" width="16"><font color="#424282">Egor
          Guz ---09/28/2015 10:20:02 PM---Also I belive docker compose
          is just command line tool which doesn’t have any api or
          scheduling feat</font><br>
        <br>
        <font color="#5F5F5F" size="2">From: </font><font size="2">Egor
          Guz <a class="moz-txt-link-rfc2396E" href="mailto:EGuz@walmartlabs.com"><EGuz@walmartlabs.com></a></font><br>
        <font color="#5F5F5F" size="2">To: </font><font size="2"><a class="moz-txt-link-rfc2396E" href="mailto:openstack-dev@lists.openstack.org">"openstack-dev@lists.openstack.org"</a>
          <a class="moz-txt-link-rfc2396E" href="mailto:openstack-dev@lists.openstack.org"><openstack-dev@lists.openstack.org></a></font><br>
        <font color="#5F5F5F" size="2">Date: </font><font size="2">09/28/2015
          10:20 PM</font><br>
        <font color="#5F5F5F" size="2">Subject: </font><font size="2">Re:
          [openstack-dev] [magnum]swarm + compose = k8s?</font><br>
      </p>
      <hr style="color:#8091A5; " align="left" noshade="noshade"
        size="2" width="100%"><br>
      <br>
      <br>
      <tt>Also I belive docker compose is just command line tool which
        doesn’t have any api or scheduling features.<br>
        But during last Docker Conf hackathon PayPal folks implemented
        docker compose executor for Mesos (</tt><tt><a
          moz-do-not-send="true"
          href="https://github.com/mohitsoni/compose-executor">https://github.com/mohitsoni/compose-executor</a></tt><tt>)<br>
        which can give you pod like experience.<br>
        <br>
        —<br>
        Egor<br>
        <br>
        From: Adrian Otto <<a class="moz-txt-link-abbreviated" href="mailto:adrian.otto@rackspace.com">adrian.otto@rackspace.com</a><</tt><tt><a
          moz-do-not-send="true" href="mailto:adrian.otto@rackspace.com">mailto:adrian.otto@rackspace.com</a></tt><tt>>><br>
        Reply-To: "OpenStack Development Mailing List (not for usage
        questions)" <<a class="moz-txt-link-abbreviated" href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><</tt><tt><a
          moz-do-not-send="true"
          href="mailto:openstack-dev@lists.openstack.org">mailto:openstack-dev@lists.openstack.org</a></tt><tt>>><br>
        Date: Monday, September 28, 2015 at 22:03<br>
        To: "OpenStack Development Mailing List (not for usage
        questions)" <<a class="moz-txt-link-abbreviated" href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><</tt><tt><a
          moz-do-not-send="true"
          href="mailto:openstack-dev@lists.openstack.org">mailto:openstack-dev@lists.openstack.org</a></tt><tt>>><br>
        Subject: Re: [openstack-dev] [magnum]swarm + compose = k8s?<br>
        <br>
        Wanghua,<br>
        <br>
        I do follow your logic, but docker-compose only needs the docker
        API to operate. We are intentionally avoiding re-inventing the
        wheel. Our goal is not to replace docker swarm (or other
        existing systems), but to compliment it/them. We want to offer
        users of Docker the richness of native APIs and supporting
        tools. This way they will not need to compromise features or
        wait longer for us to implement each new feature as it is added.
        Keep in mind that our pod, service, and replication controller
        resources pre-date this philosophy. If we started out with the
        current approach, those would not exist in Magnum.<br>
        <br>
        Thanks,<br>
        <br>
        Adrian<br>
        <br>
        On Sep 28, 2015, at 8:32 PM, 王华 <<a class="moz-txt-link-abbreviated" href="mailto:wanghua.humble@gmail.com">wanghua.humble@gmail.com</a><</tt><tt><a
          moz-do-not-send="true" href="mailto:wanghua.humble@gmail.com">mailto:wanghua.humble@gmail.com</a></tt><tt>>>
        wrote:<br>
        <br>
        Hi folks,<br>
        <br>
        Magnum now exposes service, pod, etc to users in kubernetes coe,
        but exposes container in swarm coe. As I know, swarm is only a
        scheduler of container, which is like nova in openstack. Docker
        compose is a orchestration program which is like heat in
        openstack. k8s is the combination of scheduler and
        orchestration. So I think it is better to expose the apis in
        compose to users which are at the same level as k8s.<br>
        <br>
        <br>
        Regards<br>
        Wanghua<br>
__________________________________________________________________________<br>
        OpenStack Development Mailing List (not for usage questions)<br>
        Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a><</tt><tt><a
          moz-do-not-send="true"
          href="mailto:OpenStack-dev-request@lists.openstack.org">mailto:OpenStack-dev-request@lists.openstack.org</a></tt><tt>>?subject:unsubscribe<br>
      </tt><tt><a moz-do-not-send="true"
          href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>
__________________________________________________________________________<br>
        OpenStack Development Mailing List (not for usage questions)<br>
        Unsubscribe:
        <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
      </tt><tt><a moz-do-not-send="true"
          href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>
      </tt><br>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>