What do you think of just blocking all PUTs to that field? Is that a feasible change without inducing widespread riots about breaking changes?
On Thu, Jul 16, 2015 at 2:53 AM, Salvatore Orlando <[email protected]> wrote: > It is not possible to constrain this attribute to an enum, because there > is no fixed list of device owners. Nevertheless it's good to document know > device owners. > > Likewise the API layer should have checks in place to ensure accidental > updates to this attributes do not impact control plane functionality or at > least do not leave the system in an inconsistent state. > > Salvatore > > > On 16 July 2015 at 07:51, Kevin Benton <[email protected]> wrote: > >> I'm guessing Salvatore might just be suggesting that we restrict users >> from populating values that have special meaning (e.g. l3 agent router >> interface ports). I don't think at this point we could constrain the owner >> field to essentially an enum at this point. >> >> On Wed, Jul 15, 2015 at 10:22 PM, Mike Kolesnik <[email protected]> >> wrote: >> >>> >>> ------------------------------ >>> >>> Yes please. >>> >>> This would be a good starting point. >>> I also think that the ability of editing it, as well as the value it >>> could be set to, should be constrained. >>> >>> FYI the oVirt project uses this field to identify ports it creates and >>> manages. >>> So if you're going to constrain it to something, it should probably be >>> configurable so that managers other than Nova can continue to use Neutron. >>> >>> >>> As you have surely noticed, there are several code path which rely on an >>> appropriate value being set in this attribute. >>> This means a user can potentially trigger malfunctioning by sending PUT >>> requests to edit this attribute. >>> >>> Summarizing, I think that document its usage is a good starting point, >>> but I believe we should address the way this attribute is exposed at the >>> API layer as well. >>> >>> Salvatore >>> >>> >>> >>> On 13 July 2015 at 11:52, Wang, Yalei <[email protected]> wrote: >>> >>>> Hi all, >>>> The device:owner the port is defined as a 255 byte string, and is >>>> widely used now, indicating the use of the port. >>>> Seems we can fill it freely, and user also could update/set it from cmd >>>> line(port-update $PORT_ID --device_owner), and I don’t find the guideline >>>> for using. >>>> >>>> What is its function? For indicating the using of the port, and seems >>>> horizon also use it to show the topology. >>>> And nova really need it editable, should we at least document all of >>>> the possible values into some guide to make it clear? If yes, I can do it. >>>> >>>> I got these using from the code(maybe not complete, pls point it out): >>>> >>>> From constants.py, >>>> DEVICE_OWNER_ROUTER_HA_INTF = "network:router_ha_interface" >>>> DEVICE_OWNER_ROUTER_INTF = "network:router_interface" >>>> DEVICE_OWNER_ROUTER_GW = "network:router_gateway" >>>> DEVICE_OWNER_FLOATINGIP = "network:floatingip" >>>> DEVICE_OWNER_DHCP = "network:dhcp" >>>> DEVICE_OWNER_DVR_INTERFACE = "network:router_interface_distributed" >>>> DEVICE_OWNER_AGENT_GW = "network:floatingip_agent_gateway" >>>> DEVICE_OWNER_ROUTER_SNAT = "network:router_centralized_snat" >>>> DEVICE_OWNER_LOADBALANCER = "neutron:LOADBALANCER" >>>> >>>> And from debug_agent.py >>>> DEVICE_OWNER_NETWORK_PROBE = 'network:probe' >>>> DEVICE_OWNER_COMPUTE_PROBE = 'compute:probe' >>>> >>>> And setting from nova/network/neutronv2/api.py, >>>> 'compute:%s' % instance.availability_zone >>>> >>>> >>>> Thanks all! >>>> /Yalei >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Kevin Benton >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Kevin Benton
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
