On 01/07/2020 17:55, Alexander Bokovoy wrote:

On ke, 01 heinä 2020, lejeczek via CentOS-devel wrote:

...

hi guys

latest in the repo krb5 packages - 1.18.2-2.el8 - brake freeIPA if already installed and conflict if want to install.

# dnf install -y ipa-server-dns Last metadata expiration check: 1:21:31 ago on Wed 01 Jul 2020 11:00:25 BST. Error:  Problem: package ipa-server-dns-4.8.4-7.module_el8.2.0+374+0d2d74a1.noarch requires ipa-server = 4.8.4-7.module_el8.2.0+374+0d2d74a1, but none of the providers can be installed   - conflicting requests   - nothing provides krb5-kdb-version = 7.0 needed by ipa-server-4.8.4-7.module_el8.2.0+374+0d2d74a1.x86_64

There should be no 1.18 in RHEL 8.2 at all, therefore CentOS 8.2 should not have krb5 1.18.

If you are using CentOS Stream, please make it clear in describing your configuration.

I can see krb5-1.18.2 in c8s branch here: https://git.centos.org/rpms/krb5/c/10fa7093df15784c58e82f89ba3e2a5ee0245991?...

There is no corresponding update for idm module, though.

There is no c8s-version of c8-stream-DL1 branch and therefore there is no idm:DL1 module rebuild.

Until that part is fixed, CentOS Stream is unusable for IdM deployments.

Please note that none of RHEL developers responsible for IdM have any say or control how things get merged into CentOS. If there are problems like this one nobody but CentOS maintainers could help. In case of CentOS 8 stream, it seems the whole process is done by a robot and I have no idea how this robot handles modular builds (and when).

And that seems to be a great shame, quite frankly I felt this way for a long months, probably since C8 release.

Maybe you guys @redhat could(should ?) take over "idm" module in Centos, or Centos' owners could ask for help and delegate "idm" over to you.

FreeIPA is way!!! to import to afford such cock-ups and it's been quite a wobbly ride on C8 since the beginning. Centos is a poor man choice but still seriously taken & deployed to critical environments and if my opinion is not an isolated one, then everybody will agree freeIPA must be taken care of properly.

many thanks, L.

On ke, 01 heinä 2020, Brian Stinson wrote:

On Wed, Jul 1, 2020, at 14:33, Alexander Bokovoy wrote:

...

On ke, 01 heinä 2020, lejeczek via CentOS-devel wrote:

...

hi guys

latest in the repo krb5 packages - 1.18.2-2.el8 - brake freeIPA if already installed and conflict if want to install.

# dnf install -y ipa-server-dns Last metadata expiration check: 1:21:31 ago on Wed 01 Jul 2020 11:00:25 BST. Error:  Problem: package ipa-server-dns-4.8.4-7.module_el8.2.0+374+0d2d74a1.noarch requires ipa-server = 4.8.4-7.module_el8.2.0+374+0d2d74a1, but none of the providers can be installed   - conflicting requests   - nothing provides krb5-kdb-version = 7.0 needed by ipa-server-4.8.4-7.module_el8.2.0+374+0d2d74a1.x86_64

Going back to the actual issue, the only solution right now is not to use CentOS 8 Stream, at least until all the required rebuilds are in place.

Right now CentOS 8 Stream contains exactly same IPA version as CentOS 8.2.2004. So you are not gaining anything by using the stream right now.

In CentOS Stream we're working on staying caught up to RHEL 8.3 development to jumpstart the automation that will handle this going forward. During this process we're finding that modules are a little bit unwieldy.

There are several rebases in RHEL 8.3 that require rebuild of idm module streams: krb5, samba, libldb are the requirements that need to be rebuilt before idm modules streams can be built. And changes in those packages also require rebuilding SSSD.

I don't think there is a support for a combined non-modular + modular sidetag rebuild in CentOS (it does not exist anywhere else too), so I would suggest taking care of the rebuilds together before pushing them into a publicly accessible tree. Otherwise there will be breakages like this -- which apparently is there for more than 3 weeks already.

On to, 02 heinä 2020, Troy Dawson wrote:

On Thu, Jul 2, 2020 at 12:38 AM Alexander Bokovoy abokovoy@redhat.com wrote:

...

On ke, 01 heinä 2020, Brian Stinson wrote:

...

On Wed, Jul 1, 2020, at 14:33, Alexander Bokovoy wrote:

...

On ke, 01 heinä 2020, lejeczek via CentOS-devel wrote:

...

hi guys

latest in the repo krb5 packages - 1.18.2-2.el8 - brake freeIPA if already installed and conflict if want to install.

# dnf install -y ipa-server-dns Last metadata expiration check: 1:21:31 ago on Wed 01 Jul 2020 11:00:25 BST. Error:  Problem: package ipa-server-dns-4.8.4-7.module_el8.2.0+374+0d2d74a1.noarch requires ipa-server = 4.8.4-7.module_el8.2.0+374+0d2d74a1, but none of the providers can be installed  - conflicting requests  - nothing provides krb5-kdb-version = 7.0 needed by ipa-server-4.8.4-7.module_el8.2.0+374+0d2d74a1.x86_64

Going back to the actual issue, the only solution right now is not to use CentOS 8 Stream, at least until all the required rebuilds are in place.

Right now CentOS 8 Stream contains exactly same IPA version as CentOS 8.2.2004. So you are not gaining anything by using the stream right now.

In CentOS Stream we're working on staying caught up to RHEL 8.3 development to jumpstart the automation that will handle this going forward. During this process we're finding that modules are a little bit unwieldy.

There are several rebases in RHEL 8.3 that require rebuild of idm module streams: krb5, samba, libldb are the requirements that need to be rebuilt before idm modules streams can be built. And changes in those packages also require rebuilding SSSD.

I don't think there is a support for a combined non-modular + modular sidetag rebuild in CentOS (it does not exist anywhere else too), so I would suggest taking care of the rebuilds together before pushing them into a publicly accessible tree. Otherwise there will be breakages like this -- which apparently is there for more than 3 weeks already.

Yep. There are breakages in idm, and other packages.

They aren't breakages, they are rebases. :)

But, there are two things that this entire conversation is completely missing.

1 - CentOS Stream is NOT equal to RHEL 8.<next> general release, it IS equal to RHEL 8.<next> Alpha. Yes, Alpha. Not even Beta. This whole conversation is acting like CentOS Stream should be production ready. It should not. It is to allow the general public to see what is going into the next release, problems and all. If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem.

2 - CentOS Stream was announced that it would be ready in December 2020. That's still 5 months from now. Give the team a break. They are still setting up infrastructure, workflows, and who knows what else.

For years people have gotten on CentOS's case because they are not transparent enough, and don't give people access to stuff before it's 100% ready. And now when they do, you are acting like they should take the whole thing back and wait until it's completely ready. Well, completely ready is not CentOS Stream. That's CentOS.

+1. I only would add that transparency is still not there but in this case the transparency how CentOS Stream updates happen and how to get involved with that -- how to help define logic, advise of how rebuilds should be done for specific package sets, etc. There is still something similar to a black hole with all this process: you can see its gravitational effects but cause no effect yourself to help smoothing the rebuilds.

Note that if the rebuild process for such rebases could be automated, I'd love to be able to reuse it for RHEL too. We spent six weeks rebasing krb5/samba/idm:DL1 for RHEL 8.0 last year due to various problems. If CentOS Stream is capable to automate the process to get it down to even one week, that would be awesome to reuse elsewhere.

On to, 02 heinä 2020, Brian Stinson wrote:

On Thu, Jul 2, 2020, at 09:13, Alexander Bokovoy wrote:

...

On to, 02 heinä 2020, Troy Dawson wrote:

...

On Thu, Jul 2, 2020 at 12:38 AM Alexander Bokovoy abokovoy@redhat.com wrote:

...

On ke, 01 heinä 2020, Brian Stinson wrote:

...

On Wed, Jul 1, 2020, at 14:33, Alexander Bokovoy wrote:

...

On ke, 01 heinä 2020, lejeczek via CentOS-devel wrote: >hi guys > >latest in the repo krb5 packages - 1.18.2-2.el8 - brake >freeIPA if already installed and conflict if want to install. > ># dnf install -y ipa-server-dns >Last metadata expiration check: 1:21:31 ago on Wed 01 Jul >2020 11:00:25 BST. >Error: > Problem: package >ipa-server-dns-4.8.4-7.module_el8.2.0+374+0d2d74a1.noarch >requires ipa-server = 4.8.4-7.module_el8.2.0+374+0d2d74a1, >but none of the providers can be installed > - conflicting requests > - nothing provides krb5-kdb-version = 7.0 needed by >ipa-server-4.8.4-7.module_el8.2.0+374+0d2d74a1.x86_64

Going back to the actual issue, the only solution right now is not to use CentOS 8 Stream, at least until all the required rebuilds are in place.

Right now CentOS 8 Stream contains exactly same IPA version as CentOS 8.2.2004. So you are not gaining anything by using the stream right now.

In CentOS Stream we're working on staying caught up to RHEL 8.3 development to jumpstart the automation that will handle this going forward. During this process we're finding that modules are a little bit unwieldy.

There are several rebases in RHEL 8.3 that require rebuild of idm module streams: krb5, samba, libldb are the requirements that need to be rebuilt before idm modules streams can be built. And changes in those packages also require rebuilding SSSD.

I don't think there is a support for a combined non-modular + modular sidetag rebuild in CentOS (it does not exist anywhere else too), so I would suggest taking care of the rebuilds together before pushing them into a publicly accessible tree. Otherwise there will be breakages like this -- which apparently is there for more than 3 weeks already.

Yep. There are breakages in idm, and other packages.

They aren't breakages, they are rebases. :)

...

But, there are two things that this entire conversation is completely missing.

1 - CentOS Stream is NOT equal to RHEL 8.<next> general release, it IS equal to RHEL 8.<next> Alpha. Yes, Alpha. Not even Beta. This whole conversation is acting like CentOS Stream should be production ready. It should not. It is to allow the general public to see what is going into the next release, problems and all. If people are running their production machines on CentOS Stream ... well, in my opinion, that's their problem.

2 - CentOS Stream was announced that it would be ready in December 2020. That's still 5 months from now. Give the team a break. They are still setting up infrastructure, workflows, and who knows what else.

For years people have gotten on CentOS's case because they are not transparent enough, and don't give people access to stuff before it's 100% ready. And now when they do, you are acting like they should take the whole thing back and wait until it's completely ready. Well, completely ready is not CentOS Stream. That's CentOS.

+1. I only would add that transparency is still not there but in this case the transparency how CentOS Stream updates happen and how to get involved with that -- how to help define logic, advise of how rebuilds should be done for specific package sets, etc. There is still something similar to a black hole with all this process: you can see its gravitational effects but cause no effect yourself to help smoothing the rebuilds.

I appreciate your willingness to jump in and help here. I will say that while we are in the first phase we (the Stream team) have a guiding principle that we push RHEL content in a way that RHEL maintainers don't yet have to notice/care/do-anything about the builds that land in Stream. Once Stream has exited this phase, we're in a little bit better position to let maintainers actually influence things here, and that's the ultimate goal. Until then this is our process:

1.) RHEL maintainer makes a change in the RHEL dist-git branch for a release (Currently we're focusing on 8.3) 2.) RHEL maintainer makes a RHEL build 3.) The build makes it into a RHEL nightly compose 4.) The Stream team periodically takes the RHEL nightly compose and pushes sources to git.centos.org 5.) The Stream team rebuilds the packages/modules just pushed 6.) The Stream team composes and pushes to the mirrors

In order to fully jump-start our automation we need to get and *stay* relatively caught up with RHEL development by hand. We're getting close to that milestone (save for a few hiccups with modules, and other issues that happen during a rebuild).

Thank you for the details, they are useful.

So one specific issue that I am facing and the one manifested here is that we currently have no support in Modularity for a sidetag rebuild of non-modular and modular content. This means rebases like 'libkrb5 changed ABI in KDB plugin, thus ipa-server needs a rebuilt' or 'samba changed internal ABI that ipasam module in ipa-server depends on' cannot be handled without pushing part of the packages to the nightly compose and then rebuilding next day against it.

This is what we see here. Capturing these kinds of changes and detecting that they break ABI of modular packages, thus need to be accumulated for a rebuild first would be great.

There is another, more practical issue we are witnessing: synchronization between RHEL dist-git and CentOS Stream dist-git for modules currently does not mangle module definitions (e.g. idm.yaml) to refer to the correct new branch name. As result, even though the module dist-git content is synchronized, it cannot be built as its packages' refs are pointing to RHEL branch names. Branch names are versioned and change with each release, so there should be some kind of automated branch reference replacement.

...

Note that if the rebuild process for such rebases could be automated, I'd love to be able to reuse it for RHEL too. We spent six weeks rebasing krb5/samba/idm:DL1 for RHEL 8.0 last year due to various problems. If CentOS Stream is capable to automate the process to get it down to even one week, that would be awesome to reuse elsewhere.

I'm not sure if our processes would help with that particular problem, but I'm happy to chat about those needs sometime.

Ok. May be after summer holidays and when we all have time. ;)

On Thu, Jul 2, 2020 at 8:36 PM Nico Kadel-Garcia nkadel@gmail.com wrote:

I'm going to restrain my commentary on the decisions for Samba to use Heimdal kerberos, Red Hat to use MIT kerberos, and the theory that those would someday be resolved. They're not, and support for Samba to use MIT kerberos remains listed in samba-4.12.5 released a few days ago as "experimental". I'm also miffed at Red Hat's continuing packaging of a "samba-dc" package that doesn't actually contain a domain controller.

Double checking, it looks like the empty samba-dc package was discarded from RHEL/CentOS 8.2. *Good*. .