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
