On 3/17/20 2:42 AM, William Brown wrote:
>
>> On 17 Mar 2020, at 02:49, thierry bordaz <tbordaz@redhat.com> wrote:
>>
>> Hi,
>>
>> As a follow up of the PR https://pagure.io/389-ds-base/pull-request/50939,
>> I wrote down a small design about rewriters (filter/computed_attr) plugin: http://www.port389.org/docs/389ds/design/search_rewriters.html
>>
>> Comments are welcome
> Probably the most dangerous thing to say in all of history?
Well decisions are dangerous. Sharing your wise comments reduce the risk
of bad decisions ;)
So be sure I sincerely appreciate your feedback.
>
> Like, your design is very smart, but that cleverness and flexibility carries many risks. The problem at hand is rewriting ad attributes - not to make a framework. I still say focus on that problem alone rather than trying to solve a generic class of problems.
>
> Anyway, I still don't think this is the right avenue. There are two major reasons for this:
>
> First, is the attempt to make a "generic framework" to solve a "specific problem". We should not have a generic rewrite framework, when all we need is a specific, focused, module just for doing known and well tested attribute transformations.
>
> Code like COS or MEP may be generic, and it solves many cases but the surface area is huge, it's hard to test, and it's hard to reason about.
>
> We do not have a need for allowing generic, and arbitrary rewriters to exist, especially not when you have to "compile in" the rewriters anyway!
Rewriting attributes is not a problem it is what LDAP clients do need.
But I agree rewriting attributes is not that easy.
Clearly we have been hitting a regular demand to rewrite attributes and
attributes values. Many plugins (cos, mep, addn, roles, views,
slapi-nis, filter/attribute rewriters and now AD attributes, vsphere
integration) have been related to rewrite attributes/values. This has
always been a big need. Many parts of those plugins are similar (finding
pattern, scope, craft values..) but implemented in a slightly different
way. Those plugins are generic and already let the client select,
through config, the specific transformation they need. This design does
not introduce a new generic plugin but just simplify the use of already
supported interfaces.
IMHO those interfaces are clever as they are flexible and opened. They
do not force rewriters to use strict and limited abilities of plugins
(like cos, mep,..) and let them be as complex as they need to match
their needs.
>
> This should be simply, an "ad rewrite" plugin, where all it does is that one thing - rewrite the attributes as required for AD emulation for IPA. This is far easier to deploy, test and reason about. Ideally, the configuration is simply "the plugin is enabled or disabled".
>
>
> Second, is the idea of this being a "search rewriter". I don't think this is a good idea. The search path should be simple, it's our hot path. We have many things that have to interact like indexes etc. Look at virtual attribute indexing and such and the work needed for COS to have these used?
>
> This plugin should be on the write path, transforming when a change occurs. This means the code is much simpler, easier to test, and we need no modifications to our read paths. Things like MEP and replication will "just work" as will indexing and much more.
I disagree here. Many time the write path is just not possible. Because
of schema or historical reason, the entries already exist and will not
be updated. The customer just want to see them in a transformed way.
Sometime they can not even run a batch load to provision the missing
attributes/values.
>
>
> For me to approve this plugin, I really want to see it being a write-path transformation of values into other values, and it should be focused, targeted, and simple.
>
> I do want to make one thing clear though - I think it's much better that this plugin exist in 389-ds rather than in freeipa. The 389-ds project has better tooling (like ASAN/LSAN), faster testing capability and a group of subject matter experts for code review. I think that if you were to move this to freeipa, you would not have the same level of testing or review quality as here, so I'd prefer to see you put it here. Sure, I might be difficult on this topic, but I do it because I believe there is a better, more robust manner to approach this problem space than currently you are considering. :)
I agree with you. I prefer the rewriter callback be part of 389-ds
because I think the more rewriter samples the easier a developer will do
his own.
best regards
thierry
>
>
> Thanks,
>
>
>> best regards
>> thierry
>> _______________________________________________
>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
_______________________________________________
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
No comments:
Post a Comment