[Freeipa-devel] [PATCH] 0001 User Life Cycle: create containers and scoping DS plugins

[Petr Viktorin]

On 08/13/2014 05:17 PM, thierry bordaz wrote:
> On 08/13/2014 04:48 PM, Petr Viktorin wrote:
>> On 08/08/2014 09:24 AM, thierry bordaz wrote:
>>> Hi,
>>>
>>> The attached patch is a first patch related to 'User Life Cycle'
>>> (https://fedorahosted.org/freeipa/ticket/3813)
>>>
>>> It creates 'Stage' and 'Delete' containers and configure DS plugin to
>>> scope only 'Active' container or exclude 'Stage'/'Delete'
>>
>> Hello,
>>
>> The .ldif files are copied only during initial installation. When
>> upgrading to a version with this patch, changes in .ldif files are not
>> applied.
>>
>> So all updates need to be in .update files. For example, for DNA
>> plugin configuration you would need something like this in an .update
>> file:
>>
>> dn: cn=Posix IDs,cn=Distributed Numeric Assignment
>> Plugin,cn=plugins,cn=config
>> remove:dnaScope: "$SUFFIX"
>> add:dnaScope: "cn=accounts,$SUFFIX"
>>
>>
>> .update files, on the other hand, are applied both on installation and
>> on upgrade. To avoid duplication you can put whole entries in .update
>> and delete them from the .ldif, provided the entries always end up
>> being created in a correct order.
>
> Hello Petr,
>
>     Thanks you very much for your review. I understand that the fix does
>     not work in upgrade and I will change it following your recommendation.
>     I think that adding entries with the .update syntax should be
>     similar to what is in 55-pbacmemberof.update for example.

Yes.

>> Patch submission technicalities:
>> Please don't add the "Reviewed by" tag to the commit message, it's
>> added when pushing. The other tags are not used FreeIPA. (What's a
>> "Flag Day"?)
>> When you send more patches that depend on each other, either attach
>> them all to one e-mail, or explicitly say what each patch depends on.
>>
>     That is correct I used a review template that was for 389-ds and I
>     will change it. 'Flag Day' was part of 389-DS template, it was a
>     flag to inform if the fix had a wide impact (things needing to be
>     ported/recompile).
>     I split ULC fix into several logical sub fixes and you are right
>     they are all related even if for example 0002 does not depend on 0001.
>     Do you want I resend patch 0003 with the statement it relies on 0001
>     (and with the correct commit message ?).

These guidelines just make it easier for us to handle the large numbers 
of patches that land on the list. Try to follow them next time you send 
a patch (or revision), but there's no need to resubmit things just to 
comply.
We can change the message when pushing if the patch contents are acked.

Thanks for the dependency information.

-- 
Petr³