Hi,
as discussed earlier[1], I'm proposing to extend Fedora Server release criteria to include replicated topology testing for domain controllers shipped with Fedora Server. This is an aspirational goal as there are limiting factors right now.
Fedora Server ships with two domain controllers: FreeIPA and Samba AD. OpenQA infrastructure uses domain controller-agnostic approach to enroll clients and deploys domain controllers and clients with the help of rolekit. There is only one type supported currently to deploy a domain controller: FreeIPA, and only a single domain controller can be deployed.
As result, large part of FreeIPA functionality is not tested at all because we are not able to deploy FreeIPA replicas in OpenQA via rolekit. With an ongoing Python 3 and NSS to OpenSSL migration for FreeIPA, Dogtag, SSSD, and other related components, we aren't testing critical integration of these components within Fedora.
FreeIPA upstream has a testing infrastructure that allows to test different topologies for a replicated FreeIPA deployment. The tests run against each pull request upstream and there are 'nightly' test suites which kicked off several times a week. These tests, however, use a fixed Fedora image, regenerated regularly but typically tracking current Fedora stable release, not Rawhide.
Ideally, a test covering basic replication scenario needs to exist for Rawhide/Branched.OpenQA uses rolekit to deploy a DC. Rolekit does not have support for deploying a replica. Rolekit is supposed to be deprecated (dead in development). It shouldn't be hard to extend rolekit to run FreeIPA replica promotion, though.
Based on the above, if we would extend rolekit, I believe it would be relatively easy to extend OpenQA tests to add a second domain controller into a test environment and check whether a client enrolled into the domain against one domain controller can use management services from the other domain controller.
When such extension is ready for FreeIPA, we can establish a release criteria to include a test of replicated topology for domain controller technology in Fedora Server.
Note that I'm trying to keep this generic to allow us to add Samba AD as a tested domain controller later. This, however, raises a question on whether rolekit way of configuring servers is a right approach going forward.
On pe, 15 kesä 2018, Alexander Bokovoy wrote:
Hi,
as discussed earlier[1], I'm proposing to extend Fedora Server release criteria to include replicated topology testing for domain controllers shipped with Fedora Server. This is an aspirational goal as there are limiting factors right now.
Fedora Server ships with two domain controllers: FreeIPA and Samba AD. OpenQA infrastructure uses domain controller-agnostic approach to enroll clients and deploys domain controllers and clients with the help of rolekit. There is only one type supported currently to deploy a domain controller: FreeIPA, and only a single domain controller can be deployed.
As result, large part of FreeIPA functionality is not tested at all because we are not able to deploy FreeIPA replicas in OpenQA via rolekit. With an ongoing Python 3 and NSS to OpenSSL migration for FreeIPA, Dogtag, SSSD, and other related components, we aren't testing critical integration of these components within Fedora.
FreeIPA upstream has a testing infrastructure that allows to test different topologies for a replicated FreeIPA deployment. The tests run against each pull request upstream and there are 'nightly' test suites which kicked off several times a week. These tests, however, use a fixed Fedora image, regenerated regularly but typically tracking current Fedora stable release, not Rawhide.
Ideally, a test covering basic replication scenario needs to exist for Rawhide/Branched.OpenQA uses rolekit to deploy a DC. Rolekit does not have support for deploying a replica. Rolekit is supposed to be deprecated (dead in development). It shouldn't be hard to extend rolekit to run FreeIPA replica promotion, though.
Based on the above, if we would extend rolekit, I believe it would be relatively easy to extend OpenQA tests to add a second domain controller into a test environment and check whether a client enrolled into the domain against one domain controller can use management services from the other domain controller.
When such extension is ready for FreeIPA, we can establish a release criteria to include a test of replicated topology for domain controller technology in Fedora Server.
Note that I'm trying to keep this generic to allow us to add Samba AD as a tested domain controller later. This, however, raises a question on whether rolekit way of configuring servers is a right approach going forward.
Forgot to add a reference [1] https://lists.fedorahosted.org/archives/list/server@lists.fedoraproject.org/...
On Fri, 2018-06-15 at 09:24 +0300, Alexander Bokovoy wrote:
Hi,
as discussed earlier[1], I'm proposing to extend Fedora Server release criteria to include replicated topology testing for domain controllers shipped with Fedora Server. This is an aspirational goal as there are limiting factors right now.
Fedora Server ships with two domain controllers: FreeIPA and Samba AD. OpenQA infrastructure uses domain controller-agnostic approach to enroll clients and deploys domain controllers and clients with the help of rolekit. There is only one type supported currently to deploy a domain controller: FreeIPA, and only a single domain controller can be deployed.
As result, large part of FreeIPA functionality is not tested at all because we are not able to deploy FreeIPA replicas in OpenQA via rolekit. With an ongoing Python 3 and NSS to OpenSSL migration for FreeIPA, Dogtag, SSSD, and other related components, we aren't testing critical integration of these components within Fedora.
FreeIPA upstream has a testing infrastructure that allows to test different topologies for a replicated FreeIPA deployment. The tests run against each pull request upstream and there are 'nightly' test suites which kicked off several times a week. These tests, however, use a fixed Fedora image, regenerated regularly but typically tracking current Fedora stable release, not Rawhide.
Ideally, a test covering basic replication scenario needs to exist for Rawhide/Branched.OpenQA uses rolekit to deploy a DC. Rolekit does not have support for deploying a replica. Rolekit is supposed to be deprecated (dead in development). It shouldn't be hard to extend rolekit to run FreeIPA replica promotion, though.
Based on the above, if we would extend rolekit, I believe it would be relatively easy to extend OpenQA tests to add a second domain controller into a test environment and check whether a client enrolled into the domain against one domain controller can use management services from the other domain controller.
When such extension is ready for FreeIPA, we can establish a release criteria to include a test of replicated topology for domain controller technology in Fedora Server.
Note that I'm trying to keep this generic to allow us to add Samba AD as a tested domain controller later. This, however, raises a question on whether rolekit way of configuring servers is a right approach going forward.
Rolekit is supposed to go away; what we're missing there is basically someone doing the work of reformulating the PRD, tech spec and then criteria around...*not* using rolekit. Once that's done we can update the test cases and the openQA tests.
As a practical matter, we can implement testing of this without extending rolekit, I think. All rolekit ultimately does is call ipa- server-install. We could certainly retain the existing deployment of the *initial* controller via rolekit, but extend things so we deploy a replica controller not via rolekit.
It's currently intentional that we do not treat Samba AD as release- blocking / supported / whatever for Server. It's just outside the scope of Server by design. What's in scope is acting as a *client* of an Active Directory domain, but we specifically mean actual Microsoft AD domains there, not Samba AD. This could be revisited, but it was specifically decided back when we were initially setting up the Server requirements.
On pe, 15 kesä 2018, Adam Williamson wrote:
On Fri, 2018-06-15 at 09:24 +0300, Alexander Bokovoy wrote:
Hi,
as discussed earlier[1], I'm proposing to extend Fedora Server release criteria to include replicated topology testing for domain controllers shipped with Fedora Server. This is an aspirational goal as there are limiting factors right now.
Fedora Server ships with two domain controllers: FreeIPA and Samba AD. OpenQA infrastructure uses domain controller-agnostic approach to enroll clients and deploys domain controllers and clients with the help of rolekit. There is only one type supported currently to deploy a domain controller: FreeIPA, and only a single domain controller can be deployed.
As result, large part of FreeIPA functionality is not tested at all because we are not able to deploy FreeIPA replicas in OpenQA via rolekit. With an ongoing Python 3 and NSS to OpenSSL migration for FreeIPA, Dogtag, SSSD, and other related components, we aren't testing critical integration of these components within Fedora.
FreeIPA upstream has a testing infrastructure that allows to test different topologies for a replicated FreeIPA deployment. The tests run against each pull request upstream and there are 'nightly' test suites which kicked off several times a week. These tests, however, use a fixed Fedora image, regenerated regularly but typically tracking current Fedora stable release, not Rawhide.
Ideally, a test covering basic replication scenario needs to exist for Rawhide/Branched.OpenQA uses rolekit to deploy a DC. Rolekit does not have support for deploying a replica. Rolekit is supposed to be deprecated (dead in development). It shouldn't be hard to extend rolekit to run FreeIPA replica promotion, though.
Based on the above, if we would extend rolekit, I believe it would be relatively easy to extend OpenQA tests to add a second domain controller into a test environment and check whether a client enrolled into the domain against one domain controller can use management services from the other domain controller.
When such extension is ready for FreeIPA, we can establish a release criteria to include a test of replicated topology for domain controller technology in Fedora Server.
Note that I'm trying to keep this generic to allow us to add Samba AD as a tested domain controller later. This, however, raises a question on whether rolekit way of configuring servers is a right approach going forward.
Rolekit is supposed to go away; what we're missing there is basically someone doing the work of reformulating the PRD, tech spec and then criteria around...*not* using rolekit. Once that's done we can update the test cases and the openQA tests.
As a practical matter, we can implement testing of this without extending rolekit, I think. All rolekit ultimately does is call ipa- server-install. We could certainly retain the existing deployment of the *initial* controller via rolekit, but extend things so we deploy a replica controller not via rolekit.
Yep, with current IPA using 'ipa-replica-install' will allow to install a replica in the same way as 'ipa-server-install' is run. In past it required doing that in two steps, producing a replica file on the master and then moving that to the replica-to-be. It is not needed anymore.
It's currently intentional that we do not treat Samba AD as release- blocking / supported / whatever for Server. It's just outside the scope of Server by design. What's in scope is acting as a *client* of an Active Directory domain, but we specifically mean actual Microsoft AD domains there, not Samba AD. This could be revisited, but it was specifically decided back when we were initially setting up the Server requirements.
I think we'll get back to that in F30-31 time. We aren't yet at the point when we can provide a level of automation around Samba AD similar to FreeIPA. However, I want to get there at some point.
server@lists.fedoraproject.org
-
Adam Williamson -
Alexander Bokovoy