Hi William,
I updated the design according to our offline exchange
regards
thierry
On 3/17/20 11:12 AM, thierry bordaz wrote:
On 3/17/20 2:42 AM, William Brown wrote:
>
>> On 17 Mar 2020, at 02:49, thierry bordaz <tbordaz(a)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(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> _______________________________________________
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...
_______________________________________________
389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
To unsubscribe send an email to 389-devel-leave(a)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.fedoraproje...