[Openstack] [Quantum] Public Network spec proposal
Dan Wendlandt
dan at nicira.com
Fri Jul 20 16:28:32 UTC 2012
On Fri, Jul 20, 2012 at 8:20 AM, Jay Pipes <jaypipes at gmail.com> wrote:
> 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...
>
What Salvatore is proposing now is the "shared with everyone,
no restrictions" model (i.e., what glance calls "public"), and he wanted to
avoid a name that implies that there was any more fine-grained authz
mechanism for sharing. Glance used "public" for this, so the thought was
to copy it, but I agree that "public" has wider connotations in the
networking space, so it would be good to find an alternative if possible.
We use the term "global" for this in the Essex release of Quantum (no name
I've heard quite avoid unintended connotations).
Ideally we would have a better flushed out design for what the general
authz model for sharing networks would be, and then just expose this as a
special "share all" case. That said, supporting this based "share all" use
case is something Quantum already had in Essex, and is a strict requirement
for Folsom, so we will likely have to make a decision on how to expose it
before a full authz design is available.
Dan
>
> 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 <tomoe at midokura.com
> >> <mailto:tomoe at midokura.com>> wrote:
> >>
> >> Hi Dan,
> >>
> >> On Thu, Jul 19, 2012 at 11:58 PM, Dan Wendlandt <dan at nicira.com
> >> <mailto:dan at nicira.com>> wrote:
> >> >
> >> >
> >> > On Tue, Jul 17, 2012 at 7:39 PM, Tomoe Sugihara
> >> <tomoe at midokura.com <mailto:tomoe at 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
> >> <sorlando at nicira.com <mailto:sorlando at 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 <gongysh at cn.ibm.com
> >> <mailto:gongysh at cn.ibm.com>>
> >> >> > Date: 11 July 2012 19:10
> >> >> > Subject: Re: [Openstack] [Quantum] Public Network spec proposal
> >> >> > To: Salvatore Orlando <sorlando at nicira.com
> >> <mailto:sorlando at nicira.com>>
> >> >> > Cc: openstack-dev at lists.openstack.org
> >> <mailto:openstack-dev at lists.openstack.org>
> >> >> >
> >> >> >
> >> >> > See inline comments.
> >> >> >
> >> >> > Thanks
> >> >> >
> >> >> >
> >> >> >
> >> >> > -----Salvatore Orlando <sorlando at nicira.com
> >> <mailto:sorlando at nicira.com>> wrote: -----
> >> >> > To: Yong Sheng Gong/China/IBM at IBMCN
> >> >> > From: Salvatore Orlando <sorlando at nicira.com
> >> <mailto:sorlando at nicira.com>>
> >> >> > Date: 07/12/2012 09:11AM
> >> >> > Cc: openstack-dev at lists.openstack.org
> >> <mailto:openstack-dev at 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 <gongysh at cn.ibm.com
> >> <mailto:gongysh at 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.com at lists.launchpad.net
> >> <mailto:cn.ibm.com at lists.launchpad.net> wrote:
> >> >> >> -----
> >> >> >> To: openstack <openstack at lists.launchpad.net
> >> <mailto:openstack at lists.launchpad.net>>
> >> >> >> From: Salvatore Orlando
> >> >> >> Sent by:
> >> openstack-bounces+gongysh=cn.ibm.com at lists.launchpad.net
> >> <mailto:cn.ibm.com at 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 at lists.launchpad.net
> >> <mailto:openstack at lists.launchpad.net>
> >> >> >> Unsubscribe : https://launchpad.net/~openstack
> >> >> >> More help : https://help.launchpad.net/ListHelp
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > Mailing list: https://launchpad.net/~openstack
> >> >> > Post to : openstack at lists.launchpad.net
> >> <mailto:openstack at lists.launchpad.net>
> >> >> > Unsubscribe : https://launchpad.net/~openstack
> >> >> > More help : https://help.launchpad.net/ListHelp
> >> >> >
> >> >>
> >> >> _______________________________________________
> >> >> Mailing list: https://launchpad.net/~openstack
> >> >> Post to : openstack at lists.launchpad.net
> >> <mailto:openstack at 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 at lists.launchpad.net
> >> <mailto:openstack at lists.launchpad.net>
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help : https://help.launchpad.net/ListHelp
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120720/d0b76b79/attachment.html>
More information about the Openstack
mailing list