Hi
Hmm, there should be no broken AppStream when you connect your client directly to Uyuni repositories.
We mirror the modules.yaml files and provide it 1:1 to the client.
About other management server I heard that all use the same approach we use.
Let the user make a decision and convert the module repos into normal one.
But I did not check the code.
Am Donnerstag, 10. Juni 2021, 16:25:57 CEST schrieben Sie:
> Michael, Allen;
> Thank you both for your replies.
>
> I will raise an Issue as suggested.
>
> I have found another workaround which I'm going to be using until a better solution emerged.
> For the benefit of others, it is to deploy a local version of the Centos .repo file for AppStream.
>
> Even if Uyuni also provides a "broken" Appstream via its susemanager:channels.repo file, dnf is smart enough to choose the modules from the Master mirror and updates start working again.
>
> This is not ideal since it means that each machine will be downloading packages from the main Centos mirror repos, so our external bandwidth will take a hit. However, this is a compromise that we need to make, because the only other alternatives I have is
to run a CLM project which will take me several hours extra a week, or to bypass Uyuni entirely and either download all packages directly or to use an alternative repo manager.
>
> On that last point, it's clear that Uyuni is not the only toolchain that has been broken by this change to modules. Pulp<
https://pulpproject.org/>, which I think has a larger *EL userbase than Uyuni, has quite a collection
of bug reports about it. I understand they have managed to solve the issue, and perhaps there is a method from them that can be used for Uyuni too?
> I am mindful that this is not a "Suse problem" and us poor Centos/Rhel/Fedora/Rocky/Alma/Amazon/Alibaba users, who have suffered so much from Redhat's business decisions over the past years, are grateful for the support that can be given.
> Thanks as ever,
> Simon
>
>
>
> -----Original Message-----
> From: Michael Calmer <mc@suse.de>
> Sent: 10 June 2021 15:00
> To: users@lists.uyuni-project.org
> Subject: [EXTERNAL EMAIL] Re: [EXTERNAL] Re: Centos 8 module updates - how are people dealing with this?
>
> Hi
>
> I doubt that every system needs an own clone.
> In best case you just need 1 for all. You just need to decide what streams you want to use and not use on every system a different stream combination.
>
> In uyuni we have special UIs (and APIs) for creating Projects and Environments.
> If you want an easy case, you just create 1 project with 1 environment.
> You create a module filters and select for every module the stream you want to have in the resulting repo.
>
> After the setup is done, you just need to press 1 button and all the cloning and other calculations are done.
> You get the final repositories and can update.
>
> Next day (if you want to patch) you just go to that project and press the build button again.
> It will re-build the environment and you will get the latest updates and changes from "last night" into your environment.
> So "Day 2" operation is just to click 1 Button.
>
> But here I could think of a first feature request: put a schedule on it to automate the rebuilding.
> This may not be a good solution for big companies, but would make things easier for smaller who would otherwise just connect directly to the repos.
>
> Am Donnerstag, 10. Juni 2021, 15:45:21 CEST schrieb Allen Beddingfield:
> > When you refer to the "Content Lifecycle Management Process", I assume you mean cloning repos from a particular day, making changes, and associating those with the managed server, instead of the live once that is being synced?
> > That is a whole other process that has to be implemented, just to work around this. Luckily, we only have a small handful of non SUSE or openSUSE systems to deal with this problem on, but having to clone and maintain repos for them is not really feasible.
I can't imagine it being an option for someone with hundreds of CentOS 8 systems, who isn't doing this with current systems.
> >
> > --
> > Allen Beddingfield
> > Systems Engineer
> > Office of Information Technology
> > The University of Alabama
> > Office 205-348-2251
> > allen@ua.edu
> >
> >
> > ________________________________________
> > From: cbbayburt <cbbayburt@suse.de>
> > Sent: Thursday, June 10, 2021 8:35 AM
> > To: users@lists.uyuni-project.org
> > Subject: [EXTERNAL] Re: Centos 8 module updates - how are people dealing with this?
> >
> > Hi Simon,
> >
> > On 2021-06-09 14:49, Simon Avery wrote:
> > > Hello,
> > >
> > > The recent Centos 8.4 release appears to have triggered more issues
> > > for us, and made me review how we manage our Centos 8 clients. We
> > > plan to move to Rocky soon but the same issue will persist there.
> > >
> > > Currently: Uyuni syncs Centos repos. My workaround so far has been
> > > to run "dnf -y update" on a schedule to each client instead of
> > > patching from within Uyuni as we do with Centos7. This pulls
> > > packages from the Uyuni mirror and has largely worked okay, but not
> > > any longer - lots of module related issues on all C8 clients since I
> > > updated the repos to 8.4. I'm not clear exactly why this has
> > > triggered this problem re-appearing, but it has. My understanding of
> > > this is that Uyuni doesn't update the module metadata when it
> > > populates its repositories, so the clients can't see this and fail.
> >
> > We as Uyuni team recommend consuming AppStream repositories through
> > the Content Lifecycle Management process so that you can benefit from
> > all the features that SUMA UI provides. However, I understand that the
> > method you described above can be preferred for smaller environments
> > as it is more agile and direct.
> > For that reason, we'd like to keep this as a valid option for those
> > who prefer this approach. Basically, I'd like to see this working in
> > the upcoming updates of any modular repository as well. So, please
> > feel free to open an issue on GitHub, describing the actual problem
> > you're having in detail, and we can work towards fixing it.
> >
> > > I've read about the Uyuni method of using the Content Lifecycle and
> > > have trialled this. This does work, but we don' t particularly want
> > > to be manually doing this for each Centos update or patch cycle.
> > > We're not big enough to warrant a corporate approval cycle for
> > > Centos, so updates are directly applied to our servers. (This has
> > > resulted in relatively few issues)
> > >
> > > The only other method I can think of is to change the clients to
> > > having local .repo files and pull updates directly from the Centos
> > > mirror. This obviously negates some of the benefits Uyuni brings to
> > > package management, but would work reliably.
> > >
> > > So I'm wondering - how are the other Centos/Alma/Oracle/Rocky 8
> > > users of Uyuni applying updates, and how have you overcome the
> > > module problems?
> > >
> > > Simon Avery
> > > Linux Systems Administrator
> >
> > Cheers,
> > Can
> > --
> > --
> > Can Bulut Bayburt <cbbayburt@suse.de>
> > Software Developer, SUSE Manager, R&D
> >
> > SUSE Software Solutions Germany GmbH
> > Maxfeldstr. 5
> > 90409 Nuremberg
> > Germany
> >
>
>
> --
> Regards
>
> Michael Calmer
>
> --------------------------------------------------------------------------
> Michael Calmer
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg
> T: +49 (0) 911 74053 0
> F: +49 (0) 911 74053575 - e-mail: Michael.Calmer@suse.com
> --------------------------------------------------------------------------
> SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer (HRB 36809, AG Nürnberg)
>
--
Regards
Michael Calmer
--------------------------------------------------------------------------
Michael Calmer
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg
T: +49 (0) 911 74053 0
F: +49 (0) 911 74053575 - e-mail: Michael.Calmer@suse.com
--------------------------------------------------------------------------
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer (HRB 36809, AG Nürnberg)