=== defunctzombie is now known as defunctzombie_zz === freeflying_away is now known as freeflying === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [05:06] guys, how can I get a unit's name without the /#? Let's say, instead of returning wordpress/1, return just wordpress [05:16] | sed -e '|/*||' ? === thumper is now known as thumper-afk === tasdomas_afk is now known as tasdomas === CyberJacob|Away is now known as CyberJacob === freeflying is now known as freeflying_away [07:00] hi just a quick question, anyone knows how do I know where can i get those EC2 variables from openstack env (horizon doesn't have that)? [07:19] hi, with juju core i have a services and machines that are stuck in the dying state [07:19] how do i get them to move along [07:19] ? [07:20] using 1.13.3 === CyberJacob is now known as CyberJacob|Away [07:20] or is there a better working version? [07:23] mattrae_, I used 1.13.2, and had the same problem like you :) [07:29] raywang: cool thanks for confirming :) [07:31] mattrae_, I think jpds might report the block bug like that, Maybe he has findings :) [07:31] Bug#1214651 looks similar [07:31] <_mup_> Bug #1214651: Machine stuck in 'pending' state cannot be terminated [07:31] mattrae_, or melmoth also run into the problem like that [07:32] in that bug the agent-state is pending and life: dying [07:34] does anyone know when the python based openstack charms are likely to be replaced by the python-redux one ? [07:34] urgh, I meant: does anyone know when the *bash* based openstack charms are likely to be replaced by the python-redux one ? [07:38] raywang: great thanks for the bug. i'm trying to just redploy the charm with a different service name [07:38] raywang: i'm just leaving the old charm there dying since i have a spare machine to use [07:38] mattrae_, that's good :) [07:38] hopefully it will work [07:39] gnuoy: you might ask adam_g about when the python-redux charms will be available [07:41] mattrae_, thanks, will do. [07:51] does debug-hooks in 1.13 work for the install hook? [07:51] i have an error on an install hook [07:52] how do i debug? [07:52] debug-hooks didn't take me to the install hook when i ran: juju resolved hook/0 --retry [07:52] i mean juju resolved charm/0 --retry [07:59] raywang, indeed. There are a couple of similar bugs. The main thing i remember is: never destroy a unit before the end of the install hook [07:59] otherwise, your fskcp with the machine in a state you cannot change and cannot remove it neither, all is left is destroy env === freeflying_away is now known as freeflying [08:58] gnuoy, re openstack redux charms - once they have had enought testing [08:59] we agreed a few general approach changes at vUDS that still need to be implemented [08:59] gnuoy, of course if you want todo some testing much appreciated! [09:01] jamespage, I'll certainly take them out for a spin :-) [09:02] gnuoy, lovely === dosaboy_ is now known as dosaboy === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === thumper-afk is now known as thumper [10:06] anyone know what this means from the local provider on bootstrap (juju-core, 1.13.3-1~1737~ubuntu13.04.1): error: required environment variable not set for credentials attribute: URL [10:08] also, I'm following https://juju.ubuntu.com/get-started/local/, but "juju init -w" gives "error: flag provided but not defined: -w" [10:10] also, "juju init" creates a file that includes instructions to use -e to switch environments, but that fails with "error: flag provided but not defined: -e" [10:11] * mthaddon files bugs [10:12] <_mup_> Bug #1221127 was filed: juju docs recommend "juju init -w" but that fails [10:13] mthaddon: people coming to help RSN [10:13] I've worked around it, as juju init does the right thing, just trying to help improve the docs [10:16] I don't know what the local provider error issue is, it looks like that's not the local provider at all [10:16] as it's an error we get from the openstack provider if you don't have an identity server url set in config or envvar [10:17] mthaddon: hmm, i've done it the doc way (to check what i wrote *smile*) and it worked [10:17] mthaddon: double check you have "type: local" set, and are using the right env? [10:17] mthaddon: i've used a clean environment, no other juju installation before [10:17] mgz: +1 [10:18] mgz: but that may be a good hint. when generating we default to amazon. and i didn't wrote about setting it to local. [10:18] TheMue, mgz: I've fixed it by creating a new env (using juju init) but are you saying "juju init -w" works for you? [10:18] mgz: will add this [10:19] <_mup_> Bug #1221134 was filed: "juju init" creates a file that includes comments recommending -e to switch environments [10:19] mthaddon: nope, the docs are just wrong on that (did it change at some point?) init only takes what --help says it does, which does not include -w or -e [10:19] mgz: ok, thanks - I guess those two bugs are valid then [10:20] the second one I find slightly confusing... [10:20] commands where having an environment makes sense should interpret -e [10:20] mgz: how so? [10:21] mthaddon@mallory:~$ juju -e amazon status [10:21] error: flag provided but not defined: -e [10:22] hm, maybe it's only registered as a normal flag now, after the plugin changes... I take it `juju status -e amazon` works? [10:23] ah, yeah, it does, will update the bug report [10:23] wallyworld_: ^was a deliberate change to how we parse -e in commands? [10:24] mgz: not for juju commands, only plugins [10:25] hm, am sure that the before-the-command form used to work [10:25] mgz: InitCommand extends BaseCommand and not EnvironCommand, that is the issue if -e is required [10:26] but init should not need the -e option [10:27] mgz: i *think* -w was removed because init now writes by default [10:27] and --show is required just to dump the contents [10:27] mthaddon: it seems get-started/local is out of date [10:27] wallyworld_: that makes sense for the -w removal... I guess we just update the docs [10:28] it's a doc issue rather than a juju bug [10:28] wallyworld_: what I'm not sure about is if we've changed from accepting `juju -e amazon status` to only allowing `juju status -e amazon` [10:29] wallyworld_: absolutely, I'm happy for it to be a doc bug rather than a juju bug [10:29] mgz: i think the -e may now need to come after the sub command, but not 100% sure [10:30] mgz: yes, it appears so [10:30] so if any docs say otherwise, they need to be changed too [10:32] is juju-core lxc supposed to work these days? bootstrap node seems fine, but deployed machine is stuck in pending [10:33] mthaddon: it will be pending while it downloads the image [10:33] can take a while [10:33] i think we need a better status [10:33] mthaddon: looking at juju.ubuntu.com and the branch, the local provider setup instructions say `juju generate-config` not `juju init -w` it seems [10:34] wow, generate-config is old [10:34] it's an alias [10:35] mgz: is that different from https://juju.ubuntu.com/get-started/local/ ? [10:36] ...yes [10:38] hm, clicking on local configuration from the getting started link gets me to the right page, but not that one... [10:39] oh, just seen, we're inconsistent in our internal help texts. some times "init -w", some times "generate-config -w". [10:39] ah, I see - if you navigate from the website you get to https://juju.ubuntu.com/docs/config-local.html [10:40] I was following the link in the generated juju env file from "juju init" [10:40] I'll note that in the bug report [10:40] bah, I don't have the karma to edit the askubuntu response, so I'm not sure if that's directly linked or just copied [10:43] ha, yes I do, and it is live updated [10:44] sorry, which askubuntu question is this? [10:44] so, -w is gone from that page now, hopefully people on older versions will now not be confused [10:44] mthaddon: that page is generated from an askubuntu response [10:44] if you click the byline at the top, it links there [10:45] * mthaddon nods [10:46] or, actually, the title, clicking jorge links to jorge [10:46] mgz: so why do we have to pages for getting started with the local provider? should the juju init comment link to https://juju.ubuntu.com/docs/config-local.html ? [10:46] er, why do we have *two* pages [10:46] mthaddon: I think so [10:48] the config-local.html has been written during the doc sprint last week like those other config-foo for other providers. [10:48] I think we just need to migrate properly to the lp:juju-core/docs stuff, askubuntu was a stopgap [10:50] my env is still in pending... :( [10:51] mthaddon: which bandwidth? loading the images can last some time? [10:52] TheMue: 20Mbits download - I guess it could still be working [10:58] mthaddon: still pending? after the image the software itself is downloaded and installed (e.g. worpress, mysql) [10:59] mthaddon: this may last longer on a private box than on fine ec2 instances ;) [10:59] yep - http://paste.ubuntu.com/6066089/ [10:59] does the requirement to ufw disable still exist ? [11:00] * gnuoy looks for the bug [11:00] mthaddon: a ps could show that there are some wgets running [11:01] no wgets running [11:01] Bug#998238 [11:01] <_mup_> Bug #998238: local provider unit agents get stuck in pending state because of host firewall blocking communication [11:02] mthaddon, is ufw enabled ? [11:02] gnuoy: it was, lemme destroy env, disable it and try again [11:04] mthaddon, the other issue I had some time ago was a bad image in /var/cache/lxc/cloud-precise . I removed it and all was good, but I think the ufw problem is the most likely [11:05] agent-state: started <-- seems like it was ufw again... [11:06] * mthaddon will comment on the bug report after confirming the instance boots to completion [11:09] 2013-09-05 11:08:47 ERROR juju git.go:188 worker/uniter/charm: git command failed: exec: "git": executable file not found in $PATH [11:09] this is from the unit log [11:13] gnuoy: does that sounds like the bad image issue you had a while back? ^ [11:14] no, machines were stuck pending [11:14] k, thanks === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [11:52] mgz: the -w isn't even needed anymore [12:07] marcoceppi: do you know what the status of the old askubuntu pages is? [12:08] mgz: I don't know what you mean [12:08] should we just make sure everything in those answers is also in the new configuring docs, then remove the links and pages? [12:08] mgz: we had a hybrid aproach planned for the new docs, embedding some questions in the docs, it's just been deferred [12:09] if something is out of date, anyone can edit and rectify the issue [12:09] compare juju.ubuntu.com/get-started/local and juju.ubuntu.com/docs/config-local.html [12:09] mgz: we should probably just drop that get-started link and have it redirect to the docs [12:10] jcastro evilnickveitch: thoughts ^ [12:10] marcoceppi, mgz - i am not sure but I think those pages may be culled in the redesign happening later [12:11] (the non docs ones) [12:12] I think we should redirect to the docs for all the getting started stuff [12:20] I agree [12:20] however the AU pages get a bunch of google juice, so we need to make sure they are up to date so they act as an onramp to the docs [12:34] I can't seem to ssh into unit's I've deployed locally, anyone else seen this? === tasdomas is now known as tasdomas_afk [13:17] mattyw: how are you sshing? === tasdomas_afk is now known as tasdomas [13:17] marcoceppi, juju ssh [13:17] marcoceppi, I get permission denied public key [13:18] mattyw: are you using the machine number or the unit name? [13:18] marcoceppi, machine number [13:19] mattyw: that doesn't work with local provider, use unit name instead === deej` is now known as deej [13:49] When you add postgresql service to bootstrap machine, the log goes into a loop and keep increasing forever [13:49] is it a bug? [13:54] X-warrior: file a bug with a complete description and steps how to reproduce it, easiest way to find out [13:57] X-warrior: I think this has been documented already [13:57] * marcoceppi looks [14:01] https://bugs.launchpad.net/juju-core/+bug/1218616 [14:01] <_mup_> Bug #1218616: all-machines.log is oversized on juju node

[14:18] how could I get juju/devel to work on mac ? === freeflying is now known as freeflying_away [14:20] marcoceppi, ok thanks [14:20] X-warrior: You'll need to compile it, there are instructions on this [14:22] X-warrior: http://paste.ubuntu.com/6066656/ [14:23] X-warrior: that will be in the docs soon, just a little bit behind [14:24] X-warrior: also, that will get you the tip of trunk, which should be fairly tested, but won't exactly be what's in the devel ppa [14:28] marcoceppi, is not being able to do juju ssh on the local provider a long term thing? or just a bug at the moment? [14:28] mattyw: core team is aware of it, not sure if it's a long term thing or not. AFAIK, there are two local provider caveats; no ssh to machine number and debug-log doesn't work [14:29] marcoceppi, ok cool, thanks again [15:00] arosales: actually, I don't have the edit bit set for the juju status doc it seems [15:01] mgz, sorry, please refresh and you should have edit access [15:02] arosales: thanks! [15:02] mgz, thnks for updating :-) [15:09] marcoceppi: ty [15:09] :D === tasdomas is now known as tasdomas_afk [15:52] when trying to bootstrap my local environment, i get "TLS handshake failed: x509: certificate signed by unknown authority" [15:52] I also saw this bug report https://bugs.launchpad.net/juju-core/+bug/1178312 [15:52] <_mup_> Bug #1178312: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority

[15:52] I'm not seeing any information on how to troubleshoot this [16:37] hi im using juju local but I cannot log in into lxc instances. What are the username and password?? [16:38] diegonat: you can't login, you need to ssh in, use `juju ssh UNIT` [16:40] Permission denied (publickey,password). [16:40] error: exit status 255 [16:41] diegonat: paste bit the juju status output and the exact command you ran to ssh in? [16:41] !patebin [16:41] !pastebin [16:41] ;_; [16:42] I had this I think. You have to ssh manually with ubuntu@xxx when I tried it out [16:44] that should be fine regardless, yeah (unless ~/.ssh/config is borked) [16:44] http://pastebin.com/i52qKLuD [16:45] mgz, any error? [16:45] diegonat: you can't ssh to the machine number with local, you need to use the unit, eg mysql/0 [16:47] ok [16:48] ...oddly we don't seem to have a bug open for that [16:48] another question that i cannot find an answer online. How does juju work with AWS ? I mean, when I deploy a server, does it launch an instance automatically with the service without me configuring the instance? [16:48] diegonat: yup, by default [16:50] going back to my test machine with lxc... I jujued wordpress and mysql. Is there any way that I can do the same but with wordpress and mysql already configured? For example with mysql user and pass set as I want ? [16:51] yuo can pass configuration to the carms to customise them, but user/pass is really not something you want to put it, it's much better from a security perspective to autogenerate [16:52] ok, now for example... I have wordpress and mysql. How can I configure wordpress without knowing mysql user and pass? [16:52] where should i find them? [16:53] you just add a relation between the two, and that information gets communicted across [16:53] ok thats nice [16:53] =) [17:07] yeah, the entire idea is for you to not have to care about doing that by hand [17:11] is it possible to install the web UI ? [17:11] yeah [17:11] juju deploy juju-gui [17:11] will deploy the web UI in the environment [17:11] https://jujucharms.com/precise/juju-gui-HEAD/#bws-readme has the instructions [17:12] rick_h: hey, can you guys stick the copyright of the gui README at the bottom or something? [17:12] that top thing pains me [17:13] I miss the older charm browser.. it was so much faster [17:14] http://manage.jujucharms.com/ still works! [17:14] don't get me wrong, I'm thrilled there's a juju gui demo around, and once it has listing code, I cna understand why you'd rather just maintain the one.. [17:14] jcastro: oh thanks :) nice. near-instant response. hehe. [17:16] I think once the URLs are sorted and the load time is reduced it'll be fine === defunctzombie_zz is now known as defunctzombie [18:28] Don't suppose anyone could help me with my juju hanging on mongo problem? http://askubuntu.com/q/341845/61821 [18:29] juju hangs when connecting to mongo | http://askubuntu.com/q/341845 === CyberJacob|Away is now known as CyberJacob [18:44] jackweirdy: are you doing something non-standard with a local environment? [18:45] jackweirdy: normally the bootstrap of the local environment creates a completely separate mongo db instance, so you wouldn't have a mongodb.conf like your question states. [18:45] I've followed the steps here to the letter [18:45] https://juju.ubuntu.com/docs/config-local.html [18:45] the only difference was that I had mongo already installed from the 10gen repo [18:46] so I had to purge that and remove it from sources.d [18:46] but after an update & autoclean everything seemed ok [18:46] right. [18:46] sounds like you edited the mongodb.conf to listen on the port which juju wants. don't do that. [18:47] I changed that because beforehand it was just failing [18:47] juju bootstrap will start a mongo instance with its db dir in .juju/ not the system mongo. [18:47] Ah I see; [18:47] it might not have been failing. it might have been REALLY SLOW. first connects would take 30sec for me sometimes. [18:48] In debug it was implying nothing was listening on that port [18:51] I'm getting lots of this when I juju bootstrap --debug [18:51] 2013-09-05 18:51:05 ERROR juju open.go:89 state: connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused [18:51] 2013-09-05 18:51:05 ERROR juju open.go:89 state: connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused [18:51] 2013-09-05 18:51:06 ERROR juju open.go:89 state: connection failed, will retry: dial tcp 127.0.0.1:37017: connection refused [18:51] oh, it's working now :) [18:51] I should be more patient :) [18:51] Thanks :) [19:25] jackweirdy: it should take about 30 seconds [19:25] anything longer than that is a problem [19:25] jackweirdy: is this the very first time you're bootstrapping? [20:00] jackweirdy: it depends on how fast your disks are, but it could take up 90 seconds until the bootstrap comes back. It does a bunch of stuff behind the scenes for the local provider [20:08] hazmat: around? [20:12] hazmat: hey so for the local instructions, we have the `lxc-local` convenience package so you don't need to install "mongodb-server", which I think is overkill anyway, isn't it mongodb-clients? [20:15] jcastro, local provider needs mongodb server [20:15] jcastro, the client lib is builtin-to the juju binary [20:15] its basically two extra packages though [20:15] which we made a new package to automate ;-) [20:16] oh, nm, I see mongodb-server is a depends on lxc-local [20:16] anyway, I was thinking we could slim down the install line on that page [20:16] to just `sudo apt-get install juju-local` [20:16] which pulls in lxc and mongo [20:16] yup [20:17] ok mind if I make the change? [20:17] fine by me [20:29] where can I go if I want more info on whether or not I need the ext-port set on a quantum-gateway charm? I'm deploying grizzly on bare-metal using maas & juju and each server has multiple nics....just not sure when ext-port is appropriate. [20:30] and is it wise / safe to put quantum-gateway on the same server as nova-cloud-controller, keystone, mysql, rabbitmq-server using juju-core? [20:30] jamespage adam_g ^ === CyberJacob is now known as CyberJacob|Away === CyberJacob|Away is now known as CyberJacob [22:29] davecheney: ping === defunctzombie is now known as defunctzombie_zz === defunctzombie_zz is now known as defunctzombie === defunctzombie is now known as defunctzombie_zz [23:54] mwhudson: ack