openstack team mailing list archive

[Lew Tucker <lewtucker@xxxxxxxxx>]

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.

-Lew



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 <tomoe@xxxxxxxxxxxx> wrote:
> Hi Dan,
> 
> On Thu, Jul 19, 2012 at 11:58 PM, Dan Wendlandt <dan@xxxxxxxxxx> wrote:
> >
> >
> > On Tue, Jul 17, 2012 at 7:39 PM, Tomoe Sugihara <tomoe@xxxxxxxxxxxx> 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 <sorlando@xxxxxxxxxx>
> >> 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 <gongysh@xxxxxxxxxx>
> >> > Date: 11 July 2012 19:10
> >> > Subject: Re: [Openstack] [Quantum] Public Network spec proposal
> >> > To: Salvatore Orlando <sorlando@xxxxxxxxxx>
> >> > Cc: openstack-dev@xxxxxxxxxxxxxxxxxxx
> >> >
> >> >
> >> > See inline comments.
> >> >
> >> > Thanks
> >> >
> >> >
> >> >
> >> > -----Salvatore Orlando <sorlando@xxxxxxxxxx> wrote: -----
> >> > To: Yong Sheng Gong/China/IBM@IBMCN
> >> > From: Salvatore Orlando <sorlando@xxxxxxxxxx>
> >> > Date: 07/12/2012 09:11AM
> >> > Cc: openstack-dev@xxxxxxxxxxxxxxxxxxx
> >> > 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 <gongysh@xxxxxxxxxx> 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.com@xxxxxxxxxxxxxxxxxxx wrote:
> >> >> -----
> >> >> To: openstack <openstack@xxxxxxxxxxxxxxxxxxx>
> >> >> From: Salvatore Orlando
> >> >> Sent by: openstack-bounces+gongysh=cn.ibm.com@xxxxxxxxxxxxxxxxxxx
> >> >> 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@xxxxxxxxxxxxxxxxxxx
> >> >> Unsubscribe : https://launchpad.net/~openstack
> >> >> More help   : https://help.launchpad.net/ListHelp
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Mailing list: https://launchpad.net/~openstack
> >> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >> > Unsubscribe : https://launchpad.net/~openstack
> >> > More help   : https://help.launchpad.net/ListHelp
> >> >
> >>
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> >> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp