Copr integration
by Mike McLean
There has been a lot of discussion lately about the future of Copr. The
current plan is to integrate Copr with Koji in order to get the features
folks want from Copr in a reasonable timeframe. For background, look here:
https://lists.fedoraproject.org/pipermail/devel/2013-September/188751.html
https://lists.fedoraproject.org/pipermail/devel/2013-August/188575.html
https://lists.fedorahosted.org/pipermail/copr-devel/2013-August/000729.html
The plan is not for a complete merger, but for Copr to remain a separate
project that makes use of Koji. However, this will still require changes
to Koji. These changes will need to be fairly invasive and may be a
little unstable for a while, so I've created a separate fork to track them:
https://github.com/mikem23/copr-koji
(I should probably have just used a branch in our normal upstream, but I
haven't really had a chance to really play around with github and this
seemed like a reasonable excuse)
Some of these changes will be a matter of removing some of the
hard-coded restrictions in Koji that don't necessarily make sense for a
system like Copr.
The first thing I opted to tackle was dealing with Koji's uniqueness
constraints for NVRs and NVRAs. My approach was to add namespaces for
builds. Within a given namespace, NVRs are still required to be unique,
but cross-namespaces conflicts are allowed. Additionally, within the
NULL namespace any number of conflicts are allowed.
Using namespaces allows folks that want NVR uniqueness to just stick
with the default namespace, but gives others the option of overlap.
I know there are some concerns about the wisdom of allowing NVR overlap
at all. If you have cocerns one way or the other, please raise them here.
9 years, 5 months
- 4
- 8
Running mash in Koji
by Mathieu Bridon
Hi,
Dennis Gilmore has been talking for some time about how he'd like to run
Mash in Koji tasks, instead of the set of scripts releng currently uses.
So I started working on this, and I got to the point where it actually
works, but I have a few questions before I can finish it and submit the
patches.
1. What would be an appropriate weight for this new task?
At the moment I'm just using the default, but given that mashing can be
quite intensive, it might be better to increase that. I have no idea on
what would be the right number, though.
2. What would be the appropriate permissions to run this task?
Right now, the task requires the user to be an admin. Should I introduce
a new 'mash' permission? Is there an existing 'releng' permission I
should use?
3. What to do with the output?
Mash will create the repositories for all configured architectures,
corresponding to a certain Koji tag.
As such, its output is much bigger that, say, a build task.
The task could upload everything back to the Hub, but that could take a
significant time and might hammer the Hub?
Dennis was saying that another possibility was to mount /mnt/koji as
read-write on the builder, and inside the chroot, so that the task could
write its output directly there.
What would be the preferred option?
--
Mathieu
9 years, 5 months
- 5
- 9