Open Stack

That sounds like great. Keeping simple way for the first implementation also sounds great.
I think I synchronize your explanation for now and I’ll keep up with detail specs and implementation through your branch.
Thanks for your answer!

From: Trey Morris [mailto:trey.morris at rackspace.com]
Sent: Wednesday, February 09, 2011 6:31 AM
To: RDH 桝本 圭(ＩＴアーキ＆セキュ技術)
Cc: openstack at lists.launchpad.net
Subject: Re: [Openstack] Multi-NIC support to Cactus

My original (and simple as paul states) plan for handling it is to allow multiple networks to exist within a project, then for each network a vif will get created on the instance. The network information for those vifs will be placed into the xenstore as part of the process for spawning an instance, and then we'll signal for the agent to set up networking on those vifs from the information in the xenstore.
2011/2/2 <masumotok at nttdata.co.jp<mailto:masumotok at nttdata.co.jp>>
> I know the network service is going to get complicated very quickly but I
> wanted to let everyone know for Cactus, our use case is pretty simple.
Thank you for your explanation. Very helpful.
users(admins?) somehow send a request to nova, and nova insert json strings to xenstore,
then instances can hold more than 2 nics. Single vlans for cactus.
Libvirt(kvm) case may follow the same way.

I probably understand. Thanks!

Kei

-----Original Message-----
From: Paul Voccio [mailto:paul.voccio at rackspace.com<mailto:paul.voccio at rackspace.com>]
Sent: Thursday, February 03, 2011 12:32 AM
To: RDH 桝本 圭(ＩＴアーキ＆セキュ技術); Ewan.Mellor at eu.citrix.com<mailto:Ewan.Mellor at eu.citrix.com>
Cc: openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Subject: Re: [Openstack] Multi-NIC support to Cactus

I wanted to clarify what mult-nic means to us as we're going to implement
it.

Since we use flat networking and we assign the ips to the vms it feels
like it isn't complicated. Someone please correct me if I'm
misunderstanding. We have both public and private networks for the vms.
Since we pick and assign both those addresses out of a range for the
public and private nics we are able to assign a public routable ip to to
the "public" interface and a private RFC1918 address to the "private"
side.

Since we are using XenServer, we do this by putting those addresses in a
json string in xenstore and having an agent read the xenstore and
configure the nics as necessary. Both the public and private nics are on
single vlans.

I know the network service is going to get complicated very quickly but I
wanted to let everyone know for Cactus, our use case is pretty simple.

Paul

On 2/2/11 9:04 AM, "masumotok at nttdata.co.jp<mailto:masumotok at nttdata.co.jp>" <masumotok at nttdata.co.jp<mailto:masumotok at nttdata.co.jp>>
wrote:

>Hello Ewan,
>
>Thanks for your answer. Now it's clear to me.
>
>> I assume that the tenant will not be able to configure any rich network
>> topologies until network-service is done.
>
>Network model topic is big issue and multi-nic issue is also not a small
>issue if we cover "any" network topologies. I'm expecting at first
>thought -
>1. instances can have more than 2 vifs.
>2. cloud user can decide how many vifs instance have.
>3. different vlan can be assigned to vifs.
>4. different security groups can be assigned to vifs.
>5. "vifs are assigned which physical nics" kind of thought is necessary(?)
>Those are just first shallow thought - things can go step by step.
>
>I personally feel that not only model-basis discussion but also
>functionality-based discussion may be good to accelerate better network
>model..
>
>Kindly Regards,
>Kei Masumoto
>
>
>-----Original Message-----
>From: Ewan Mellor [mailto:Ewan.Mellor at eu.citrix.com<mailto:Ewan.Mellor at eu.citrix.com>]
>Sent: Wednesday, February 02, 2011 10:06 PM
>To: RDH 桝本 圭(ＩＴアーキ＆セキュ技術); openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
>Subject: RE: Multi-NIC support to Cactus
>
>That's a good question.  Multi-NIC support could be separated out from
>the rest of the network-service blueprint, but I don't know whether it
>would be useful to do so.
>
>I assume that the tenant will not be able to configure any rich network
>topologies until network-service is done.  If that is true, what else
>would you do with multi-NIC support?  And how do you imagine that it
>would work?
>
>Thanks,
>
>Ewan.
>
>> -----Original Message-----
>> From: openstack-bounces+ewan.mellor=citrix.com<http://citrix.com>@lists.launchpad.net<http://lists.launchpad.net>
>> [mailto:openstack-bounces+ewan.mellor<mailto:openstack-bounces%2Bewan.mellor>=citrix.com<http://citrix.com>@lists.launchpad.net<http://lists.launchpad.net>]
>> On Behalf Of masumotok at nttdata.co.jp<mailto:masumotok at nttdata.co.jp>
>> Sent: 02 February 2011 06:34
>> To: openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
>> Subject: [Openstack] Multi-NIC support to Cactus
>>
>> Hello,
>>
>> Regarding to the blueprint to Cactus,
>> I found 2 blueprints that may be related to multi-NIC.
>> ( I expect instances can have multiple vnic. )
>>
>> 1. <https://blueprints.launchpad.net/nova/+spec/multi-nic>
>> 2. <https://blueprints.launchpad.net/nova/+spec/multinic-libvirt>
>>
>> Q1. New network model topic and multi-nic support topic will be
>> discussed as different topics for Cactus.
>> A new netowk model is deferred to Diablo but multi-NIC support may be
>> included in Cactus, am I following to current discussion?
>>
>> Q2. If so, looking back to discussions till now, multi-nic might be
>> supported to Xenserver and KVM to Cactus?
>> I know we are not sure till any blueprint be approved, my team is
>> curious to KVM multi-nic support.
>>
>> Regards,
>> Kei Masumoto
>>
>> _______________________________________________
>> 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
>_______________________________________________
>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



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse at rackspace.com<mailto:abuse at rackspace.com>, and delete the original message.
Your cooperation is appreciated.

_______________________________________________
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




Confidentiality Notice: This e-mail message (including any attached or

embedded documents) is intended for the exclusive and confidential use of the

individual or entity to which this message is addressed, and unless otherwise

expressly indicated, is confidential and privileged information of Rackspace.

Any dissemination, distribution or copying of the enclosed material is prohibited.

If you receive this transmission in error, please notify us immediately by e-mail

at abuse at rackspace.com, and delete the original message.

Your cooperation is appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110209/127dbfa1/attachment.html>