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 <blak...@gmail.com> 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 <mkole...@redhat.com> > 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 <yalei.w...@intel.com> 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: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Kevin Benton > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
