#6663 Create another new tag for Modularity
Closed: Fixed 2 years ago Opened 3 years ago by ralph.

This is related to #6658 but is different.

Through discussions with @puiterwijk in and audit of the MBS code, we are trying to reduce the permissions required by the module-build-service, so that it poses less of a risk.

In order to do that (for mbs#333) we need a new tag created that has the full package list for Fedora, but which should not inherit from an existing Fedora tag.

Let's call the new tag module-package-list (which describes precisely what it is for).

Why we need a tag with the full package list

Current, MBS runs with admin permissions. When it tags builds into tags that it has created, it does so with force=True which automatically adds the package to the package list of the tag first, before tagging the build.

We want to remove force=True because it is too heavy handed.

We could dynamically add packages to the package list of the new module tag every time a new build comes along, but that requires elevated permissions.

Instead, if we have a master tag with a full package list of every package in Fedora, and if our new modules tags inherit from that tag, then we don't have to worry about the package list or have any special rights to manipulate it (good).

Why the new tag should not inherit from an existing tag.

If we made this new tag inherit from the rawhide tag, then it would automatically get the nice package list that we need.

However, we need to ensure that the new tag does not accidentally provide any BuildRequires which are not explicitly specified by the module being built. If a BuildRequires is absent, we want the build to fail to ensure modules are really isolated from one another.

Therefore, we need this new tag to not inherit from any other tags.

Once created, we will need to patch this script to automatically populate the package list of this new tag, while not contributing any builds.


@ralph Few questions that needs to be answered:

  1. How long are you planning on using this tag?
  2. Are you going to merge the builds later into any other tag?
  3. If its based on release, can we name it after the release like f26-module-package-list?
  4. If its not based on release, whats the future for this tag? Just testing purposes?

Thanks! Good questions.

How long are you planning on using this tag?

Roughly, forever.

  • It would be something that would stick around that every new module tag would inherit from.
  • It would be maintained by the pkgdb sync script once I submit a patch for it.

Are you going to merge the builds later into any other tag?

No.

If its based on release, can we name it after the release like f26-module-package-list?

Unfortunately, it is not based on release. (Modules are supposed to be release independent until they are composed into a release later). The same build of a module might be composed into two different releases some day (at least, that's part of the goal).

If its not based on release, whats the future for this tag? Just testing purposes?

We need it to stick around indefinitely with no builds in it, but with a full package list, so that tags which inherit from it can inherit the package list.

New tag "module-package-list" is added:

$ koji add-tag module-package-list

Metadata Update from @mohanboddu:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

3 years ago

This needs careful consideration, as I suspect it will break our blocking model. lets leave it open and discuss at the meeting

Metadata Update from @ausil:
- Issue status updated to: Open (was: Closed)
- Issue tagged with: meeting

3 years ago

:+1: I'll try to be there. Is there any info on the blocking model you can point me at ahead of time?

@ralph is this still a required feature?

Please advise and update if there have been changes.

Modularity is now working in F28. Closing this ticket.

Metadata Update from @syeghiay:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata