Open Stack

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.com> 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.com> 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.ibm.com> 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.launchpad.net wrote:
>>> -----
>>> To: openstack at lists.launchpad.net
>>> From: Endre Karlson
>>> Sent by: openstack-bounces+gongysh=cn.ibm.com at lists.launchpad.net
>>> 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.com>
>>>
>>>>  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.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~openstack
>>>> Post to     : openstack at lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~openstack
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack at lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack at lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack at lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120717/16fd9dc6/attachment-0001.html>