On Tue, 2015-05-26 at 17:09 +0200, Christian Heimes wrote: > On 2015-05-26 16:50, Nathaniel McCallum wrote: > > Right. So as I see it, we have three options: > > 1. Merge kdcproxy soon with a global switch. > > A. Build per-replica switches later. > > B. Never build per-replica switches. > > 2. Merge kdcproxy later with per-replica switches. > > > > I don't think having both types of switches is bad UX. In fact, I > > think > > it is better UX than per-replica switches alone. Since per-replica > > switches are a superset of the global switch functionality, let's > > do 1A > > and do per-replica switches later (if needed and feasible) > > You know what? That was basically my second implementation. :) I had > a > global switch in cn=ipaConfig,cn=etc and a per-replica switch in > cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. The code is still in > another branch on my laptop. > > Since I have both variants mostly implemented, I'd like to suggest > yet > another option: > > 2. Merge kdcproxy with global and per-replica switch, but for now > offer > only a CLI command for the global switch. > > That's easy to implement. I only need an ACI for > cn=masters,cn=ipa,cn=etc in order to allow compare and search for > ipaConfigString=enabledService.
I don't want to add code that: 1. is half-baked 2. we aren't committed to supporting. I'd rather land per-replica switches as a separate commit with everything polished and supportable. Nathaniel -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code