On 03/02/2017 04:11 PM, Jakub Hrozek wrote:
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.


I agree, we just have to come to agreement of *which* gears are really

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

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..

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.

That's ok, the thing is that you will be consuming this information so we should try our best to make you happy :).

Martin^3 Babinsky

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

Reply via email to