#400 per-tag configuration of chroot mock behaviour
Merged 4 years ago by mikem. Opened 5 years ago by tkopecek.
tkopecek/koji issue398  into  master

file modified
+5
@@ -364,6 +364,11 @@ 

          #if self.options.debug_mock:

          #    cmd.append('--debug')

          # TODO: should we pass something like --verbose --trace instead?

+         if 'mock.new_chroot' in self.config['extra']:

+             if self.config['extra']['mock.new_chroot']:

+                 cmd.append('--new-chroot')

+             else:

+                 cmd.append('--old-chroot')

          cmd.extend(args)

          self.logger.info(' '.join(cmd))

          workdir = getattr(self, 'workdir', None)

@@ -403,6 +403,25 @@ 

  you will need to pass in --topurl=https://kojipkgs.fedoraproject.org/ to

  any mock-config command to get a working mock-config from fedoras koji.

  

+ Tuning mock's behaviour per tag

+ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

+ 

+ Few options for mock can be configured per-tag. These options are stored in

+ tag info's *extra* field. Extra values can be checked via `koji taginfo`

+ command.  Example for forcing `dnf` usage in specific build

+ environment follows:

+ 

+ ::

+ 

+     koji edit-tag dnf-fedora-tag -x mock.package_manager=dnf

+ 

+ 

+ * `mock.package_manager` - If this is set, it will override mock's default

+   package manager. Typically used with `yum` or `dnf` values.

+ * `mock.new_chroot` - 0/1 value. If it is set, `--new-chroot` or

+   `--old-chroot` option is appended to any mock call. If it is not set,

+   mock's default behaviour is used.

+ 

  Using Koji to control tasks

  ^^^^^^^^^^^^^^^^^^^^^^^^^^^

  

There was alredy --new-chroot option for runroot plugin. I think, the best way would be to remove it now as it will be configurable per builder.

Question is also if we want to raise mock version requirement in spec. I don't think it is needed as we are not using any other new feature yet. I've also chosen --old-root as default, so we don't get behaviour change in build itself. It is not that cool, as builder with old mock will need to set it to False (reason for raising requirement).

Currently composes use the runroot plugin to run ostree (which needs the new chroot) and lorax (plus a couple other tools) that use the old chroot. If the chroot type is configurable per builder, would it mean we need separate builders for these kinds of tasks?

Quite possible that we will want finer grained control than this

there was some tasks in runroot that did not work in systemd-nspawn. the control is going to have to be more granular.

Is there now any imaginable other problem except runroot?

  • If yes: Does it make sense to have generic task option to use old/new?
  • If not, can we change --new-chroot to --mock-method with 'chroot' or 'nspawn' options which could overwrite builder settings?

Other ideas?

there has been some reports of el6 builds failing with systemd-nspawn as the environment is different at the very least we likely only want to introduce --new-chroot for development branches and have a phased approach to adoption. much like we have with dnf today

I agree with @ausil that this should match the way the yum/dnf option is handled, i.e. per tag config. I don't think it should be per-builder at all.

At the moment, we do not have a good way to discriminate which builders can support the systemd-nspawn. If a Koji instance contains hosts that do not support it, yet the admins want to use the option for some tags, then I think they will need to use the channel policy to route builds accordingly.

For Fedora, I think all builders should be able to handle this, so that shouldn't be a problem for them.

rebased

5 years ago

I've added option to tag's extra field. Could it be useful to add more generic 'mock.options' field for list of options instead of specific one?

rebased

5 years ago

1 new commit added

  • docs for mock per-tag config
5 years ago

Could it be useful to add more generic 'mock.options' field for list of options instead of specific one?

It's tempting, but the idea gives me pause

  1. I'm not sure that tag admins should be allowed to set arbitrary mock options
  2. It's harder to see history of changes when tag extra options are structured
  3. I'm not sure we can or should support them all in kojid

Agreed, let's proceed with tailored usecases.

I've rebased against current master. Three variants are possible:

  • there is no special info in tag, use default
  • extra.mock.new_chroot == True - use --new-chroot option
  • extra.mock.new_chroot == False - use --old-chroot

Can we proceed (for 1.13 release) or are there still some concerns?

rebased

4 years ago

I'm going to retitle the PR though

Commit 01277c1 fixes this pull-request

Pull-Request has been merged by mikem@redhat.com

4 years ago