[Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts

[Jan Cholasta]

On 2.5.2013 12:52, Martin Kosek wrote:
> On 04/26/2013 07:02 PM, Dmitri Pal wrote:
>> On 04/26/2013 06:47 AM, Petr Viktorin wrote:
>>> On 04/25/2013 06:59 PM, Dmitri Pal wrote:
>>>> Also we have, I suspect a lot of metadata about attributes encoded in
>>>> the framework, right?
>>>> Why can't we use some kind of the data file(s) for it? This way one can
>>>> add attributes dynamically and the framework would pick them up.
>>>> It is clear that it would have to be done on all replicas
>>>
>>> So we should store it in LDAP and have it replicated.
>>
>>
>> I am not against it. Files might be an interim step before getting there.
>>
>>>
>>>> but still it
>>>> would not require people to change the code - only configuration. Have
>>>> we ever thought about this?
>>>
>>> If you're talking about parameters in the the framework commands, I
>>> think --setattr is fine.
>>> Or is this also about the schema? Web UI?
>>>
>>
>> There are three parts:
>> a) Schema
>> b) Code
>>
>> option: Str('userclass', attribute=True, cli_name='class', multivalue=True, required=False)
>> ...
>> option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, query=True, required=False)
>> ...
>> option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, required=False)
>>
>> +        Str('userclass*',
>> +            cli_name='class',
>> +            label=_('Class'),
>> +            doc=_('Host category (semantics placed on this attribute are for '
>> +                  'local interpretation)'),
>> +        ),
>>       ) + ticket_flags_params
>>
>> + test
>>
>> This code can be completely parametarized and values read from the LDAP
>> or files
>>
>> c) UI metadata - should be similar to above
>>
>> Then adding a new field would be equivalent to changing the schema and
>> adding an entry or two - it is not a a software update per say.
>>
>> We would need to keep the data version clear rather than in addition to
>> the hardcoded version in the code
>
> d) custom normalizer - function able to normalize data added by user
>
> e) custom validator - function able of validation of user data
>
> f) custom processing based on the attribute which is being done in a pre or
> post callback
>
> I think that defining attribute in LDAP would solve only a small portion of
> user use cases. This approach would not be able to store d), e) and f) as I do
> not think we want to execute code stored in LDAP... I still think that custom
> user plugins for server/client part and for the Web UI is the way to go.

+1, I think custom plugins is the way to go. But we should first make 
installing user plugins easier (allow loading plugins from arbitrary 
python packages - not just ipalib.plugins and friends - etc.)

Honza

-- 
Jan Cholasta