Thanks for all the upstream work Alexander!
https://hachyderm.io/@sgnj151/109444697712463380
On Sat, Jul 22, 2023 at 2:44 PM Alexander Bokovoy abbra@fedoraproject.org wrote:
On Суб, 22 ліп 2023, Adam Williamson wrote:
On Sat, 2023-07-22 at 06:31 -0400, Neal Gompa wrote:
What I intend after that is that we will be OK with releasing so long as the automated tests against Samba AD pass, but if anyone decides to manually test against Microsoft AD and finds a bug, that can potentially be a blocker. But we will not block the release on making sure Microsoft AD has been tested.
Does this sound like a decent solution to everyone? Thanks!
Does that mean that we will also have tests for setting up and using Samba AD from Fedora? Because if we're going to block on client connectivity on Samba AD, I think we should also block on Samba AD from the server side too.
It means we'll have a test, but as things stand, failures of it won't be blocking, because "work as a Samba AD server" is not in the criteria.
You could, of course, propose a criterion change and we could debate it, though I think that might be a bit of a stretch - we already block on one domain server technology which is more in our ecosystem. Who's going to be the "throat to choke" for Samba AD server functionality if it breaks?
The same people who are responsible for 'FreeIPA server functionality if it breaks', for years.
We chose to have FreeIPA and Samba AD with MIT Kerberos as our domain controller technologies in Fedora more than a decade ago, we committed to develop them through Samba and FreeIPA upstreams, we keep doing so. Please watch our talk at SambaXP'23: 'Samba AD / MIT Kerberos: path out of experimental'.
https://www.youtube.com/watch?v=0_cdYuIYw0o
As I said, we already committed to this work for more than a decade ago in Fedora. We first announced productization of Samba AD DC with MIT Kerberos in Fedora 27 in 2017, this was a milestone which went into Fedora 27's release notes:
https://docs.fedoraproject.org/en-US/fedora/f27/release-notes/sysadmin/Domai...
As things stand, only failures in the client tests would be direct blockers; problems with the server test wouldn't be. (If we couldn't work around the server issues they would mean we'd have to fall back to testing manually against Microsoft AD to pass the client requirements, I guess, which would be a pain, but they wouldn't be blockers in themselves).
We do test weekly against Microsoft AD the following stack:
SSSD in direct integration with Microsoft AD domain (SSSD upstream)
SSSD on FreeIPA client, with IPA trust to Microsoft AD (FreeIPA upstream)
This happens on current Fedora N, on the Fedora N-1, and on Rawhide, every week. Issues typically get addressed upstream or investigated and filed against broken parties.
You don't see most of this in OpenQA testing in Fedora because we typically get through all failures prior to releasing to Fedora.
On Samba side, we have comprehensive test suite that allows us to get behavior pinned down against Microsoft AD implementation and then applied against both Samba AD/Heimdal and Samba AD/MIT Kerberos. There are differences but we are able to pin down those and generally know what happens or should happen. Samba upstream runs Fedora 38/MIT Kerberos target for each commit, on par with the rest of targets.
So we have pretty good coverage semantics-wise and OpenQA use here would be more of making sure other parts of Fedora don't unintentially break behavior of these enterprise environments.
-- / Alexander Bokovoy _______________________________________________ server mailing list -- server@lists.fedoraproject.org To unsubscribe send an email to server-leave@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/server@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue