Open Stack

Hi Aaron,

In OVS and ML2 plugins, on port-update, there is a check to make sure that
allowed-address-pairs and fixed-ips don't overlap. Can you please explain
why that is needed?

------------- icehouse final: neutron/plugins/ml2/plugin.py ------------

677             elif changed_fixed_ips:

678                 self._check_fixed_ips_and_address_pairs_no_overlap(

679                     context, updated_port)
-----------------------

Thanks,
Praveen


On Wed, Jul 17, 2013 at 3:45 PM, Aaron Rosen <arosen at nicira.com> wrote:

> Hi Ian,
>
> For shared networks if the network is set to port_security_enabled=True
> then the tenant will not be able to remove port_security_enabled from their
> port if they are not the owner of the network. I believe this is the
> correct behavior we want. In addition, only admin's are able to create
> shared networks by default.
>
> I've created the following blueprint
> https://blueprints.launchpad.net/neutron/+spec/allowed-address-pairs and
> doc:
> https://docs.google.com/document/d/1hyB3dIkRF623JlUsvtQFo9fCKLsy0gN8Jf6SWnqbWWA/edit?usp=sharingwhich will provide us a way to do this. It would be awesome if you could
> check it out and let me know what you think.
>
> Thanks,
>
> Aaron
>
>
> On Tue, Jul 16, 2013 at 10:34 AM, Ian Wells <ijw.ubuntu at cack.org.uk>wrote:
>
>> On 10 July 2013 21:14, Vishvananda Ishaya <vishvananda at gmail.com> wrote:
>> >> It used to be essential back when we had nova-network and all tenants
>> >> ended up on one network.  It became less useful when tenants could
>> >> create their own networks and could use them as they saw fit.
>> >>
>> >> It's still got its uses - for instance, it's nice that the metadata
>> >> server can be sure that a request is really coming from where it
>> >> claims - but I would very much like it to be possible to, as an
>> >> option, explicitly disable antispoof - perhaps on a per-network basis
>> >> at network creation time - and I think we could do this without
>> >> breaking the security model beyond all hope of usefulness.
>> >
>> > Per network and per port makes sense.
>> >
>> > After all, this is conceptually the same as enabling or disabling
>> > port security on your switch.
>>
>> Bit late on the reply to this, but I think we should be specific on
>> the network, at least at creation time, on what disabling is allowed
>> at port level (default off, may be off, must be on as now).  Yes, it's
>> exactly like disabling port security, and you're not always the
>> administrator of your own switch; if we extend the analogy you
>> probably wouldn't necessarily want people turning antispoof off on an
>> explicitly shared-tenant network.
>> --
>> Ian.
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140519/20ff8adb/attachment.html>