[releng] Issue #6967: new mock and systemd-nspawn
by Kevin Fenzi
kevin added a new comment to an issue you are following:
``
Yes, the loop issue was fixed in 1.4.6.
I don't know if bind-ro will work for pesign.
I also know appliance image creation doesn't work in nspawn, and some of the runroot stuff I suspect also will not work. I suppose we need someone to go through all the various tasks that a compose fires off and confirm that they work or should work in nspawn. Sadly a pretty daunting task.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6967
6 years, 4 months
[releng] Issue #7100: new koji tags for atomic host
by Dusty Mabe
dustymabe reported a new issue against the project: `releng` that you are following:
``
With the new [Fedora CI objective](https://fedoraproject.org/wiki/Objectives/Continuous_Integrati...
we will have better testing of the packages that comprise Fedora Atomic Host
and eventually extend that out to packages that aren't included in Atomic Host
(i.e. the broader Fedora).
It is almost guaranteed that we won't catch everything before some packages make
it into stable (some long running tests or even possibly some failures that we
don't yet have tests for). For that reason we have established that we will need
the ability to revert packages in Atomic Host that fail tests (or are otherwise bad).
This is mostly so that the testing of future packages doesn't get blocked by a host
that is now in a bad state.
We had previously considered using modularity for this purpose, but we aren't quite
ready to use modularity yet. In the interim we'd like to use a few koji tags and a rigorous
definition of Atomic Host to achieve this goal.
Today:
- we have the `f27-atomic` tag. This is used to primarily "freeze" our install
media for Atomic Host at the f27 "release day" package set. Occasionally we will need
a new version of anaconda or ostree/rpm-ostree for the installer and we'll ask to
have things tagged into this tag.
- we build our ostree for Atomic Host from the release day repo (f27) as well as the
updates repo that was created by Bodhi (f27-updates).
Proposed Future:
- we have an `f27-atomic-installer` tag that is used for the same purpose as the
`f27-atomic` tag is today. Mainly to freeze the installer package set at f27
release day packages. This tag inherites from f27 (release day) tag.
- we have an `f27-atomic-overrides` tag. This tag does not inherit from any other
tag and only contains rpms that we have tagged in there for reverting to previous
versions of rpms.
- we have a dist-repo for `f27-atomic-overrides` so that whenever we tag something
into that tag we can request a repo get created for it.
- we update the ostree compose definition (in our pungi configs) to pull from this new
dist-repo, as well as f27 and f27-updates. In our fedora-atomic tree manifest we will
specify NVR for rpms (possibly even for all packages that make up atomic host).
- we request a new "atomic" koji permission. This permission will have the appropriate
policy to allow people with this permission to add/remove packages from these tags.
Thanks to @mikeb who helped me come up with this solution by providing technical guidance.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/7100
6 years, 4 months