Open Stack

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/attachments/20120717/b2b66646/attachment.html>