Open Stack

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 <sorlando at nicira.com>
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 <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
>>
>>
>
> __________________________________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150716/4092b1f5/attachment.html>