=== CyberJacob is now known as CyberJacob|Away [02:59] good nigth everyone [02:59] there is any document about how to deploy juju on rackspace infrastructure? === mwhudson is now known as zz_mwhudson [03:45] marcoceppi: ping, I think it's done, I'll be around for a couple more hours :) === timrc is now known as timrc-afk [04:44] marcoceppi: hey, you coming downstairs? === JoseeAntonioR is now known as jose === stub` is now known as stub === seelaman` is now known as seelaman === thumper is now known as thumper-afk === CyberJacob|Away is now known as CyberJacob === mthaddon` is now known as mthaddon === Geek_Juice is now known as Bryanstein === ev_ is now known as ev [11:49] trying to run juju test, I get ' does not exist in ~/.juju/environments.yaml' or when specifying the current environment using -e, says it is already bootstrapped, so I need an environment but not have it bootstrapped? [12:11] hazmat: is this any better: http://paste.ubuntu.com/6986642/ http://paste.ubuntu.com/6986643/ [12:12] cjohnston, yes.. thanks.. [12:13] hazmat: do you need anything else from it before I trash it? [12:13] cjohnston, btw.. just needed deployer run output and machine-0.log not all-machines. [12:13] ack [12:13] cjohnston, let me check on #juju-dev one moment [12:13] http://paste.ubuntu.com/6986666/ [12:17] cjohnston, i'm wondering if you picked/sized a larger state server if this issue would go away.. [12:17] a 1g server isn't good enough? :-( [12:25] depends on how over subscribed things really are on canonistack [12:25] it was pretty bad last i looked, not sure what the current state is. === zz_frobware is now known as frobware [12:41] horrible would be the correct word I believe :-) [13:03] cjohnston, have you run mpstat or top to look at your stolen cpu percentage? [13:04] hazmat: no.. the load avg yesterday when I watched it got up to ~3 [13:04] cjohnston, on a single vcpu system.. that seems high [13:11] hazmat: I'll give it a try with a larger bootstrap today === mhall119_ is now known as mhall119 === timrc-afk is now known as timrc [13:39] Are we upgrading the image stream information again? I'm getting missing image stream data errors from juju this morning on AWS East AZ [13:39] s/East/US East/ === jcsackett_ is now known as jcsackett [13:55] ah looks like i missed an update: https://bugs.launchpad.net/juju-core/+bug/1283246 [13:55] <_mup_> Bug #1283246: cannot deploy on 1.17.2 on trusty: error on image-stream [14:00] lazyPower: yea, get .3 [14:00] It threw me for a loop. I've seen that error on HPCloud before, but not aws - google sorted me though. === deej` is now known as deej === psivaa is now known as psivaa-afk-bbl [14:52] lazyPower, I just got that as well - its 1.17.2 client against a 1.17.3 environmnet [14:53] jamespage: Yep - the bug sorted me out. I forgot we got a version bump last week that i was dragging feet on upgrading. [14:53] Thanks for the follow up though! [14:54] lazyPower, np === bdmurray_ is now known as bdmurray [15:28] trying to run juju test, I get ' does not exist in ~/.juju/environments.yaml' or when specifying the current environment using -e, says it is already bootstrapped, so I need an environment but not have it bootstrapped? [15:34] is there a way to juju set a new key, a key that is not in config.yaml already? [15:38] cargill: correct, juju test will do bootstraping for each test [15:38] vds: you can't create new configuration values for charms on the fly, it has to already exist in config.yaml [15:44] is it possible to run the juju run command from inside a unit? [15:45] hello! I'm running juju devel (1.17.3-0ubuntu1~ubuntu13.10.1~juju1) and I'm using juju to bootstrap some services for the click-package-index project. With juju we start a solr and a elasticsearch unit. When bootstrapping those I never see the units progressing from the "pending" state. Ouput of juju status, and unit logs are at https://pastebin.canonical.com/105456/ [15:45] mattyw: in the dev releases there's a new 'juju run' command that can do that [15:46] rick_h, yeah - can that command be run from inside a unit? [15:46] vds: no, the key has to exist and the charm has to know what to do/change on that key as there's not an explicit connection between the config.yaml and what the charm does [15:46] mattyw: oh, inside the unit? well it runs the command in the unit [15:46] like ps or such [15:46] an example is juju run uptime [15:49] marcoceppi_: and how do I create one? I tried adding "test: type:local admin-sercet: ..." but still says that it's already bootstrapped === psivaa-afk-bbl is now known as psivaa [15:50] cargill: well, is that environment bootstrapped? [15:50] no, I just added it to the environments.yaml file [15:51] cargill: do you have /any/ local environment bootstrapped? [15:51] yes, it's name is local [15:51] *its [15:51] cargill: you can't bootstrap two local environments at the same time without some tweaking [15:51] re: my issue with unit stuck in pending state, one of the errors show "2014-02-24 15:43:22 ERROR juju runner.go:220 worker: exited "upgrader": cannot read tools metadata in tools directory: open /home/nessita/.juju/local/tools/1.17.3.1-precise-amd64/downloaded-tools.txt: no such file or directory" and when browsing the content of /home/nessita/.juju/local/tools/ there is no folder named 1.17.3.1-precise-amd64, just 1.17.3.1-saucy- [15:52] marcoceppi_: so how can i test stuff then? :) [15:52] is that a known issue? shall I downgrade to 1.17.2? [15:52] cargill: well, you'll need to either destroy the existing local environment, or make a few tweaks to have two simultaneously bootstrapped local environments [15:53] nessita: that's something weird, like cloud-init failing, can you pastebin the cloudinit logs? [15:53] yes [15:53] cargill: also, try running ssh elasticsearch/0 and running sudo apt-get update [15:53] err, nessita ^^ sorry, cargill [15:53] nessita: verify those boxes have networking [15:54] marcoceppi_: how can I do that? [15:54] nessita: try running ssh elasticsearch/0 and running sudo apt-get update [15:54] ack [15:58] * nessita1 internet hiccup === rektide_ is now known as rektide [16:04] marcoceppi_: thanks for the pointer. So, I ssh'd into elasticsearch and confirmed the unit has network connection [16:05] nessita1: cool, cloud-init logs will help illuminate why git wasn't installed [16:05] pasting [16:06] marcoceppi_: http://pastebin.ubuntu.com/6987662/ === nessita1 is now known as nessita [16:07] marcoceppi_: the issue I see is the mismatch between the tools folder [16:07] /home/nessita/.juju/local/tools/1.17.3.1-saucy-amd64 vs /home/nessita/.juju/local/tools/1.17.3.1-precise-amd64 [16:08] the unit expects the latter [16:08] and cloud-init uses the former? [16:09] the unit and cloud-init should both be using the precise one [16:12] nessita: this cloud-init from bootstrap node [16:12] marcoceppi_: perhaps is a bug on juju devel tools 1.17.3? [16:12] nessita: juju ssh elasticsearch/0 [16:12] I installed the update this moring [16:12] and give me the cloud-init log from there [16:12] marcoceppi_: on it [16:12] marcoceppi_: where shall I find the cloud init inside the unit? [16:14] nessita: somewhere in /var/log [16:14] marcoceppi_: http://pastebin.ubuntu.com/6987690/ [16:14] perhaps you need the full content not just the last 10 lines, no? [16:16] let me fix that, sorry [16:16] nessita: yeah, full content of the ones in /var/log, don't need /var/log/juju [16:17] marcoceppi_: http://pastebin.ubuntu.com/6987710/ [16:17] so as you predicted there seem to be some network failure, but when I ssh'd into the unit, apt-get update fetched all the repos [16:17] nessita: yeah, seems like for some reason it wasn't able to resolve dns at first [16:17] nessita: so, juju destroy-environment, try bootstrapping/deploying again [16:17] marcoceppi_: thanks, will do === seelaman` is now known as seelaman [17:17] marcoceppi_: so, I destroyed the env and re-bootstrapped, both agents (solr and elasticsearch) show as started, thanks a lot for your help. One more question though: unit-solr-jetty-0.log and unit-elasticsearch-0.log keep showing: [17:17] 2014-02-24 17:16:46 ERROR juju runner.go:220 worker: exited "upgrader": cannot read tools metadata in tools directory: open /home/nessita/.juju/local/tools/1.17.3.1-precise-amd64/downloaded-tools.txt: no such file or directory === hatch_ is now known as hatch === roadmr_ is now known as roadmr [17:47] nessita: is there a /home/nessita/.juju/local/tools/1.17.3.1-precise-amd64 directory? [17:48] marcoceppi_: no, there is not http://pastebin.ubuntu.com/6988138/ [17:48] just 1.17.3.1-saucy-amd64 [17:50] nessita: interesting, wonder why that didnt' get created. What's in 1.17.3.1-saucy-amd64 [17:51] marcoceppi_: http://pastebin.ubuntu.com/6988149/ [17:52] nessita: huh, maybe make a symlink to that directory named1.17.3.1-precise-amd64> [17:52] marcoceppi_: can this be "caused" by latest 1.17.3 juju-local? [17:53] nessita: hard to say, I haven't seen anyone else have problems yet [17:54] marcoceppi_: ok, symlink added -- shall the units pick up the change by themselves? [17:54] or this should "work" on futures bootstraps? [17:56] marcoceppi_: I was getting the ERROR every 3 seconds, now they seem to have stopped [17:56] nessita: the agents should keep trying [17:56] right [17:57] marcoceppi_: thanks a lot for your help! === zz_mwhudson is now known as mwhudson [19:04] hello @ all of you! === mwhudson is now known as zz_mwhudson [19:07] webbrandon: o/ [19:34] Need an additional +1 on this MP if anyone has time: https://code.launchpad.net/~stub/charms/precise/postgresql/syslog/+merge/206176 its going to run pretty quick, solid tests unless someone see's something glaring === zz_mwhudson is now known as mwhudson [20:57] HI -- how do I get revision numbers from the store? I know juju spits them out in different areas, but I was wanting a more api-ish way? [20:57] dpb1: if you query the store you can get the latest version number. e.g. https://store.juju.ubuntu.com/charm-info?charms=cs:precise/juju-gui [20:58] rick_h_: ah, excellent, that will be fine. === Guest70848 is now known as wallyworld === CyberJacob is now known as CyberJacob|Away === hloeung is now known as Guest14965 [23:09] is there a bug with the unit logger? My install script is running but there is no history in my unit log of the installation. === Guest14965 is now known as hloeung === frobware is now known as zz_frobware === zz_frobware is now known as frobware [23:55] webbrandon: be more specific, what version of juju, how are you trying to log, etc