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


Jan Cholasta

Freeipa-devel mailing list

Reply via email to