#6037: Create .xz images for docker builds
by Fedora Release Engineering
#6037: Create .xz images for docker builds
-----------------------------+------------------------
Reporter: kushal | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 21 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Currently we provide .tar.gz output for Fedora docker builds in Koji. But
the Docker team prefers to have .xz compressed image. We should have .xz
as output in future builds.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6037>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years
#5866: Create new channel for building Java packages
by Fedora Release Engineering
#5866: Create new channel for building Java packages
----------------------+------------------------
Reporter: mizdebsk | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: koji
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------
== Request ==
Please create a new Koji channel for building Java packages which
would exclude ARM builders, or implement an equivalent solution. My
goal is to be able to build noarch Java packages skipping any ARM
builders. Using custom koji command is not a problem for me.
== Justification ==
The great majority of Java packages are noarch. As such they are most
often pisked up by ARM builders.
Java performance on ARM is very poor. The situation got even worse
after JIT for ARM was disabled in JVM. ARM machines are often slower
by one to three orders of magnitude than x86_64. Some tests which
execute in a few seconds on x86_64 can take over half an hour on ARM.
Current state of Java on ARM combined with Koji configuration makes it
difficult to maintain Java packages in Fedora. A substantial amount
of human resources is wasted on waiting for builds to complete,
debugging tests which fail only on ARM, keeping track on builds and
resubmitting them. That resources could be utilised better and I
think that justifies my request.
== Alternative solutions ==
I have tried differnt alternative solutions since ARM became a primary
architecture and none of them is good enough.
One ad-hoc solution is submitting numerous dummy koji tasks for ARM
builders until their capacity is exhausted, then submitting Java
package build and canceling ARM tasks. This is obviously a hack and
should be avoided.
If Koji configuration is not improved the only remaining solution will
be converting Java packages from noarch to arch-specific and adding
ExcludeArch. I still hope that ARM situation will eventually improve,
so I would like to avoid doing drastic things like that, if possible.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5866>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years
RFC: Proposal for Rel-Eng project management/planning
by Adam Miller
Hello all,
Hot off the heals of my email to start a conversation about what
all it's going to take to get the Fedora Rel-Eng Staging environment
up and running again[0] I wanted to make a proposal for a new way to
manage projects that can be broken down into small consumable "units
of work" much in line with kanban[1].
Proposal:
Projects would be planned in the open in irc meetings (logged with
meetbot) and documented in the wiki for general overview and
posterity, from there this is broken down into specific units of work
that can be tracked and picked up (hopefully) by any interested member
of the Rel-Eng team. I like to think this will make the process of
work transparent to the broader community as well as offer an
approachable avenue for new Rel-Eng team members to join in allowing
them to select low-hanging-fruit type units of work to use as learning
experiences.
Also, the details of this project planning workflow (whatever it
ends up being) would be documented in the Fedora wiki such that it
could be used as part of an "on-boarding" document for community
members interested in joining the Fedora Rel-Eng team.
My hope here is to introduce a new piece of infrastructure to fill
this requirement that provides a kanban-style board of cards much like
Trello[2] but using a FOSS solution that we can host ourselves. For
this I'd like to propose the use of Cantas[3]. (This part would likely
need a request sent to Fedora Infrastructure team unless we're fine
just hosting it somewhere like OpenShift Online).
Questions, comments and general snide remarks welcome! :)
Thank you,
-AdamM
[0] - https://lists.fedoraproject.org/pipermail/rel-eng/2015-April/019800.html
[1] - https://en.wikipedia.org/wiki/Kanban_%28development%29
[2] - https://trello.com/
[3] - https://github.com/onepiecejs/nodejs-cantas
9 years
How *could* we make it more easy to deliver late-breaking deliverables?
by Matthew Miller
>From today's FESCo meeting, on the topic of adding a non-blocking
Vagrant image that got missed for Alpha and Beta, Dennis noted
"It sets a bad precident if we let it in. People will push the limits
further than they already do." and
"We can physically do it. But we really should not
add new deliverables just for final."
This particular change was, as Kevin said in the meeting, a trainwreck
of bad communication, and we've got a number of corrections in the
works to fix that --
* an official list of deliverables for each release
* change process amended to note need for releng communication
And I've heard a few other good ideas, including FESCo liasons for
Cloud/Server/Workstation working groups helping to track individual
changes more closely throughout the process.
But, in general, I feel sad about the outcome here. This would have
been very useful to Fedora users, and help us in a particular target
area in which we need to grow. Rather than focusing on this particular
thing, though, I want to go with the assumption that in the future, we
_will_ have more new and changing deliverables.
I see where Dennis is coming from in frustration with people not
following process. That can causes a lot of extra work for _other_
people, and can result in lower-quality results which we might not be
proud of as a project, and which can erode trust in Fedora overall.
However, there's another side too. Docker was the last big thing, but
who knows what the next one will be? Increasing communication and
long-term planning is one thing, but often with these emerging
technologies we're _really_ making it up as we go along. When these
things have little negative impact outside of their own space (they are
effectively self-contained changes _except_ for releng needs), and have
significant benefits for the user community and for Fedora's adoption
and growth, I *want* the limits pushed further than they currently can
be.
What would we need in order to have release engineering which can
provide a space for that? And let me be clear — that includes not
making work or life overwhelming with all the work you all already do.
I'm not taking the heroic existing tasks for granted, I'm asking what
_else_ would be needed to make this possible.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
9 years
#6165: Rawhide nightly boot.iso has IsFinal=True in /.buildstamp
by Fedora Release Engineering
#6165: Rawhide nightly boot.iso has IsFinal=True in /.buildstamp
-----------------------------+------------------------
Reporter: adamwill | Owner: rel-eng@…
Type: defect | Status: new
Milestone: Fedora 23 Alpha | Component: other
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Not quite sure why this is happening (as I follow it through from pungify
to pungi to lorax), but somehow, current Rawhide nightlies have this in
/.buildstamp:
IsFinal=True
this causes anaconda to disable the 'rawhide' repo, and hence no repos are
available by default. This means all our automated tests fail except ones
that specify a repo in a kickstart.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6165>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years
#6160: buildbranched mash complains about unsigned packages
by Fedora Release Engineering
#6160: buildbranched mash complains about unsigned packages
-----------------------------+------------------------
Reporter: kalev | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 22 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
From
https://kojipkgs.fedoraproject.org/mash/branched-20150426/logs/mash.log
{{{
2015-04-26 07:32:16 mash: WARNING: package bitten-
master-1:0.6-6.fc22.noarch is not signed with a preferred key (signed with
no key)
2015-04-26 07:32:16 mash: WARNING: package websvn-selinux-
None:2.3.3-8.fc22.noarch is not signed with a preferred key (signed with
no key)
2015-04-26 07:32:16 mash: WARNING: package bitten-
common-1:0.6-6.fc22.noarch is not signed with a preferred key (signed with
no key)
2015-04-26 07:32:16 mash: WARNING: package websvn-None:2.3.3-8.fc22.noarch
is not signed with a preferred key (signed with no key)
2015-04-26 07:32:16 mash: WARNING: package copr-frontend-doc-
None:1.44-1.fc22.noarch is not signed with a preferred key (signed with no
key)
2015-04-26 07:32:16 mash: WARNING: package bitten-
slave-1:0.6-6.fc22.noarch is not signed with a preferred key (signed with
no key)
2015-04-26 07:32:16 mash: WARNING: package copr-frontend-
None:1.44-1.fc22.noarch is not signed with a preferred key (signed with no
key)
2015-04-26 07:32:16 mash: WARNING: package perl-Satcon-
None:1.20-3.fc21.noarch is not signed with a preferred key (signed with
95a43f54)
2015-04-26 07:32:17 mash: WARNING: package bitten-
master-1:0.6-6.fc22.noarch is not signed with a preferred key (signed with
no key)
2015-04-26 07:32:17 mash: WARNING: package bitten-
common-1:0.6-6.fc22.noarch is not signed with a preferred key (signed with
no key)
2015-04-26 07:32:17 mash: WARNING: package bitten-
slave-1:0.6-6.fc22.noarch is not signed with a preferred key (signed with
no key)
2015-04-26 07:32:17 mash: WARNING: package websvn-None:2.3.3-8.fc22.noarch
is not signed with a preferred key (signed with no key)
2015-04-26 07:32:17 mash: WARNING: package copr-frontend-doc-
None:1.44-1.fc22.noarch is not signed with a preferred key (signed with no
key)
2015-04-26 07:32:17 mash: WARNING: package copr-frontend-
None:1.44-1.fc22.noarch is not signed with a preferred key (signed with no
key)
2015-04-26 07:32:17 mash: WARNING: package websvn-selinux-
None:2.3.3-8.fc22.noarch is not signed with a preferred key (signed with
no key)
2015-04-26 07:32:17 mash: WARNING: package perl-Satcon-
None:1.20-3.fc21.noarch is not signed with a preferred key (signed with
95a43f54)
2015-04-26 07:32:17 mash: WARNING: package bitten-
master-1:0.6-6.fc22.noarch is not signed with a preferred key (signed with
no key)
2015-04-26 07:32:17 mash: WARNING: package bitten-
common-1:0.6-6.fc22.noarch is not signed with a preferred key (signed with
no key)
2015-04-26 07:32:17 mash: WARNING: package bitten-
slave-1:0.6-6.fc22.noarch is not signed with a preferred key (signed with
no key)
2015-04-26 07:32:17 mash: WARNING: package websvn-None:2.3.3-8.fc22.noarch
is not signed with a preferred key (signed with no key)
2015-04-26 07:32:17 mash: WARNING: package copr-frontend-doc-
None:1.44-1.fc22.noarch is not signed with a preferred key (signed with no
key)
2015-04-26 07:32:17 mash: WARNING: package copr-frontend-
None:1.44-1.fc22.noarch is not signed with a preferred key (signed with no
key)
2015-04-26 07:32:17 mash: WARNING: package websvn-selinux-
None:2.3.3-8.fc22.noarch is not signed with a preferred key (signed with
no key)
2015-04-26 07:32:17 mash: WARNING: package perl-Satcon-
None:1.20-3.fc21.noarch is not signed with a preferred key (signed with
95a43f54)
}}}
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6160>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years
Random thoughts/crazy idea: Drop SSL certs
by Pierre-Yves Chibon
Good morning everyone,
This week-end I had a random thought, which I quickly discussed with Dennis on
IRC on Sunday but that I thought might be interesting to discuss in a wider
audience.
The initial thought came from a text that Dennis wrote:
"""
Releng tracks this data in 2 systems, 1 of which we own: Koji and Bodhi. Koji
uses ssl certs tied to FAS and bodhi uses FAS for authentication to provide a
strong relationship between a user and the content
"""
Source: https://fedoraproject.org/wiki/ReleaseEngineering/Philosophy#Auditable
This has lead me to the question: Is this all what SSL certs are bringing us?
The following only works under the assumption that it is.
So SSL certs are basically a certain type of API token. Everyone has one,
specific to koji and the lookaside cache, time limited and gives us a way of
doing authentication and authorization server side.
So on this they behave just like any other API token, but using SSL certs has
some pros and downs:
pros:
- Easy to find out when the token expires
- In place and working
- Known to the current process maintainers
cons:
- One per client
- Hard to invalidate iiuc (ie: if someone's machine is compromised/lost it is
hard to make this user's certificate invalide)
- Relise on the SSL pile
- master certificate
- self-signed vs signed by an authority
- complex tooling
- Makes us maintain a whole infrastructure stack around this (cf the dogtag
discussion)
- Relies on the master certificate that expires every X years making everyone
generate a new client certificate
On the otherside, recently we have been more and more feeling the need for a
centralized API authentication place. Something along the line of a personalized
0Auth. This has also pros and cons.
pros
- API token per user and per application
- Could support multiple tokens per application
- Central place to manage API token (ie a central place to revoke someone's
access if a machine gets compromised/lost)
- Simpler than dealing with the SSL stack
- Can be re-used by multiple applications
cons:
- It's an idea and it needs work :)
- Impacts
- dist-git
- koji
- ?
I do realize that this would be a pretty big task to undertake but we are
currently at a stage where we are planning for the future, including for the
next generation of koji but also FAS3, dogtag, our master cert expiring in a
couple of years...
So I thought I would leave this here as food for thoughts and I'm happy to
discuss pros and cons of this idea.
Thanks,
Pierre
9 years
#5941: Requesting Koji user certificate for Koschei
by Fedora Release Engineering
#5941: Requesting Koji user certificate for Koschei
-----------------------------+------------------------
Reporter: msimacek | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 20 Final | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Koschei is a continuous integration tool for Fedora packages that does
scratch-builds of packages in rawhide as their dependencies change. Right
now it is using my personal certificate for initiating the scratch-builds,
but since we'd like to deploy it in the Fedora Infrastructure, we need a
separate Koji account for it. It will be used only for scratch-building,
no other permissions are needed.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5941>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years
#6164: bodhi2 status update requested
by Fedora Release Engineering
#6164: bodhi2 status update requested
---------------------+------------------------
Reporter: ausil | Owner: rel-eng@…
Type: task | Status: new
Milestone: | Component: other
Keywords: meeting | Blocked By:
Blocking: |
---------------------+------------------------
Luke,
Release Engineering would like you to attend the weekly releng meeting on
may 4th at 15:30 UTC to give a status update on bodhi2. Additionally we
would like to have regular, i.e. every 2 weeks or monthly status updates
of bodhi2 until at least it is deployed live.
Thanks
Fedora Release Engineering
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6164>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
9 years