#2511 build.cg_id not set for non-reserved content generator imports
Closed: Fixed 6 months ago by tkopecek. Opened 8 months ago by mikem.

The cg_id field was added to the build table to enable reservations by content generators.

However for cg imports that are not reserved, it appears that cg_id is not set.

This is tricky because technically the cg spec allows for one import to cover multiple content generators. However, I'm unaware of systems performing imports that span multiple cgs.

I'm not sure what the right thing here is, but there is certainly potential for confusion.

We could:

  • leave things as is. If so, we should document this behavior
  • make a best effort to set build.cg_id for builds. E.g. set it when the build has a unique cg_id, or even just pick one if there are multiples.
  • drop support for cg imports that span multiple cgs (one build, one cg)

Thanks to @mfilip for pointing this out

Metadata Update from @mikem:
- Custom field Size adjusted to None

8 months ago

I would pick a second option. I'm not sure if we want to drop multiple CGs support. On the other hand as you've said it is 100% usage now that only one CG is included. Maybe we can pick not randomly but come near with picking CG with majority usage in the import buildroots.

What I wonder now is the semantics of cg_id field - If we are allowing more CGs as part of the buildroots which have created different parts of output - what is the CG for the build itself - does it make any sense even? /Isn't the other option to drop cg_id from buildinfo?/

I'm not sure if we want to drop multiple CGs support. On the other hand as you've said it is 100% usage now that only one CG is included. Maybe we can pick not randomly but come near with picking CG with majority usage in the import buildroots.

It's a tough spot. The cg_id field is decidedly single, and the CGImport code distinctly allows multiple. So, we are already contradicting ourselves.

I frequently regret the choice to support multiple CGs in one import. I'd be interested in trying to move to make them singular, but I don't know if that is feasible (i.e. I don't know if anyone is using that option).

Doing the above right is probably a change to the json schema for cgs.

Metadata Update from @tkopecek:
- Issue set to the milestone: 1.24

7 months ago

Let's gather all CG implementations: #2572 (and I'll start a thread in koji-devel)

I came across this issue while looking to file another RFE. In the event that you do end up moving to a one-cg-per-build implementation it won't be necessary ...

For now in order to identify what CGs a given build was produced with it requires a number of calls. We have to load all archives for the build, then load the individual buildroot records that produced each of those archives, and from there we can get the list of CGs. It would be great if there were a single hub call to fetch this in one go, similar to how the getBuildType call works.

If the issue #2574 goes through, then presumably the fields used to reserve the build for a CG can be used for this instead. But in the event that this doesn't work or cannot be safely implemented, would you prefer a file an RFE for the new call now or wait to see how things pan out?

Note that even with #2574, some existing systems could have old imports with multiple cgs. Also, this change does not add cg_id values to old builds that lack them

Metadata Update from @jcupova:
- Issue tagged with: testing-ready

6 months ago

Metadata Update from @mfilip:
- Issue tagged with: testing-done

6 months ago

Commit f5ddbbf relates to this ticket

Login to comment on this ticket.

Metadata
Related Pull Requests
  • #2574 Merged 6 months ago
  • #2572 Merged 3 months ago