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.


Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to