[00:46] <SpamapS> adam_g: If it gets super custom per node.. then ensemble becomes a bit pointless.
[00:48] <SpamapS> adam_g: whatever is creating these one-off nodes (I'm assuming this is orchestra not ec2) should just make sure each node has the block device at the specified location.. maybe make a symlink.
[00:52] <adam_g> SpamapS: i wouldnt consider the existence of a specific blockdev to be super custom. :) but yeah, im thinking it should be left up to cobbler/orchestra/admin.  even if that is the case, though, and we can declare something similar to m1.large with specific storage layout, it would be useful to be able to direct add-unit to a specific machine type/class 
[00:55] <SpamapS> yeah, --placement=available is pretty inadequate for this.. we probably need a better one.
[02:27] <niemeyer> adam_g: Yeah, I agree with SpamapS.. we need to find a way to scale that.. if the admin has to put info per node, it becomes harder to manage
[02:27] <niemeyer> adam_g: I understand your point, though.. we can dig a bit deeper to find a way to manage that need without introducing individual entries per node in the config
[08:33] <Whiz> Hi, I'm having a hard time on finding information about whether it is possible to override default-image-id somehow per service-unit/formula or something. I.e. I wan't to use small instances for everything but when it comes to db-nodes I'd like'd them to be high-mem instances. My google-fu isn't strong enough :)
[08:35] <SpamapS> Whiz: there's an open bug for that..
[08:35] <Whiz> SpamapS, ok. so it was my google-fu :D thank you
[08:36] <SpamapS> Whiz: you can set it in the environments.yaml just before you deploy right now.. and it will be "the image id" for that service as you add units
[08:36] <SpamapS> there are actually two bugs.. tho they might need to be merged..
[08:37] <SpamapS> bug 830995 and bug 808969
[08:37] <_mup_> Bug #830995: default-instance-type and default-image-id are inadequate <Ensemble:New> < https://launchpad.net/bugs/830995 >
[08:37] <_mup_> Bug #808969: determine the instance type at deploy <Ensemble:Confirmed> < https://launchpad.net/bugs/808969 >
[08:39] <Whiz> okay :)
[08:39] <Whiz> thank you
[11:59] <hazmat> morning folks
[12:42] <lynxman> hazmat: ping, whenever you're around :)
[13:07] <hazmat> lynxman, pong
[13:08]  * hazmat contemplates an oneiric upgrade
[13:14] <hazmat> niemeyer, how's oneiric been treating you?
[13:14] <niemeyer> hazmat: Haven't been using it yet, but was just pondering yesterday about how it _might_ treat me :)
[13:15] <hazmat> niemeyer, i'm considering taking the plunge this morning, although bug 818830 concerns me
[13:15] <_mup_> Bug #818830: [Sandy Bridge] serious power regression from kernel 3.0.0-6 to 3.0.0-7 (rc6 disabled) <3.0> <kernel> <oneiric> <power> <linux (Ubuntu):Triaged> < https://launchpad.net/bugs/818830 >
[13:16] <_mup_> ensemble/stack-crack r328 committed by kapil.thangavelu@canonical.com
[13:16] <_mup_> merge trunk
[13:17] <niemeyer> hazmat: Looks like there's a trivial way to fix it?
[13:17] <hazmat> niemeyer, doesn't work for everyone
[13:18] <niemeyer> Ah, gotcha
[13:18] <_mup_> ensemble/local-ubuntu-provider r330 committed by kapil.thangavelu@canonical.com
[13:18] <_mup_> refactor get class path utility function into managed zk method
[13:18]  * hazmat commits work in progress and pushes pre upgrade
[13:20] <niemeyer> hazmat: Good choice ;-)
[13:22] <_mup_> txzookeeper/errors-with-path r44 committed by kapil.foss@gmail.com
[13:22] <_mup_> zk exceptions w/ path information
[13:25] <hazmat> niemeyer, apparently i scored in the race to get a touchpad as well :-)
[13:25] <hazmat> took a week to get a confirmation email of my order out of hp, which is sad
[13:25] <niemeyer> hazmat: Neat
[13:26] <niemeyer> hazmat: I'm curious about these machines
[13:27] <hazmat> niemeyer, their dual core qualcomms, 1.2 ghz.. overclockable to 1.5ghz... seem reasonably capable, there's a couple of bounties out to get android on them, wifi only + usb. even if nothing else they should make decent xmas gifts
[13:33] <niemeyer> hazmat: They are neat Ubuntu machines it seems :)
[13:37] <hazmat> niemeyer, mee+go+ubuntu :-)
[13:51] <hazmat> niemeyer, update-manager failed
[13:52] <niemeyer> hazmat: Ugh
[13:52] <niemeyer> hazmat: Let me know how it goes
[13:53] <niemeyer> hazmat: Depending on your results I could get "brave" ;-)
[13:53] <hazmat> niemeyer, looks like it rolled back properly, i think i might wait till the official beta on sept 1st
[13:54] <niemeyer> hazmat: Oh, seriously?
[13:54] <niemeyer> hazmat: That's quite amazing on itself
[13:54] <niemeyer> hazmat: Well.. depending on where it failed
[13:54] <hazmat> niemeyer, it looks like it adjusted packages sources, updated, calculated the upgrade, failed to do so, and restored the sources
[13:55] <niemeyer> hazmat: Ah, ok
[13:55] <niemeyer> hazmat: That's less impressive
[13:55] <hazmat> niemeyer, do you still use smart for dist-upgrades?
[13:56] <niemeyer> hazmat: I know mvogt is looking at doing magic for rolling back for quite a while
[13:56] <niemeyer> hazmat: Like, _real_ rollbacks :)
[13:56] <niemeyer> hazmat: I never used Smart for dist-upgrades
[13:56] <niemeyer> hazmat: update-manager is not just apt.. it's full of hand-made fixes
[14:17] <hazmat> ugh.. post earthquake.. hurricane.. just got a call from the power company to expect multi-day outages
[14:17] <robbiew> hazmat: damn
[14:20] <Daviey> http://t.co/2fNBu7M
[14:21] <robbiew> heh
[14:25] <niemeyer> hazmat: Good time for a sprint!
[14:26] <niemeyer> Daviey: LOL
[14:32] <RoAkSoAx> fwereade: howdy!!
[14:33] <fwereade> heya RoAkSoAx
[14:33] <fwereade> how's life?
[14:33] <RoAkSoAx> fwereade: pretty good, testing ensemble/orchestra on real HW
[14:33] <fwereade> RoAkSoAx: sweet
[14:33] <fwereade> RoAkSoAx: all that's missing in trunk is the unicode-key thing now
[14:34] <RoAkSoAx> fwereade: alrgith, great then
[14:34] <fwereade> RoAkSoAx: not mped yet though, haven't actually finished it yet
[14:34] <fwereade> RoAkSoAx: ...and damn, I need to be off a little early today and might not quite get there
[14:34] <RoAkSoAx> fwereade: that's fine
[14:34] <RoAkSoAx> fwereade: at least it is just one more to go
[14:35] <fwereade> RoAkSoAx: *might* be able to polish it off this evening but don't count on it :)
[14:35] <RoAkSoAx> fwereade: no worries
[14:35] <RoAkSoAx> I'm testing with cobbler-compelte-fixes now
[14:35] <RoAkSoAx> fwereade: but have a few things that might already sound familiar
[14:35] <fwereade> RoAkSoAx: oh ah?
[14:36] <RoAkSoAx> fwereade: 1. bootstrap doesn't check if there's ssh keys apparently, so when trying to do status it fails due to not having a ssh key in the zk node. 2. which is related to 1, is throwing and exception when it should probably throw just an error message: http://pastebin.ubuntu.com/675290/ 3. When we bootstrap/deploy, we need to check that power management is configured in the system, cause it is bootstrapping/depoying without actually checking
[14:37] <fwereade> 1/2: is that just saying that bootstrap fails if you don't have a public key in ~/.ssh?
[14:37] <RoAkSoAx> fwereade: 3 (cont'd) which means that enmsemble will think it started a machine but since cobbler doesn't have power management configured nothing really happened
[14:38] <fwereade> 3: hm, I guess that's set in the system dict somewhere, I can just filter on that I presume?
[14:38] <lynxman> hazmat: ping?
[14:38] <RoAkSoAx> fwereade: 1/2. not exactlyu. it bootstraps correctly, but since there are no keys on ~/.ssh then, we cannot connect to the zk (I think there's a bug report already)
[14:39] <RoAkSoAx> fwereade: 3. yes, if I have time later today I'll do it myself so don';t worry just yet ;)
[14:39] <fwereade> RoAkSoAx: yeah, it rings a bell
[14:39] <fwereade> RoAkSoAx: cool
[14:39] <fwereade> RoAkSoAx: nothing showstopping then :)
[14:39] <hazmat> lynxman, pong
[14:40] <RoAkSoAx> fwereade: not really, just wanted to make you aware in case you stumbled on them
[14:40] <lynxman> hazmat: I have an issue with Ensemble + Openstack
[14:40] <RoAkSoAx> s/on/upon/
[14:40] <hazmat> lynxman, details?
[14:40] <lynxman> hazmat: I can bootstrap machines but it looks that no matter how I try the ssh keys are not copied over, the console output logs don't help either :/
[14:40] <RoAkSoAx> fwereade: speaking of which ^^
[14:41] <lynxman> hazmat: tried to a) specify public key with authorized-keys variable in environments.yaml b) create default id_rsa and let Ensemble choose it
[14:41] <fwereade> RoAkSoAx: hmm :)
[14:41] <hazmat> lynxman, i had that problem as well.. i worked around with specifying a euca key pair
[14:41] <lynxman> hazmat: in both cases Ensemble bootstraps successfully but then it complains about incorrect SSH key, even ssh'ing manually says that the key is not valid
[14:41] <fwereade> RoAkSoAx: ...or maybe a different issue
[14:41] <lynxman> hazmat: cool, any details in how to do so in environments.yaml ?
[14:42] <RoAkSoAx> fwereade: yeah but related as there was a similar bug report anyways, will test and see what happens ;)
[14:42] <hazmat> lynxman, its a new option on that branch,  from the paste its under ec2-key-name http://pastebin.ubuntu.com/673083/
[14:42] <lynxman> hazmat: when I tried that ensemble complained at bootstrap that no SSH was found :)
[14:42]  * lynxman comes full circle
[14:42] <hazmat> lynxman, effectively euca-add-keypair and then use the name
[14:42] <lynxman> hazmat: it's when you suggested to use authorized-keys
[14:43] <lynxman> hazmat: I'll try again
[14:43] <hazmat> lynxman, its not authorized keys from your local machine, its the provider managed keys
[14:43] <lynxman> hazmat: I know :)
[14:43] <lynxman> hazmat: and that's the one I specified
[14:43] <hazmat> hmm
[14:43] <RoAkSoAx> fwereade: nothing to worry from our side though
[14:43] <lynxman> hazmat: as a matter of fact copy/pasted the key name from euca-describe-keys
[14:44] <lynxman> hazmat: I'll quickly produce a pastebin so you can see the issue
[14:45] <hazmat> lynxman, sounds good, just trying to figure out how to debug it
[14:47] <lynxman> jcastro: excess flood? wow
[14:52] <lynxman> hazmat: it worked perfectly now *shrugs* thanks :)
[14:52] <hazmat> lynxman, magic :-)
[14:52] <hazmat> lynxman, yeah... i had some transient issues with keys as well, i'm not even entirely sure the ec2-key-name has any purpose
[14:52] <lynxman> hazmat: looks like my version of the line before wasn't loved by Ensemble
[14:52] <lynxman> hazmat: or yeah, transient issues as you say :)
[14:53] <hazmat> lynxman, i think it might be cloud-init related (delay in key installation) but its hard to say without more investigation
[14:54] <_mup_> ensemble/go r2 committed by gustavo@niemeyer.net
[14:54] <_mup_> Merged go-schema branch into go [r=fwereade,jimbaker]
[14:54] <_mup_> Ported schema verification and coercion logic from Python.
[15:00] <niemeyer> http://goneat.org/lp/ensemble/go/schema
[15:06] <fwereade> niemeyer: very neat :)
[15:25] <fwereade> I need to skip out a bit early today -- happy weekends all :)
[15:27] <niemeyer> fwereade: Cheers man!
[15:28] <RoAkSoAx> fwereade: see ya my frioend
[15:29] <hazmat> fwereade, have a good one
[15:29] <hazmat> niemeyer, 503 on http://goneat.org/lp/ensemble/go/schema
[15:31] <niemeyer> hazmat: Try again
[15:31] <niemeyer> hazmat: I was updating it so that searching would work too
[15:33] <niemeyer> hazmat: http://goneat.org/search?q=FieldMap
[15:34] <hazmat> niemeyer, looks good
[15:36] <niemeyer> On that note, I'm stepping out for lunch.. I hope to nail down Formulas this afternoon, given that we have a clean Eureka review queue (!)
[15:38] <hazmat> ugh.. that can't be allowed to continue ;-)
[15:38] <hazmat> niemeyer, have a good one
[15:38] <niemeyer> hazmat: Thanks! :-)
[16:05] <SpamapS> $ ./unit2machine.py master-jenkins/0
[16:05] <SpamapS> ec2-107-20-64-136.compute-1.amazonaws.com
[16:05] <SpamapS> :-D
[16:06]  * SpamapS is in ur tezts, writing new codez
[16:08] <hazmat> :-)
[16:17] <hazmat> this looks pretty interesting http://wiki.perfkit.org/index.php?title=Main_Page
[16:17] <hazmat> a nice gui to profiling tools
[16:17] <hazmat> ala osx instruments
[16:19] <SpamapS> hm.. how does ensemble work on python 2.6 if we use argparse?
[16:19] <SpamapS> is it just an external module?
[16:22] <jimbaker> SpamapS, correct
[16:23] <SpamapS> so using argparse won't cause my code to be 2.7 only?
[16:23] <jimbaker> there are some small differences in error messages iirc, so that breaks a couple of tests
[16:23] <jimbaker> SpamapS, that's right
[16:24] <jimbaker> SpamapS, i was running the ensemble test suite for a while on os x (don't tell anyone), it worked just fine except for a few trivial issues
[16:25] <jimbaker> SpamapS, it would certainly be useful to have a jenkins slave testing the client code, as packaged by macports
[16:27] <kim0> um, can a formula request to run on oneiric specifically ?
[16:27] <SpamapS> jimbaker: yeah we should do that. I'm sure we can find an old mac mini to use as a slave. :)
[16:27] <SpamapS> kim0: not yet no
[16:27] <kim0> okie .. ami-id is env.yaml then for now
[16:31] <SpamapS> kim0: yeah, thats being discussed in a couple of bugs tho
[16:42] <hazmat> SpamapS, python 2.6 and ensemble work, there was one minor incompatibility recently that jim fixed
[16:47] <SpamapS> We'll find out for sure.. running lots of examples on lucid in my test script.. :)
[16:59] <m_3> SpamapS: I do lots of ensemble cli on lucid VMs... couple of warnings lately, but it's generally worked
[17:00] <m_3> never spun up lucid amis tho
[17:10] <SpamapS> jamespage: go back to your vacation! ;)
[17:24] <niemeyer> hazmat: ping
[17:24] <hazmat> niemeyer, pong
[17:24] <niemeyer> hazmat: Can I get a quick review on this simplification: http://paste.ubuntu.com/675388/
[17:26] <hazmat> niemeyer, hmm.. doesn't the existing use of resphaper inline to the formula need to be removed as well if its directly in the schema
[17:27] <niemeyer> hazmat: How do you mean?
[17:27] <hazmat> oh.. nm. its all in the schema
[17:27] <niemeyer> Right
[17:27] <niemeyer> hazmat: The only logical  change is removing the OneOf
[17:27] <hazmat> niemeyer, +1
[17:28] <niemeyer> hazmat: Thanks!
[17:28] <hazmat> np
[17:30] <_mup_> ensemble/trunk r332 committed by gustavo@niemeyer.net
[17:30] <_mup_> Minor simplification in metadata schema [r=hazmat]
[17:30] <_mup_> The OneOf was redundant since the interface reshaper/expander also
[17:30] <_mup_> takes care of a complete interface.
[17:30] <_mup_> Also took the chance for improving naming and docs a bit.
[17:36] <niemeyer> Me and Ale teaching our future kids: http://www.smbc-comics.com/index.php?db=comics&id=2348#comic
[17:47] <hazmat> cute
[17:51] <niemeyer> if not formula_id.count(":") >= 1:
[17:51] <niemeyer> That's an awesome way to say == 0 :-)
[17:58] <SpamapS> hmm.. is there a way to add an SSH key to an ensemble environment currently?
[18:00] <hazmat> SpamapS, ? there already is one
[18:00] <SpamapS> Yeah, so say I bootstrapped from my laptop...
[18:00] <hazmat> SpamapS, the authorized key specified ( or default ssh key found if not specified) is installed on all the machines on the env
[18:00] <SpamapS> then I want to hand off maintenance to Bob
[18:01] <SpamapS> I'm not going to give Bob my key. :)
[18:01] <SpamapS> Needs to be a way to add/remove keys.
[18:01] <hazmat> SpamapS, atm no. we haven't really tackled multi-user management.. better would be to specify a shared key when creating the env, but your right we should probably support changing
[18:01] <SpamapS> better, but not realistic
[18:02] <SpamapS> s/should probably/must/ IMO
[18:02] <hazmat> indeed
[18:02] <SpamapS> It shouldn't be too hard really
[18:02] <SpamapS> ensemble is root.. so it can just twiddle the keys as needed
[18:02] <hazmat> SpamapS, its straight forward, its just a question of handling multiple users.. i think we'll might start walking down a rest api road for multi-user support
[18:02] <SpamapS> I will file a bug.
[18:03] <hazmat> sounds good
[18:03] <SpamapS> hazmat: that will mitigate some of it, but you still need to be able to ssh to the machines.
[18:03] <hazmat> true
[18:05] <_mup_> Bug #834930 was filed: Need a way to manage SSH keys in an ensemble environment. <Ensemble:New> < https://launchpad.net/bugs/834930 >
[18:05] <_mup_> ensemble/go-formulas r3 committed by gustavo@niemeyer.net
[18:06] <_mup_> Implemented ParseId.
[18:06] <negronjl> has the behavior of ensemble debug-hooks <blah> changed?  The hooks are being executed ( apparently ) but, I don't see anything happening in the debug-hooks windows 
[18:07] <niemeyer> negronjl: There was a minor change by kirkland to use byobu, but this shouldn't have affected anything
[18:07] <niemeyer> negronjl: Which hook are you trying to debug?
[18:08] <negronjl> niemeyer: mysql-admin-relation-joined/changed on cloudfoundry-server and cf-mysql formulas
[18:08] <niemeyer> negronjl: Ok, this should definitely be working
[18:08] <niemeyer> SpamapS, m_3: Any comments?
[18:08] <negronjl> niemeyer:  I bootstrapped, deployed both formulas, debug-hooks on both and then add-relation.....and I get nothing on the debug-hooks .... it's stuck on "bash"
[18:09] <niemeyer> negronjl: Yeah, this scenario sounds fine
[18:09] <negronjl> btw. I deployed....waited for them to be successfully deployed ( started ), then debug-hooks on them...
[18:09] <niemeyer> negronjl: Does the relation get succesfully established afterwards?
[18:09] <niemeyer> negronjl: According to status
[18:10] <negronjl> niemyer:  according to status yes but, none of the changes get applied.
[18:10] <niemeyer> negronjl: Hmm
[18:10] <niemeyer> negronjl: So the hooks do not run either
[18:11] <niemeyer> ?
[18:11] <niemeyer> negronjl: ?
[18:11] <negronjl> niemeyer:  not consistenly.  they apparently run on one of the two deployed formulas but not on both of them.
[18:11] <negronjl> niemeyer:  this doesn't always/nor never happens....it's all erratic.
[18:12] <niemeyer> negronjl: Very supect..
[18:12] <niemeyer> jimbaker: Are you able to investigate this?
[18:12] <niemeyer> jimbaker
[18:15] <hazmat> negronjl, do you have a debug-log output
[18:15] <negronjl> I am writing up exactly what I am doing ( down to the environment.yaml file ) so I can pass it on....
[18:15] <hazmat> negronjl, awesome
[18:16] <hazmat> negronjl, i can't think of anything directly related to debug-hooks which has changed recently outside of the byobu changes
[18:17] <kirkland> hallyn: negronjl: hmm, I'm here, if there's any issue to look at, wrt to the byobu/debug-hooks changes
[18:17] <negronjl> hazmat:  yeah... I tend to agree plus, I don't see byobu breaking debug-hooks either.... I am just hoping that I am missing something here and a fresh set of eyes on this issue can just clear it all up for me :)
[18:44] <m_3> negronjl: send your config... haven't seen this, but I was on a pretty stale version until yesterday
[18:45] <negronjl> m_3:  I will... I am also documenting everything ( environment.yaml, steps, debug-log, formula.log, etc. ) so I can give you a complete picture on what's going on and the necessary resources for you to reproduce if you can .
[18:49]  * SpamapS starts another test run .. 25th time is the charm!
[19:01] <jimbaker> m_3, are you looking into this with negronjl? just ping me if you need some help from the core perspective
[19:01] <m_3> jimbaker: will do
[19:15] <negronjl> m_3, hazmat, kirkland, niemeyer, jimbaker, bcsaller, anyone :) :  Here is more or less my issue with as much documentation as I can remember.  Please let me know if I missed anything here.
[19:15] <negronjl> m_3, hazmat, kirkland, niemeyer, jimbaker, bcsaller, anyone :) :  Here is more or less my issue with as much documentation as I can remember.  Please let me know if I missed anything here:  It would help if I paste it: http://paste.ubuntu.com/675480/
[19:16] <niemeyer> negronjl: Sweeet
[19:16] <niemeyer> negronjl: Thanks!
[19:16] <niemeyer> Now, who's looking at this?  It won't help us if everyone jumps into it :)
[19:16] <negronjl> niemeyer:  Please let me know if there is anything at all I can do to help solve this :)
[19:17] <niemeyer> negronjl: Will do, thanks again
[19:17] <niemeyer> hazmat: Are you interested in looking?
[19:17] <hazmat> sure
[19:18]  * negronjl going to grab a quick byte while you guys look at this....
[19:18]  * negronjl will be back in a few minutes.
[19:18] <hazmat> negronjl, cool, i should  have some more info soon
[19:18] <negronjl> hazmat: thx
[19:19] <niemeyer> hazmat: Thanks!
[19:36] <SpamapS> Hrm.. I need shutdown --yes-really-I-want-that
[19:37] <m_3> SpamapS: +1  I so want a '-y' option to shutdown
[19:37] <SpamapS> currently I'm walking through and just torching all services/machines now because it doesn't exist
[19:38] <SpamapS> python experts.. halp
[19:38] <SpamapS> http://paste.ubuntu.com/675490/
[19:39] <SpamapS> if my eyes don't deceive me, those two things equal
[19:39] <bcsaller> p type(service)
[19:40] <SpamapS> <type 'str'>
[19:40] <SpamapS> (Pdb) type(status['services'].keys()[2])
[19:40] <SpamapS> <type 'str'>
[19:40] <bcsaller> I thought it might be a __str__ method on the state object
[19:40] <bcsaller> wordpess
[19:40] <bcsaller> spelling
[19:40] <SpamapS> No I'm actually just parsing ensemble status via subprocess and yaml.load() ;)
[19:41] <SpamapS> wordpess ? hahahahahaha
[19:41] <SpamapS> thats what I get for copy/pasting
[19:41] <bcsaller> I can see why they didn't go with that name
[19:41] <SpamapS> instead of using a durn variable
[19:41] <SpamapS> well wordpuke was taken
[19:42] <bcsaller> by a slam poet?
[19:42] <m_3> slampress
[19:42] <bcsaller> heh
[19:42] <hazmat> negronjl, is that cloud foundry formula the latest, on my deploy it fails to start
[19:42] <hazmat> although i don't see anything obvious in the error log
[19:44] <hazmat> odd it seems like its hanging on config-changed
[19:44] <hazmat> but there isn't a config-change hook here
[19:45] <hazmat> but it never finishes the transition to start, and stays installed, and resolved doesn't help :-(
[19:46] <hazmat> i've got two debug windows up though
[19:47] <m_3> hazmat: heck of a long install
[19:47] <hazmat> indeed
[19:48] <hazmat> still its a bug that's not in debug-log output..
[19:49] <_mup_> ensemble/go-formulas r4 committed by gustavo@niemeyer.net
[19:49] <_mup_> The schema package now consistently outputs values of type schema.M
[19:49] <_mup_> for maps and schema.L for lists.
[19:51] <SpamapS> heh.. well at least my tests legitimately failed for a good reason
[19:52] <SpamapS> service names can only be like 16 chars long w/ the example formulas
[19:52]  * negronjl is back
[19:52] <negronjl> hazmat:  I'll make sure you get the latest one....committing, pushing now
[19:53] <negronjl> hazmat: cloudfoundry-server and cf-mysql both updated.
[19:54] <hazmat> negronjl, thanks, redeploying
[19:54] <negronjl> hazmat:  make sure you deploy on oneiric and not natty.  I put the ami and type in the environment file there.
[19:56] <hazmat> negronjl, indeed i'm using those, i don't see any new revs on cf-mysql.. latest revno is 2
[19:57] <m_3> so I get joined and two changes firing
[19:57] <m_3> walking through the logic
[19:57] <negronjl> hazmat:  I pushed revno 3
[19:59] <hazmat> negronjl, to where? https://pastebin.canonical.com/51828/
[19:59] <negronjl> hazmat: cf-mysql is here: bzr+ssh://bazaar.launchpad.net/~negronjl/%2Bjunk/cf-mysql/
[20:00] <negronjl> hazmat: cloudfoundry-server is here: bzr+ssh://bazaar.launchpad.net/~canonical-sig/%2Bjunk/cloudfoundry-server/
[20:00] <hazmat> negronjl, cool
[20:08] <hazmat> hmm
[20:08] <negronjl> hazmat: hmm...doesn't sound so good :)
[20:10] <hazmat> negronjl, so it looks like debug-hooks isn't working, i haven't seen a hook go by yet, ( ic new hooks being executed while sitting in the tmux session), and it seems to active be preventing successful transition recording.. quite odd.. 
[20:11]  * hazmat baselines against trunk
[20:11] <hazmat> and the example formulas
[20:11] <negronjl> hazmat:  ahah!!  I finally got someone to see it too ....YEAH!!!  I am not crazy :)
[20:12] <hazmat> negronjl, indeed, not i'm going to see if this also occurs with the example formulas and take it from there
[20:12] <hazmat> s/not/
[20:16] <_mup_> ensemble/go-formulas r5 committed by gustavo@niemeyer.net
[20:16] <_mup_> Fixed and tested schema coercing of nil values in several cases.
[20:18] <m_3> I'm running default amis (already had other services running) and saw debug-hooks fire between cf and cf-mysql
[20:20] <m_3> install failed though
[20:20] <negronjl> m_3:  install fails on natty....works only on oneiric
[20:20] <m_3> (exited cleanly but the service wasn't up)
[20:21] <_mup_> ensemble/go-formulas r6 committed by gustavo@niemeyer.net
[20:21] <_mup_> Ported formula id parsing and interface schema normalization.
[20:25] <hazmat> seems like the easiest way to debug is to setup an ssh into python interpreter on the agents
[20:25]  * hazmat goes back to trying it from the cli
[20:26] <negronjl> hazmat: FWIW.  I deploy both formulas ( cloudfoundry-server and cf-mysql ), ensemble ssh to both of them and tail -f formula.log... 
[20:26] <negronjl> hazmat: then I add-relation etc.  At least I get to see more or less what's going on 
[20:26] <_mup_> Bug #835037 was filed: Go port must handle interface schemas <Ensemble:New> < https://launchpad.net/bugs/835037 >
[20:29] <hazmat> negronjl, indeed that's a good thing to do, i'm just focusing on debug-hook functionality and forensics there is really about getting into the runtime state in the process to try and see what's going wrong.. before getting a local failing test case i can bisect against.. i have some suspicions but evidence is better
[20:30] <negronjl> hazmat: indeed :)
[20:31] <_mup_> ensemble/simplify-iface-schema r333 committed by gustavo@niemeyer.net
[20:31] <_mup_> Simplify the interface schema further.
[20:32] <niemeyer> hazmat++
[20:33] <hazmat> reproduced against example formulas
[20:33] <_mup_> Bug #835044 was filed: Interface schema handling is too complex <Ensemble:In Progress by niemeyer> < https://launchpad.net/bugs/835044 >
[20:33] <niemeyer> hazmat**2
[20:36] <hazmat> niemeyer, so i deployed mysql, and then did an immediate debug-hooks.. install hook is still running, completes and then executes start transition, config-change hook tries to execute.. no new debug-hook window in tmux session.. and it looks like the debug hook watcher is still running..
[20:37] <hazmat> unit agent log.. https://pastebin.canonical.com/51830/
[20:39] <hazmat> hook.pid never shows up in the debug-hook dir
[20:40] <hazmat> so creating the new window seems to have the problem
[20:40] <niemeyer> hazmat: Yeah, looks stuck in config-changed
[20:40] <niemeyer> hazmat: What's the deal there?
[20:40] <hazmat> niemeyer, its not really config-changed, its any hook, config-changed doesn't exist on these
[20:41] <niemeyer> hazmat: Ok, but I supposed you've hooked in with debug
[20:41] <hazmat> niemeyer, the debug hook script that executes something into tmux and waits for it, the launch in tmux portion is failing
[20:41] <hazmat> and the script just waits around forever
[20:41] <negronjl> hazmat, niemeyer:  unrelated question... config-change seems to be called when anything changes on the instances.   Is there a way to ( from inside the config-change hook ) figure out which hook changed or some indication of what changed?  This way I know more or less what needs to be updated .
[20:41] <niemeyer> hazmat: Any idea of how's it failing?
[20:42] <hazmat> niemeyer, still looking bbiam
[20:42] <niemeyer> negronjl: Not yet.. we've discussed a few ideas around that
[20:42] <niemeyer> negronjl: But still have to evolve a bit more
[20:42] <negronjl> niemeyer: cool...thx
[20:43] <niemeyer> negronjl: np
[20:45] <hazmat> niemeyer, what's this line do exec > $ENSEMBLE_DEBUG/debug.log >&1
[20:46] <hazmat> its just execing the rest of the script and sending stdout/sterr to the debug.log file?
[20:47] <niemeyer> hazmat: That's right
[20:47] <hazmat> niemeyer, hmm.. executing the script by hand works.. creates the new tmux window
[20:48] <niemeyer> Hmmm
[20:51] <niemeyer> hazmat: Is the log empty?
[20:51] <hazmat> niemeyer, it is
[20:51] <niemeyer> Feels like it hasn't run
[20:51] <hazmat> i'm adding a bunch of echoes to it, and going to run it again
[20:51] <hazmat> niemeyer, its running, its in the process list
[20:51] <hazmat> when the hook 'hangs'
[20:51] <niemeyer> Cool, that's good at least
[20:53] <hazmat> niemeyer, found it.. unit-name isn't being exported to debug hook
[20:53] <niemeyer> hazmat: Woah?
[20:53] <hazmat> niemeyer, tmux command doesn't get captured as error (there is a set -e at the top), and then goes onto wait for hook.pid
[20:54] <hazmat> tmux fails to start the new window because of the invalid session name
[20:54] <niemeyer> hazmat: set -e is the opposite.. it forces everything to error out
[20:54] <hazmat> ah
[20:55] <hazmat> niemeyer, i got it wrong about the env var i think.. i was using another window in the session, and its env variables got exported overwriting the original debug hook ones
[20:55] <niemeyer> Hmm, ok
[20:56]  * hazmat goes back to drawing board
[20:58] <hazmat> hmm tmux versions went from 1.3 in natty to 1.5 in oneiric
[21:01] <niemeyer> Nice bump.. I hope they didn't introduce the screen bug on the way
[21:01]  * niemeyer looks at the release notes
[21:01] <hazmat> yeah. was just checking those out
[21:06] <hazmat> niemeyer, this interesting comparison of screen 2 tmux.. makes why 2 use tmux pretty clear.. http://www.techrepublic.com/blog/opensource/is-tmux-the-gnu-screen-killer/1901
[21:07] <niemeyer> hazmat: Can't see anything obvious at least in the changelog
[21:07] <hazmat> i'm going to try backing the byobu work to see
[21:08] <niemeyer> hazmat: What about the echos?
[21:08] <hazmat> niemeyer, yeah.. me neither.. lots of couple of new session starting option
[21:08] <hazmat> niemeyer, just executing the debug hook script with echoes inserted to figure out the failure point
[21:09] <hazmat> i'm going to back out to a higher level and just try it sans the byobu work
[21:10] <hazmat> one more try on the cli b4 that
[21:11] <niemeyer> hazmat: Note that I've screwed up when merging the byobu work..
[21:11] <hazmat> niemeyer, yeah.. i saw the two commits
[21:11] <niemeyer> hazmat: Cool
[21:14] <hazmat> niemeyer, this is the line that locks up it looks like -> http://www.techrepublic.com/blog/opensource/is-tmux-the-gnu-screen-killer/1901
[21:14] <hazmat> whoops.. copy paste error
[21:14] <hazmat> tmux new-session -d -s $ENSEMBLE_UNIT_NAME 2> /dev/null || true
[21:15] <niemeyer> hazmat: Oh my.. not again :-)
[21:15] <niemeyer> hazmat: Ok.. what happens if you run two tmux with the same name on Oneiric?
[21:15] <niemeyer> hazmat: Using that line
[21:16] <niemeyer> This would also explain why sometimes it happens and sometimes it doesn't, since it depends on who wins the race to get the session created
[21:16] <hazmat> niemeyer, root@domU-12-31-39-05-75-E1:/tmp# tmux new-session -d -s wordpress/0 
[21:16] <hazmat> duplicate session: wordpress/0
[21:17] <niemeyer> hazmat: Phew.. alright, that's good
[21:17] <niemeyer> hazmat: No locks or anything
[21:17] <niemeyer> ?
[21:17] <hazmat> niemeyer,  but there's serveral processes in the process listing that are on that same command
[21:17] <hazmat> its definitely locked for some of them
[21:17] <niemeyer> hazmat: What's the behavior if you use a new name
[21:17] <niemeyer> ?
[21:18] <niemeyer> hazmat: That "-d" is from detach.. it should never stay
[21:18] <hazmat> hmmm.. i should probably try it outside of tmux ;-)
[21:18] <niemeyer> hazmat: Yeah, sounds like an idea :)
[21:19] <hazmat> hmm. on login via ssh ERROR: [/home/ubuntu/.byobu] is not writable by the current user
[21:21] <niemeyer> hazmat: That sounds like a hit
[21:22] <niemeyer> hazmat: Let's try to roll byobu back
[21:22] <hazmat> i'm not entirely convinced, but i'm not sure what else to try
[21:22] <hazmat> its wierd i can execute the debug hook new-session command from the cli and get the duplicate output, but it hangs if i execute the script on that line
[21:23]  * hazmat tries the rollback
[21:23] <niemeyer> hazmat: If you execute in which line?
[21:23] <hazmat> niemeyer, the tmux new-session -d -s unit_name 2   line
[21:24] <niemeyer> hazmat: Sorry, I'm not sure I understand
[21:24] <niemeyer> hazmat: You say it hangs if you execute the script on that line
[21:24] <niemeyer> hazmat: How are the working and the non-working executions different/
[21:24] <niemeyer> ?
[21:24] <hazmat> niemeyer, i can execute "tmux new-session -d -s unit_name" on the cli, works fine.. but the debug-hook hangs on that line
[21:25] <niemeyer> hazmat: Ok.. are you able to reproduce a hanging tmux somehow?
[21:25] <niemeyer> hazmat: Or is it just the outcome of the debug-hooks context itself that gets there?
[21:26] <hazmat> niemeyer, its a new ssh shell executing it, and it is reproducible.. executing the debug-hook script hangs
[21:27] <hazmat> this is with some previous context of the debug-hook session already being active
[21:27] <niemeyer> hazmat: Ok
[21:27] <hazmat> anyways.. going to rollback byobu and see if that helps
[21:27] <niemeyer> hazmat: If you get rid of ~/.tmux.conf, does it hang?
[21:27] <hazmat> niemeyer, checking
[21:27] <niemeyer> hazmat: "Getting rid" is just removing the tmux.conf..
[21:28] <niemeyer> hazmat: If byobu is at fault, the hanging script should be free as in speech
[21:28] <hazmat> niemeyer, still hangs
[21:28] <niemeyer> Ok, that's not it then
[21:28] <hazmat> yup
[21:28] <niemeyer> hazmat: Can you strace that?
[21:29] <hazmat> suer
[21:29] <niemeyer> hazmat: strace f
[21:29] <niemeyer> hazmat: strace -f
[21:29] <hazmat> sitting in epoll
[21:31] <niemeyer> hazmat: On what fds?
[21:31] <hazmat> niemeyer, hold on grabbing a trace output for pastebin
[21:33] <hazmat> niemeyer, https://pastebin.canonical.com/51834/
[21:33] <niemeyer> hazmat: Super
[21:35] <niemeyer> hazmat: 23695 connect(7, {sa_family=AF_FILE, path="/tmp/tmux-0/default"}, 21) = 0
[21:35] <niemeyer> hazmat: That's what it's waiting on
[21:37] <hazmat> somethings wonkey.. i started killing off the new-session processes that are hanging now i'm a tmux refresh loop
[21:38] <niemeyer> hazmat: I'm connecting some dots here
[21:39] <negronjl> hazmat, niemeyer: fwiw....I think byobu is installed and enabled by default on oneiric.. not sure how it could affect what's going on but, worth mentioning
[21:39] <hazmat> niemeyer, so the byobu session was still active actually in the existing session after the conf file
[21:39] <niemeyer> hazmat: Hmm
[21:39] <niemeyer> hazmat: Makes sense
[21:40] <niemeyer> negronjl: Cool.. we still have to source the file I think, but from hazmat's comment we were actually still with it
[21:40] <niemeyer> hazmat: I'm starting to suspect this may actually be a new internal race too
[21:40] <niemeyer> hazmat: Worth testing without byobu
[21:40] <hazmat> niemeyer, in progress
[21:42] <niemeyer> hazmat: If it happens again, try to see what are the initial tmux processes that are active 
[21:42] <niemeyer> hazmat: It looks like a lock is being left acquired
[21:45] <niemeyer> hazmat: I have a workaround in mind, but we should probably try to understand a bit better what's going on before that 
[21:48] <niemeyer> hazmat: I read it wrong.. it's not waiting for a lock.. it's waiting for data
[21:49] <niemeyer> Makes it yet more strange
[21:55] <hazmat> hmm. ah i see what negronjl was saying.. oneiric defaults you into a byobu screen shell
[21:58] <niemeyer> hazmat: How do you mean?
[21:58] <hazmat> ssh ec2-instance.. -> byobu shell
[21:59] <hazmat> ec2 is being slow today..
[21:59] <hazmat> at instance creation for me
[22:00] <_mup_> ensemble/fix-functional-testing r332 committed by jim.baker@canonical.com
[22:00] <_mup_> Fixes for a variety of bitrot in ftests
[22:00] <niemeyer> hazmat: Wow, really?
[22:00] <niemeyer> hazmat: So we get straight into a screen?
[22:01] <hazmat> niemeyer, yeah.
[22:01] <hazmat> on debug-hooks into a new machine "To launch in a nested session, run: byobu" is at the top
[22:01] <niemeyer> hazmat: Oh my
[22:02] <niemeyer> hazmat: Well, wait.. but that's because we're within a tmux session, right?
[22:02] <hazmat> it is in that case
[22:02] <niemeyer> hazmat: What does CTRL-A-C do?
[22:02] <hazmat> new window
[22:03] <niemeyer> hazmat: Does it create something into the internal tmux, or in an outside screen?
[22:03] <hazmat> its in tmux
[22:03] <hazmat> i think
[22:03] <niemeyer> hazmat: Ok, so there must be no outside screen
[22:03] <niemeyer> hazmat: Or tmux
[22:03] <niemeyer> hazmat: Isn't that simply reflecting the fact we're reading the byobu conf?
[22:04] <hazmat> niemeyer, we're using the old conf, not sourcing byobu
[22:04] <hazmat> for tmux
[22:05] <niemeyer> hazmat: So where is byobu being loaded in? I don't get it..
[22:05] <niemeyer> kirkland: ping
[22:05] <negronjl> niemeyer:  byobu is being loaded from $HOME/.profile
[22:05] <hazmat> hmm. there both tmux sessions
[22:05] <niemeyer> negronjl: Aha
[22:05] <niemeyer> Ok
[22:05] <niemeyer> hazmat: Hm?
[22:06] <hazmat> oh.. i'm on different machines nevermind
[22:06] <hazmat> okay debug-hooks goes into tmux with the proper config
[22:07] <hazmat> and still hangs
[22:07] <hazmat> https://pastebin.canonical.com/51835/
[22:08] <niemeyer> WOah
[22:09] <niemeyer> SO, how come
[22:10] <niemeyer> hazmat: Is that the initial state?
[22:11] <hazmat> niemeyer, that's debug-hooks into a new machine, service unit finishes install, and tries to execute config-changed
[22:11] <hazmat> otherwise clean
[22:11] <niemeyer> hazmat: I don't understand how there are two pts's there
[22:16] <niemeyer> hazmat: Ah, I get it I think
[22:17] <niemeyer> hazmat: What does tmux list-sessions show?
[22:17] <hazmat> mysql/0: 2 windows (created Fri Aug 26 22:01:05 2011) [168x36] (attached)
[22:20] <niemeyer> hazmat: The pstree has one tmux
[22:20] <niemeyer> hazmat: The ps auxw has three..
[22:21] <niemeyer> hazmat: Sorry, my mistake
[22:21] <hazmat> negronjl, looks like byobu is activated by  /etc/profile.d/Z98-byobu.sh 
[22:21] <niemeyer> hazmat: Seriously, there are two sessions somehow :/
[22:21] <kirkland> hazmat: right, that's the package-enabled way
[22:21] <negronjl> hazmat:  you're right....sorry for the misinformation.  I checked MY box and not the oneiric instance.
[22:21] <kirkland> hazmat: there's also a per-user method
[22:22] <niemeyer> hazmat: Can you get a list of files that each of those tmux new-session processes are using?
[22:23] <niemeyer> hazmat: lsof -p 1634
[22:23] <niemeyer> hazmat: lsof -p 3667
[22:29] <niemeyer> hazmat?
[22:29] <hazmat> niemeyer, 1634 -> https://pastebin.canonical.com/51837/ 3667 -> https://pastebin.canonical.com/51836/   tmux-attach / 1636 -> https://pastebin.canonical.com/51838/
[22:29] <niemeyer> hazmat: Is there more than one /tmp/tmux-* dir?
[22:30] <hazmat> what's that command to install someones launchpad key on a machine?
[22:31] <hazmat> niemeyer, one tmux dir 
[22:32] <hazmat> ssh-import-lp-id
[22:33] <hazmat> niemeyer, ubuntu@ec2-174-129-118-179.compute-1.amazonaws.com
[22:35] <niemeyer> hazmat: Cheers!
[22:40] <niemeyer> kirkland: This is starting to feel a bit too intrusive
[22:40] <niemeyer> ubuntu@ip-10-46-54-97:/tmp$ sudo su -
[22:40] <niemeyer> To launch in a nested session, run: byobu
[22:40] <niemeyer> root@ip-10-46-54-97:~#
[22:41] <kirkland> niemeyer: right, do you want a nested session, or not?
[22:41] <niemeyer> kirkland: I want to run sudo
[22:41] <kirkland> niemeyer: then run sudo
[22:41] <niemeyer> kirkland: I did.. and the system tells me completely unrelated facts all the time
[22:42] <kirkland> niemeyer: what are "unrelated facts"
[22:42] <niemeyer> kirkland: I've just pasted above
[22:43] <SpamapS> /usr/lib/pymodules/python2.6/ensemble/providers/ec2/files.py:8: DeprecationWarning: the sha module is deprecated; use the hashlib module instead
[22:43] <SpamapS> Is there a way to suppress that?
[22:43] <kirkland> niemeyer: the fact you're speaking of being, "To launch in a nested session, run: byobu"
[22:43] <kirkland> ?
[22:43] <niemeyer> kirkland: Getting output from "sudo su -" every time telling me to run something else is a bit obnoxious
[22:44] <niemeyer> SpamapS: Ugh.. yeah, we should follow the advice :)
[22:44] <niemeyer> hazmat: Was that a clean run?
[22:44] <niemeyer> hazmat: There are 4 different tmp directories in /tmp
[22:44] <niemeyer> hazmat: With hook data, that is
[22:44] <hazmat> niemeyer, outside of me killing processes yes ;-)
[22:44] <niemeyer> Oh man :)
[22:45] <hazmat> niemeyer, its pretty clean though, those are the original processes competing
[22:45] <SpamapS> a good, clean kill
[22:45] <kirkland> niemeyer: that's a one liner to comment out or remove, file a bug and i'll fix it
[22:45] <kirkland> ./usr/bin/byobu-launcher:                       printf "$(gettext 'To launch in a nested session, run: byobu')\n"
[22:45] <kirkland> niemeyer: i put that there at the request of users, however
[22:46] <niemeyer> kirkland: Probably of users of byobu.. I'm concerned about people that are used to using sudo
[22:47] <kirkland> niemeyer: does it do that if you do "sudo true" ?
[22:47] <kirkland> niemeyer: in my experience, "no, it does not";  it does that when it establishes a new login shell, a la 'su -'
[22:47] <niemeyer> kirkland: No, that doesn't load the env
[22:47] <kirkland> niemeyer: right
[22:48] <kirkland> niemeyer: fine.  if you file a bug at https://bugs.launchpad.net/ubuntu/+source/byobu/+filebug, I'll silence that now
[22:48] <niemeyer> kirkland: Cheers!
[22:48] <kirkland> niemeyer: cheers
[22:48] <kirkland> niemeyer: paste me the bug number and i'll commit and push
[22:50] <niemeyer> kirkland: #835130
[22:50] <_mup_> Bug #835130: byobu is too verbose <byobu (Ubuntu):New> < https://launchpad.net/bugs/835130 >
[22:51] <kirkland> niemeyer: Committed revision 1622.                                                                                                                     
[22:51] <kirkland> niemeyer: thanks for playing ;-)
[22:51] <niemeyer> kirkland: Interestingly, users seem to have asked the feature because it was even more disruptive to the workflow
[22:51] <niemeyer> kirkland: #747649
[22:51] <_mup_> Bug #747649: opening a nested session from byobu to byobu should not ask, but rather should remind the user... <byobu (Ubuntu):Fix Released by kirkland> < https://launchpad.net/bugs/747649 >
[22:52] <niemeyer> kirkland: This kind of tool should really not kick in before the user decides to use, IMO
[22:55] <kirkland> niemeyer: it's silently exiting now, as of this commit
[22:57] <niemeyer> kirkland: Have you seen this one:
[22:58] <niemeyer> ERROR: [/home/ubuntu/.byobu] is not writable by the current user
[22:58] <niemeyer> ubuntu@ip-10-46-54-97:~$ 
[22:58] <kirkland> niemeyer: yes
[22:58] <niemeyer> kirkland: Supa
[22:58] <kirkland> niemeyer: this happens if you sudo byobu
[22:59] <kirkland> niemeyer: or run byobu while under sudo
[22:59] <kirkland> niemeyer: the byobu directory gets created under the root user
[22:59] <kirkland> niemeyer: rather than the $SUDO_USER
[22:59] <niemeyer> kirkland: Yeah, I understand why it happened
[23:00] <niemeyer> Now I just have to understand tmux
[23:01] <kirkland> niemeyer: let me see if I can come up with a suitable fix to that right quick ....
[23:04] <niemeyer> hazmat: I have little doubts that this is a race introduced in tmux
[23:05] <niemeyer> hazmat: Oh ho ho
[23:06] <niemeyer> hazmat: 
[23:06] <niemeyer> # tmux new-session -d -s mysql/0 < /dev/null 2> /dev/null
[23:06] <niemeyer> ^C^\Quit (core dumped)
[23:07]  * SpamapS wonders if core is feeling vulnerable and lonely after being dumped..
[23:08] <hazmat> niemeyer, hmm
[23:08] <hazmat> so what are options..
[23:08] <hazmat> SpamapS, probably just lazing around getting fat ;-)
[23:09] <niemeyer> hazmat: 1) Fixing the bug in tmux; 2) Changing the logic so it doesn't hit the bug
[23:09] <hazmat> niemeyer, the race seems odd, there are seconds between them
[23:09] <niemeyer> hazmat: It's not even a race
[23:09] <niemeyer> hazmat: Plain bug :(
[23:10] <hazmat> niemeyer, back to screen :-)
[23:10] <kirkland> SpamapS: probably relieved, stomachs feeling much better
[23:10] <niemeyer> hazmat: :-)
[23:10] <niemeyer> hazmat: Let's use dash instead
[23:11] <niemeyer> kirkland: You're in oneiric right?
[23:11] <kirkland> niemeyer: yup
[23:11] <niemeyer> kirkland: Would you mind to help us with a quick test
[23:11] <kirkland> niemeyer: i've got a fix for your ownerships issue;  file another bug and i'll commit
[23:12] <kirkland> niemeyer: sure, whaddaya need?
[23:12] <niemeyer> kirkland: tmux new-session -d -s foo
[23:12] <niemeyer> kirkland: Run that a couple of times in different non-nested terminals
[23:12] <kirkland> Nicke: k
[23:12] <kirkland> kirkland@x201:~$ tmux new-session -d -s foo
[23:12] <kirkland> kirkland@x201:~$ tmux new-session -d -s foo
[23:12] <kirkland> duplicate session: foo
[23:12] <niemeyer> kirkland: Should blow up the second time with duplicated session error
[23:12] <niemeyer> Cool
[23:12] <niemeyer> kirkland: Now, one more
[23:12] <niemeyer> kirkland: tmux new-session -d -s foo 2> /dev/null
[23:13] <kirkland> kirkland@x201:~$ tmux new-session -d -s foo 2> /dev/null
[23:13] <kirkland> ......

[23:13] <niemeyer> Man.. I'm getting out of this software business
[23:13] <niemeyer> kirkland: Thanks!
[23:13] <kirkland> niemeyer: np
[23:15] <kirkland> niemeyer: checking my $SUDO_USER fix with the security team
[23:15] <niemeyer> kirkland: Thanks man
[23:15] <hazmat> niemeyer, http://sourceforge.net/mailarchive/forum.php?thread_name=20110826161855.GC13865%40smoon&forum_name=tmux-users
[23:17] <niemeyer> hazmat: WOAH!
[23:18] <niemeyer> hazmat: Sadly, the workaround there doesn't work
[23:18] <kirkland> niemeyer: security team says: <kees> run sudo with -H :)
[23:18] <niemeyer> kirkland: Heh
[23:19] <kirkland> niemeyer: i'm negotiating with him ;-)
[23:21] <niemeyer> hazmat: Let's make sure we don't do anything absurd with tmux like redirecting its output to /dev/null
[23:23] <niemeyer> hazmat: tmux new-session -d -s mysql/0 2>&1 | cat > /dev/null
[23:23] <niemeyer> !!!
[23:24] <niemeyer> negronjl: So.. there's a bug in tmux that we're hitting.  We should have a solution in a moment
[23:25] <negronjl> niemeyer:  no worries.  I've been monitoring this :)
[23:39] <kirkland> Nicke: do you have a bug for the $SUDO_USER issue?
[23:39] <kirkland> niemeyer: ^
[23:53] <niemeyer> kirkland: Nope, haven't created one for that
[23:53] <SpamapS> hrm.. debug-log seems to not be as useful as it once was
[23:53] <kirkland> niemeyer: 835152
[23:53] <kirkland> niemeyer: i created it for you
[23:54] <niemeyer> kirkland: Thanks!
[23:55] <hazmat> niemeyer, yeah.. works for me
[23:59] <niemeyer> hazmat, kirkland, negronjl: http://paste.ubuntu.com/675631
[23:59] <hazmat> niemeyer, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609444
[23:59] <hazmat> niemeyer, that looks fine minus all the formula/* stuff
[23:59] <kirkland> +tmux new-session -d -s {unit_name} 2>&1 | cat > /dev/null || true
[23:59] <kirkland> wowzer