openstack team mailing list archive

["Xu (Simon) Chen" <xchenum@xxxxxxxxx>]

Salvatore,

This is a very interesting concept... I can see it being useful in our
production environments...

I wonder if we can make this a bit more general than "public or
not"... Think about a generic ownership and "mode bits" concept of networks.

For example, the infrastructure owner can create a public network, to your
point, that every tenant can see, plug into, but nothing else. For a
network created by a tenant, it is by default only seen by itself. But it
might be interesting for this tenant to allow other tenants to see or plug
into that network.

What do you think?

Thanks.
-Simon

On Fri, Jul 20, 2012 at 10:24 AM, Lew Tucker <lewtucker@xxxxxxxxx> 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.
>
> -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@lists.launchpad.netwrote:
>> >> >> -----
>> >> >> 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
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>