Open Stack

Steven, just filed two bps to trace all the discussions for network and
scheduler support for native docker, we can have more discussion there.

https://blueprints.launchpad.net/magnum/+spec/native-docker-network
https://blueprints.launchpad.net/magnum/+spec/magnum-scheduler-for-docker

Another I want to discuss is still network, currently, magnum only support
neutron, what about nova-network support?

2015-01-19 0:39 GMT+08:00 Steven Dake <sdake at redhat.com>:

>  On 01/18/2015 09:23 AM, Jay Lau wrote:
>
> Thanks Steven, more questions/comments in line.
>
> 2015-01-19 0:11 GMT+08:00 Steven Dake <sdake at redhat.com>:
>
>>  On 01/18/2015 06:39 AM, Jay Lau wrote:
>>
>>   Thanks Steven, just some questions/comments here:
>>
>>  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?
>>
>>  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.
>>
> What about introducing neutron/nova-network support for native docker
> container just like nova-docker?
>
>>
>>
> 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.
>
>     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?
>>
>>   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.
>>
> 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?
>
>
> Cool that WFM.  Too bad we can't just use gantt out the gate.
>
> Regards
> -steve
>
>
>
>> Regards
>> -steve
>>
>>
>>  Thanks!
>>
>> 2015-01-18 8:51 GMT+08:00 Steven Dake <sdake at redhat.com>:
>>
>>> Hi folks and especially Magnum Core,
>>>
>>> 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.
>>>
>>> The milestone #2 blueprints:
>>> https://blueprints.launchpad.net/magnum/milestone-2
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> The Milestone #1 bluerpints are here for comparison sake:
>>> https://blueprints.launchpad.net/magnum/milestone-1
>>>
>>> Regards,
>>> -steve
>>>
>>>
>>> [1] https://review.openstack.org/#/admin/groups/473,members
>>>
>>>
>>> __________________________________________________________________________
>>> 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:unsubscribehttp://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:unsubscribehttp://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/20150119/8f470bb0/attachment.html>