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

[Martin Kosek]

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:
>>> On 04/25/2013 09:54 AM, Martin Kosek wrote:
>>>> On 04/25/2013 12:37 PM, Petr Viktorin wrote:
>>>>> On 04/23/2013 10:10 AM, Martin Kosek wrote:
>>>>>> This new freeform host attribute will allow provisioning systems
>>>>>> to add custom tags for host objects which can be later used for
>>>>>> in automember rules or for additional local interpretation.
>>>>>>
>>>>>> Design page:
>>>>>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems
>>>>>>
>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3583
>>>>>>
>> [...]
>>>
>>> Can we use this patch to create a HOWTO on how to add and LDAP attribute
>>> to IPA?
>>
>> Yes, I can annotate the patch and put it on the wiki. I'll do it once
>> it's pushed so I can link to it.
>>
>> I know we're trying to organize the wiki page names. What's the
>> correct location for a developer-focused HOWTO?
> 
> I do not have a preference. Whatever makes sense.
> 
>>
>>> 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.

Martin