= Attendance = benji, gmb, gary_poster
apologies from frankban and bac, though frankban pre-supplied some notes for the meeting. = Project plan review = * fewer, more exciting test failures * we need to explore the new cohosting plans in order to inform the purchasing plans = Tricks = frankban: MultiArchSpec allows 32 bit and 64 bit libraries on the same Debian machine. C libraries for different architectures go into different directories. LXC is starting to do that in quantal. If you use Python and ctypes, path search by default in precise does not include MultiArchSpec. You need to manually look for the MultiArchSpec versions. /usr/lib/dpkg-architecture -qDEB_HOST_MULTIARCH/[NAME OF LIBRARY] is location. MORE DETAILS: By default, ctypes looks in the libraries returned by ldconfig -p, which has the format of, for example, "libHalf.so.6 (libc6,x86-64) => /usr/lib/libHalf.so.6". This knows about MultiArchSpec (for instance, see cat /etc/ld.so.conf.d/x86_64-linux-gnu.conf) but doesn't appear to understand the nested directories that lxc uses. Therefore, you must do it manually. frankban: lxc-ip is a nice tool he wrote for reliably getting the ip of an lxc container. It will be going into Ubuntu, and is part of the lpsetup package now (see the Yellow PPA, https://launchpad.net/~yellow/+archive/ppa) with the name "lp-lxc-ip". It requires sudo to work, so he changed sudoers to make lxc-ip not require a password (e.g., "frankban ALL = (ALL) NOPASSWD: /usr/bin/lp-lxc-ip"). frankban: Pay attention if you modify your sudoers file, because if you introduce an error you lose root (and have to start Ubuntu in recovery mode). visudo for the win (it parses before it saves and complains if you do it wrong). gary_poster: lxc docs are here: https://help.ubuntu.com/12.04/serverguide/lxc.html benji: gary_poster asked for hints on how benji uses strace on non-hanging processes, which benji and bac had to do recently. gary_poster's problem: so much blather! benji's solutions: he scrolls and squints, looking for changes in the output (Python starts with a whole bunch of stat blather, for instance). Look for file names, which then become file descriptors. Read the man page! -ttt & -s are particularly helpful. Be careful of joining processes because it can introduce heisenbugs. benji: metatrick: to share more tips and tricks, he has made a daily reminder to ask himself if he did anything interesting or unusual that might be worth sharing, before he forgets. You could too! benji: to patch database and have it affect a test (for sampledata and stored procedures and schemas), use “psql launchpad_ftest_template -1 -f patch-1.sql” (-1 means “run all this in a single transaction”). benji: not a trick yet: how do you get postgres logging from stored procedures (plpy.debug(“...”))? where did it go? = Nice successes = gary_poster was pleased with the docs and measurements he produced this week, but couldn't think of a less on to be learned. = Pain experienced = gary_poster: New test environments caused new test failures. Higher contention means more issues in tests. We already knew that we wanted to run this in the data center early to make the tests run well in that environment, but it was unavailable until just the past week. In addition to hardware differences, in the data center we have to deal with "dirty" machines in a way that we don't with juju/cloud/easy-come-easy-go test instances. gary_poster: Changed goals, or even the perception of changed goals, when nearing the end of a project is demotivating. Robert wants to run the devel and db-devel tests simultaneously on the same slave. We had tried that initially, a couple of months ago, and turned it off because it was causing problems; recent tests on 32 core machine show that contention of resources (what resources? not sure) can still cause problems. We didn't know that this was an actual goal. It would have been nice to know Robert’s sharing plans/desires earlier--we would have been testing that scenario all along. Could we have done a better job gathering requirements from him? Discussion of term “requirements gathering” ensues. benji suggests replacing term with “requirements waterboarding”. We wish we would have had the co-location requirement sooner. gary_poster: a lesson for us to learn is to not assume that internal customers will require any less effort to gather requirements than external customers. benji: a way to gather requirements that might have helped us is to ask the customer, “please tell us what you imagine the ideal end state to be.” gary_poster: Is there anything to be learned from the cards sitting there for weeks to get the python-shell-toolbox and Python charm helpers packaged by Clint? gmb: If we needed a squad to work on something, we would go to manager. Perhaps appropriate? gary_poster: Yes, but some smaller tasks don’t need manager involvement, particularly in open source world. How do we know what the line is? One possible solution might be a week timer for kanban cards that are waiting on other people--if a card doesn’t move, ping in some way. gary_poster requested this kind of feature from leankitkanban a few weeks ago and got no reply. Maybe add "ping" technology to lp22kanban. our tool that interacts with our kanban board with the webservice! This could move our own cards to "blocked" if they don’t move in one day for us; and move cards waiting on others to "blocked" in a week if they don't move. We would need to discuss and unblock on the morning call. We could identify cards waiting on others with a tag--“waiting on external” or something--or maybe simply a tag that lengthens the default one day timer to multiple days, like "7-day-timer" or something? gary_poster added a slack time "idea" card for this, if anyone is interested. gary_poster: lpsetup is intended to be infrastructure, but has been worked on as slack project. Because it has been a slack project, we have not gone through any official requirements gathering or scoping. However, this is not fair if we actually intend the Launchpad team to maintain the project after it is done. benji: it is worked on in slack time but not a personal project. Something to ask the day after a slack card shows up: whose project will this be, when it grows up? If it is just the developer (e.g. benji’s termbeamer), as long as we like the use of slack time, no problem. If the squad will maintain it (e.g. lp2kanban), we should talk about it. If the LP team will maintain it (e.g. lpsetup), we should go through a more official process (LEP, specifically). team: discussed Go. gary_poster has been experimenting with it, and assembling notes for the surprises/annoyances he encounters. He is enjoying the exploration. He finds a lack of uniformity and of general API support to be annoying: as far as he knows, you can't write your own object that is a reference type (which is between a pointer and a direct reference, e.g. slice, map, chan); you can't write your own object that works with the "range" keyword; you can't write an interface for a generic slice, etc. We collectively wondered what the expected benefit of using Go in Juju will be, given that it is not a task that requires blistering performance speed from the code. We are still interested in the effort, nonetheless, and would enjoy participating in it. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
