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

[Petr Viktorin]

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.

http://www.freeipa.org/page/HowTo/Add_a_new_attribute

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

Keep in mind that clients would need the info too.

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

Having one definitive list for the framework, UI, and various flags like 
default_attributes is the better design, but sadly without much 
practical advantage except the configurability.

And the configurability would be limited. Lots of IPA code depends on 
"our" attributes being there, so users would need to only add additional 
ones, or risk breaking something. For small things a schema change and 
--setattr is enough (except the Web UI needs a way to do setattr too). 
If they need to add something big (custom validators, interdependencies 
between attributes), they'll need to write code anyway.

> 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

It would be a pretty large change, and it would need to be designed 
carefully to deal with replication, clients, data/schema/API versioning, 
etc.
Don't get me wrong, I'd love to implement this, but I don't think 
there's enough demand/value to justify it.


I filed a RFE: https://fedorahosted.org/freeipa/ticket/3595

-- 
Petr³