[neutron] upgrading port binding:profile.allocation value for port-resource-request-groups API extension

Balazs Gibizer balazs.gibizer at est.tech
Wed Sep 22 13:44:24 UTC 2021

On Tue, Sep 21 2021 at 06:30:46 PM +0200, Rodolfo Alonso Hernandez 
<ralonsoh at redhat.com> wrote:
> Hello Balazs:
> Sorry for the late reply, I was on PTO.
> If I'm not wrong, now port['binding:profile']['allocation'] is a UUID 
> and you need it to be a list of UUIDs. Am I correct?

It is a bit more complicated than that. The old value is a single RP 
UUID. the new value is a dict where the key is the group_id and the 
value is the RP UUID fulfilling that group. So the transformation needs 
to access to the group_id.
The group_id is a stable UUID generated by neutron server as part of 
the port.resource_request value, but it is not persisted.

> To make this change in the DB you should use the Alembic migrations, 
> as you said. That should ensure all registers are translated. We 
> should also include a sanity check to ensure the DB migration was 
> done correctly.

I'm not 100% sure but I think such data migration can only be done in 
the contract part as it needs to be done while the neutron server is 
down as the old code can only use the old data format while the new 
code can only use the new format. Is it OK to introduce a new contract 
migration in Yoga in neutron?


> Is that what you needed? Don't hesitate to ping me in IRC if needed.
> Regards.
> On Fri, Sep 10, 2021 at 6:06 PM Balazs Gibizer 
> <balazs.gibizer at est.tech> wrote:
>> Hi Neutrinos!
>>  We found a technical challenge during implementing the
>>  port-resource-request-groups API extension[1]. That extension 
>> changes
>>  the format of the port.resoruce_request as well as the format of the
>>  port.binding:profile.allocation. The former is a calculated field on
>>  the port so that is easy. However the bindig:profile is persisted in
>>  the database so data migration is needed. What is the canonical way 
>> to
>>  do such DB data translation in Neutron? Can we translate the data in
>>  place during alembic migration? Or should we do some kind of online
>>  data migration when the data is translated by neutron when it is 
>> read
>>  from the db?
>>  cheers,
>>  gibi
>>  [1] https://review.opendev.org/c/openstack/neutron/+/805637/5

More information about the openstack-discuss mailing list