Hi Dan, On Thu, Jul 19, 2012 at 11:58 PM, Dan Wendlandt <d...@nicira.com> wrote: > > > On Tue, Jul 17, 2012 at 7:39 PM, Tomoe Sugihara <to...@midokura.com> wrote: >> >> Hi Salvatore, >> >> I have a few questions regarding your proposal mostly related to L3 >> services. >> I've read in another thread that L3 services are out of Quantum's scope >> for >> Folsom > > > Actually, for Folsom-3 we are working on a blueprint > (https://blueprints.launchpad.net/quantum/+spec/quantum-l3-fwd-nat) to > support the simple L3 and NAT/Floating-IP forwarding available in Nova (plus > a bit more flexibility).
Thanks for the info. This is very good to know. Now I'm assuming that *public* network just as the legacy network still get private IP prefix and they can have floating ip associated. Let me know if I'm missing something. Thanks, Tomoe > > Dan > > >> >> but I'd like to know how this publ networks? >> >> >> - How does VM on public network get internet connectivity? Would it >> get private IP >> first and then floating IP associated with it just as legacy >> nova+quantum network, >> or would public network get public IP connectivity directly? >> >> - What about the non-public networks? Would VMs on non-public >> networks be able to >> get internet connectivity with floating ip and masquerading using >> nova-network? Or >> they wouldn't get internet access because it's not public? >> >> >> 2. How ports in a public network for different tenants are isolated? or >> not isolated at all? >> >> If I understand correctly, ports on the same quantum network should >> get virtual L2 >> connectivity (within a single broadcast domain). So I'm assuming that >> ports on the same network >> are not isolated (unless security groups rules are enforced). >> But shouldn't those port be isolated? If so, wouldn't that cause semantic >> change to quantum network? >> >> >> Cheers, >> Tomoe >> >> On Thu, Jul 12, 2012 at 11:30 AM, Salvatore Orlando <sorla...@nicira.com> >> wrote: >> > Re-including openstack ML in the loop, as several Quantum contributors >> > might >> > not yet be registered to openstack-dev. >> > >> > Apologies for spamming. >> > >> > Salvatore >> > >> > ---------- Forwarded message ---------- >> > From: Yong Sheng Gong <gong...@cn.ibm.com> >> > Date: 11 July 2012 19:10 >> > Subject: Re: [Openstack] [Quantum] Public Network spec proposal >> > To: Salvatore Orlando <sorla...@nicira.com> >> > Cc: openstack-...@lists.openstack.org >> > >> > >> > See inline comments. >> > >> > Thanks >> > >> > >> > >> > -----Salvatore Orlando <sorla...@nicira.com> wrote: ----- >> > To: Yong Sheng Gong/China/IBM@IBMCN >> > From: Salvatore Orlando <sorla...@nicira.com> >> > Date: 07/12/2012 09:11AM >> > Cc: openstack-...@lists.openstack.org >> > Subject: Re: [Openstack] [Quantum] Public Network spec proposal >> > >> > >> > Yong, >> > thanks for your feedback. See my comments inline. >> > >> > Sorry for sending the previous email to the wrong list! >> > Yong, thanks for fixing the recipients. >> > >> > On 11 July 2012 17:38, Yong Sheng Gong <gong...@cn.ibm.com> wrote: >> >> >> >> Hi, >> >> Thanks for the spec >> >> Below is my understanding about it: >> >> >> >> About POST network: >> >> >> >> quantum net-create --tenant_id mynet --public True >> > >> > >> > Sounds correct, but I think that the convention with boolean attributes >> > is >> > that if they're specified on the command line then they're true, >> > otherwise >> > false. >> > so the above command could become: >> > >> > quantum net-create --tenant_id mynet --public >> > [yong sheng gong] As you know, bool has just two values True or False, >> > we >> > should use three logic here, True, False or not specified. >> > True mean we list only public networks, False means we show only private >> > networks, not specified mean we don't care if the network is public or >> > private. >> >> >> >> >> >> About GET networks: >> >> >> >> qantum net-list --tenant_id myid >> >> which should return all the networks owned by myid and public networks. >> >> quantum net-list --tenant_id myid --public True >> >> which should return only public networks. >> >> >> >> quantum net-list --tenant_id myid --public False >> >> which should return the non-public networks owned by myid. >> >> quantum net-list >> >> Which should return only public networks if there is no tenant_id in >> >> context. >> > >> > >> > I am still a bit undecided concerning the CLI syntax for this operation. >> > My current thinking is: >> > >> > quantum net-list --tenant_id myid >> > - return private networks for tenant my_id >> > quantum net-list --public >> > - return public networks (--tenant_id, if specified is ignored). >> > >> > The drawback is that we will need two calls for knowing all the >> > networks, >> > private and public, a tenant has access to. I have a similar dilemma in >> > the >> > filter discussion on the spec. >> > What's your opinion? >> > [yong sheng gong] with my three logics, we need only one call. >> > >> >> >> >> About subnets >> >> >> >> Only the public networks' owner can operate(create/list/show/update) >> >> subnets for public network. >> > >> > >> > Correct >> >> >> >> About create Port >> >> >> >> Public networks' owner can create port normally, I mean they can >> >> specify >> >> fixed_ip, mac and other stuff. >> >> Other tenant can create port under public network but he cannot specify >> >> the fixed_ip, mac. How fixed_ip and mac are populated? >> >> >> >> Are they still allocated auto just the same way when we create the >> >> normal >> >> port? >> > >> > >> > Correct, they are autogenerated. >> > >> >> >> >> I think we can disallow other tenant to create port under public >> >> network. >> >> If they need to use public network's ports, they can get them from >> >> public >> >> network's owner. >> > >> > >> > This would simplify a lot the authZ scenario. I am not sure whether this >> > would work for our use cases. >> > My concerns are: >> > 1) If we restrict port creation to the owner of the network we would >> > probably need the owner to "pre allocate" a number of ports for tenants >> > to >> > use >> > [yong sheng gong] if not pre allocate, the port with specified ip will >> > not >> > work since customer tenant cannot create port with specified ip. >> > 2) We should still allow the PUT operation to normal tenants, as they >> > will >> > set the device_id of the VM they've attached to the port. >> > [yong sheng gong] Yes. PUT is should be allowed on device_id field of >> > port >> > >> > Nevertheless, the proposed change to the design is valuable in my >> > opinion, >> > and I am very keen to hear what the other members of the community think >> > of >> > it. >> > >> >> >> >> So the scenario looks like this: >> >> 1. public owner creates public network >> >> 2. public owner creates subnets under the public network >> >> 3. public owner creates port, with fixed_ip, mac and other stuff >> >> populated. >> >> 4. other tenant asks for using the port under the public network >> >> 5. public owner assigns a port to the customer tenant >> > >> > >> > Do you mean that in this step the ownership of the port object is give >> > to >> > the tenant? >> > [Yong sheng gong] I think ownership is not given up. We just add one >> > more >> > field to record who is using this port. After that the 'quantum >> > port-list >> > --tenant_id' should also have --public options to show ports assigned to >> > the >> > tenant. >> > >> >> >> >> 6. customer tenant associates its instance to the port. At this time, >> >> the >> >> port's devise_id is populated >> >> >> >> With this scenario: >> >> 1. nova integration >> >> we can specify the ports when booting an instance. >> >> so except nova boot --nic net-id=privatenetworkid,ipv4-ip=ip1 >> >> we have nova boot --nic port-id=portid. >> >> where the portid can be a port under a public network and a port under >> >> a >> >> private network. >> >> >> >> Thanks >> >> Yong Sheng Gong >> >> >> >> -----openstack-bounces+gongysh=cn.ibm....@lists.launchpad.net wrote: >> >> ----- >> >> To: openstack <openstack@lists.launchpad.net> >> >> From: Salvatore Orlando >> >> Sent by: openstack-bounces+gongysh=cn.ibm....@lists.launchpad.net >> >> Date: 07/12/2012 06:59AM >> >> Subject: [Openstack] [Quantum] Public Network spec proposal >> >> >> >> >> >> Hi, >> >> >> >> A proposal for the implementation of the public networks feature has >> >> been >> >> published. >> >> It can be reached from the quantum-v2-public-networks blueprint page >> >> [1]. >> >> Feedback is more than welcome! >> >> >> >> Regards, >> >> Salvatore >> >> >> >> [1]: >> >> >> >> https://blueprints.launchpad.net/quantum/+spec/quantum-v2-public-networks >> >> _______________________________________________ >> >> Mailing list: https://launchpad.net/~openstack >> >> Post to : openstack@lists.launchpad.net >> >> Unsubscribe : https://launchpad.net/~openstack >> >> More help : https://help.launchpad.net/ListHelp >> > >> > >> > >> > >> > _______________________________________________ >> > Mailing list: https://launchpad.net/~openstack >> > Post to : openstack@lists.launchpad.net >> > Unsubscribe : https://launchpad.net/~openstack >> > More help : https://help.launchpad.net/ListHelp >> > >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira, Inc: www.nicira.com > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
