Releases, locking and ldb

[Stefan Metzmacher]

Am 24.06.2017 um 09:02 schrieb Andrew Bartlett via samba-technical:
> On Sat, 2017-06-24 at 08:32 +1200, Andrew Bartlett via samba-technical
> wrote:
>> On Fri, 2017-06-23 at 13:25 +0200, Stefan Metzmacher wrote:
>>>
>>>> For the 1.1.30 ldb version, the even context changes require this in
>>>> Samba (less important, only hits -M single):
>>>>
>>>> commit 7259661467776a76c4fa3aabaf1ae8a3d531e506
>>>> Author: Andrew Bartlett <abartlet at samba.org>
>>>> Date:   Fri May 12 01:55:45 2017 +0200
>>>>
>>>>     dsdb: Use ldb_handle_use_global_event_context for rootdse modifies
>>>>     
>>>>     The modify operations on the rootDSE turn into IRPC messages, and
>>>> these need
>>>>     to be handled on the global event context, not the per-operation
>>>> context
>>>
>>> Would it help to introduce an
>>> ldb_set_allow_private_event_context() that's called by a new Samba
>>> release. And other callers get the old behavior?
>>>
>>> It would still leave us with unusable 1.1.30 and 1.1.31,
>>> but 1.2.0 would be usable again.
>>
>> No, I don't think that is wise.  That just invites other operations
>> (possibly writes) to happen during a read lock, and that invites
>> LDB_ERR_BUSY (unable to upgrade hash locks). 
> 
> I'm not really worried about this use case, in that the only thing that
> happens is that rootDSE modifies against -M single (not the default,
> and not really that workable) DCs would fail. 
> 
> However the change in behaviour is only needed with the locking
> patches, so we could:
>  - fork a new ldb 1.1 branch in the repo
>  - release ldb 1.1.32 with this change reverted
> 
> This would give us a basis to make backported fixes to ldb that may be
> required by Samba 4.6 and earlier, which can't take ldb 1.2.0.
> 
> The locking change is like an ABI break, but only really impacts Samba
> the the full extent because of the way we use the partitions module. 
> 
> I'm not sure we want to enforce a full ABI break for this (ldb-2.0.0),
> as it would just make backporting this even more difficult. 
> 
> Let's continue to work on this.  
> 
> So we don't find ourselves under artificial deadlines here, can we
> agree not to fork 4.7 without this resolved?  

At least we can't release 4.7.0 without this.

I don't like having an ldb 1.1 branch.
I'm still thinking about possible solutions.
Maybe reverting things in master for a ldb-1.1.32
and then reapplying for a 1.2.0.

Would sssd break with these changes?

Do we have other known external users, beside openchange?

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170626/ab86b744/signature.sig>