PR#400: per-tag configuration of chroot mock behaviour - koji

koji

#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

per-tag configuration of mocks' --new-chroot

Tomas Kopecek • 4 years ago

18432c1

builder/kojid

file modified

		`@@ -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)`

docs/source/using_the_koji_build_system.rst

file modified

+19

		`@@ -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`
		`^^^^^^^^^^^^^^^^^^^^^^^^^^^`

tkopecek commented 5 years ago

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).

Edited 5 years ago by tkopecek

lsedlar commented 5 years ago

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?

mikem commented 5 years ago

Quite possible that we will want finer grained control than this

ausil commented 5 years ago

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

tkopecek commented 5 years ago

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?

ausil commented 5 years ago

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

mikem commented 5 years ago

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

tkopecek commented 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