On pe, 15 kesä 2018, Adam Williamson wrote:
On Fri, 2018-06-15 at 09:24 +0300, Alexander Bokovoy wrote:
> as discussed earlier, 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
> 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
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
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
I think we'll get back to that in F30-31 time. We aren't yet
point when we can provide a level of automation around Samba AD similar
to FreeIPA. However, I want to get there at some point.
/ Alexander Bokovoy