openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

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