[00:11] <phe_13> marcoceppi, here am i
[00:11] <marcoceppi> phe_13: are you running this command from your machine, or the AWS machine?
[00:12] <phe_13> my machine
[00:13] <marcoceppi> Okay, do you have your juju environment setup to connect to AWS?
[00:14] <marcoceppi> https://juju.ubuntu.com/docs/getting-started.html#configuring-your-environment-using-ec2
[00:14] <phe_13> sorry man, thats my AWS machine, but it in my own DMZ
[00:16] <phe_13> # juju bootstrap
[00:16] <phe_13> Could not find AWS_ACCESS_KEY_ID
[00:16] <phe_13> 2012-06-13 21:16:24,605 ERROR Could not find AWS_ACCESS_KEY_ID
[00:19] <marcoceppi> phe_13: what version of Ubuntu are you running?
[00:21] <phe_13> debian wheezy
[07:40] <pkimber> #join pocoo
[11:04] <zyga> hey, https://juju.ubuntu.com/ says "If you are testing Ubuntu 12.04"... I think we should apply s/testing/using/
[11:04] <zyga> how can I fix that?
[11:11] <zyga> juju does not work well when co-installed with virtualbox
[11:12] <zyga> juju bootstrap fails because virbr0 is already created
[13:07] <bbcmicrocomputer> I'm guessing it is, but is the transmission of config data between the juju client to the cloud (and subsequently to the deployed instances) encrypted?
[13:08] <marcoceppi> bbcmicrocomputer: data between client and bootstrap node is encrypted to my understanding, however I'm not sure about node -> node communication (though I would assume it is)
[13:08] <imbrandon> via ssh from you to the bootstrap node yes, between clients no idea
[13:08] <imbrandon> heya marcoceppi
[13:08] <marcoceppi> o/
[13:09] <bbcmicrocomputer> imbrandon, marcoceppi: thanks
[13:09] <marcoceppi> imbrandon: I've got fixes for the wordpress session issue *maniacal laugh*
[13:09] <imbrandon> ann yea i figured out what it was tooo
[13:09] <imbrandon> ahh*
[13:10] <imbrandon> the secret keys were diffrent on the nodes
[13:10] <marcoceppi> yup
[13:10] <marcoceppi> \o/ soo easy.
[13:10] <imbrandon> yea , when i noticed that i was like yay
[13:10] <imbrandon> heh
[13:10] <marcoceppi> I should have generic wp charm ready end of next week
[13:11] <imbrandon> sweet, i am hoping to have the drupal one tomarrow ( drupal 7 not 6 )
[13:11] <imbrandon> 6 is in the store
[13:11] <imbrandon> but not "great"
[13:11] <marcoceppi> imbrandon: is there an nginx proxy charm yet?
[13:11] <imbrandon> thats comming with the 7 charm
[13:11] <marcoceppi> cool
[13:11] <imbrandon> its really a group of charms
[13:12] <imbrandon> nginx and nginx proxy and drupal and drupal-site
[14:14] <SpamapS> imbrandon: we need a way to define a strong primary<->subordinate relationship.
[14:14] <SpamapS> imbrandon: I like the way you're going w/ drupal/nginx .. but its going to make the setup pretty non-intuitive.. we need "stacks"
[14:15] <imbrandon> yea i was working on a dependancy hack
[14:15] <imbrandon> but yea we need a real way
[14:16] <imbrandon> the problem i came accross in the depend hack was it made it hard to use the charm outside of that stack
[14:17] <imbrandon> e.g. nginx-proxy dont HAVE to use nginx as the server etc
[14:18] <imbrandon> SpamapS ( or hazmat ) yall know what the deal is with the docs build, i see the error but no idea why it dident build
[14:24] <SpamapS> error?
[14:25] <imbrandon> yea something about the makefile conflict, i am guessing thats it
[14:25] <imbrandon> one sec
[14:30] <imbrandon> erm cant fin it in LP right now
[14:31] <imbrandon> i was checking earlier that the merge went ok after hazmat approved it yesterday
[14:31] <imbrandon> and noticed it dident build , some page listed a makefile conflict but now i cant find it , heh
[14:39] <cheez0r> hrm, I'm running a juju bootstrap in a maas environment, and when I run juju -v status, it says it's trying to SSH connect to remote port 2181; why would that be?
[14:39] <cheez0r> SSH is running on port 22 of the targeted nodes, leading to the connection for juju status timing out.
[14:40] <imbrandon> zookeeper
[14:41] <cheez0r> nothing on the targeted node is listening to port 2181 however.
[14:50] <imbrandon> SpamapS: +1000 on the missing-hook idea
[14:55] <m_3> imbrandon: yeah, that sounds awesome
[15:38] <lucian> hello. i'm trying to find out about the status of rackspace support
[15:39] <lucian> there is a ticket from 2011, but that's all i could find
[15:41] <m_3> lucian: no native openstack provider yet... you still need to have the ec2 api enabled.  so no love on the rackspace cloud proper yet
[15:41] <m_3> (afaik)
[15:41] <lucian> m_3: ok, thanks
[15:42] <m_3> np
[15:59] <negronjl> 'morning all
[16:03] <m_3> negronjl: mornin
[16:03] <negronjl> 'morning m_3
[16:03] <imbrandon> heya
[16:04] <negronjl> 'morning imbrandon
[17:24] <hspencer> congrats on getting juju into Debian unstable..good work guys
[17:32] <m_3> SpamapS: whoohoo!!  ^
[17:35] <koolhead17> hspencer, :)
[17:35] <koolhead17> SpamapS, siir
[17:41] <SpamapS> hspencer: thanks :)
[17:43] <negronjl> jcastro: ping
[17:43] <koolhead17> SpamapS, hello sirr
[17:44] <SpamapS> koolhead17: howdy
[17:44] <shazzner> I'm curious, does juju on debian bootstrap debian nodes?
[17:45] <SpamapS> no
[17:45] <SpamapS> debian lacks a few things
[17:45] <shazzner> ah ok, just curious
[17:45] <SpamapS> actually its possible that the local provider could be made to do it
[17:45] <SpamapS> I haven't looked at the lxc debian template to see
[17:45] <shazzner> huh
[17:46] <SpamapS> But the code itself calls 'lxc-create -t ubuntu' so.. no ;)
[17:46] <shazzner> ah ok cool
[17:46] <shazzner> having to rewrite charms would be a waste of effort anyway
[17:54] <SpamapS> shazzner: I think at least some charms will work fine crossing over from debian and ubuntu
[17:54] <SpamapS> shazzner: but yeah, I don't see much point honestly
[17:55] <SpamapS> Maybe if somebody wants to spin up on architectures that ubuntu doesn't have
[19:17] <bkerensa> jcastro: any update on the HP thing? I got a call from someone in their engineering team yesterday randomly
[19:29] <m_3> jcastro's at a conference today
[19:53] <robbiew> bkerensa: I can confirm you are on the list
[19:53] <bkerensa> robbiew: thanks
[19:53] <robbiew> and we received confirmation from HP that they have you
[19:54] <bkerensa> robbiew: So I can start using a instance now?
[19:54] <robbiew> as to why someone from engineering would call...no idea...job offer? :)
[19:54] <robbiew> hmm
[19:54] <robbiew> one sec
[19:55] <robbiew> bkerensa: now THAT I don't know...let me check with our internal liason...one sec
[19:58] <robbiew> bkerensa: not getting a response, I shoot him an email and let you know
[19:58] <bkerensa> kk
[20:11] <robbiew> bkerensa: our internal HP contact just responded and said he'll follow up...translation, no one knows :/
[20:12] <bkerensa> :)
[22:30] <mars> SpamapS, around?
[22:43] <SpamapS> mars: I am, wassup?
[22:45] <mars> Hey SpamapS, I replied to bug 1006553, and I have a live runaway process on my system right now.  I was wondering if you needed to gather any other feedback while I have it?
[22:45] <_mup_> Bug #1006553: Juju uses 100% CPU after host reboot <juju:New> < https://launchpad.net/bugs/1006553 >
[22:46] <mars> SpamapS, it isn't hard to reproduce, takes about a day, but I thought if you needed more info, a live discussion would speed things up.  But if you prefer to keep it in the bug, that's cool too.
[22:47] <SpamapS> mars: yeah hm
[22:47] <SpamapS> mars: can you strace -f $thepid -o /tmp/foo.txt .. wait about 5 seconds, then pastebin that file?
[22:48] <SpamapS> oh now I see your reply, reading
[22:49] <mars> just for fun, the 5 second tracelog is 8.2M :)
[22:49] <SpamapS> mars: takes a day is a bit weird
[22:50] <mars> SpamapS, well, it doesn't start as soon as the system is booted.  I have to wait for the process to go nuts.  I haven't measured exactly, but 24 hours is enough.
[22:50] <SpamapS> thats very weird
[22:52] <mars> SpamapS, fwiw, zookeeper has a cron entry in cron.daily
[22:53] <SpamapS> mars: zookeeper or zookeeperd ? (meaning, the package names)
[22:53] <mars> zookeeper
[22:54]  * SpamapS checks that out
[22:57] <SpamapS> mars: well that doesn't seem to cause the issue
[22:57] <SpamapS> mars: in fact that just exits immediately
[23:01] <mars> SpamapS, what limits the machine agent connection loop?  You said yours tries every few seconds, whereas mine is in a busy-wait loop
[23:05] <SpamapS> mars: I think mine is blocked on something else
[23:05] <SpamapS> mars: is anything landing in $datadir/machine-agent.output ?
[23:06] <mars> SpamapS, nope
[23:06] <SpamapS> mars: actually it might even be /tmp/juju-$user-$envname-machine-agent.output
[23:06] <mars> the only file I have is machine-agent.log, which I posted to the original bug report
[23:06] <SpamapS> mars: do you have the file in /tmp tho?
[23:08] <mars> SpamapS, you mean, my data directory? Yes, that is: /tmp/local-juju/mars-local/machine-agent.log
[23:11] <SpamapS> mars: no the upstart job seems to redirect output to a special file
[23:12] <SpamapS> mars: check /etc/init/juju-mars-local-machine-agent.conf
[23:12] <SpamapS> mars: it should be redirecting output somewhere. Check that file.
[23:14] <SpamapS> mars: I'm trying to get a way for you to run the agent in the python debugger
[23:15] <SpamapS> mars: hopefully you can run it that way, and when it goes wack-o again, ctrl-c will drop you wherever it is polling
[23:15] <SpamapS> hazmat: ^^ your expertise in python debugging would be helpful here :)
[23:15] <SpamapS> jimbaker: ^^
[23:15] <mars> SpamapS, found it: machine-agent.output is empty.  file-storage.output has Python exceptions in it, but it isn't growing.
[23:19] <SpamapS> hrm.. debugger doesn't actually help that much because of twisted
[23:21] <mars> You need to embed one of those SIGUSR1 "dump trace and exit" hooks :)
[23:21] <SpamapS> mars: can you pastebin 'sudo lsof -n -p ...' whatever the pidof is
[23:21] <SpamapS> mars: yeah
[23:24] <mars> SpamapS, http://pastebin.ubuntu.com/1041631/
[23:31] <mars> This looks promising: http://stackoverflow.com/questions/132058/showing-the-stack-trace-from-a-running-python-application
[23:37] <SpamapS> mars: the second answer looks helpful
[23:39] <SpamapS> I think threading may be getting int he way here too
[23:43] <SpamapS> mars: can you attach to the process with gdb -p $thepid and do a 'bt' then 'thread 2' then 'bt' ?
[23:44] <SpamapS> mars: In mine, there are three threads (1 2 3) and 2 are inside libzookeeper
[23:45] <SpamapS> mars: thanks for going through this btw
[23:45] <mars> SpamapS, np
[23:46] <mars> SpamapS, same here, three threads, Py_Main, and two in libzookeeper
[23:47] <mars> SpamapS, one of them is in setsockopt, called from zookeeper_interest in libzookeeper.  Is that what you see?
[23:49] <SpamapS> mars: no actually
[23:50] <SpamapS> #0  0x00007ffc5c18db03 in __GI___poll (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87
[23:51] <SpamapS> mars: I'm beginning to think this is some weird libzookeeper bug
[23:51] <SpamapS> mars: either way, I think we should actually just take out the 'start on ...' from the local provider agents until zookeeper is started as well
[23:52] <mars> SpamapS, if it is Python, I can just hack a fix in there to test it out
[23:58] <SpamapS> mars: anyway, I think the right fix is to not start the agents on reboot