[Freeipa-devel] [RANT] --setattr validation is a minefield.

[Petr Viktorin]

On 04/11/2012 09:42 AM, Jan Cholasta wrote:
> On 11.4.2012 09:27, Martin Kosek wrote:
>> On Wed, 2012-04-11 at 09:18 +0200, Jan Cholasta wrote:
>>> On 10.4.2012 19:56, Dmitri Pal wrote:
...
>>>>
>>>> The use case I would see is the extensibility. Say a customer wants to
>>>> extend a schema and add an attribute X to the user object. He would
>>>> still be able to manage users using CLI without writing a plugin for
>>>> the new attribute. Yes plugin is preferred but not everybody would go
>>>> for it. So in absence of the plugin we can't do validation but we still
>>>> should function and be able to deal with this attribute via CLI (and UI
>>>> if this attribute is enabled for UI via UI configuration).
>>>>
>>>> I am generally against dropping this interface. But expectations IMO
>>>> should be:
>>>> 1) If the attribute is managed by us with setattr and friends it should
>>>> behave in the same way as via the direct add/mod/del command

Does this include refusing to modify no_update attributes?
Or do we treat those the same way as non-managed attributes (no 
validation.conversion)?
Or is it okay as it's done now, validating and updating as if no_update 
wasn't there?

>>>> 2) If attribute is not managed it should not provide any guarantees and
>>>> act in the same way as via LDAP

I never had an issue with the non-managed attributes; addattr is perfect 
for those.

>>>> Hope this helps.
>>> This might be the best thing to do, but IMO it is still no good, because
>>> the behavior of --{set,add,del}attr for a particular attribute might
>>> change between API versions, when that attribute changes from unmanaged
>>> to managed.
>>>
>>> Honza
>>>
>>
>> I think this is OK and expectable - user may use setattr option to set
>> an attribute before it is officially supported by IPA and still have it
>> working when he upgrades.
>
> There's no guarantee the user will still have it working. User
> application might break if it depends on the unmanaged behavior and we
> are too strict in validation of the managed attribute, for example. I
> don't known how much of an issue is this actually, but this kind of
> unpredictability is not a good thing IMHO.

Since our validation now allows working with bad attributes, just not 
adding new ones, I think this is not much of a problem.

>> Though we should make sure that we describe
>> this API well in our documentation to make sure this expectation is
>> shared with users.
>>
>> Martin
>>
>
> Honza
>


-- 
Petr³