On Fri, Jul 20, 2012 at 9:16 AM, Salvatore Orlando <sorla...@nicira.com> wrote: > Indeed, "public" in our context means "shared among several tenants". We are > not dealing with tenant access to the Internet or direct association of VIF > to public IP addresses. > > The basic model is still the 'guest network' model. This blueprint, for > which some code is already available on gerrit, just addresses the authZ > work necessary for ensuring multiple tenants can share the same network > object.
Understood. Thanks for the clear explanation. Tomoe > > Salvatore > > > On 19 July 2012 17:03, Tomoe Sugihara <to...@midokura.com> wrote: >> >> 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
