openstack team mailing list archive

[Salvatore Orlando <sorlando@xxxxxxxxxx>]

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> <sorlando@xxxxxxxxxx> wrote:
-----
To: Yong Sheng Gong/China/IBM@IBMCN
From: Salvatore Orlando <sorlando@xxxxxxxxxx> <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><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
> **
>