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 <aro...@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.ubu...@cack.org.uk>wrote: > >> On 10 July 2013 21:14, Vishvananda Ishaya <vishvana...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev