<div dir="ltr"><div>Steven, just filed two bps to trace all the discussions for network and scheduler support for native docker, we can have more discussion there.<br><br><a href="https://blueprints.launchpad.net/magnum/+spec/native-docker-network">https://blueprints.launchpad.net/magnum/+spec/native-docker-network</a><br><a href="https://blueprints.launchpad.net/magnum/+spec/magnum-scheduler-for-docker">https://blueprints.launchpad.net/magnum/+spec/magnum-scheduler-for-docker</a><br><br></div>Another I want to discuss is still network, currently, magnum only support neutron, what about nova-network support?<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-19 0:39 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 09:23 AM, Jay Lau wrote:<br>
</div>
<blockquote type="cite">
<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>
<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><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> <br>
</span></div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br></span>
Does that mean introducing an agent on the uOS? I'd rather not have
agents, since all of these uOS systems have wonky filesystem layouts
and there is not an easy way to customize them, with dib for
example.<span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span>
<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>
</div>
</div>
</div>
</blockquote>
<br></span>
Cool that WFM. Too bad we can't just use gantt out the gate.<br>
<br>
Regards<br>
-steve<div><div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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><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>
<div dir="ltr">
<div>
<div dir="ltr">
<div>Thanks,<br>
<br>
</div>
Jay Lau (Guangya Liu)<br>
</div>
</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>