[05:06] <jose> guys, how can I get a unit's name without the /#? Let's say, instead of returning wordpress/1, return just wordpress
[05:16] <lifeless>  | sed -e '|/*||' ?
[07:00] <raywang> 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] <mattrae_> hi, with juju core i have a services and machines that are stuck in the dying state
[07:19] <mattrae_> how do i get them to move along
[07:19] <mattrae_> ?
[07:20] <mattrae_> using 1.13.3
[07:20] <mattrae_> or is there a better working version?
[07:23] <raywang> mattrae_, I used 1.13.2, and had the same problem like you :)
[07:29] <mattrae_> raywang: cool thanks for confirming :)
[07:31] <raywang> mattrae_, I think jpds might report the block bug like that, Maybe he has findings :)
[07:31] <gnuoy> Bug#1214651 looks similar
[07:31] <_mup_> Bug #1214651: Machine stuck in 'pending' state cannot be terminated <juju-core:Triaged> <https://launchpad.net/bugs/1214651>
[07:31] <raywang> mattrae_, or melmoth also run into the problem like that
[07:32] <gnuoy> in that bug the agent-state is pending and  life: dying
[07:34] <gnuoy> does anyone know when the python based openstack charms are likely to be replaced by the python-redux one ?
[07:34] <gnuoy> urgh, I meant: does anyone know when the *bash* based openstack charms are likely to be replaced by the python-redux one ?
[07:38] <mattrae_> raywang: great thanks for the bug. i'm trying to just redploy the charm with a different service name
[07:38] <mattrae_> raywang: i'm just leaving the old charm there dying since i have a spare machine to use
[07:38] <raywang> mattrae_, that's good :)
[07:38] <mattrae_> hopefully it will work
[07:39] <mattrae_> gnuoy: you might ask adam_g about when the python-redux charms will be available
[07:41] <gnuoy> mattrae_, thanks, will do.
[07:51] <mattrae_> does debug-hooks in 1.13 work for the install hook?
[07:51] <mattrae_> i have an error on an install hook
[07:52] <mattrae_> how do i debug?
[07:52] <mattrae_> debug-hooks didn't take me to the install hook when i ran: juju resolved hook/0 --retry
[07:52] <mattrae_> i mean juju resolved charm/0 --retry
[07:59] <melmoth> 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] <melmoth> otherwise, your fskcp with the machine in a state you cannot change and cannot remove it neither, all is left is destroy env
[08:58] <jamespage> gnuoy, re openstack redux charms - once they have had enought testing
[08:59] <jamespage> we agreed a few general approach changes at vUDS that still need to be implemented
[08:59] <jamespage> gnuoy, of course if you want todo some testing much appreciated!
[09:01] <gnuoy> jamespage, I'll certainly take them out for a spin :-)
[09:02] <jamespage> gnuoy, lovely
[10:06] <mthaddon> 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] <mthaddon> 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] <mthaddon> 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 <juju:New> <https://launchpad.net/bugs/1221127>
[10:13] <thumper> mthaddon: people coming to help RSN
[10:13] <mthaddon> I've worked around it, as juju init does the right thing, just trying to help improve the docs
[10:16] <mgz> I don't know what the local provider error issue is, it looks like that's not the local provider at all
[10:16] <mgz> 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] <TheMue> mthaddon: hmm, i've done it the doc way (to check what i wrote *smile*) and it worked
[10:17] <mgz> mthaddon: double check you have "type: local" set, and are using the right env?
[10:17] <TheMue> mthaddon: i've used a clean environment, no other juju installation before
[10:17] <TheMue> mgz: +1
[10:18] <TheMue> 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] <mthaddon> 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] <TheMue> mgz: will add this
[10:19] <_mup_> Bug #1221134 was filed: "juju init" creates a file that includes comments recommending -e to switch environments <juju:New> <https://launchpad.net/bugs/1221134>
[10:19] <mgz> 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] <mthaddon> mgz: ok, thanks - I guess those two bugs are valid then
[10:20] <mgz> the second one I find slightly confusing...
[10:20] <mgz> commands where having an environment makes sense should interpret -e
[10:20] <mthaddon> mgz: how so?
[10:21] <mthaddon> mthaddon@mallory:~$ juju -e amazon status
[10:21] <mthaddon> error: flag provided but not defined: -e
[10:22] <mgz> 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] <mthaddon> ah, yeah, it does, will update the bug report
[10:23] <mgz> wallyworld_: ^was a deliberate change to how we parse -e in commands?
[10:24] <wallyworld_> mgz: not for juju commands, only plugins
[10:25] <mgz> hm, am sure that the before-the-command form used to work
[10:25] <wallyworld_> mgz: InitCommand extends BaseCommand and not EnvironCommand, that is the issue if -e is required
[10:26] <wallyworld_> but init should not need the -e option
[10:27] <wallyworld_> mgz: i *think* -w was removed because init now writes by default
[10:27] <wallyworld_> and --show is required just to dump the contents
[10:27] <wallyworld_> mthaddon: it seems get-started/local is out of date
[10:27] <mgz> wallyworld_: that makes sense for the -w removal... I guess we just update the docs
[10:28] <wallyworld_> it's a doc issue rather than a juju bug
[10:28] <mgz> 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] <mthaddon> wallyworld_: absolutely, I'm happy for it to be a doc bug rather than a juju bug
[10:29] <wallyworld_> mgz: i think the -e may now need to come after the sub command, but not 100% sure
[10:30] <wallyworld_> mgz: yes, it appears so
[10:30] <wallyworld_> so if any docs say otherwise, they need to be changed too
[10:32] <mthaddon> is juju-core lxc supposed to work these days? bootstrap node seems fine, but deployed machine is stuck in pending
[10:33] <wallyworld_> mthaddon: it will be pending while it downloads the image
[10:33] <wallyworld_> can take a while
[10:33] <wallyworld_> i think we need a better status
[10:33] <mgz> 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] <wallyworld_> wow, generate-config is old
[10:34] <TheMue> it's an alias
[10:35] <mthaddon> mgz: is that different from https://juju.ubuntu.com/get-started/local/ ?
[10:36] <mgz> ...yes
[10:38] <mgz> hm, clicking on local configuration from the getting started link gets me to the right page, but not that one...
[10:39] <TheMue> oh, just seen, we're inconsistent in our internal help texts. some times "init -w", some times "generate-config -w".
[10:39] <mthaddon> ah, I see - if you navigate from the website you get to https://juju.ubuntu.com/docs/config-local.html
[10:40] <mthaddon> I was following the link in the generated juju env file from "juju init"
[10:40] <mthaddon> I'll note that in the bug report
[10:40] <mgz> 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] <mgz> ha, yes I do, and it is live updated
[10:44] <mthaddon> sorry, which askubuntu question is this?
[10:44] <mgz> so, -w is gone from that page now, hopefully people on older versions will now not be confused
[10:44] <mgz> mthaddon: that page is generated from an askubuntu response
[10:44] <mgz> if you click the byline at the top, it links there
[10:45]  * mthaddon nods
[10:46] <mgz> or, actually, the title, clicking jorge links to jorge
[10:46] <mthaddon> 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] <mthaddon> er, why do we have *two* pages
[10:46] <mgz> mthaddon: I think so
[10:48] <TheMue> the config-local.html has been written during the doc sprint last week like those other config-foo for other providers.
[10:48] <mgz> I think we just need to migrate properly to the lp:juju-core/docs stuff, askubuntu was a stopgap
[10:50] <mthaddon> my env is still in pending... :(
[10:51] <TheMue> mthaddon: which bandwidth? loading the images can last some time?
[10:52] <mthaddon> TheMue: 20Mbits download - I guess it could still be working
[10:58] <TheMue> mthaddon: still pending? after the image the software itself is downloaded and installed (e.g. worpress, mysql)
[10:59] <TheMue> mthaddon: this may last longer on a private box than on fine ec2 instances ;)
[10:59] <mthaddon> yep - http://paste.ubuntu.com/6066089/
[10:59] <gnuoy> does the requirement to ufw disable still exist ?
[11:00]  * gnuoy looks for the bug
[11:00] <TheMue> mthaddon: a ps could show that there are some wgets running
[11:01] <mthaddon> no wgets running
[11:01] <gnuoy> Bug#998238
[11:01] <_mup_> Bug #998238: local provider unit agents get stuck in pending state because of host firewall blocking communication <juju:Confirmed> <https://launchpad.net/bugs/998238>
[11:02] <gnuoy> mthaddon, is ufw enabled ?
[11:02] <mthaddon> gnuoy: it was, lemme destroy env, disable it and try again
[11:04] <gnuoy> 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] <mthaddon>     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] <mthaddon> 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] <mthaddon> this is from the unit log
[11:13] <mthaddon> gnuoy: does that sounds like the bad image issue you had a while back? ^
[11:14] <gnuoy> no, machines were stuck pending
[11:14] <mthaddon> k, thanks
[11:52] <marcoceppi> mgz: the -w isn't even needed anymore
[12:07] <mgz> marcoceppi: do you know what the status of the old askubuntu pages is?
[12:08] <marcoceppi> mgz: I don't know what you mean
[12:08] <mgz> should we just make sure everything in those answers is also in the new configuring docs, then remove the links and pages?
[12:08] <marcoceppi> mgz: we had a hybrid aproach planned for the new docs, embedding some questions in the docs, it's just been deferred
[12:09] <marcoceppi> if something is out of date, anyone can edit and rectify the issue
[12:09] <mgz> compare juju.ubuntu.com/get-started/local and juju.ubuntu.com/docs/config-local.html
[12:09] <marcoceppi> mgz: we should probably just drop that get-started link and have it redirect to the docs
[12:10] <marcoceppi> jcastro evilnickveitch: thoughts ^
[12:10] <evilnickveitch> marcoceppi, mgz - i am not sure but I think those pages may be culled in the redesign happening later
[12:11] <evilnickveitch> (the non docs ones)
[12:12] <evilnickveitch> I think we should redirect to the docs for all the getting started stuff
[12:20] <jcastro> I agree
[12:20] <jcastro> 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] <mattyw> I can't seem to ssh into unit's I've deployed locally, anyone else seen this?
[13:17] <marcoceppi> mattyw: how are you sshing?
[13:17] <mattyw> marcoceppi, juju ssh
[13:17] <mattyw> marcoceppi, I get permission denied public key
[13:18] <marcoceppi> mattyw: are you using the machine number or the unit name?
[13:18] <mattyw> marcoceppi, machine number
[13:19] <marcoceppi> mattyw: that doesn't work with local provider, use unit name instead
[13:49] <X-warrior> When you add postgresql service to bootstrap machine, the log goes into a loop and keep increasing forever
[13:49] <X-warrior> is it a bug?
[13:54] <mgz> X-warrior: file a bug with a complete description and steps how to reproduce it, easiest way to find out
[13:57] <marcoceppi> X-warrior: I think this has been documented already
[13:57]  * marcoceppi looks
[14:01] <X-warrior> https://bugs.launchpad.net/juju-core/+bug/1218616
[14:01] <_mup_> Bug #1218616: all-machines.log is oversized on juju node <juju-core> <juju-core:Triaged> <https://launchpad.net/bugs/1218616>
[14:18] <X-warrior> how could I get juju/devel to work on mac ?
[14:20] <mattyw> marcoceppi, ok thanks
[14:20] <marcoceppi> X-warrior: You'll need to compile it, there are instructions on this
[14:22] <marcoceppi> X-warrior: http://paste.ubuntu.com/6066656/
[14:23] <marcoceppi> X-warrior: that will be in the docs soon, just a little bit behind
[14:24] <marcoceppi> 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] <mattyw> marcoceppi, is not being able to do juju ssh <machine-number> on the local provider a long term thing? or just a bug at the moment?
[14:28] <marcoceppi> 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] <mattyw> marcoceppi, ok cool, thanks again
[15:00] <mgz> arosales: actually, I don't have the edit bit set for the juju status doc it seems
[15:01] <arosales> mgz, sorry, please refresh and you should have edit access
[15:02] <mgz> arosales: thanks!
[15:02] <arosales> mgz, thnks for updating :-)
[15:09] <X-warrior> marcoceppi: ty
[15:09] <X-warrior> :D
[15:52] <dalek49>  when trying to bootstrap my local environment, i get "TLS handshake failed: x509: certificate signed by unknown authority"
[15:52] <dalek49> 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 <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1178312>
[15:52] <dalek49> I'm not seeing any information on how to troubleshoot this
[16:37] <diegonat> hi im using juju local but I cannot log in into lxc instances. What are the username and password??
[16:38] <mgz> diegonat: you can't login, you need to ssh in, use `juju ssh UNIT`
[16:40] <diegonat> Permission denied (publickey,password).
[16:40] <diegonat> error: exit status 255
[16:41] <mgz> diegonat: paste bit the juju status output and the exact command you ran to ssh in?
[16:41] <mgz> !patebin
[16:41] <mgz> !pastebin
[16:41] <mgz> ;_;
[16:42] <rick_h> I had this I think. You have to ssh manually with ubuntu@xxx when I tried it out
[16:44] <mgz> that should be fine regardless, yeah (unless ~/.ssh/config is borked)
[16:44] <diegonat> http://pastebin.com/i52qKLuD
[16:45] <diegonat> mgz, any error?
[16:45] <mgz> diegonat: you can't ssh to the machine number with local, you need to use the unit, eg mysql/0
[16:47] <diegonat> ok
[16:48] <mgz> ...oddly we don't seem to have a bug open for that
[16:48] <diegonat> 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] <mgz> diegonat: yup, by default
[16:50] <diegonat> 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] <mgz> 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] <diegonat> ok, now for example... I have wordpress and mysql. How can I configure wordpress without knowing mysql user and pass?
[16:52] <diegonat> where should i find them?
[16:53] <mgz> you just add a relation between the two, and that information gets communicted across
[16:53] <diegonat> ok thats nice
[16:53] <diegonat> =)
[17:07] <jcastro> yeah, the entire idea is for you to not have to care about doing that by hand
[17:11] <diegonat> is it possible to install the web UI ?
[17:11] <jcastro> yeah
[17:11] <jcastro> juju deploy juju-gui
[17:11] <jcastro> will deploy the web UI in the environment
[17:11] <jcastro> https://jujucharms.com/precise/juju-gui-HEAD/#bws-readme has the instructions
[17:12] <jcastro> rick_h: hey, can you guys stick the copyright of the gui README at the bottom or something?
[17:12] <jcastro> that top thing pains me
[17:13] <sarnold> I miss the older charm browser.. it was so much faster
[17:14] <jcastro> http://manage.jujucharms.com/ still works!
[17:14] <sarnold> 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] <sarnold> jcastro: oh thanks :) nice. near-instant response. hehe.
[17:16] <jcastro> I think once the URLs are sorted and the load time is reduced it'll be fine
[18:28] <jackweirdy> Don't suppose anyone could help me with my juju hanging on mongo problem? http://askubuntu.com/q/341845/61821
[18:29] <AskUbuntu> juju hangs when connecting to mongo | http://askubuntu.com/q/341845
[18:44] <jrwren> jackweirdy: are you doing something non-standard with a local environment?
[18:45] <jrwren> 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] <jackweirdy> I've followed the steps here to the letter
[18:45] <jackweirdy> https://juju.ubuntu.com/docs/config-local.html
[18:45] <jackweirdy> the only difference was that I had mongo already installed from the 10gen repo
[18:46] <jackweirdy> so I had to purge that and remove it from sources.d
[18:46] <jackweirdy> but after an update & autoclean everything seemed ok
[18:46] <jrwren> right.
[18:46] <jrwren> sounds like you edited the mongodb.conf to listen on the port which juju wants. don't do that.
[18:47] <jackweirdy> I changed that because beforehand it was just failing
[18:47] <jrwren> juju bootstrap will start a mongo instance with its db dir in .juju/  not the system mongo.
[18:47] <jackweirdy> Ah I see;
[18:47] <jrwren> it might not have been failing. it might have been REALLY SLOW. first connects would take 30sec for me sometimes.
[18:48] <jackweirdy> In debug it was implying nothing was listening on that port
[18:51] <jackweirdy> I'm getting lots of this when I juju bootstrap --debug
[18:51] <jackweirdy> 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] <jackweirdy> 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] <jackweirdy> 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] <jackweirdy> oh, it's working now :)
[18:51] <jackweirdy> I should be more patient :)
[18:51] <jackweirdy> Thanks :)
[19:25] <jcastro> jackweirdy: it should take about 30 seconds
[19:25] <jcastro> anything longer than that is a problem
[19:25] <jcastro> jackweirdy: is this the very first time you're bootstrapping?
[20:00] <marcoceppi> 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] <jcastro> hazmat: around?
[20:12] <jcastro> 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] <hazmat> jcastro, local provider needs mongodb server
[20:15] <hazmat> jcastro, the client lib is builtin-to the juju binary
[20:15] <hazmat> its basically two extra packages though
[20:15] <hazmat> which we made a new package to automate ;-)
[20:16] <jcastro> oh, nm, I see mongodb-server is a depends on lxc-local
[20:16] <jcastro> anyway, I was thinking we could slim down the install line on that page
[20:16] <jcastro> to just `sudo apt-get install juju-local`
[20:16] <jcastro> which pulls in lxc and mongo
[20:16] <hazmat> yup
[20:17] <jcastro> ok mind if I make the change?
[20:17] <hazmat> fine by me
[20:29] <kentb> 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] <kentb> 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] <marcoceppi> jamespage adam_g ^
[22:29] <mwhudson> davecheney: ping
[23:54] <davecheney> mwhudson: ack