<div dir="ltr">Thanks Steven, more questions/comments in line.<br><div class="gmail_extra"><br><div class="gmail_quote">2015-01-19 0:11 GMT+08:00 Steven Dake <span dir="ltr"><<a href="mailto:sdake@redhat.com" target="_blank">sdake@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <div>On 01/18/2015 06:39 AM, Jay Lau wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>Thanks Steven, just some questions/comments here:<br>
              <br>
            </div>
            1) For native docker support, do we have some project to
            handle the network? The current native docker support did
            not have any logic for network management, are we going to
            leverage neutron or nova-network just like nova-docker for
            this?<br>
          </div>
        </div>
      </div>
    </blockquote></span>
    We can just use flannel for both these use cases.  One way to
    approach using flannel is that we can expect docker networks will
    always be setup the same way, connecting into a flannel network.<span class=""><br></span></div></blockquote><div>What about introducing neutron/nova-network support for native docker container just like nova-docker? <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>2) For k8s, swarm, we can leverage the scheduler in those
          container management tools, but what about docker native
          support? How to handle resource scheduling for native docker
          containers?<br>
          <br>
        </div>
      </div>
    </blockquote></span>
    I am not clear on how to handle native Docker scheduling if a bay
    has more then one node.  I keep hoping someone in the community will
    propose something that doesn't introduce an agent dependency in the
    OS.<br></div></blockquote><div>My thinking is as this: Add a new scheduler just like what nova/cinder is doing now and then we can migrate to gantt once it become mature, comments?<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <br>
    Regards<br>
    -steve<div><div class="h5"><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">Thanks!<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">2015-01-18 8:51 GMT+08:00 Steven Dake <span dir="ltr"><<a href="mailto:sdake@redhat.com" target="_blank">sdake@redhat.com</a>></span>:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks
            and especially Magnum Core,<br>
            <br>
            Magnum Milestone #1 should released early this coming week. 
            I wanted to kick off discussions around milestone #2 since
            Milestone #1 development is mostly wrapped up.<br>
            <br>
            The milestone #2 blueprints:<br>
            <a href="https://blueprints.launchpad.net/magnum/milestone-2" target="_blank">https://blueprints.launchpad.net/magnum/milestone-2</a><br>
            <br>
            The overall goal of Milestone #1 was to make Magnum usable
            for developers.  The overall goal of Milestone #2 is to make
            Magnum usable by operators and their customers.  To do this
            we are implementing blueprints like multi-tenant,
            horizontal-scale, and the introduction of coreOS in addition
            to Fedora Atomic as a Container uOS.  We are also plan to
            introduce some updates to allow bays to be more scalable. 
            We want bays to scale to more nodes manually (short term),
            as well as automatically (longer term).  Finally we want to
            tidy up some of the nit-picky things about Magnum that none
            of the core developers really like at the moment.  One
            example is the magnum-bay-status blueprint which will
            prevent the creation of pods/services/replicationcontrollers
            until a bay has completed orchestration via Heat.  Our final
            significant blueprint for milestone #2 is the ability to
            launch our supported uOS on bare metal using Nova's Ironic
            plugin and the baremetal flavor.  As always, we want to
            improve our unit testing from what is now 70% to ~80% in the
            next milestone.<br>
            <br>
            Please have a look at the blueprints and feel free to
            comment on this thread or in the blueprints directly.  If
            you would like to see different blueprints tackled during
            milestone #2 that feedback is welcome, or if you think the
            core team[1] is on the right track, we welcome positive
            kudos too.<br>
            <br>
            If you would like to see what we tackled in Milestone #1,
            the code should be tagged and ready to run Tuesday January
            20th.  Master should work well enough now, and the developer
            quickstart guide is mostly correct.<br>
            <br>
            The Milestone #1 bluerpints are here for comparison sake:<br>
            <a href="https://blueprints.launchpad.net/magnum/milestone-1" target="_blank">https://blueprints.launchpad.net/magnum/milestone-1</a><br>
            <br>
            Regards,<br>
            -steve<br>
            <br>
            <br>
            [1] <a href="https://review.openstack.org/#/admin/groups/473,members" target="_blank">https://review.openstack.org/#/admin/groups/473,members</a><br>
            <br>
            __________________________________________________________________________<br>
            OpenStack Development Mailing List (not for usage questions)<br>
            Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
            <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
          </blockquote>
        </div>
        <br>
        <br clear="all">
        <br>
        -- <br>
        <div>
          <div dir="ltr">
            <div>
              <div dir="ltr">
                <div>Thanks,<br>
                  <br>
                </div>
                Jay Lau (Guangya Liu)<br>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Thanks,<br><br></div>Jay Lau (Guangya Liu)<br></div></div></div></div>
</div></div>