On Wed, 06 Oct 2010 22:34:40 -0000, Martin Pool <[email protected]> wrote: > On 7 October 2010 07:15, Michael Hudson-Doyle <[email protected]> > wrote: > > On Wed, 06 Oct 2010 08:43:44 -0000, Martin Pool <[email protected]> wrote: > >> notes from talking this over with spm: > >> > >> Â * at the moment you can see in the process listing which branch is > >> being accessed; it would be very nice to keep that; but at least we > >> should log the pid/user/branch > > > > This isn't affected by this branch, although the process name ends up > > being a bit unwieldy: > > > > 21266 pts/1 Â Â S+ Â Â 0:00 /usr/bin/python > > /home/mwh/canonical/checkouts/trunk/eggs/bzr-2.2.0-py2.6-linux-x86_64.egg/EGG-INFO/scripts/bzr > > launchpad-forking-service --path /var/tmp/launchpad_forking_service.sock > > BRANCH:~mark/upstart/branch > > > > Maybe inserting a call to setproctitle in become_child would be useful, > > especially as we have the dependency already -- one piece of information > > we've lost is the user who has connected, although we can probably > > figure that out from logs still. > > Without the call to setproctitle, we would be losing this thing spm > said he liked, which is to immediately show which user and branch it > corresponds to.
Uh? No, that's the bit we retain. The ps output I showed above was from running with the branch being reviewed. > To my mind it's more important to log the username, branch and pid, so > that you can see who it was both while the process is running and > afterwards. It's also nice that jam logs the rusage. But putting > them into the argv is more immediately accessible. I'm not sure if you're recommending this branch be changed before landing here. > >> Â * can run this on staging, then edge, then lpnet > >> Â * propose changes into lp:lp-production-configs to gradually turn it on > >> Â * might want an rt describing how to monitor the new daemon process, > >> which just needs to mention the socket location and the hello command; > >> they can write the script from there > >> Â * francis should formally tell tom and charlie we'll be making this > >> change > > > > I still vaguely wonder about controlling this with a feature flag. Â The > > thing is, the codehosting systems don't connect to the database > > currently, and that's actually kind of nice in some ways. Â We could add > > an XML-RPC method to query a flag, and have the ssh daemon check that > > every 30s or so -- I don't think we want an XML-RPC call delaying the > > launch of the lp-servce process on every connection. > > Actually I was thinking of just having an http URL, accessible only > within the DC, that just presents all the feature flag rules in a > machine readable form: maybe json by default, perhaps others. There's > no need for xmlrpc when we just want to read, and avoiding startup > dependencies is good. Then we can have a FeatureRuleSource that gets > and parses this rather than talking to storm, and it will be fast to > start up for this type of thing; probably fast enough to run on every > request if we want to. bug 656031. That would be interesting. The sftp server being a twisted app, access to this URL should really be nonblocking which always adds a wrinkle. Maybe that would be fine though, or maybe we can just cheat. Cheers, mwh -- https://code.launchpad.net/~jameinel/launchpad/lp-service/+merge/37531 Your team Launchpad code reviewers is requested to review the proposed merge of lp:~jameinel/launchpad/lp-service into lp:launchpad. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-reviewers Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-reviewers More help : https://help.launchpad.net/ListHelp
