=== freeflying_away is now known as freeflying === CyberJacob is now known as CyberJacob|Away === waigani_ is now known as waigani [06:17] Hi Guys, after all the hassles i was finally able to see the bootstrapping process made some progress, however still it was unable to start the bootstrap instance due to this error [06:17] " ERROR juju supercommand.go:282 cannot start bootstrap instance: index file has no data for cloud {blr http://192.168.124.81:5000/v2.0} not found" [06:17] any idea how to solve this [06:19] sarnold, davecheney any thoughts? === CyberJacob|Away is now known as CyberJacob === freeflying is now known as freeflying_away === CyberJacob is now known as CyberJacob|Away [13:23] hi guys.. anybody there? [13:24] asking something like that just just begging for a "no" :P [13:24] this is irc, if you have a question just write it and wait [13:25] sorry.. sorry.. a moment of panic :) logged into launchpad, all my code was gone.. after a minor heart attach figured out i used a wrong account.. all better now.. [13:25] :D [13:26] sorry again [13:26] happy ending [13:53] I've used the 'juju sync-tools --source ' sucessfully after downloading tarballs locally. Is there a way to have --source point at a remote URL over HTTP? Thanks === freeflying_away is now known as freeflying [15:00] hey sinzui - is there anything I can do about this other than wait? https://bugs.launchpad.net/charm-tools/+bug/1262836 [15:00] <_mup_> Bug #1262836: charm-tools fails to build on trusty [15:00] I didnt' see a workaround in the bug report [15:00] * sinzui looks [15:01] oops, you didn't report that, jjox did === hatch_ is now known as hatch [15:02] hmm, recipes always force native version, so the issue is to change the package version string [15:07] marcoceppi, This does look like the bzr-plugin forcing the recipe to build as native. Lp always rung with fallback mode [15:08] marcoceppi, I experienced this in Oct/Nov and found that I could make a version string that was acceptable. While I could get a recipe for juju-core, I abandoned it. [15:08] * sinzui looks for old nots [15:11] marcoceppi, change the plus to a squiggle in the recipe. I seem to have played with that a lot [15:11] sinzui: there's not recipie for this, I've been cutting releases myself [15:12] marcoceppi, This is what I got to work before abandoning recipes: https://code.launchpad.net/~ce-orange-squad/+recipe/juju-core-unstable-packaging [15:12] using ppa-release similar to the juju-core releases now [15:13] err, ppa-release == backportpackage [15:13] oh, suddenly this bug makes sense [15:13] sinzui: sorry about that, I see the problem now [15:14] marcoceppi, oh, I saw the recipe was using quit in debian/source/format is your branch doing the same [15:14] sinzui: this is charmtools 0.3 [15:14] 1.x isn't backwards compatible I think IS is building it themselves. I'll update the bug [15:14] ha ha [15:16] let me go get some caffine [15:32] hi, i'm working on clustering for rabbit charm, and i found an issue retrieving all the peers for a relation [15:33] i created 4 clustered nodes, if nodes are up, it works ok and i get a list of the 4 nodes when trying to query peers [15:33] but then i just stop first unit with nova stop, do the query again, and only the first unit (the one stopped) is reported [15:37] yolanda: that's interesting. When you say query you mean with relation-list or in the juju status [15:37] marcoceppi, in the relation-list [15:38] i can reproduce it right now [15:38] i got logs telling i only had first unit when i stop it [15:38] i started again and got all the units [15:39] i'm programming rabbitmq clustering and that's an issue, if first unit is stopped for some reason, i cannot add more units [15:39] jcastro, did you release your mongodb bundle? [15:40] yolanda: that's odd, I've never seen that before and I don't quite know where to start looking. If it's replicatable I'd file a bug against juju-core about it with instrutions to replicate [15:40] yes, i can replicate it [15:40] i'll write some bug [15:40] lazypower, I was just going to check [15:40] https://jujucharms.com/fullscreen/search/bundle/~jorge/mongodb-cluster/1/mongodb-cluster/?text=mongodb-cluster [15:40] Kablammo! [15:40] Great minds think alike [15:40] BOOM! [15:40] yolanda: thanks! sorry I couldn't be of more help [15:40] hey wanna give it a shot? [15:41] no problem [15:41] * marcoceppi pings fwereade to see if he can shed light on yolanda's issue [15:41] You know i do! [15:50] files this one: https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1267913 [15:51] <_mup_> Bug #1267913: juju relation-list doesn't report full units list when unit is down [15:51] marcoceppi, sorry, was meeting, reading back [15:52] yolanda, thanks for the bug, that's bizarre and terrifying, I'll take a look [15:53] thx [16:26] Okay, last call for changes to charm-tools [16:33] marcoceppi: I request a pony! [17:05] Hey jorge [17:05] with your mongodb-cluster bundle, the relationships incoming is a bit wonky and did not draw on the gui [17:05] yeah so [17:05] that happened to me yesterday [17:05] http://i.imgur.com/QUcHZQg.png [17:06] https://jujucharms.com/fullscreen/search/bundle/~jorge/mongodb-cluster/1/mongodb-cluster/?text=mongodb-cluster [17:06] WHen i go to draw the relationship, it shows a dialogue displaying the options for the relationship. [17:06] they're supposed to be there [17:07] let me try with a simple wordpress bundle [17:08] I mean, if you look in the bundle itself, the relationships are there [17:08] I dont doubt it, i'm still investigating. [17:08] Just reporting my initial findings [17:09] yeah, I'm just saying, I don't think it's the bundle itself [17:10] Ah, i think what happened is the relationships were pending this last unit coming online [17:11] I love juju, its so smart. [17:11] lazypower: jcastro yea, relationships in budles are only applied after all units are up I believe [17:11] ah [17:11] but what happens if he had to resolve --retry a bunch of things? [17:11] not sure, if the bundle process was still processing it might work, but not tested it tbh. [17:11] I can wipe this and start over [17:12] if something throws an error the bundle deploy quits [17:13] aha [17:13] so basically, the race condition in the charm probably causes the bundle to quit [17:14] Thats my guess, but the other problem i ran into is the lxc container already created bug. [17:14] thats reported as resolved in .17 is it not? [17:31] lazypower, I tried it on aws [17:31] so I don't think it's a provider-specific thing [17:39] Ah ok [18:07] rick_h_: there's no way to re-run deployer? [18:07] wipe everything and try again [18:08] rick_h_: is there anything on the roadmap to report when deployer throws an error to the gui? maybe like a "re-run" since deployer will pick up where it left off [18:08] I meah, obviously fixing the charm is a priority [18:08] marcoceppi: right now if it dies in an error it should report whatever Juju tells it [18:08] in the Gui notification box [18:08] rick_h_: gotchya [18:08] if it does not, then there's an issue we need to fix, but we try to help the user know something went bad if we can === CyberJacob|Away is now known as CyberJacob [20:19] aha! [20:19] marcoceppi, found the issue with the local provider [20:19] I had to blow away .juju/local too [20:19] jcastro: which issue is this? [20:19] marcoceppi, do you have that list of stuff you need to blow away from thumper? we should write that up [20:20] rick_h_, my local provider stopped working [20:23] jcastro: yeah [20:25] /etc/init/juju-*; /etc/rsyslog.d/25-juju*; /var/lib/juju/containers/*; /var/lib/lxc/juju-*; ~/.juju/; ~/.juju/environments/.jenv [20:25] jcastro: ^ [20:31] also /etc/lxc/auto/ I think [20:31] the symlinks in it [20:32] http://askubuntu.com/questions/403618/how-do-i-clean-up-a-machine-after-using-the-local-provider/403619#403619 [20:32] avoine, gotcha, adding now [20:35] jam: btw I create a bzr branch for that like you ask: https://code.launchpad.net/~patrick-hetu/golxc/fix-1238541 [21:15] marcoceppi:/jcastro: very simple apache2 fix, it's broken right now if you don't set "servername" and are generating self-signed-certs: https://code.launchpad.net/~davidpbritton/charms/precise/apache2/fix-no-servername-case/+merge/201254 [21:15] ack [21:15] it's coming up on the charm audit anyway [21:15] nice catch! [21:16] dpb1: thanks [21:30] :) [22:07] hello, this is more of a generic cloud question than juju-specific, but are there any cloud providers who give free accounts on micro/tiny instances? [22:07] i thought a micro instance on EC2 might have been free, but it looks like that's only a promo price for 1 year [22:08] achiang: not that I'm aware of. AWS has 700 free hours of micro a month (which equates to about 1 micro a month) but the micro is a pretty poor performance instance size [22:08] marcoceppi: is that forever? [22:08] achiang: for the first yea [22:09] or does that only last for 1 year? [22:09] damn, right... [22:09] hoping for a more long term solution [22:09] canonistack? [22:09] if you work for Canonical, then that does work [22:09] i'm working on something for the general public [22:09] ah [22:10] too bad heroku isn't a generic OS [22:12] maybe i should play with the vagrant images after all [22:12] but that's slightly more annoying [22:16] it's certainly the cheapest [22:17] going down the heroku path... i could package up my stuff and put it in pip maybe [22:17] or pypi, rather [22:18] and then could specify my package in requirements.txt [22:18] ugh [22:18] but then i have to make a whole django app [22:18] * achiang keeps searching for a free lunch somewhere [22:19] can i conceptually think of juju+vagrant as a "cloud environment on your desktop" ? [22:26] who owns content here - https://juju.ubuntu.com/docs/config-vagrant.html [22:26] the vagrant download link is old [22:26] should be this link: http://www.vagrantup.com/downloads.html === gary_poster is now known as gary_poster|away