Releases, locking and ldb
metze at samba.org
Mon Jun 26 16:11:10 UTC 2017
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
>> 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
>>> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the samba-technical