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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
