Re: [Freeipa-devel] default / unexpressed / implicit values in LDAP and elsewhere

2015-11-26 Thread Jan Cholasta

Hi,

On 26.11.2015 14:17, Petr Spacek wrote:

Hello,

The Problem
===
During work on DNSSEC patches for FreeIPA it repeatedly happened that I had to
hard-code default values for optional LDAP attributes to various places.

A constant in code is a nice thing, but it does not help to CLI/WebUI/API
users because they do not see the default in ipa dnszone-show output etc.

Moreover, even the constant does not help when multiple code-bases are using
the default value, e.g. bind-dyndb-ldap (written in C) and FreeIPA framework
(written in Python).

What next?
==
I do not know :-) Following text is just boiling pure water.

Simplest thing to do would be to create a Python module like
ipa.defaults and create a dictionary with defaults for each object class.

I can imagine something like:

idnszone = {
 'idnssecinlinesigning': False
}

Then in Python code it would be easy to do
complete_object = ipa.defaults.idnszone.copy().update(object_from_LDAP)
And now the complete_object contains everything including optional (but in
fact not present) attributes which has a default value defined.


This would be very alien in the framework.



We might want to have some metadata for each attribute for various reasons.
E.g. some values should be only shown in WebUI and the attribute will be
populated, e.g. uid attribute is generated from first and last name when user
submits the form with empty 'uid' field. In other words, this default makes
sense on object creation but on when reading existing objects from LDAP.

The example with uid obviously calls for something more fancy. When one
attribute is generated from other attributes of the same object, it might be
sufficient to define a regex based on other attributes. Regex is easy to
evaluate in C, Python and Javascript, if we limit ourselves to intersection of
regex languages supported by libraries of our choice.

Now, we can take this dictionary and generate #define strings from it ...


Dynamic defaults would have to be fetched from the server with an API 
call. This will likely be part of the thin client / API compatibility 
feature.





The open question is how to handle defaults taken from another object, e.g.
when idnsallowtransfer attribute is inherited from global DNS configuration 
entry.

Any ideas?


Is api.Object.dnszone.get_default() not sufficient?

Honza

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


Re: [Freeipa-devel] default / unexpressed / implicit values in LDAP and elsewhere

2015-11-26 Thread Petr Spacek
On 26.11.2015 14:58, Jan Cholasta wrote:
> Hi,
> 
> On 26.11.2015 14:17, Petr Spacek wrote:
>> Hello,
>>
>> The Problem
>> ===
>> During work on DNSSEC patches for FreeIPA it repeatedly happened that I had 
>> to
>> hard-code default values for optional LDAP attributes to various places.
>>
>> A constant in code is a nice thing, but it does not help to CLI/WebUI/API
>> users because they do not see the default in ipa dnszone-show output etc.
>>
>> Moreover, even the constant does not help when multiple code-bases are using
>> the default value, e.g. bind-dyndb-ldap (written in C) and FreeIPA framework
>> (written in Python).
>>
>> What next?
>> ==
>> I do not know :-) Following text is just boiling pure water.
>>
>> Simplest thing to do would be to create a Python module like
>> ipa.defaults and create a dictionary with defaults for each object class.
>>
>> I can imagine something like:
>>
>> idnszone = {
>>  'idnssecinlinesigning': False
>> }
>>
>> Then in Python code it would be easy to do
>> complete_object = ipa.defaults.idnszone.copy().update(object_from_LDAP)
>> And now the complete_object contains everything including optional (but in
>> fact not present) attributes which has a default value defined.
> 
> This would be very alien in the framework.
> 
>>
>> We might want to have some metadata for each attribute for various reasons.
>> E.g. some values should be only shown in WebUI and the attribute will be
>> populated, e.g. uid attribute is generated from first and last name when user
>> submits the form with empty 'uid' field. In other words, this default makes
>> sense on object creation but on when reading existing objects from LDAP.
>>
>> The example with uid obviously calls for something more fancy. When one
>> attribute is generated from other attributes of the same object, it might be
>> sufficient to define a regex based on other attributes. Regex is easy to
>> evaluate in C, Python and Javascript, if we limit ourselves to intersection 
>> of
>> regex languages supported by libraries of our choice.
>>
>> Now, we can take this dictionary and generate #define strings from it ...
> 
> Dynamic defaults would have to be fetched from the server with an API call.
> This will likely be part of the thin client / API compatibility feature.
> 
>>
>>
>> The open question is how to handle defaults taken from another object, e.g.
>> when idnsallowtransfer attribute is inherited from global DNS configuration
>> entry.
>>
>> Any ideas?
> 
> Is api.Object.dnszone.get_default() not sufficient?

Good! I wanted something like this :-) We can dig into it later.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code