Should we provide current/previous release links in URLs?

[Orion Poplawski]

As part of the cobbler project testing, we need to test accessing Fedora 
releases with various URLs:

"http://download.fedoraproject.org/pub/fedora/linux/releases/35/Everything/x86_64/os",
"https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-35&arch=x86_64"
"https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64",

These need to get updated continuously as Fedora progresses.  Could we 
perhaps have a "current" and "previous" (or similar) that tracks the 
most recent and previous release?


-- 
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager                         720-772-5637
NWRA, Boulder/CoRA Office             FAX: [phone]
3380 Mitchell Lane                       orion(a)nwra.com
Boulder, CO 80301                 https://www.nwra.com/

[Kevin Fenzi]

On Mon, Jul 17, 2023 at 05:59:50PM -0600, Orion Poplawski wrote:
>  As part of the cobbler project testing, we need to test accessing
> Fedora
>  releases with various URLs:
>  
>
> "http://download.fedoraproject.org/pub/fedora/linux/releases/35/Everything/x86_64/os",
>  "https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-35&arch=x86_64"
>  "https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64",
>  
>  These need to get updated continuously as Fedora progresses.  Could we
>  perhaps have a "current" and "previous" (or similar) that tracks the
> most
>  recent and previous release? 
Could we? Sure... but... there's a big can of worms around the source of
truth as to what releases are in what state. We could add yet another
thing that we have to manually update here I suppose. Not a super fan of
that. 

Someday I hope we will finally solve that... 

kevin

[Adam Williamson]

On Tue, 2023-07-18 at 13:42 -0700, Kevin Fenzi wrote:
>  On Mon, Jul 17, 2023 at 05:59:50PM -0600, Orion Poplawski wrote:
>  > As part of the cobbler project testing, we need to test accessing Fedora
>  > releases with various URLs:
>  > 
>  >
> "http://download.fedoraproject.org/pub/fedora/linux/releases/35/Everything/x86_64/os",
>  >
> "https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-35&arch=x86_64"
>  >
> "https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64",
>  > 
>  > These need to get updated continuously as Fedora progresses.  Could we
>  > perhaps have a "current" and "previous" (or similar) that tracks
> the most
>  > recent and previous release?
>  
>  Could we? Sure... but... there's a big can of worms around the source of
>  truth as to what releases are in what state. We could add yet another
>  thing that we have to manually update here I suppose. Not a super fan of
>  that. 
>  
>  Someday I hope we will finally solve that...  
well...could we possibly engineer this in such a way that it ultimately
keys off the definitions in the infra ansible repo? e.g. perhaps these
kinda aliases could be defined in a config file for mirrormanager, and
we could deploy such a config file from ansible?
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net

[Kevin Fenzi]

On Tue, Jul 18, 2023 at 01:58:09PM -0700, Adam Williamson wrote:
>  On Tue, 2023-07-18 at 13:42 -0700, Kevin Fenzi wrote:
>  > On Mon, Jul 17, 2023 at 05:59:50PM -0600, Orion Poplawski wrote:
>  > > As part of the cobbler project testing, we need to test accessing Fedora
>  > > releases with various URLs:
>  > > 
>  > >
> "http://download.fedoraproject.org/pub/fedora/linux/releases/35/Everything/x86_64/os",
>  > >
> "https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-35&arch=x86_64"
>  > >
> "https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64",
>  > > 
>  > > These need to get updated continuously as Fedora progresses.  Could we
>  > > perhaps have a "current" and "previous" (or similar) that
> tracks the most
>  > > recent and previous release?
>  > 
>  > Could we? Sure... but... there's a big can of worms around the source of
>  > truth as to what releases are in what state. We could add yet another
>  > thing that we have to manually update here I suppose. Not a super fan of
>  > that. 
>  > 
>  > Someday I hope we will finally solve that... 
>  
>  well...could we possibly engineer this in such a way that it ultimately
>  keys off the definitions in the infra ansible repo? e.g. perhaps these
>  kinda aliases could be defined in a config file for mirrormanager, and
>  we could deploy such a config file from ansible? 
Yeah, at least that would not add any more things to update. ;)

kevin

[Stephen Smoogen]

On Tue, Jul 18, 2023 at 16:43 Kevin Fenzi <kevin(a)scrye.com&gt; wrote:

>  On Mon, Jul 17, 2023 at 05:59:50PM -0600, Orion Poplawski wrote:
>  > As part of the cobbler project testing, we need to test accessing Fedora
>  > releases with various URLs:
>  >
>  > "
>  http://download.fedoraproject.org/pub/fedora/linux/releases/35/Everything...
>  ",
>  > "https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-35&arch=x86_64
>  "
>  >
> "https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64",
>  >
>  > These need to get updated continuously as Fedora progresses.  Could we
>  > perhaps have a "current" and "previous" (or similar) that tracks
> the most
>  > recent and previous release?
>
>  Could we? Sure... but... there's a big can of worms around the source of
>  truth as to what releases are in what state. We could add yet another
>  thing that we have to manually update here I suppose. Not a super fan of
>  that.
>  

Having done something similar in the past you find out quickly people will
use such urls or current/past in configs you don’t expect. Then when Fedora
moves from 36 to 37 in current you get angry complaints that 5000 systems
are broken because yum update tried to move a live system from one version
to another and failed in a hundred different ways.



>  Someday I hope we will finally solve that...
>
>  kevin
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  
-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren

[Smith, Stewart]

On Jul 19, 2023, at 1:24 AM, Stephen Smoogen <ssmoogen(a)redhat.com&gt; wrote:


On Tue, Jul 18, 2023 at 16:43 Kevin Fenzi
<[e-mail]<mailto:[e-mail]>> wrote:
On Mon, Jul 17, 2023 at 05:59:50PM -0600, Orion Poplawski wrote:
>  As part of the cobbler project testing, we need to test accessing
> Fedora
>  releases with various URLs:
>
>
> "http://download.fedoraproject.org/pub/fedora/linux/releases/35/Everything/x86_64/os",
>  "https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-35&arch=x86_64"
>  "https://mirrors.fedoraproject.org/metalink?repo=fedora-35&arch=x86_64",
>
>  These need to get updated continuously as Fedora progresses.  Could we
>  perhaps have a "current" and "previous" (or similar) that tracks the
> most
>  recent and previous release?
>  
Could we? Sure... but... there's a big can of worms around the source of
truth as to what releases are in what state. We could add yet another
thing that we have to manually update here I suppose. Not a super fan of
that.


Having done something similar in the past you find out quickly people will use such urls
or current/past in configs you don’t expect. Then when Fedora moves from 36 to 37 in
current you get angry complaints that 5000 systems are broken because yum update tried to
move a live system from one version to another and failed in a hundred different ways.

I was also involved in recently doing such a thing, when we switched the “latest”
container image of Amazon Linux from Amazon Linux 2 (i.e. circa 2018 base of things) to
Amazon Linux 2023. Looking at the metrics not too many weeks after that of what tags were
being pulled showed that the majority of those relying on “latest” can actually jump from
something like Amazon Linux 2 (circa 2018) to Amazon Linux 2023 without a problem.

But I’ve also seen the other side of things too often too… where people have made pretty
bad assumptions about what is safe to do.

Ultimately, I’ve come up with the following “OS users deeply believe two things that are
fundamentally not true. 1) That the OS vendor is flawless and never makes a mistake in
releasing an update, and 2) That they are using the OS in exactly the way it is intended,
and exclusively relying on things to stay constant that the OS vendor also agrees are
things that will stay constant”.