launchpad-dev team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

= 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.