Looking at the code, I don't see a clear case to even use set() type there. A list would seem to work just fine. Should we try to convert to using lists there? Nevertheless, we can look into extending the object base class for hashing. I wonder though if it's something to tackle in Neutron scope. Sounds more like an oslo.versionedobjects library feature request. Ihar On Wed, Jan 25, 2017 at 11:53 AM, Das, Anindita <anindita.das at intel.com> wrote: > Hi Ihar, > > > > While doing the integration for vlanallocation [1] I found that OVO > associated with VlanAllocation throws “unhashable type” error with py35. > > The associated stack trace is here [2]. > > > > To resolve this issue I added an equality and hash method in the > vlanallocation OVO [3]. > > My understanding is we will face the same problem with other OVO objects as > well when we do similar operations on the object as in [1]. > > Should we make all the OVO objects hashable or deal it case by case? > Thoughts? > > > > > > [1] > https://review.openstack.org/#/c/367810/28/neutron/plugins/ml2/drivers/type_vlan.py@77 > > [2] http://paste.openstack.org/show/596281/ > > [3] > https://review.openstack.org/#/c/367810/28/neutron/objects/plugins/ml2/vlanallocation.py@38-55 > > > > Thanks, > > Anindita (irc: dasanind)