On Thu, Mar 02, 2017 at 02:47:24PM +0100, Martin Babinsky wrote: > On 03/02/2017 10:25 AM, Jakub Hrozek wrote: > > 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 > > hack. > > > > 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.. > > > > If we introduce a new objectclass providing the attribute, we may then > easily extend IDView object by it (or any other object for that matter) and > fix the plugin code so that it can be set by framework, it is easy. > > If you all agree that this is the way we want to move forward with this > project, I can update the design page and start implementing stuff. We need > to decide quicky, time is short.
This sounds good to me from purely the client perspective, but I'm hardly the best person to decide IPA server-side design questions. -- 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