Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: OpenStack: Dev

Fwd: [Quantum] Public Network spec proposal

 

 

OpenStack dev RSS feed   Index | Next | Previous | View Threaded


sorlando at nicira

Jul 11, 2012, 7:30 PM

Post #1 of 12 (200 views)
Permalink
Fwd: [Quantum] Public Network spec proposal

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>
Date: 11 July 2012 19:10
Subject: Re: [Openstack] [Quantum] Public Network spec proposal
To: Salvatore Orlando <sorlando [at] nicira>
Cc: openstack-dev [at] lists


See inline comments.

Thanks



-----Salvatore Orlando <sorlando [at] nicira> <sorlando [at] nicira> wrote:
-----
To: Yong Sheng Gong/China/IBM [at] IBMC
From: Salvatore Orlando <sorlando [at] nicira> <sorlando [at] nicira>
Date: 07/12/2012 09:11AM
Cc: openstack-dev [at] lists
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> 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 wrote: -----
> To: openstack <openstack [at] lists><openstack [at] lists>
> From: Salvatore Orlando **
> Sent by: openstack-bounces+gongysh=cn.ibm.com [at] lists
> 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
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
> **
>


endre.karlson at gmail

Jul 12, 2012, 4:47 AM

Post #2 of 12 (191 views)
Permalink
Fwd: [Quantum] Public Network spec proposal [In reply to]

Why not just --public or not ? Why do you need --public True ? That just
adds confusion...

Endre.


2012/7/12 Gary Kotton <gkotton [at] redhat>

> **
> Hi,
> 1. Is this also applicable to the agents? Say for example a user wants to
> ensure that a public network is attached to network interface em1 and the
> private network attached to em2. Is this something that will be addressed
> by the blueprint?
> 2. I prefer option #3. This seems to be a cleaner approach for the user
> interface.
> Thanks
> Gary
>
>
> On 07/12/2012 01:52 AM, Salvatore Orlando wrote:
>
> 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
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>


gongysh at cn

Jul 12, 2012, 5:37 AM

Post #3 of 12 (188 views)
Permalink
Fwd: [Quantum] Public Network spec proposal [In reply to]


If we just use one flag, it can represent just two values True or False. If we want to represent three values True, False or not specified, we have to use --public True or --public False or nothing at all.

So it is a three-values logic.


-----openstack-bounces+gongysh=cn.ibm.com [at] lists wrote: -----To: openstack [at] lists
From: Endre Karlson
Sent by: openstack-bounces+gongysh=cn.ibm.com [at] lists
Date: 07/12/2012 07:53PM
Subject: [Openstack] Fwd: [Quantum] Public Network spec proposal

Why not just --public or not ? Why do you need --public True ? That just adds confusion...

Endre.


2012/7/12 Gary Kotton <gkotton [at] redhat>
Hi,
1. Is this also applicable to the agents? Say for example a user wants to ensure that a public network is attached to network interface em1 and the private network attached to em2. Is this something that will be addressed by the blueprint?
2. I prefer option #3. This seems to be a cleaner approach for the user interface.
Thanks
Gary

On 07/12/2012 01:52 AM, Salvatore Orlando wrote:
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"]https://blueprints.launchpad.net/quantum/+spec/quantum-v2-public-networks
_______________________________________________
Mailing list: https://launchpad.net/%7Eopenstack"]https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/%7Eopenstack"]https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/%7Eopenstack"]https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/%7Eopenstack"]https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp



_______________________________________________
Mailing list: https://launchpad.net/%7Eopenstack"]https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/%7Eopenstack"]https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp"]https://help.launchpad.net/ListHelp


sorlando at nicira

Jul 12, 2012, 8:39 AM

Post #4 of 12 (190 views)
Permalink
Re: Fwd: [Quantum] Public Network spec proposal [In reply to]

Thank you again for your feedback.

On the discussion about two or three-way logic, I understand Yong's point
of being able to fetch public and private networks in one call, but I also
I agree with Endre that using a boolean flag for something which is
actually Yes/No/Whatever sounds confusing and is different by what the
Openstack CLI usually does.

Hence, if we have a large agreement on the need of being able to specify
whether we want public networks, private networks or both, I'd go for the
approach #3 in the design proposal, as suggested by Gary, and the CLI
option would became something like --network_type={public|private|both}.

On the agent issue raised by Gary - I'm afraid I don't understand. Gary,
could you please elaborate more?

Regards,
Salvatore

On 12 July 2012 05:37, Yong Sheng Gong <gongysh [at] cn> wrote:

>
> If we just use one flag, it can represent just two values True or False.
> If we want to represent three values True, False or not specified, we have
> to use --public True or --public False or nothing at all.
>
> So it is a three-values logic.
>
>
> -----openstack-bounces+gongysh=cn.ibm.com [at] lists wrote: -----
> To: openstack [at] lists
> From: Endre Karlson **
> Sent by: openstack-bounces+gongysh=cn.ibm.com [at] lists
> Date: 07/12/2012 07:53PM
> Subject: [Openstack] Fwd: [Quantum] Public Network spec proposal
>
>
> Why not just --public or not ? Why do you need --public True ? That just
> adds confusion...
>
> Endre.
>
>
> 2012/7/12 Gary Kotton <gkotton [at] redhat>
>
>> **
>> Hi,
>> 1. Is this also applicable to the agents? Say for example a user wants to
>> ensure that a public network is attached to network interface em1 and the
>> private network attached to em2. Is this something that will be addressed
>> by the blueprint?
>> 2. I prefer option #3. This seems to be a cleaner approach for the user
>> interface.
>> Thanks
>> Gary
>>
>>
>> On 07/12/2012 01:52 AM, Salvatore Orlando wrote:
>>
>> 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
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
> **
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>


gkotton at redhat

Jul 14, 2012, 11:10 PM

Post #5 of 12 (183 views)
Permalink
Re: Fwd: [Quantum] Public Network spec proposal [In reply to]

On 07/12/2012 06:39 PM, Salvatore Orlando wrote:
> Thank you again for your feedback.
>
> On the discussion about two or three-way logic, I understand Yong's
> point of being able to fetch public and private networks in one call,
> but I also I agree with Endre that using a boolean flag for something
> which is actually Yes/No/Whatever sounds confusing and is different by
> what the Openstack CLI usually does.
>
> Hence, if we have a large agreement on the need of being able to
> specify whether we want public networks, private networks or both, I'd
> go for the approach #3 in the design proposal, as suggested by Gary,
> and the CLI option would became something like
> --network_type={public|private|both}.
>
> On the agent issue raised by Gary - I'm afraid I don't understand.
> Gary, could you please elaborate more?

The current implementation of the open source agents makes use of one
network interface with the network isolation being done by vlan tagging.
It may be required that a agent can connect to a public non secure
network and a private secure network. The first layer of network
isolation may be done by the physical network interfaces. The API that
you are proposing enables the quantum service to provide the support,
but what about the agents? Will the agents be able to differentiate
between a private and public network. Taking this further will the
agents be able to assign these networks to different network interfaces.
Maybe it is not in the scope of the work that you are proposing.

Thanks
Gary


>
> Regards,
> Salvatore
>
> On 12 July 2012 05:37, Yong Sheng Gong <gongysh [at] cn
> <mailto:gongysh [at] cn>> wrote:
>
>
> If we just use one flag, it can represent just two values True or
> False. If we want to represent three values True, False or not
> specified, we have to use --public True or --public False or
> nothing at all.
>
> So it is a three-values logic.
>
>
> -----openstack-bounces+gongysh=cn.ibm.com [at] lists
> <mailto:cn.ibm.com [at] lists> wrote: -----
> To: openstack [at] lists
> <mailto:openstack [at] lists>
> From: Endre Karlson
> Sent by: openstack-bounces+gongysh=cn.ibm.com [at] lists
> <mailto:openstack-bounces+gongysh=cn.ibm.com [at] lists>
> Date: 07/12/2012 07:53PM
> Subject: [Openstack] Fwd: [Quantum] Public Network spec proposal
>
>
> Why not just --public or not ? Why do you need --public True ?
> That just adds confusion...
>
> Endre.
>
>
> 2012/7/12 Gary Kotton <gkotton [at] redhat <mailto:gkotton [at] redhat>>
>
> Hi,
> 1. Is this also applicable to the agents? Say for example a
> user wants to ensure that a public network is attached to
> network interface em1 and the private network attached to em2.
> Is this something that will be addressed by the blueprint?
> 2. I prefer option #3. This seems to be a cleaner approach for
> the user interface.
> Thanks
> Gary
>
>
> On 07/12/2012 01:52 AM, Salvatore Orlando wrote:
>> 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
>> <https://launchpad.net/%7Eopenstack>
>>
>> Post to : openstack [at] lists
>> <mailto:openstack [at] lists>
>> Unsubscribe : https://launchpad.net/~openstack
>> <https://launchpad.net/%7Eopenstack>
>> More help : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> Post to : openstack [at] lists
> <mailto:openstack [at] lists>
> Unsubscribe : https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> Post to : openstack [at] lists
> <mailto:openstack [at] lists>
> Unsubscribe : https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> More help : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> Post to : openstack [at] lists
> <mailto:openstack [at] lists>
> Unsubscribe : https://launchpad.net/~openstack
> <https://launchpad.net/%7Eopenstack>
> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp


sorlando at nicira

Jul 17, 2012, 3:04 PM

Post #6 of 12 (169 views)
Permalink
Re: Fwd: [Quantum] Public Network spec proposal [In reply to]

Gary,
I think your are making a very good point here.
It is true that the way in which the proposed design (and related patch in
gerrit) addresses only the 'model' problem at the API layer.
I think it is outside of the scope of this blueprint how the plugins, and
then more specifically their agents, should then react to a "public"
network as opposed to a "private" one.

I reckon Bob's "part II' of the provider network problem is moving in the
right direction for addressing this problem by having an extension that
adds an attribute which will let the plugin implements the network
differently according to their nature (for instance flat vs
tagged). Another approach would be that plugins might leverage the "public"
attribute and automatically activate anti-spoofing rules on interfaces
attached to such networks. In both cases, it is my opinion that we can
address this problem with a separate blueprint.

Salvatore

On 14 July 2012 23:10, Gary Kotton <gkotton [at] redhat> wrote:

> **
> On 07/12/2012 06:39 PM, Salvatore Orlando wrote:
>
> Thank you again for your feedback.
>
> On the discussion about two or three-way logic, I understand Yong's
> point of being able to fetch public and private networks in one call, but I
> also I agree with Endre that using a boolean flag for something which is
> actually Yes/No/Whatever sounds confusing and is different by what the
> Openstack CLI usually does.
>
> Hence, if we have a large agreement on the need of being able to specify
> whether we want public networks, private networks or both, I'd go for the
> approach #3 in the design proposal, as suggested by Gary, and the CLI
> option would became something like --network_type={public|private|both}.
>
> On the agent issue raised by Gary - I'm afraid I don't understand. Gary,
> could you please elaborate more?
>
>
> The current implementation of the open source agents makes use of one
> network interface with the network isolation being done by vlan tagging. It
> may be required that a agent can connect to a public non secure network and
> a private secure network. The first layer of network isolation may be done
> by the physical network interfaces. The API that you are proposing enables
> the quantum service to provide the support, but what about the agents? Will
> the agents be able to differentiate between a private and public network.
> Taking this further will the agents be able to assign these networks to
> different network interfaces. Maybe it is not in the scope of the work that
> you are proposing.
>
> Thanks
> Gary
>
>
>
>
> Regards,
> Salvatore
>
> On 12 July 2012 05:37, Yong Sheng Gong <gongysh [at] cn> wrote:
>
>>
>> If we just use one flag, it can represent just two values True or False.
>> If we want to represent three values True, False or not specified, we have
>> to use --public True or --public False or nothing at all.
>>
>> So it is a three-values logic.
>>
>>
>> -----openstack-bounces+gongysh=cn.ibm.com [at] lists wrote:
>> -----
>> To: openstack [at] lists
>> From: Endre Karlson
>> Sent by: openstack-bounces+gongysh=cn.ibm.com [at] lists
>> Date: 07/12/2012 07:53PM
>> Subject: [Openstack] Fwd: [Quantum] Public Network spec proposal
>>
>>
>> Why not just --public or not ? Why do you need --public True ? That just
>> adds confusion...
>>
>> Endre.
>>
>>
>> 2012/7/12 Gary Kotton <gkotton [at] redhat>
>>
>>> Hi,
>>> 1. Is this also applicable to the agents? Say for example a user wants
>>> to ensure that a public network is attached to network interface em1 and
>>> the private network attached to em2. Is this something that will be
>>> addressed by the blueprint?
>>> 2. I prefer option #3. This seems to be a cleaner approach for the user
>>> interface.
>>> Thanks
>>> Gary
>>>
>>>
>>> On 07/12/2012 01:52 AM, Salvatore Orlando wrote:
>>>
>>> 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
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack [at] lists
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>


sorlando at nicira

Jul 17, 2012, 3:12 PM

Post #7 of 12 (175 views)
Permalink
Re: Fwd: [Quantum] Public Network spec proposal [In reply to]

Yong,

Regarding the comments you had on whether the owner of the public network
should own the ports attached on it as well, and kind of 'assign' them to
other tenants.
Although I recognize this as a viable approach, I do believe an approach in
which a tenant actually still owns the port even if it is on a public
network leads to a simpler model, as we won't need to add any attribute to
the existing model classes, and operations will still have the current
semantics. With the other approach, for instance, we would need to add an
attribute to port (something like 'assigned_to') and change the semantics
of index for ports in a way such that if net-id was a public network id it
should have returned the ports for which assigned-to matched the tenant,
instead of tenant-id.

On another note, the proposed approach allows for making the actual policy
enforce completely configurable. For instance, while by default we disallow
manipulation of mac and ips on public networks, the quantum admin can
change the policy by editing policy.json.
Similarly, the quantum administrators can decide that only a given subset
of users can plug VIFs into public networks, and it might also give to some
particular users, say "power users" the power of creating public networks.

Regards,
Salvatore

[.fwd to openstack-dev - please ensure it is kept in the recipient list]





On 17 July 2012 15:04, Salvatore Orlando <sorlando [at] nicira> wrote:

> Gary,
> I think your are making a very good point here.
> It is true that the way in which the proposed design (and related patch in
> gerrit) addresses only the 'model' problem at the API layer.
> I think it is outside of the scope of this blueprint how the plugins, and
> then more specifically their agents, should then react to a "public"
> network as opposed to a "private" one.
>
> I reckon Bob's "part II' of the provider network problem is moving in the
> right direction for addressing this problem by having an extension that
> adds an attribute which will let the plugin implements the network
> differently according to their nature (for instance flat vs
> tagged). Another approach would be that plugins might leverage the "public"
> attribute and automatically activate anti-spoofing rules on interfaces
> attached to such networks. In both cases, it is my opinion that we can
> address this problem with a separate blueprint.
>
> Salvatore
>
> On 14 July 2012 23:10, Gary Kotton <gkotton [at] redhat> wrote:
>
>> **
>> On 07/12/2012 06:39 PM, Salvatore Orlando wrote:
>>
>> Thank you again for your feedback.
>>
>> On the discussion about two or three-way logic, I understand Yong's
>> point of being able to fetch public and private networks in one call, but I
>> also I agree with Endre that using a boolean flag for something which is
>> actually Yes/No/Whatever sounds confusing and is different by what the
>> Openstack CLI usually does.
>>
>> Hence, if we have a large agreement on the need of being able to
>> specify whether we want public networks, private networks or both, I'd go
>> for the approach #3 in the design proposal, as suggested by Gary, and the
>> CLI option would became something like --network_type={public|private|both}.
>>
>> On the agent issue raised by Gary - I'm afraid I don't understand.
>> Gary, could you please elaborate more?
>>
>>
>> The current implementation of the open source agents makes use of one
>> network interface with the network isolation being done by vlan tagging. It
>> may be required that a agent can connect to a public non secure network and
>> a private secure network. The first layer of network isolation may be done
>> by the physical network interfaces. The API that you are proposing enables
>> the quantum service to provide the support, but what about the agents? Will
>> the agents be able to differentiate between a private and public network.
>> Taking this further will the agents be able to assign these networks to
>> different network interfaces. Maybe it is not in the scope of the work that
>> you are proposing.
>>
>> Thanks
>> Gary
>>
>>
>>
>>
>> Regards,
>> Salvatore
>>
>> On 12 July 2012 05:37, Yong Sheng Gong <gongysh [at] cn> wrote:
>>
>>>
>>> If we just use one flag, it can represent just two values True or False.
>>> If we want to represent three values True, False or not specified, we have
>>> to use --public True or --public False or nothing at all.
>>>
>>> So it is a three-values logic.
>>>
>>>
>>> -----openstack-bounces+gongysh=cn.ibm.com [at] lists wrote:
>>> -----
>>> To: openstack [at] lists
>>> From: Endre Karlson
>>> Sent by: openstack-bounces+gongysh=cn.ibm.com [at] lists
>>> Date: 07/12/2012 07:53PM
>>> Subject: [Openstack] Fwd: [Quantum] Public Network spec proposal
>>>
>>>
>>> Why not just --public or not ? Why do you need --public True ? That just
>>> adds confusion...
>>>
>>> Endre.
>>>
>>>
>>> 2012/7/12 Gary Kotton <gkotton [at] redhat>
>>>
>>>> Hi,
>>>> 1. Is this also applicable to the agents? Say for example a user wants
>>>> to ensure that a public network is attached to network interface em1 and
>>>> the private network attached to em2. Is this something that will be
>>>> addressed by the blueprint?
>>>> 2. I prefer option #3. This seems to be a cleaner approach for the user
>>>> interface.
>>>> Thanks
>>>> Gary
>>>>
>>>>
>>>> On 07/12/2012 01:52 AM, Salvatore Orlando wrote:
>>>>
>>>> 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
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to : openstack [at] lists
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack [at] lists
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to : openstack [at] lists
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to : openstack [at] lists
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>


tomoe at midokura

Jul 17, 2012, 7:39 PM

Post #8 of 12 (174 views)
Permalink
Re: Fwd: [Quantum] Public Network spec proposal [In reply to]

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, but I'd like to know how this public network model would work
with those services.


1. What are the assumptions for public 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> 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>
> Date: 11 July 2012 19:10
> Subject: Re: [Openstack] [Quantum] Public Network spec proposal
> To: Salvatore Orlando <sorlando [at] nicira>
> Cc: openstack-dev [at] lists
>
>
> See inline comments.
>
> Thanks
>
>
>
> -----Salvatore Orlando <sorlando [at] nicira> wrote: -----
> To: Yong Sheng Gong/China/IBM [at] IBMC
> From: Salvatore Orlando <sorlando [at] nicira>
> Date: 07/12/2012 09:11AM
> Cc: openstack-dev [at] lists
> 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> 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 wrote: -----
>> To: openstack <openstack [at] lists>
>> From: Salvatore Orlando
>> Sent by: openstack-bounces+gongysh=cn.ibm.com [at] lists
>> 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
>> Unsubscribe : https://launchpad.net/~openstack
>> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


dan at nicira

Jul 19, 2012, 7:58 AM

Post #9 of 12 (174 views)
Permalink
Re: Fwd: [Quantum] Public Network spec proposal [In reply to]

On Tue, Jul 17, 2012 at 7:39 PM, Tomoe Sugihara <tomoe [at] midokura> 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).

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>
> 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>
> > Date: 11 July 2012 19:10
> > Subject: Re: [Openstack] [Quantum] Public Network spec proposal
> > To: Salvatore Orlando <sorlando [at] nicira>
> > Cc: openstack-dev [at] lists
> >
> >
> > See inline comments.
> >
> > Thanks
> >
> >
> >
> > -----Salvatore Orlando <sorlando [at] nicira> wrote: -----
> > To: Yong Sheng Gong/China/IBM [at] IBMC
> > From: Salvatore Orlando <sorlando [at] nicira>
> > Date: 07/12/2012 09:11AM
> > Cc: openstack-dev [at] lists
> > 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> 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 wrote:
> -----
> >> To: openstack <openstack [at] lists>
> >> From: Salvatore Orlando
> >> Sent by: openstack-bounces+gongysh=cn.ibm.com [at] lists
> >> 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
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help : https://help.launchpad.net/ListHelp
> >
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to : openstack [at] lists
> > Unsubscribe : https://launchpad.net/~openstack
> > More help : https://help.launchpad.net/ListHelp
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack [at] lists
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~


tomoe at midokura

Jul 19, 2012, 5:03 PM

Post #10 of 12 (163 views)
Permalink
Re: Fwd: [Quantum] Public Network spec proposal [In reply to]

Hi Dan,

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


sorlando at nicira

Jul 19, 2012, 5:16 PM

Post #11 of 12 (161 views)
Permalink
Re: Fwd: [Quantum] Public Network spec proposal [In reply to]

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> wrote:

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


tomoe at midokura

Jul 20, 2012, 6:22 AM

Post #12 of 12 (159 views)
Permalink
Re: Fwd: [Quantum] Public Network spec proposal [In reply to]

On Fri, Jul 20, 2012 at 9:16 AM, Salvatore Orlando <sorlando [at] nicira> 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.

Understood. Thanks for the clear explanation.

Tomoe

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

OpenStack dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.