Agenda for Env-and-Stacks WG meeting (2014-07-01)
by Marcela Mašláňová
On odd weeks WG meeting will be at 15:00 UTC, 17:00 Central Europe,
11:00 (noon) Boston, 8:00 San Francisco, 0:00 Tokyo in #fedora-meeting
on Freenode.
= Topics =
* free seats in Env WG
* Taskotron and rpmgrill
* OpenFloor
9 years, 10 months
docker image questions!
by Matthew Miller
See https://fedorahosted.org/cloud/ticket/65
Adam asks:
What "Fedora" exactly is the image going to contain? Fedora Server?
Fedora Cloud? Will it be a part of either of those products? If not, what
is its status, exactly? Who's responsible for it? Is it considered a
primary or frontline or whatever Fedora deliverable? Who's going to test
it? How's it going to be promoted in relation to all our other
deliverables?
Here are *my* answers -- let's make sure we all agree. :)
* It will contain its own very minimal "spin". We're not (currently) going
to produce "layered" images -- just the base. (Application images will
be made via Docker's "trusted builds" service from the fedora-dockerfiles
repo, on top of this base.)
* It will initially be part of Fedora Cloud, but long term I think we want
to move it to Env & Stacks (CC'ing).
* Correspondingly, I think we're responsible.
* On "primary or frontline", I think the answer is "not release blocking",
but we'd like to produce and upload the image after release if we miss
it
* Who is going to test it? We should. Possibly, launching _this_ image
will be part of the Fedora Atomic tests?
* The goal is to upload the official image to the Docker index in a manner
similar to our other cloud images.
* We may promote it on the web site in some manner, but the primary point
is that we want to appear at <https://registry.hub.docker.com/>
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9 years, 10 months
Koschei - Continuous integration for Fedora packages
by Michael Šimáček
Hello,
Recently I've been working on Koschei - a new continuous integration tool for
Fedora. It's main goal is to track dependency changes in Rawhide and be able to
(scratch) rebuild packages in Koji after their dependencies change.
It will use Hawkey library to resolve packages' dependencies in order to match
resolution happening during the Koji build as closely as possible. That would
also enable marking packages with unresolved build dependencies as unbuildable
without needing actual rebuild in Koji.
The packages will be scheduled based on their current priority value, which will
be increased with each depenendency update by a value inversely proportional to
the distance between the package and the dependency in the dependency chain. The
priority will also slowly increase over time and will be reset back when a new
rebuild is scheduled.
It will provide a web interface with:
- detailed reports about current state of packages
- their recent builds
- analysis of package failures - buildroot differences, parsing failure reasons
out of build logs
- statistics - build times, common failure reasons
It will be limiting the number of rebuilds in order to not overload Koji
builders - by limiting maximum number of running builds and monitoring Koji
current load. Listening to Koji events will be done over fedmsg bus.
If you have any questions or suggestions, please contact me.
Michael Simacek
9 years, 10 months
