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

Martin Kosek mkosek at redhat.com
Thu May 2 10:51:04 UTC 2013

On 04/29/2013 05:35 PM, Petr Viktorin 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:
>>>> 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

Thanks. When I finish and deploy the mediawiki version with better CSS and
syntax highlighing it will look even better :-)


More information about the Freeipa-devel mailing list