Hi, EOL and Obsoletes were planned as a feature of Modularity. The feature should enable to set shorter/longer life cycles on Modules than the OS release. The initial idea was to set this information in the disgit metadata of a Module. As time went by the requirements have changed. From my point of view right now it seems that this information should not be a part of the module (disgit, repository metadata). It is prone to human error when we leave this in the hands of a packager. So this would need a review of Engineering to be reliable. Next is that a lot of 3rd parties like to handle the EOL and Obsoletes of packages/modules by other means, which makes this redundant. Also, as the release cycle of Fedora is so fast, I am not sure this is a necessary feature at all I spoke to people in the community and I got mixed information/opinions, so I want to open a discussion about this feature. So WDYT? Is this necessary for Fedora? If yes, how should we handle this?

At the end of the day for Fedora, packagers are maintaining the modules, so they should be able to mark a module as EOL when they feel like they don't want it in the distribution anymore. As for module obsoletes, this is necessary for supporting transitions and upgrades, which broke *two* Fedora release upgrades because there was no way to handle this. Additionally, with my third-party packager hat on, I need these to be declarable in the module metadata so that it's easy to convey in a machine-enforceable way when something is maintained/supported or not. I don't know which third-parties you've been talking to, but as an actual third-party packager who does work for an ISV that supports Fedora and RHEL/CentOS for a product, I don't know where else I would put it.

On Tue, Oct 27, 2020 at 01:52:00PM +0100, Martin Curlej wrote: > From my point of view right now it seems that this information should not > be a part of the module (disgit, repository metadata). It is prone to human > error when we leave this in the hands of a packager. So this would need a > review of Engineering to be reliable. > Did you mean a Release Engineering, or a general engineering like FESCo?

Why module obsoletes are dangerous for mere packagers, while package obsoletes are safe? Can you elaborate?

What are the other means which the 3rd parties use?

This all seem to revolve around the (mysterious) engineering team. Who "owns" the modular EOL information in Fedora, if not the packagers? IIRC There is no modularity supervision team in Fedora. The Fedora modularity issue tracker is dead since January/February, the meetings have been cancelled.

IIRC the current policy is: no modular EOLs mid-release (although I've failed to locate it at the Polices page of the Modularity documentation).

While I get Petr's point about the usefulness of mid-release EOLs, I am a bit worried about the UX if we allowed that. Let's say Anna enables the postgresql:9.5 stream on her database server with Fedora 33 and once the stream goes EOL (presumably around the upstream EOL date in February 2021), postgresql suddenly updates to a newer version? Wouldn't Anna be frustrated by this behavior? IMHO our users are familiar with this happening on Fedora release boundary only. OTOH If the EOL date is informational only (Anna keeps postgresql:9.5 but sees a warning during dnf upgrades) and the obsoletes only actually happen on a specific user action (and on release boundary), great.

> OTOH If the EOL date is informational only (Anna keeps postgresql:9.5 but > sees a warning during dnf upgrades) and the obsoletes only actually happen > on a specific user action (and on release boundary), great. That's how it is suspposed to work. Read "Proposed dnf behavior" in <https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL>;.

On Tue, Oct 27, 2020 at 3:53 PM Petr Pisar <ppisar(a)redhat.com&gt; wrote: > What are the other means which the 3rd parties use? > Your imagination is the limit. ;) Just joking. Now seriously. For example, Redhat and Fedora. The information about EOL and Obsoletes will be used and distributed differently.

Also it depends to whom you serve your content. If you build modules just for your company and distribute it on your intranet it's different from a community driven opensource linux distribution.

Then there's a question how to get the documents into modules.yaml. From my perspective, it's up to Fedora infra/releng/packaging people. Whether it should be in dist-git, git repo (similar to modulemd-defaults or comps), PDC, Bodhi (similar to updateinfo) or somewhere else - that's entirely their call.

On Mon, 2 Nov 2020 at 06:55, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote: > On 11/2/20 12:33 PM, Daniel Mach wrote: > > Then there's a question how to get the documents into modules.yaml. From > my > > perspective, it's up to Fedora infra/releng/packaging people. Whether it > should > > be in dist-git, git repo (similar to modulemd-defaults or comps), PDC, > Bodhi > > (similar to updateinfo) or somewhere else - that's entirely their call. > > I understand this perspective, but unless we have Fedora > infra/releng/packaging > people who would own this and drive this, it won't happen. I consider > myself > "packaging people" and I certainly won't. Do we have at least an idea if > we have > such people? > > I do not think Fedora/CentOS Infra/Releng could do any of this without a scoped out project to Community Platform Engineering. Most of the items (outside of bodhi) listed above are 'run' by CPE but not 'owned' by CPE in a way that CPE architects what is there and how it is done. dist-git is dictated by what koji wants and needs. modularity git repo is dictated by what MBS needs. PDC is abandoned-ware from some internal group and works only when it wants to, etc. Most of the CPE infra/releng work is just trying to keep the Rube Goldberg machine of the Fedora/CentOS build systems running 24x7x365 while meeting the 'oh by the way we promised that XYZ would be built this release.. disk and cpu are free right?' project demands of some component which works fine by itself and now needs to work in the existing systems already. We have a long list of these items to complete in the next 6 months..

Hi, Dne 27. 10. 20 v 13:52 Martin Curlej napsal(a): > Hi, > > EOL and Obsoletes were planned as a feature of Modularity. The feature > should enable to set shorter/longer life cycles on Modules than the OS > release. The initial idea was to set this information in the disgit > metadata of a Module. As time went by the requirements have changed. From DNF team's perspective, a packaging system is not complete without Obsoletes. That's why we believe module Obsoletes are a must have to ensure smooth system upgrades and regular updates on systems consuming Rawhide (or any other rolling stream). I created a Fedora Change[1] which got accepted already. We'll deliver support for module Obsoletes in DNF as soon as possible and we hope it's going to be used in Fedora 34 (or 35 at latest). The API is clear: DNF expects additional 'modulemd-obsoletes' YAML documents in modules.yaml. The new document format is getting into libmodulemd and there's going to be documentation on how to write it. Then there's a question how to get the documents into modules.yaml. From my perspective, it's up to Fedora infra/releng/packaging people. Whether it should be in dist-git, git repo (similar to modulemd-defaults or comps), PDC, Bodhi (similar to updateinfo) or somewhere else - that's entirely their call.

On Tue, Nov 03, 2020 at 12:26:46AM +0100, Dan Čermák wrote: > Daniel Mach <dmach(a)redhat.com&gt; writes: >> The API is clear: DNF expects additional 'modulemd-obsoletes' YAML >> documents in modules.yaml. The new document format is getting into >> libmodulemd and there's going to be documentation on how to write it. >> >> Then there's a question how to get the documents into modules.yaml. From >> my perspective, it's up to Fedora infra/releng/packaging people. Whether >> it should be in dist-git, git repo (similar to modulemd-defaults or >> comps), PDC, Bodhi (similar to updateinfo) or somewhere else - that's >> entirely their call. > > I think the package/module maintainer should be able to set the EOL and > obsoletes for their module in a simple fashion, preferably without > requiring to create tickets for releng or anyone else. So that leaves > dist-git as the only option, right? > I also like the idea of having EOL data in dist-git in hands of the packagers. The problem is that a compose process run by relengs does not use dist-git at all. It picks up builds from Koji and data from various git repositories. The various git repositores is where the module default profiles live. Problem is that the various repositories are not dist-git. They have a rigid commit access by a few people. Those are not packagers. We could create a dedicated repository in dist-git for collecting the EOL data from various module maintainers and give the module maintainers a commit access there. But the problem with dist-git is that a special repository does not fit into the namespace schemata (rpms, modules, tests). We could create a dedicated repository on pagure.io instead, give maintainers a commit access there (the account system is shared with Fedora, I think) and confugure pungi (a tool run by relengs to make composes) to read EOL data from there. But there still had to be a manual step of granting the commit access. Another option would be adding the EOL data into modules dist-git repositories. To the same branches where modules are built from. But a different file. Pungi would enumarate all module builds directed to a compose, locate their dist-git sources by mapping name:stream to git://src.fedoraproject/org/modules/name.git#stream and download EOL data from there. That would enable module maintains to control EOLs simply by pushing an eol.yaml file into the branch of the module. Wouldn't relengs object that it's not accountable because the EOL data can be updated asynchrously of module builds and tagging in Koji? And isn't that what we want to acheive -- EOL data independent from the module builds? Alternatively we could append EOL YAML document to modulemd YAML document in the dist-git (a YAML file can contain multiple YAML documents) and rebuild the build. That way the EOL data would get together with the modulmd to Koji and to the compose. But that would bind the EOL data to module builds. If we wanted to EOL a module stream, we would have to make an unnecessary module build. Would it be still worthwile? -- Petr

On Tue, Nov 3, 2020 at 1:16 PM Petr Pisar <ppisar(a)redhat.com&gt; wrote: > Another option would be adding the EOL data into modules dist-git > repositories. To the same branches where modules are built from. But > a different file. Pungi would enumarate all module builds directed to > a compose, locate their dist-git sources by mapping name:stream to > git://src.fedoraproject/org/modules/name.git#stream and download EOL data from > there. That would enable module maintains to control EOLs simply by pushing an > eol.yaml file into the branch of the module. This is not a reliable method as the branch name can be anything if stream name is defined in modulemd. Technically even the repository name can be anything.

Have anybody considered to use AppData for that information? Or at least similar approach?