July 2016 - rel-eng - Fedora Mailing-Lists

#6440: Please, need unblock of un-retired gossip package for koji build f25 rawhide

by Fedora Release Engineering

#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

7 years, 9 months

1
1
0 / 0

Re: #6173: Same volume-id on all F22 ISOs

by Fedora Release Engineering

#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

7 years, 9 months

1
0
0 / 0

[Fedocal] Reminder meeting : Fedora Release Engineering

by Dennis Gilmore

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/

7 years, 9 months

2
1
0 / 0

Re: #6173: Same volume-id on all F22 ISOs

by Fedora Release Engineering

#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

7 years, 9 months

1
0
0 / 0

Re: #5805: add index.asc files for cloud images for virt-builder

by Fedora Release Engineering

#5805: add index.asc files for cloud images for virt-builder ------------------------------+----------------------- Reporter: mattdm | Owner: rel-eng@… Type: enhancement | Status: new Milestone: Fedora 25 Alpha | Component: other Resolution: | Keywords: planning Blocked By: | Blocking: ------------------------------+----------------------- Changes (by ausil): * milestone: Fedora 23 Alpha => Fedora 25 Alpha -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/5805#comment:18> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 9 months

1
0
0 / 0

Re: #6173: Same volume-id on all F22 ISOs

by Fedora Release Engineering

#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: ---------------------+----------------------- Changes (by ausil): * milestone: Fedora 23 Alpha => -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6173#comment:14> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 9 months

1
0
0 / 0

Re: #6173: Same volume-id on all F22 ISOs

by Fedora Release Engineering

#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

7 years, 9 months

1
0
0 / 0

Update about Autocloud deployment

by Kushal Das

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.in https://dgplug.org

7 years, 9 months

1
0
0 / 0

Re: #6173: Same volume-id on all F22 ISOs

by Fedora Release Engineering

#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

7 years, 9 months

1
0
0 / 0

#6436: please install PyYAML and python-requests-kerberos on composer.stg.phx2.fedoraproject.org

by Fedora Release Engineering

#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

7 years, 9 months

1
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng July 2016