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@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
_______________________________________________
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