August 2016 - rel-eng - Fedora Mailing-Lists

#6313: atomic host: reorienting ostree commits to match 2 week cadence

by Fedora Release Engineering

#6313: atomic host: reorienting ostree commits to match 2 week cadence -----------------------------+------------------------ Reporter: walters | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 23 Final | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Current as I understand it, we have a "two week" process for images (cloud, ISO etc.), but the OSTree commits are made at the default Fedora at-most-once-a-day cadence. I would like to propose doing only one released OSTree commit matching the two week release. Meaning `atomic host upgrade` would exactly what the images give. The advantage of this is predictability. NOTE: we need an exception for critical async security errata. The /testing/ ref though would continue at its current rate - and ideally go even faster. I would be a lot happier if we skipped the manual once-a-day RPM signing and did direct Koji -> /testing/. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6313> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 6 months

1
17
0 / 0

#6195: Signed commits for ostree / Project Atomic

by Fedora Release Engineering

#6195: Signed commits for ostree / Project Atomic -----------------------------+------------------------ Reporter: mattdm | Owner: rel-eng@… Type: enhancement | Status: new Milestone: Fedora 23 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ As Atomic moves from experimental to something users will actually depend on, we need to get this right. It's my understanding that the current workflow doesn't make it easy (the signing needs to happen in a place different from what we're used to). I don't know the specifics, but as Dennis says, "we should figure something out. I just do not know what a good answer is". The same thing might let us also sign RPM repo metadata. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6195> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 7 months

1
2
0 / 0

#6267: sign ostree commits

by Fedora Release Engineering

#6267: sign ostree commits -----------------------------+------------------------ Reporter: walters | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 23 Final | Component: koji Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ This has been discussed several times. AIUI it is blocked on a Fedora policy of not doing detached signatures. As downstream Red Hat Enterprise Linux and its associated PST are OK with detached signatures, I think Fedora should as well. The GPG signature would have helped mitigate https://git.fedorahosted.org/cgit/spin- kickstarts.git/commit/?id=1e408e111008f539c89212a9ca9bb955e2c4f823 for example. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6267> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 7 months

1
11
0 / 0

#6350: integrate atomic (host and other) CI/CD into Fedora

by Fedora Release Engineering

#6350: integrate atomic (host and other) CI/CD into Fedora -----------------------------+------------------------ Reporter: walters | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Breaking out from: https://fedorahosted.org/rel-eng/ticket/6313 Let's define a system and process for CD (Continuous Delivery) that bypasses manual integration via Koji/Bodhi and ships as quickly as possible to a small audience on dl.fedoraproject.org. Specifically, use rpmdistro-gitoverlay to mirror upstream sources that we know have been peer reviewed already, and build/ship them automatically. Also generate a devel/ ostree ref based on this content, and potentially images. Integrate pull request testing into this too. Resources required: - OpenStack tenant resources - Ability to write to dl.fedoraproject.org somewhere -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6350> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 7 months

1
9
0 / 0

#6385: [RFE] provide unique product name in .treeinfo

by Fedora Release Engineering

#6385: [RFE] provide unique product name in .treeinfo -----------------------------+------------------------ Reporter: bpeck | Owner: rel-eng@… Type: enhancement | Status: new Milestone: Fedora 24 Alpha | Component: other Keywords: | Blocked By: Blocking: | -----------------------------+------------------------ Currently nightly composes all produce the same name in product section of .treeinfo Adding <DATE>-<SPIN> to the name would be one way to solve this. This would make rsyncing and testing clearer about which product is being synced/tested. Thank you -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6385> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 7 months

1
2
0 / 0

#6408: Fedora 24 Atomic Updates Testing ostree.

by Fedora Release Engineering

#6408: Fedora 24 Atomic Updates Testing ostree. ----------------------------+------------------------ Reporter: dustymabe | Owner: rel-eng@… Type: task | Status: new Milestone: Fedora 24 Beta | Component: koji Keywords: | Blocked By: Blocking: | ----------------------------+------------------------ Can we create a ref for updates-testing for f24? If we follow from the f23 model [1] then the ref should live at: https://dl.fedoraproject.org/pub/fedora/linux/atomic/24/refs/heads/fedora- atomic/24/x86_64/testing/docker-host [1] https://dl.fedoraproject.org/pub/fedora/linux/atomic/23/refs/heads /fedora-atomic/f23/x86_64/testing/docker-host -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6408> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 7 months

1
4
0 / 0

#6460: Disable GPG check in repository config between branch and Bodhi enablement

by Fedora Release Engineering

#6460: Disable GPG check in repository config between branch and Bodhi enablement ----------------------+------------------------ Reporter: adamwill | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: other Keywords: | Blocked By: Blocking: | ----------------------+------------------------ Every cycle, we have a problem in the time between the branch point and the Bodhi enablement point. During that period, not all packages are signed. However, the 'fedora' repository configuration has gpgcheck=1 . So you either have to manually modify the repository configuration or pass --nogpgcheck (or equivalent for whatever package install method you're using) every time you try to install a package. This is especially annoying for automated tests, because to deal with it you need a messy logic branch in all your tests, and you also need to somehow *detect* when the test is running between branch point and Bodhi enablement point, which isn't especially easy to do. We've been saying this will be fixed properly (by making sure all the packages are signed) forever, but it never seems to happen; until that happens, it would be good if fedora-repos could be built with gpgcheck=0 for the fedora repo at branch point, then with gpgcheck=1 for the fedora repo at Bodhi enablement point. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6460> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 7 months

1
2
0 / 0

#6467: Consider splitting the ancient portions of the archive

by Fedora Release Engineering

#6467: Consider splitting the ancient portions of the archive -------------------+------------------------ Reporter: tibbs | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: other Keywords: | Blocked By: Blocking: | -------------------+------------------------ In order to try and cut down on the amount of space on the mirrors, it might be reasonable to consider splitting the archive module. Some of that stuff is only of historical interest at this point, and there might not even be any point in having it mirrored at all. (Given that we really don't want people actually using it.) I know that the older releases really aren't large compared with the modern ones, but if we kept, say, only the last ten(?) releases in archive and moved everything older off to either a "historical" rsync module or just a separate server somewhere that isn't rsyncable, we'd save something on the order of a terabyte, or nearly 10% of a full mirror load. Of course, there's pretty much no churn of that content so there's no bandwidth savings. -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6467> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 7 months

1
3
0 / 0

#6473: Please create a epel7-mono side tag

by Fedora Release Engineering

#6473: Please create a epel7-mono side tag ----------------------+------------------------ Reporter: tpokorra | Owner: rel-eng@… Type: task | Status: new Milestone: | Component: epel Keywords: | Blocked By: Blocking: | ----------------------+------------------------ Hi, Please create a new epel7-mono side tag and build target. We'll use it for building Mono4.2 and depending packages before submitting them to testing. Thanks, Timotheus -- Ticket URL: <https://fedorahosted.org/rel-eng/ticket/6473> Fedora Release Engineering <http://fedorahosted.org/rel-eng> Release Engineering for the Fedora Project

7 years, 7 months

1
15
0 / 0

Docker images included in the compose and what that means for Pungi

by Adam Miller

Hello all, Currently there is a ticket filed in Taiga[0] that is lacking in details mostly because I'm not entirely sure what all we need in there so I wanted to start that discussion here. The motivation behind this is that we're moving towards a future where we are shipping content that is in the format of a Docker Layered Image and I can imagine that we will want to include these as installable artifacts at compose time for certain things such as Atomic Host. An example of why we'd want that is so that on a fresh install from the ISO image there can be a set of services and/or applications installed without them needing to be pre-baked into the ostree. This would hopefully allow for more flexibility with the services and applications to be lifecycled independently of the operating system. There's definitely a lot of details to sort out through the entire stack, but the concept of bringing Layered Images into the fold as compose artifacts is something I wanted to start discussing among the group to find out if it is needed and if so, if it's most appropriately handled by pungi or potentially some other tool. Thank you, -AdamM [0] https://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-t...

7 years, 7 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

rel-eng August 2016