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). 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
