#6440: Please, need unblock of un-retired gossip package for koji build f25
rawhide
-----------------------------+------------------------
Reporter: rvais | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 25 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
I un-retired package named gossip in pkgdb and it has been already
approved.
I uploaded sources by "fedpkg import SRPM-FILE" and pushed to git but I
still
need unblock package for koji build.
http://koji.fedoraproject.org/koji/taskinfo?taskID=14870031
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6440>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6173: Same volume-id on all F22 ISOs
---------------------+-----------------------
Reporter: zeenix | Owner: rel-eng@…
Type: defect | Status: new
Milestone: | Component: koji
Resolution: | Keywords:
Blocked By: | Blocking:
---------------------+-----------------------
Comment (by chrismurphy):
I trust that this is not easily fixed and that there are higher
priorities. But that argument is not at all related to the
appropriateness, and conformance aspect, of intentionally using the same
Volume Identifier for two obviously very different volumes.
The ISO 9660 spec makes it really clear that the Volume Identifier is
expected to be reasonably unique specifically for the purpose of volume
differentiation and therefore file location. The Volume Set Identifier can
be the same among volumes. Setting the Volume Identifier field to the same
value for two different volumes thwarts the entire purpose of the Primary
Volume Descriptor. I agree with zeenix that the current behavior is
flawed, but further I think it arguably makes these ISOs not in
conformance with ISO 9660's intent to enable the user to identify and
differentiate what are in fact different volumes.
If it's OK to do this with two ISOs, then why not do it to all ISOs and
just stick "fedora" as the Volume Identifier?
{{{
Fedora-Server-netinst-x86_64-24-1.2.iso
/dev/loop1: UUID="2016-06-14-15-55-58-00" LABEL="Fedora-S-dvd-x86_64-24"
TYPE="iso9660" PTUUID="041a2601" PTTYPE="dos"
Volume Identifier=Fedora-S-dvd-x86_64-24
Volume Creation Date and Time=2016061415555800
ISO MD5SUM = 81ffacb48528f35651fe01eaa892060d
}}}
By filename, this is the net installer, not the dvd, but the Volume
Identifier and therefore the LABEL provided by libblkid says it is the
dvd.
{{{
Fedora-Server-dvd-x86_64-24-1.2.iso
/dev/loop0: UUID="2016-06-14-16-21-47-00" LABEL="Fedora-S-dvd-x86_64-24"
TYPE="iso9660" PTUUID="26760f17" PTTYPE="dos"
Volume Identifier=Fedora-S-dvd-x86_64-24
Volume Creation Date and Time=2016061416214700
ISO MD5SUM = 9e37b58618c7f598417c620f92de9d15
}}}
The ISO MD5SUMs are different because they two ISOs contain completely
different contents, and of course are intended for different installation
use cases. So saying these two volumes are sufficiently similar to give
them the same name is not compelling.
ISO 9660 has no field for UUID. It looks like libblkid is producing a UUID
based on the Volume Creation Date and Time field in the Primary Volume
Descriptor, which while it supports 1/100s precision is only populated
with 1s precision. It might be sufficiently unique anyway, but there is
also the MD5SUM field. So there are a couple of less obvious ways to know
that two identically named volumes are in fact not identical. But both
suffer from the same problem is differentiation on file size, which is
that these values aren't known until the ISO is already created.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6173#comment:16>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
Dear all,
You are kindly invited to the meeting:
Fedora Release Engineering on 2016-07-11 from 09:30:00 to 10:30:00 US/Central
At fedora-meeting-1(a)irc.freenode.net
The meeting will be about:
Fedora Release Engineering weekly meeting
Source: https://apps.fedoraproject.org/calendar/meeting/2026/
#6173: Same volume-id on all F22 ISOs
---------------------+-----------------------
Reporter: zeenix | Owner: rel-eng@…
Type: defect | Status: new
Milestone: | Component: koji
Resolution: | Keywords:
Blocked By: | Blocking:
---------------------+-----------------------
Comment (by zeenix):
Replying to [comment:13 ausil]:
> Any change requires massive rewriting and change in how we do things, we
will have to run some processes twice. It's likely not going to happen any
time soon. You really should not be relying on the volume id to
differenciate between install DVD and boot.i
The problems isn't just that but the fact that volume ID naming seems to
change from release to release and that's what elmarco was talking about.
The differentiate between DVD and netiso isn't critical but we really
really need the volume IDs to adhere to a specific pattern over the
releases and different stages of the release.
The only other means to detect the ISO is volume-size and I've already
spent quite many days in getting libosinfo to be able to do that. However,
the volume size is not finalised until the release day and therefore we
are unable to rely on that either until Fedora release. i-e no detection
for Alpha, Beta or rawhide ISOs.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6173#comment:15>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6173: Same volume-id on all F22 ISOs
------------------------------+-----------------------
Reporter: zeenix | Owner: rel-eng@…
Type: defect | Status: new
Milestone: Fedora 23 Alpha | Component: koji
Resolution: | Keywords:
Blocked By: | Blocking:
------------------------------+-----------------------
Comment (by ausil):
Any change requires massive rewriting and change in how we do things, we
will have to run some processes twice. It's likely not going to happen any
time soon. You really should not be relying on the volume id to
differenciate between install DVD and boot.i
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6173#comment:13>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
Hi all,
Below are the notes about Autocloud update happened last week. There
were few things which went bad, few points worked well. I am trying to
list them here, and how do we plan to make sure that the bad things
never happen again. I am ccing patrick in this mail as he was the
contact point from fedora infrastructure (read: he did all the work).
## deployment using ansible to the newly installed systems
We only had to change yum to dnf, and also had to remove the old hotfix
part from the roles. The current playbooks, roles seems to be stable,
and can help us in the future too.
## fedmsg-hub on the backends double enqueue
We had to restart fedmsg-hubs few times in the backends servers. In
between we also found that fedmsg-hub service was happily enqueueing the
jobs twice (for each compose), and then it got fixed automagically,
nothing was changed in our configuration or in code.
We are still not sure why this happened, but we are trying to dig more
on this.
## fedmsg-hub broke due to a faulty dependency
Even though we kept our code up and running for weeks, after the
production deployment we found one of the dependency (fedfind, adamw is
the upstream author) was broken with the fedora atomic image names, and
causing our fedmsg-hub instances go crazy. We have informed upstream,
and got a quick hotfix deployment in few hours after finding the issue.
For the next release we will make sure if keep it running for longer on
our internal hardware with messages from production fedmsg. This
dependency failure was something we should have caught, but could not.
## missing fedmsg(s) from autocloud on completing the testing of a compose
Now this was a known part of the whole development+release cycle. Sayan had
submitted the patch [1], but there was some slight miscommunication. In my part
i missed to track the state of this dependency.
For the next release, i will make a release/deployment checklist for
autocloud, and get it validated from everyone involved. Most probably we
will add too many minor details to this checklist, but that will help us
to keep things in track about any future deployment. sayan is currently
working to get that particular change in production so that we can send
out fedmsg(s) as required by adam.
## missing package dependency causing missing bridge on libvirt backend
We also found that a missing link in the dependency chain caused a
missing virtual bridge in the libvirt backend. Patrick helped to find
that adding libvirt as dependency for that particular box will fix the
issue in future.
We should test on clean installations while developing next time to make
sure this is not repeated. Plus we should think about getting better on
the stage environment.
## the new webfrontend is better
Sayan did a good job in making the new webfrontend. We can now point out
to the exact failures [2].
In future we should try to get more input about the features of the
webfrontend. Even though the whole service is made for automation, but
this frontend helps us to find, and point to the right issues found in
the tests.
## autocloud+tunir did what they are supposed to do
After fixing the hiccups, the autocloud service is doing what it
supposed to do, testing the images. We will push our effort in having
better test coverage in the coming months to take the advantage from
this new deployment.
Please comment/suggest whatever you think about the work. This will help
us to improve in the future releases.
[1]
https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/pull/386
[2] https://apps.fedoraproject.org/autocloud/jobs/66/output#290
Kushal
--
Fedora Cloud Engineer
CPython Core Developer
https://kushaldas.inhttps://dgplug.org
#6173: Same volume-id on all F22 ISOs
------------------------------+-----------------------
Reporter: zeenix | Owner: rel-eng@…
Type: defect | Status: new
Milestone: Fedora 23 Alpha | Component: koji
Resolution: | Keywords:
Blocked By: | Blocking:
------------------------------+-----------------------
Comment (by elmarco):
Still problematic with f24,
Fedora-S-dvd-{i386,x86_64}-24 is used both regular and netinst iso.
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6173#comment:12>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project
#6436: please install PyYAML and python-requests-kerberos on
composer.stg.phx2.fedoraproject.org
-----------------------------+------------------------
Reporter: lkocman | Owner: rel-eng@…
Type: task | Status: new
Milestone: Fedora 25 Alpha | Component: koji
Keywords: | Blocked By:
Blocking: |
-----------------------------+------------------------
Hello,
I'm working on a small trigger that triggers koji signed-repo or pungi-
signed-repo after module build was finished.
However I do need to query pdc for some data (such as tag for module etc.)
The trigger itself is currently being executed on
composer.stg.phx2.fedoraproject.org (due pungi-signed-repo need to link
stuff from /mnt/koji ...)
I'd like you to install following rpms on
composer.stg.phx2.fedoraproject.org
python-requests-kerberos
PyYAML
pdc-client (If available, so I don't have to use checkout)
Thanks
Lubos
--
Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6436>
Fedora Release Engineering <http://fedorahosted.org/rel-eng>
Release Engineering for the Fedora Project