Open Stack

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 <blak111 at 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 <mkolesni at 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.wang at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> 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/20150716/b03dda88/attachment.html>