Comment 3 for bug 1715190

I took a look at the versions of objects, between Ocata and Pike. There is only one object that has a different version, the Port object is version 1.6 in Ocata, and 1.7 (added 'physical_network' field) in Pike.

After someone upgrades (rolling or cold) from Ocata to Pike, at some point (before they upgrade to Queens), they will have to run 'ironic-dbsync online_data_migrations' which invokes the backfill_column_version() code (from the Pike release). Without this fix, there is the possibility that *if* one or more ports' physical_network field are being set at 'the same time' as the dbsync call, that the port's version will end up being set to 1.6 (instead of 1.7) and the physical_network field will be set to None.

Since the ironic-dbsync call is being done in the Pike release, this fix needs to be backported to stable/pike.

Running ironic-dbsync online_data_migrations from master (Queens) doesn't make sense; it'll be too late. Because in order to upgrade to master (or Queens), they would have had to run the online_data_migrations cmd from Pike, and if they did that, all the version columns in the DB would already be populated, so there would be no need to run it in Queens/master (which is why we can delete the backfill code in master*)

* assuming we also backport the 'set conductor version' patch to stable/pike too.