RPM Support

during the migration - do we plan to look just into modules information?in case we do so, then the rest of non-modular rpms will miss the 'modular' field, right?
how do we plan to identify ursine modular rpms? analysing each header for rpm ( which is present on fs) does not seem like a good approach.
we could add a validation later to figure out any ursine content

I suggest for migration to rely on modulemd content only and set a new field for every RPM either to True or to False.
We can have false negatives but at the moment the probability is very low + we can always verify or fix it with a validation tool.
So +1 to ignore that problem.
+1 for a validation tool later.
For huge repos with an immediate policy it could be too expensive migration if we look at every RPM on a FS.

Any thoughts from someone else?

LGTM;

FWIW I was able to check 150k unit sizes in about 8min with pulp-integrity, checking checksums took about 45 minutes.
Reading the rpm header could take longer indeed than checking the unit sizes; the stats are cached in-memory thru i-nodes but to figure out the flag, each rpm unit header would have to be read and parsed by the rpm lib but will probably take less than the checksums calculation as only the rpm headers need processing. We could still experiment and measure this way of migration, if not in too much hurry, the code might be simpler too (reusing the upload bits).

Sounds like a reasonable approach/plan to me. The migration should be a best effort using the manifests in the DB. Further migration or correctness should be provided by running a CLI tool at customer request.

Just a thought: do we want a new check function (plugin) for pulp-integrity for the migration check?

Probably not. We no longer can reliably do any checks. Not all modular RPMs are with modular metadata in a repo. Not all modular RPMs have DISTTAG set :( E.g. F28 modular repo.