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