Default DNS server for Samba 4.0

[Kai Blin]

On 2012-09-06 13:16, Andrew Bartlett wrote:

Hi Andrew,

> I'm not sure where you got the idea that it was acceptable to have
> untested code in Samba.  That the DLZ code is in this state (which I am
> working to rectify) is no excuse to introduce more untested code.  

Well, I got the idea by looking at the other DNS implementation we had.
I agree it's nice to have tests, and I'd have bought the argument if the
tests had been in there a couple of betas ago.

> Secondly, I'm sorry if you felt that the required feature standard was
> anything less than DNS forwarding and GSS-TSIG correctly coupled to the
> directory ACLs.  I'm not sure how that wasn't clear, but you clearly
> feel mislead.  

This probably is twenty bloody lines of code, looking at the DLZ plugin.

> In terms of the deadline, yes, it keeps changing.  When we previously
> talked about needing to close off Samba 4.0 to new features, you raised
> that you will not be able to complete this feature in time, and asked
> that you be allowed an even closer approach to the RC to finish your
> features off.  Perhaps it would have been kinder to have left this at
> the beta stage, but then we wouldn't have this impressive facility at
> all!

I can't shake the impression that our betas were simply alphas with a
different name, though. The release candidate stage is where we stop
working on new features and work on stabilizing the ones we have. If
"has to be bug free" is the bar, then we probably should just give up.
But yes, I agree that I'd probably have spent my time differently if it
had been clear we don't care about the internal DNS a couple of months
back. This certainly is a reason why this feels like bait-and-switch. It
sure is the reason why I'm disappointed.

> I do hope you didn't feel I promised you that you would have the
> automatic right to change the default, because I always intended to
> assess the state of the two options at the time the internal DNS server
> is 'finished'.  

No, but I had the impression that you are not the only person who gets
to decide what the 4.0 release will look like. And I had the feedback
from other people that they were really interested in getting the
internal server in as the default implementation. That's why I brought
this up on the mailing list.

> You described your testing as joining a Windows7 client.  I'm
> particularly concerned to ensure that things like DC joins also work, as
> do the other things I mentioned.  

Right. There's a wiki page for DNS, how about we put a test matrix
there. That'll give people an idea of what's been tested, and which dns
backend they want to use.

> We should walk before we run:  Get the feature finished, get the
> automated tests written, make it available and ask that people test it.
> Test it with the various windows combinations that we need.  Get it into
> the SerNet appliance.  

I'm happy to work on all that. I just don't see why this has to be done
before even considering the implementation. I see this as part of the
"shake out bugs" phase.

> Then, with that backing, you would have good grounds to discuss a change
> in the default.  Anything else is premature, particularly as we don't
> yet even have correct ACL checking on the updates.  

Right. If you point me at the tests for the ACL stuff in bind_dlz, I'm
happy to make them work in the internal server.

> It is particularly premature to ask to change the default the day you
> finish the most complex component, before adding the required tests.  

At least it's a component where adding tests is an option.

> I'm happy that you have managed to almost complete the feature before
> RC1.  This means we can include it in the release.  

Thank you.

> No, I don't see the release candidate period as a time to flip features
> on and off.  The agreed procedure is for bug fixes, with a genuine
> feeling that this is a release candidate, not just another period of
> betas. 

Right, my suggestion was for the case that we couldn't fix the bug in
time. We try to make it work on the "easy for the users" end, and if
that doesn't work, we can still fall back to the bind_dlz backend.

> I'm glad you understand my position.  Had we had this code in the tree
> even just a couple of betas ago, and the tests had been finished in the
> meantime, I think this would be a very different discussion.  

As I mentioned before, I didn't see that much difference between the
alpha and beta releases. We had two beta releases that were more broken
than many of our alphas were. I fail to see how that is stabilization.
RC1 is the first point were we draw a line on the ground and say "from
here on, we focus on making it work reliably".

Anyway, we seem to be measuring our DNS implementations using different
scales, and I happen to be passionate for the one that got the shorter
stick. It was pretty clear from our IRC conversation yesterday that we
disagree on this. You have made some clear points, even if they aren't
necessarily convincing in my arguably biased opinion. Anybody else with
an opinion to get us out of this?

Cheers,
Kai

-- 
Kai Blin
Worldforge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/