Releases, locking and ldb (was: Re: [PATCH] [ldb_modules ABI break] Re: [WIP][PATCH] Safe LDB locking for better replication)

[Andrew Bartlett]

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?  

I know this is a big ask, and totally against our procedures, but I'm
really uncomfortable proceeding with a release with this unresolved,
but resolving it isn't just technically difficult, it is about
balancing competing interests, something best done without time
pressure.

For others trying to follow the thread, the summary is here:
https://bugzilla.samba.org/show_bug.cgi?id=12858 and 
https://bugzilla.samba.org/show_bug.cgi?id=12859

Thanks,

Andrew Bartlett
-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba