wiki:WeeklyMinutes20120228

BIND 10 Team Meeting

2012-02-28

Attendees

Michal
Jeremy
Larissa
Jelte
Shane
Stephen
Aharen
Fujiwara
Jinmei
Haikou
Kambe
Jeremy

Welcome to Mukund

Mukund is our new BIND 10 developer. Welcome aboard!
Maybe next time. :(

Release Status

Jeremy: Release is Thursday so will do the branch tomorrow at this time.
Jeremy: Did not check through current milestone so do not know if 1-week goals are done.
Jelte: "critical" tickets are done, but perhaps some other tickets are missing

Jeremy: I never used the NSEC3. Has anybody been using it?
Jelte: Only as far as writing the lettuce tests.
Jinmei: I'm not using on my personal server.
Shane: Me either, I act as a slave now.
Jinmei: I suspect that even if I tested on my personal server it would not be as good as the lettuce tests.

Jeremy: Working on minor documentation improvements and cleanup.

Year 4 Usability Goals

https://lists.isc.org/pipermail/bind10-dev/2012-February/003115.html

Log messages define debug level

help admin know what debug level to use to get a log output (include in .mes file? include in docs.)

Jeremy: Debug levels are hardcoded in the code, spread throughout the tree. From an administrator's point of view it is difficult to know what to enable to get certain debugging. Consistent levels help for documentation, but for per-message debugging we don't have that information. Include the debugging level in the .mes file itself?

Stephen: These are for debugging. We had things like "<30 may be of interest to adminstrators". But what debug messages are for the most part should not be useful to administrators.

Shane: So if administrators are using DEBUG level, then we whould make it INFO?

Jeremy: Then INFO can be really noisy.

Michal: One of my friends said a good logging system should have a way to turn specific messages on or off independent of the level.

Jeremy: That would be a solution, I like that.

Jinmei: I think in some cases debug messages are useful for administrators. In some cases they are noisy information. Even if the adminsistrators don't understand the meaning they can submit bug reports, and numbering the levels is useful.

Stephen: In some cases debug levels are useful for administrators, that's why we have a level of 30 which might be of use.

Shane: I think the idea of enabling a specific message is nice.

Stephen: In essence that will be adding a separate filter level for logging.

Michal: Filter could be not expensive when a specific message is set, and more expensive when there are more messages. So if the user does not tweak the logging that much it wil be fine.

Stephen: This is why we have components.

Haikou: From my side, I know a lot of administrators will enable log monitor, so noise of debugging information is okay for administrator.

Shane: True, but they won't be happy about performance hits. ;)

Jeremy: The debug levels make sense, but even with the debug levels administrators won't know. The naming of the log entries aren't clear, so you don't know the numbering. Right now you would just set it to 99, or use trial-and-error.

Stephen: But if you're debugging a problem, you wouldn't necesarily be an administrator, you'd be a coder.

Jeremy: No, I'm thinking of as an adminstrator, so trying to debug a transfer...

Stephen: In this case, you'd enable debugging up to level 30 for b10-xfr.

Michal: Definitely not have them in both the code and the message file.

Jinmei: Isn't it possible to copy this information from the source to a generated file?

Shane: Seems weird since we have a file that defines this...

Jelte: The problem would be that we don't always use the logging calls directly. And if they are indirect we'll need a complete parser.

Shane: I think we need to discuss on list.

Schedule to go through all log messages

(not during this call)
as a group? break up and do invidually as ticket tasks?
severity okay?
debug level okay? (need to document these still?)
understandable?

Shane: I have this as "audit logging" in our Y4 usability work.

Stephen: We also need to go through the description too.

Jeremy: Yes.

Superflous? Duplicate? Missing?

Jelte: I think this is something we need to do as long as the software is used.

Stephen: I think this is a background task, maybe 1 set of messages per month.

Jeremy: Once we catch up, we don't want to get behind. Maybe this needs to be a clear part of the review.

Shane: Nothing in code review procedure now.

Hacks for Build/Install Problems

For example: sqlite3-difftbl-check.py, short-term workaround in python/isc/log/ to warn about old library, failed builds due to bin/stats/tests/{isc,http}
When to use? When to remove?

Comments should be clear to say ticket number and when to remove the hack?

Jinmei: I don't think there is a general policy about when to use, and it is quite rightly case-by-case. I do think we should add the ticket number and an expected expiration date.

Jinmei: Maybe one general case is when we introduce backwards-incompatible changes to schema are that we add things like that.

Shane: I think ultimately we may benefit from having a project-wide calendar to schedule these kinds of things, like "this ticket is now old".

C++ cast usage

in particular, which cast we should use, reinterpret_cast or nested static_cast, when we need to convert two "incompatible" pointer types when it's actually safe (it often happens when dealing with C-level system APIs). See http://bind10.isc.org/ticket/1593#comment:11

conversion between struct sockaddr* and struct sockaddr_in*

struct sockaddr* sa;
sockaddr_in* sin = reinterpret_cast<sockaddr_in*>(sa);

or

void* p = sa
sockaddr_in* sin = static_cast<sockaddr_in*>(p);

Michal: if we're using a C API shouldn't we use C casting? (sockaddr_in*) sa

Stephen: I would argue that you are actually doing a reinterpret_cast() just hiding it. If searching for dangerous casts you will miss that.

Michal: For the record, the cast is completely safe only the compiler is confused.

Jinmei: If it is not safe, then we should definitely use reinterpret_cast() or consider a safer way to do it.

Stephen: I meant "incompatible" not "unsafe".

Jinmei: I personally prefer to reduce the number of reinterpret_cast(), even if static_cast() is ugly.

Michal: Or we can define our own templates to do our own...

Stephen: Most common in the Python interface code.

Jinmei: Should be safe but my question is which one we should use in the safe case?

Stephen: I prefer reinterpret_cast()

Michal: I really don't like static_cast() because it is two lines long for a simple operation.

Jelte: I have no prefrence between reinterpret_cast() and a specially-written template just for this.

Jinmei: At least we should avoid using the nested cast.

Release Engineering

Broken until proven VERSUS release to a production-like or real production environment on every push

Jeremy: Would like our code to be releaseable at any time. We need more tests, and we are doing better with lettuce tests, but we should consider having an environment that is production or near-production like that we update on every push.

Michal: Sounds like a lot of work.

Shane: Doesn't sound like too much work.

Jeremy: Not a lot of work, but we need to change our paradigm so we can roll back.

Jinmei: What is the definition of "releasable"? Compile+all tests pass, or install and running?

Jeremy: Useful in a real environment.

Jinmei: If it includes documentation updates I'm afraid it is unrealistic.

Shane: It will push branches into a holding pattern until they are "done". So things will stay as branches longer.

Jinmei: In some sense it is always releaseable, since all tests pass.

Shane: Perhaps we can do it in several steps, first setting up a push to a production environment, and then think about how to change our processes around this.

Jelte: Can also run lettuce tests after "make install". Maybe that is a step towards this.

Jeremy: Even if it wasn't automated we should do it before release. Run in a real production environment before release.

Shane: Not opposed, as long as we have real checks and measurements of that environment.

Performance

http://bind10.isc.org/wiki/PerformanceTasks
multiple auth had awesome improvement

Within 15% of BIND 9 speed based on this change.

Shane: We have 4 weeks to squeeze 16% out of the code. ;)

Release Engineering and DHCP

(communication needed: goals, schedule, proving success, release notes, documentation, communication with end-users, etc.)

Jeremy: Feel out of loop for DHCP. So release engineering never has DHCP focus. Need to figure out what to do about this.

Stephen: Part of that is because nothing that has come up in DHCP is something that users can use. It's just getting a very basic framework. Over the next 6 months the aim is to be able to have a system that works. It is on my list of things to do to publisize that stuff.

Jeremy: Don't want to wait until this is ready. With DHCP it's had for me to understand since I don't really use it.

Stephen: Part of the problem is there is only 1 person working on BIND 10 DHCP.

agreement to have Jeremy join Kea planning calls


End of Call

Phone call ends here. 2 minutes past time.

Bikeshed: Operator Overloading in C++

https://lists.isc.org/pipermail/bind10-dev/2012-February/003113.html

Possible topic: "libcache" renaming

http://bind10.isc.org/ticket/632

Possible topic: splitting BIND 10

https://lists.isc.org/pipermail/bind10-dev/2012-February/003064.html

Last modified 6 years ago Last modified on Feb 28, 2012, 4:26:29 PM