On 02/25/2015 04:00 PM, Alexander Bokovoy wrote:
> On Wed, 25 Feb 2015, Martin Basti wrote:
>> On 25/02/15 15:37, Alexander Bokovoy wrote:
>>> On Wed, 25 Feb 2015, Martin Basti wrote:
>>>> * All plugins are migrated into new configuration style.
>>>> * I left attribute uniqueness plugin disabled, cn=uid
>>>> uniqueness,cn=plugins,cn=config is checking the same attribute.
>>>> * POST_UPDATE plugin for uid removed, I moved it to update file. Is it okay
>>>> Alexander? I haven't found reason why we need to do it in update plugin.
>>> So I looked up the original thread and since there are three different
>>> ways of defining uniqueness plugin's configuration, update plugin was to
>>> me the only way to handle all different configuration types. In general
>>> we cannot rely on the fact that FreeIPA deployment only contains
>>> FreeIPA-defined plugin configurations.
>> IMO, we should care only about IPA configured plugins, we cant handle
>> everything, what users added there.
>> If user adds an own plugin configuration there, the one should keep
>> responsibility to test, if the plugin configuration still works after the IPA
>> We can't keep what user want, and what IPA needs in all cases, we would break
>> IPA or users expectations, or both.
>> In this case we can add detection of conflicts and print errors during
>> upgrade, but we cant fix plugins which user created. If we want to handle
>> user custom configuration, we will need to add detection for lot of things
>> during upgrade not just uid uniqueness plugin.
I tend to agree with Martin. I know that we created the special uniqueness
plugin handling custom user plugins in the last release, but I am not convinced
it is a good idea, it adds complexity to the upgrade, making it more difficult
So if we can create the cn=uid uniqueness,cn=plugins,cn=config plugin just with
simple update, I am fine with it.
> Uhm, right. Where my brain was today? :)
Is that an agreement with Martin's approach? I am not sure :-)
Freeipa-devel mailing list