[Openstack] [Quantum] Public Network spec proposal
Jay Pipes
jaypipes at gmail.com
Fri Jul 20 15:20:01 UTC 2012
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 <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
>
More information about the Openstack
mailing list