| Preytell | seems to work if I add it to the environ file... hmmm... wonder why it didn't work the other way. | 00:00 |
|---|---|---|
| cjohnston | heya.. I'm trying to setup a local env for using Juju... I'm getting ERROR error parsing environment "local": no public ssh keys found when running juju bootstrap.. the docs don't seem to cover anything about adding public keys somewhere.. any ideas? | 00:31 |
| AskUbuntu | Reset MAAS after loosing Juju configuration? | http://askubuntu.com/q/364821 | 04:04 |
| === CyberJacob|Away is now known as CyberJacob | ||
| Roconda | cjohnston: try: ssh-keygen | 12:19 |
| cjohnston | Roconda: I have ssh keys | 12:24 |
| Roconda | cjohnston: you sure you've got a public one? Cause I had the same error and generating my keys solved it | 12:26 |
| cjohnston | Roconda: yup | 12:27 |
| Roconda | cjohnston: maybe your key hasn't the right permissions. Could you try: mv ~/.ssh ~/.ssh_backup && ssh-keygen | 12:27 |
| Roconda | just to be sure | 12:27 |
| cjohnston | Roconda: it works for ssh elsewhere | 12:27 |
| cjohnston | It's 644 which is what a pub key is supposed to be IIRC | 12:28 |
| Roconda | cjohnston: well thats weird. If generating new ones doesn't do the job then I would not know what else to do. I'm not a JuJu dev or something | 12:29 |
| === freeflying_away is now known as freeflying | ||
| === liam_ is now known as Guest1997 | ||
| TSK | Greetings. Been trying to follow the Juju "Getting Started" doc, but upon reaching the "sudo juju bootstrap" I get "ERROR Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused" and hours of web search and poring over documentation has turned up a whole lotta nothin'. Anyone else have a similar issue, or better yet, anyone know where I ought to be reading to solve this issue? | 14:31 |
| marcoceppi | TSK: What version of Ubuntu are you on? | 14:32 |
| TSK | Currently on 13.04 tho I have been considering upgrading soon. | 14:32 |
| marcoceppi | TSK: What version of Juju do you have? | 14:33 |
| TSK | 1.16.0-raring-i386 | 14:34 |
| marcoceppi | TSK: do you have the "juju-local" package installed? | 14:34 |
| === elopio_ is now known as elopio | ||
| TSK | Aye, I do indeed. | 14:34 |
| marcoceppi | TSK: Are you on an encrypted home directory? | 14:35 |
| TSK | I am not. | 14:35 |
| marcoceppi | does ps -aef | grep mongo show a mongod process running? | 14:35 |
| TSK | Sure does. | 14:35 |
| TSK | Yes indeed. | 14:35 |
| marcoceppi | TSK: So, we encountered something like this yesterday. Where it took mongod longer to start up than bootstrap expected and resulting in this false positive | 14:36 |
| TSK | How long did it take? I've been tryin' for a few hours now to get this runnin'. | 14:37 |
| marcoceppi | TSK: can you run `sudo juju destroy-environment` then rebootstrap one more time with --debug --show-log flags? | 14:38 |
| marcoceppi | TSK: bootstrap will only wait for X seconds before giving up, even if mongod/juju-db starts shortly after that time | 14:38 |
| TSK | By golly, that seems to have fixed 'er right up. | 14:40 |
| TSK | Thank you very much. Seems to be workin' as expected now. | 14:43 |
| marcoceppi | TSK: the next time you bootstrap it might fail, let me know if it does, we may increase the timeout for bootstraps waiting on mongdb | 14:50 |
| TSK | I surely shall. Thank you. It's good to know where the source of the issue is. I appreciate the help greatly. | 14:51 |
| TSK | The web was not much help, sadly. Is this a fairly new issue? | 14:51 |
| marcoceppi | TSK: I first heard of it yesterday. to my knowledge it hasn't been an issue | 15:06 |
| TSK | Right on. That's good. Explains why there's not much info on the web about it. | 15:06 |
| TSK | If not many folk have seen the issue, then not many folk would have posted about it yet. :) | 15:07 |
| === TSK is now known as {TSK} | ||
| === {TSK} is now known as TSK | ||
| TSK | Juju is pretty neat thus far. Might have to use this to provision all my virtual machines from now on. | 15:51 |
| === TSK is now known as Guest92173 | ||
| === Guest92173 is now known as [TSK] | ||
| [TSK] | Howdy. So, now I'm gettin' that same error as before, except when trying to access the same already bootstrapped environment after a reboot. | 16:46 |
| [TSK] | Is there somewhere in the code I should look/test changing some variables to see if it helps anything? I'm familiar with Python if that helps any. | 16:47 |
| marcoceppi | <[TSK]> Well, this is golang, so it's compiled | 16:48 |
| marcoceppi | <[TSK]> So when you run juju status, you're getting an error? | 16:48 |
| [TSK] | Aye. Same error as when trying to bootstrap. | 16:48 |
| marcoceppi | <[TSK]> But you said it's already bootstraped? | 16:49 |
| marcoceppi | <[TSK]> You only bootstrap once, unless you've torn down the environment since last we talked | 16:49 |
| [TSK] | Aye. Already installed some things and tested them, then restarted the system to see how it'd go. | 16:49 |
| [TSK] | Aye. It was already bootstrapped and working before the reboot. | 16:49 |
| marcoceppi | <[TSK]> So, the local environment should survive reboot, what happens when you run `juju status --show-log --debug` | 16:50 |
| [TSK] | 2013-10-24 16:50:25 INFO juju.provider.local environprovider.go:32 opening environment "local" | 16:51 |
| [TSK] | 2013-10-24 16:50:26 ERROR juju supercommand.go:282 Unable to connect to environment "local". | 16:51 |
| [TSK] | Please check your credentials or use 'juju bootstrap' to create a new environment. | 16:51 |
| [TSK] | and then | 16:51 |
| [TSK] | Error details: | 16:51 |
| [TSK] | Get http://10.0.3.1:8040/provider-state: dial tcp 10.0.3.1:8040: connection refused | 16:51 |
| [TSK] | (And of course before that all the key junk and stuff) | 16:51 |
| [TSK] | Not seeing anything in there that really looks useful to ME, bein' that I'm entirely new to juju as yet. | 16:52 |
| [TSK] | Looks like such a potentially interesting tool, too. I'd be bummed out if I couldn't actually use it in practice. | 16:55 |
| marcoceppi | <[TSK] Well the Local provider is a very special provider and relatively new | 16:55 |
| marcoceppi | <[TSK] try `sudo juju destroy-environment` then `sudo juju bootstrap` again. While it's designed to survive reboots, it may not have in this case | 16:56 |
| [TSK] | destroy and re-bootstrap does sorta fix the problem but of course that leaves me with a shiny new empty environment again. | 17:00 |
| [TSK] | LOVE the use of YAML, BTW. SO much better than say XML for example. | 17:03 |
| === Makyo|Air is now known as Makyo | ||
| marcoceppi | <[TSK] yes, I'll look into reboot survival | 17:28 |
| [TSK] | Looks like the bootstrap issue seems to happen on all three of my machines (including the more powerful gaming rig I just tested it out on for curiosity.) I'm on a 50 megabit down/20 megabit up DSL line, and 100 megabit LAN, so that should not affect things, should it? | 17:30 |
| [TSK] | Of course your original suggestion to destroy and re-bootstrap works equally well on all three machines, too. | 17:31 |
| marcoceppi | <[TSK] the bootstrap problem being the timeout? | 17:31 |
| [TSK] | Aye | 17:31 |
| marcoceppi | Or the reboot survival? | 17:31 |
| [TSK] | Have not yet tested reboot survival on the other two machines yet. | 17:31 |
| marcoceppi | <[TSK] interesting. Let me ask the core developers what logs to collect to help troubleshoot this problem | 17:31 |
| [TSK] | One is a netbook, the other is the gaming rig. | 17:31 |
| [TSK] | Figured I'd test on a wide variety of hardware to see if the issue was specific to any one machine, or if it was on all machines. | 17:32 |
| [TSK] | (The first test was on my development server.) | 17:32 |
| marcoceppi | <[TSK] thanks for taking the time to test this out | 17:36 |
| [TSK] | Hey, no problem. I'm always happy to help when I'm able. :) | 17:40 |
| === [TSK] is now known as TSK | ||
| TSK | This is actually the first real project I've ever played with that was written in go. (I'ma Python guy myself) | 17:43 |
| * TSK goes to search GitHub for Juju source. | 17:45 | |
| marcoceppi | TSK: http://launchpad.net/juju-core | 17:47 |
| TSK | Looks like someone mirrored that at GitHub about 9 months ago. https://github.com/prabhakhar/juju-core | 17:48 |
| marcoceppi | TSK: yeah, that's largely out of date. We're looking to mirror it at https://github.com/juju/juju-core | 17:48 |
| TSK | Aye. Doesn't look like they got ANY of the actual code history, either. Just a straight mirror of the state of the code 9 months ago. | 17:49 |
| marcoceppi | TSK: right | 17:49 |
| TSK | Ah, looks like your original source repo is in bzr | 17:51 |
| * TSK installs bazaar | 17:51 | |
| TSK | OOoo neat! There's a plugin for my filemanager for Bazaar now. | 17:52 |
| TSK | sudo aptitude show dolphin-plugins-bazaar | 17:53 |
| TSK | Only of interest to KDE users, but still... Nifty. :) | 17:53 |
| Azendale | Could someone explain to me what the 'vip' and 'vip_cidr' options for charms do/are? I get the idea that they are a shared/load balanced IP to have a HA API. But should the be an address in the same range as the addresses the machines already have assigned by MaaS (but one that the DHCP server won't hand out?) Or should the been on a different NIC on the server and on their own subnet? | 17:55 |
| marcoceppi | Azendale: to my understanding it can be either | 17:59 |
| marcoceppi | Azendale: I believe the times I've used it, it's been on the same NIC but outside the range of IPs that the DHCP server provides | 18:00 |
| Azendale | marcoceppi: Ok, thanks. I think I'll try that as that'll probably be easiest to set up for now. (I imagine there is some more configuration if you want to specify that the IP be on a specific interface) | 18:01 |
| zradmin | Is there any way to force a service to delete itself? I destroyed it yesterday but juju is still reporting the service exists | 19:13 |
| mgz | zradmin: using `juju destroy-environment` takes everything down | 19:17 |
| zradmin | mgz: yeah i dont want to do that for just the one service though | 19:17 |
| mgz | zradmin: running it again wouldn't hurt, and you need terminate-machine after to actually kill resource usage | 19:23 |
| zradmin | mgz: my process to down a service looks like this: remove the units from the service, destroy the service, terminate machines... running a juju stat service just brings up a blank result | 19:25 |
| AskUbuntu | What's the lastest version of Openstack that I can deploy with Juju? Where can find this information? | http://askubuntu.com/q/365216 | 19:42 |
| === liam_ is now known as Guest32295 | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| === CyberJacob|Away is now known as CyberJacob | ||
| === CyberJacob is now known as CyberJacob|Away | ||
| === Topic unset by jcastro_ on #juju | ||
| === jcastro_ changed the topic of #juju to: Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://goo.gl/9yBZuv || Unanswered Questions: http://goo.gl/dNj8CP | ||
| === jcastro_ changed the topic of #juju to: Welcome!! Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://goo.gl/9yBZuv || Unanswered Questions: http://goo.gl/dNj8CP | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!