On 07/20/2012 10:24 AM, Lew Tucker wrote: > We might want to think a bit about words here. I believe it would be > less confusing to call this something else such as a "shared" network > instead of public. As Salvatore indicates below, this is simply a > network that is "shared among several tenants". A common use case as > given by the blueprint is to allow tenant access to service-provider > created networks. By calling it a public network, many would assume > Internet access. I believe this capability is very important as it > could open up the possibility not only for the service provider but also > for one tenant to offer services to others by allowing multiple tenants > to connect to a shared network without using public IP addresses. > Perhaps for right now, the authZ work could simply support sharing with > "All", but this could be refined later so that the owner of a shared > network could implement finer-grained control such that only certain > tenants (e.g. subscribers) could create ports.
Totally agree here. In Glance, a public image is shared with everyone, no restrictions. "Shared" images are images that have their access shared with one or more image access members. A similar concept seems to apply perfectly here... Best, -jay > > On Jul 19, 2012, at 5:16 PM, Salvatore Orlando 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. >> >> Salvatore >> >> On 19 July 2012 17:03, Tomoe Sugihara <to...@midokura.com >> <mailto:to...@midokura.com>> wrote: >> >> Hi Dan, >> >> On Thu, Jul 19, 2012 at 11:58 PM, Dan Wendlandt <d...@nicira.com >> <mailto:d...@nicira.com>> wrote: >> > >> > >> > On Tue, Jul 17, 2012 at 7:39 PM, Tomoe Sugihara >> <to...@midokura.com <mailto: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 <mailto: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 >> <mailto:gong...@cn.ibm.com>> >> >> > Date: 11 July 2012 19:10 >> >> > Subject: Re: [Openstack] [Quantum] Public Network spec proposal >> >> > To: Salvatore Orlando <sorla...@nicira.com >> <mailto:sorla...@nicira.com>> >> >> > Cc: openstack-...@lists.openstack.org >> <mailto:openstack-...@lists.openstack.org> >> >> > >> >> > >> >> > See inline comments. >> >> > >> >> > Thanks >> >> > >> >> > >> >> > >> >> > -----Salvatore Orlando <sorla...@nicira.com >> <mailto:sorla...@nicira.com>> wrote: ----- >> >> > To: Yong Sheng Gong/China/IBM@IBMCN >> >> > From: Salvatore Orlando <sorla...@nicira.com >> <mailto:sorla...@nicira.com>> >> >> > Date: 07/12/2012 09:11AM >> >> > Cc: openstack-...@lists.openstack.org >> <mailto: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 >> <mailto: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 >> <mailto:cn.ibm....@lists.launchpad.net> wrote: >> >> >> ----- >> >> >> To: openstack <openstack@lists.launchpad.net >> <mailto:openstack@lists.launchpad.net>> >> >> >> From: Salvatore Orlando >> >> >> Sent by: >> openstack-bounces+gongysh=cn.ibm....@lists.launchpad.net >> <mailto: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 >> <mailto: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 >> <mailto: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 >> <mailto:openstack@lists.launchpad.net> >> >> Unsubscribe : https://launchpad.net/~openstack >> >> More help : https://help.launchpad.net/ListHelp >> > >> > >> > >> > >> > -- >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > Dan Wendlandt >> > Nicira, Inc: www.nicira.com <http://www.nicira.com/> >> > twitter: danwendlandt >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> <mailto: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
