389ds / 389-ds-base

The enterprise-class Open Source LDAP server for Linux
https://www.port389.org/
Other
211 stars 91 forks source link

Disable MEP plugin by default #2377

Open 389-ds-bot opened 4 years ago

389-ds-bot commented 4 years ago

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/49318


Issue Description

Even if the MEP plugin is not being used/configured, it still causes a significant amount of overhead for update operations. I saw almost a 10% modrate performance boost with this plugin disabled.

It should be disable by default.

However, I'm not sure how this might impact IPA, as IPA might expect it to be enabled by default during installation.

Opening ticket for investigation...

389-ds-bot commented 4 years ago

Comment from abbra at 2017-07-07 15:48:35

Yes, FreeIPA does not explicitly enable mep plugin but expects it is enabled -- some of update files actually modify cn=Managed Entries,cn=plugins,cn=config content.

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2017-07-13 05:59:57

@abbra We have an issue where MEP causes a perf issue by default. That's why we want to disable it by default.

I would have expected that IPA does a check for the existance of the plugin rather that assuming it's there though.

@mreynolds389 Is there a reason we couldn't track down the perf issue instead? Perhaps if there are no mep configs we shortcut and no-op?

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2017-07-13 05:59:58

Metadata Update from @Firstyear:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2017-07-13 06:14:29

@abbra We have an issue where MEP causes a perf issue by default. That's why we want to disable it by default. I would have expected that IPA does a check for the existance of the plugin rather that assuming it's there though. @mreynolds389 Is there a reason we couldn't track down the perf issue instead? Perhaps if there are no mep configs we shortcut and no-op?

It needs more investigation, but I think the perf hit is the plugin trying to see if it should do something or not. It always does an internal search for every mod.

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2017-07-13 06:18:20

@mreynolds389 Is it trying to find the mep template perhaps? Maybe we should be internally caching the template when it changes istead of looking it up each op ....

As well, we should make it postop, not pre, because there is some issue atm with it being in pre. I have some test cases commented out in lib389 that can easily break mep ;)

389-ds-bot commented 4 years ago

Comment from lkrispen (@elkris) at 2017-07-14 16:48:02

created ipa ticket https://pagure.io/freeipa/issue/7061 to be independent

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2017-08-10 17:31:52

Metadata Update from @mreynolds389:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2017-08-10 17:35:44

Need to file RN with doc team about this change

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2019-08-23 20:20:48

Metadata Update from @mreynolds389:

389-ds-bot commented 4 years ago

Comment from vashirov (@vashirov) at 2020-03-11 15:41:07

Metadata Update from @vashirov:

389-ds-bot commented 4 years ago

Comment from mreynolds (@mreynolds389) at 2020-05-08 17:03:00

Part of the performance issue might be addressed in this ticket:

4129

vashirov commented 2 months ago

We should test the performance impact of MEP, maybe it was already addressed. If not, we should disable it by default, and work with FreeIPA to ensure they don't rely on MEP being enabled by default.

Firstyear commented 2 months ago

FreeIPA does rely on MEP - it's how the synthesise user-private groups. However it should be up to FreeIPA to enable the plugin during their install process.