[openstack-dev] [Openstack] [Netstack] [Quantum] Multi-host implementation

Nachi Ueno nachi at nttmcl.com
Mon Aug 13 07:19:19 UTC 2012


Hi Dan

Thanks. OK I'll take the implementation.

> Hua
I really needs the solution you pointed out.
But I couldn't find the solution..
If networks are something like VlanManager or FlatManager in nova-network,
iptables could be one solution.
However, I'm not sure if the network are based on multiple types of
plugins including
openflow solutions..

2012/8/13 Dan Wendlandt <dan at nicira.com>:
>
>
> On Sat, Aug 11, 2012 at 7:51 AM, Nachi Ueno <nachi at nttmcl.com> wrote:
>>
>> Hi Dan
>>
>> How do you think current multi-host design?
>>
>> - Currently, a centralized dhcp agent hosts all dhcp networks as children.
>>
>>
>> https://docs.google.com/presentation/d/1kisLDcWg_Mus5g8QzXMD4w7gWou-3t1drbOKTlYg6MU/edit#slide=id.p9
>>
>> Current Design
>> - To know what network must be on the host where the agent running on,
>> implement get_local_port_ids (Look at the doc page 9)
>> - If an network must be on the host, spawn dhcp service process,
>> otherwise don't do anything.
>
>
> Yes, a design like that makes more sense to me, as we can cut out a lof the
> complexity (I hope).
>
> dan
>
>>
>>
>> https://blueprints.launchpad.net/quantum/+spec/quantum-multihost-dhcp
>>
>> 2012/8/8 MURAOKA Yusuke <yusuke at jbking.org>:
>> > Hi,
>> >
>> > I've updated the bp to correspond with current design spec.
>> >> https://blueprints.launchpad.net/quantum/+spec/quantum-multihost-dhcp
>> >
>> >
>> > I'd know the case of failure, improper, insane, by that.
>> > Anyway, comments, discussions are welcome.
>> >
>> > Thanks.
>> >
>> > --
>> > MURAOKA Yusuke
>> >
>> > Mail: yusuke at jbking.org
>> >
>> >
>> > 日付:2012年8月7日火曜日、時刻:2:47、差出人:Nachi Ueno:
>> >
>> >> Hi Dan
>> >>
>> >> Thank you for pointing this.
>> >>
>> >> Yusuke updated design spec.
>> >> https://blueprints.launchpad.net/quantum/+spec/quantum-multihost-dhcp
>> >>
>> >> 2012/8/6 Dan Wendlandt <dan at nicira.com (mailto:dan at nicira.com)>:
>> >> > Hi Nachi,
>> >> >
>> >> > I've reviewed the code and added comments. I'd like to see at least a
>> >> > basic
>> >> > spec describing the proposed approach (need only be a couple
>> >> > paragraphs,
>> >> > perhaps with a diagram) linked to the blueprint so we can have a
>> >> > design
>> >> > discussion around it. Thanks,
>> >> >
>> >> > Dan
>> >> >
>> >> >
>> >> > On Fri, Aug 3, 2012 at 1:03 PM, Nachi Ueno <nachi at nttmcl.com
>> >> > (mailto:nachi at nttmcl.com)> wrote:
>> >> > >
>> >> > > Hi folks
>> >> > >
>> >> > > Sorry.
>> >> > > I added openstack-dev at lists.openstack.org
>> >> > > (mailto:openstack-dev at lists.openstack.org) in this discussion.
>> >> > >
>> >> > > 2012/8/3 Nati Ueno <nati.ueno at gmail.com
>> >> > > (mailto:nati.ueno at gmail.com)>:
>> >> > > > Hi folks
>> >> > > >
>> >> > > > > Gary
>> >> > > > Thank you for your comment. I wanna discuss your point on the
>> >> > > > mailing
>> >> > > > list.
>> >> > > >
>> >> > > > Yusuke pushed Multi-host implementation for review.
>> >> > > > https://review.openstack.org/#/c/10766/2
>> >> > > > This patch changes only quantum-dhcp-agent side.
>> >> > > >
>> >> > > > Gary's point is we should have host attribute on the port for
>> >> > > > scheduling.
>> >> > > > I agree with Gary.
>> >> > > >
>> >> > > > In the nova, vm has available_zone for scheduling.
>> >> > > > So Instead of using host properties.
>> >> > > > How about use available_zone for port?
>> >> > > >
>> >> > > > Format of availability_zone is something like this
>> >> > > > available_zone="zone_name:host".
>> >> > > >
>> >> > > > We can also add availability_zone attribute for the network as a
>> >> > > > default value of port.
>> >> > > > We can write this until next Monday.
>> >> > > > However I'm not sure quantum community will accept this or not,
>> >> > > > so I'm
>> >> > > > asking here.
>> >> > > >
>> >> > > > If there are no objections, we will push zone version for review.
>> >> > > > Thanks
>> >> > > > Nachi
>> >> > > >
>> >> > > > _______________________________________________
>> >> > > > Mailing list: https://launchpad.net/~openstack
>> >> > > > Post to : openstack at lists.launchpad.net
>> >> > > > (mailto:openstack at lists.launchpad.net)
>> >> > > > Unsubscribe : https://launchpad.net/~openstack
>> >> > > > More help : https://help.launchpad.net/ListHelp
>> >> > >
>> >> > >
>> >> > >
>> >> > > _______________________________________________
>> >> > > OpenStack-dev mailing list
>> >> > > OpenStack-dev at lists.openstack.org
>> >> > > (mailto:OpenStack-dev at lists.openstack.org)
>> >> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >> > Dan Wendlandt
>> >> > Nicira, Inc: www.nicira.com (http://www.nicira.com)
>> >> > twitter: danwendlandt
>> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> >> >
>> >> >
>> >> > --
>> >> > Mailing list: https://launchpad.net/~netstack
>> >> > Post to : netstack at lists.launchpad.net
>> >> > (mailto:netstack at lists.launchpad.net)
>> >> > Unsubscribe : https://launchpad.net/~netstack
>> >> > More help : https://help.launchpad.net/ListHelp
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Mailing list: https://launchpad.net/~openstack
>> >> Post to : openstack at lists.launchpad.net
>> >> (mailto:openstack at lists.launchpad.net)
>> >> Unsubscribe : https://launchpad.net/~openstack
>> >> More help : https://help.launchpad.net/ListHelp
>> >
>> >
>> >
>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>



More information about the OpenStack-dev mailing list