Add info field to RepositoryVersion

[hstct]

closes #2998

The name of the field was chosen arbitrarily and is certainly open to be changed into whatever fits the best.

[quba42]

We now have a working state of the pulp_deb optmize sync that needs this field.

As such, it would be nice if we could settle on a name for the field, so we can update this PR and move towards final review.

sync_details is not a good name, since I definitely envision the pulp_deb advanced copy API also making use of this field in the future (that is it is not just intended for syncs).

Personally I vote for creation_details, because this is somewhat opinionated about what this field is intended for. Given that the field can factually contain arbitrary json data, a completely generic name like version_details would alternatively also make sense.

Does anyone want to wade in, or should we go ahead and change this PR to use creation_details?

[dkliban]

What about just 'details' or 'info' ?

[ggainey]

+1 to "info"

[quba42]

The current consensus is "info".

[hstct]

Updated the PR renamed the field to info and removed exposing the data in the serializer.

[ipanova]

The current consensus is "info".

Sorry for back and forth on this, I would personally vote for more explicit name like version_details or was the intention to leave this as generic as possible to leave the door opened to add such field to other models too? @ggainey @dkliban

[quba42]

@ipanova I guess one could consider the version_ part in RepositoryVersion.version_<whatever> redundant?
If so, then info or details seems just as good as version_info or version_details. (I have no opinion on info vs details).

The other thought was that since the field is inherently generic (can contain arbitrary Json), the name should also be generic?
My original thought was that the field name could be more "opinionated" than the field itself, which is why I suggested creation_details, but this was never a strong opinion. At the end of the day I am fine with any of the suggestions within this thread (so long as they don't explicitly include sync in the name).

My 2ct.

[ipanova]

@dralley if you want to also take a look

[dralley]

If we're going for a generic name like "info" then we maybe ought to consider whether this could be more broadly applicable than just repository versions, something like the Pulp 2 "scratchpad". For example I can see a use case having publications store particular details about how they were created as well.

But on the flip side, I'm not sure if we want to resurrect the "scratchpad", and we already have a label system which has a small overlap in intended purpose.

[ipanova]

If we're going for a generic name like "info" then we maybe ought to consider whether this could be more broadly applicable than just repository versions, something like the Pulp 2 "scratchpad". For example I can see a use case having publications store particular details about how they were created as well.

But on the flip side, I'm not sure if we want to resurrect the "scratchpad", and we already have a label system which has a small overlap in intended purpose.

If my recollection is correct, I believe we discussed this aspect in pulpcore meeting, that's why we're trying to pick as generic name as we can.
I agree with you about the feeling of adding this to all models, hence I'd say let's add only where we have a request for now?

Labels are user visible, this is not intended to be seen.

[dralley]

Unfortunately once it's been added to a model it can't just be easily moved to another model in the inheritance hierarchy. You can make a new field with a different name but keeping the same name is really problematic.

[ipanova]

Unfortunately once it's been added to a model it can't just be easily moved to another model in the inheritance hierarchy. You can make a new field with a different name but keeping the same name is really problematic.

oh, i see, yes

[dralley]

If we were ever to remove this and move it to the base model we would likely call it pulp_info, precluding the aforementioned concern.