On Thu, Mar 02, 2017 at 08:12:04AM +0100, Martin Babinsky wrote:
> On 03/01/2017 05:28 PM, Alexander Bokovoy wrote:
> > On ke, 01 maalis 2017, Simo Sorce wrote:
> > > > > My take is: cut API/UI work, and do the underlying infrastructure work
> > > > > for the widest set of serves/clients possible instead.
> > > > >
> > > > > It is much more important to get the underlying gears done than to add
> > > > > UI candy, that can be delayed.
> > > > >
> > > > > Simo.
> > > > >
> > > > 
> > > > I agree, we just have to come to agreement of *which* gears are really
> > > > necessary.
> > > 
> > > Indeed, but adding attributes to ipaConfig and the ID Views is not hard,
> > > it is a matter of extending two objectclasses instead of one ... if we
> > > decide that Id Views are a good abstraction point.
> > Adding the same attribute to ID View and to ipaConfig sounds logical to
> > me.
> > 
> > Martin, if you want help with this, I can implement ID View-related
> > parts. SSSD does have code to retrieve ipaConfig already, and it also
> > has support for reading ID View associated with the host. The resulting
> > value wouldn't end up in the same place, though, but this is something
> > to handle on SSSD side.
> > 
> I was thinking about this at night (insomnia FTW) and it is actually pretty
> easy to extend ID view with the same attribute (see my other reply to Simo).
> Given the UI will be pretty dumb, we just can add the new attribute to the
> ID view object and a common code will be responsible for validation of
> changed values.

(I'm sorry to come late to the discussion, but I spent yesterday
debugging a nasty issue in SSSD and my brain wasn't working anymore)

To be honest, I haven't heard about users requesting to set the feature
per-host. Most were interested in a global setting and given the short time
before the next release, I thought for users who need a per-client solution,
a local sssd.conf modification could also work, also considering that the
/only/ solution so far was to modify sssd.conf with the default_domain_suffix

On the other hand, I see Simo's point about easy migration to this new
setting and easier tinkering with the option if it's possible to set
this per-view. And more importantly, I'm quite sure someone /will/ ask to
set this centrally, but per host(group) eventually.

So as long as the final design is a) extendable to provide a per-host
setting in the future, even if that part is not implemented in this version
in the UI or not used by the clients immediatelly and b) it's easy for
clients to consume this setting, I'm fine.

I'm afraid I can't comment on the ipaConfig issues and the replication
concerns as I'm not that proficient with IPA internals..

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

Reply via email to