=== freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === CyberJacob|Away is now known as CyberJacob === axw_ is now known as axw [09:30] Hi, I've use the openstack charms to deploy swift and joined swift-proxy to keystone and as the admin user I can post objects etc without a problem. But as any other user I'm getting a 403. I can't see any likely looking roles that need granting. As far as I can see keystone returns a valid token but the swift proxy rejects it with a 403 [10:14] nm, I didn't appreciate the admin role was a prereq for creating objects === CyberJacob is now known as CyberJacob|Away [10:16] gnuoy: Do you know what I'm doing wrong with https://bugs.launchpad.net/charms/+source/swift-proxy/+bug/1238660 ? [10:16] <_mup_> Bug #1238660: Default installation fails [10:17] Hmm... no keystone... [10:17] stub, it looks like you're not explicitly setting any config for swift-storage, is that right / [10:17] ? [10:19] If you're using a single swift storage node I think you'll want replicas to be 1 [10:19] gnuoy: yeah, was going to use defaults [10:19] You are saying things that sound like I need to read some Swift documentation. [10:20] stub, defaults assume 3 swift storage nodes each with region set differently. Unless you use zone-assignment=auto but even then the number of replicas needs to be intune with the number of storage nodes [10:21] stub, the README in the swift-proxy charm is good [10:23] charm store has really low google juice :-( [10:51] jamespage, is there a workaround for Bug #1241674 ? [10:51] <_mup_> Bug #1241674: juju-core broken with OpenStack Havana for tenants with multiple networks

[11:25] # losetup --find /etc/swift/storagedev1.img [11:25] losetup: Could not find any loop device. Maybe this kernel does not know [11:25] about the loop device? (If so, recompile or `modprobe loop'.) [11:26] # modprobe loop [11:26] FATAL: Could not load /lib/modules/3.11.0-13-generic/modules.dep: No such file or directory [11:30] Is this just going to fail with lxc? [11:34] is it possible to force rerun hooks [11:46] yer, looks like you need custom lxc templates to get loop mounts (required for swift) [11:46] freeflying: 'juju resolved --retry' can rerun failed hooks. Apart from that, no. [11:47] stub, we have a node in error, retried times, but can't resolve it [11:48] and now it even reuse to retry :) [11:49] refuse [11:50] You will need to be more specific, maybe a pastebin of juju status output. Someone here might be able to identify the problem. === freeflying is now known as freeflying_away [12:42] Hey guys, I just bootstrapped a machine on amazon, then I tried to deploy a postgresql to the same machine as bootstrap (already did this in the past and it worked), but now it stays as pending forever, and if I check the logs inside the machine there is a log of "/bin/sh: 1: exec: /var/lib/juju/tools/unit-postgresql-0/jujud: not found" messages === freeflying_away is now known as freeflying [13:04] Ideas? :S === gary_poster|away is now known as gary_poster [13:33] X-warrior: oh, that's interesting [13:36] X-warrior: if you try to deploy to a machine other than bootstrap, does it work? [13:36] can you also install and run tree on /var/lib/juju/tools and pastebin it? [13:38] marcoceppi: let me run this tests [13:38] just a sec [13:49] marcoceppi: you want me to run tree on bootstrap + postgresql machine right? [13:49] X-warrior: yeah [13:50] just run tree /var/lib/juju/tools and pastebinit [14:09] marcoceppi: sorry, I'm recreating it x) [14:34] marcoceppi: http://pastebin.com/prp1ttWj [14:39] X-warrior: okay, so something is failing during install [14:39] X-warrior: do you have a unit-postgresql-0.log in /var/log/juju ? [14:39] yes [14:40] http://pastebin.com/ZQYFCxQi [14:43] awesome, X-warrior, what does machine-0.log show? [14:43] * marcoceppi notes that this is def a bug [14:44] http://pastebin.com/BFuhLuX3 [14:45] Could it be a problem because I'm using juju 1.12 on my localhost? I'm thinking that maybe, when I do a bootstrap it download latest juju version, which could not be compatible with mine. [15:07] marcoceppi: thoughts? [15:09] X-warrior: it's quite possible that is the issue [15:09] especially when using the --to flag [15:11] marcoceppi, well that doesn't seem very nice imo... I have a production environment that was deploy with juju 1.12, if I update my local version, maybe I could have problems with the production environment. Maybe, when bootstrapping, juju should send local version to server, and it downloads the same that I'm using, to guarantee compatibility? [15:11] X-warrior: well, it's supposed to do that [15:11] how could I check the bootstrap version? [15:11] it should, to some extent perform version matches for tools [15:12] X-warrior: it's 1.16.3 [15:12] so it is not working [15:12] if you destroy, then run juju bootstrap --show-log --debug [15:12] since my local version says I'm using 1.12 [15:12] you should see the tool matching logic [15:14] does the output of this new bootstrap could help you guys find out what is going on? [15:14] X-warrior: potentially [15:14] sinzui: juju should match minor versions of tools to client? [15:14] let me rerun it [15:14] X-warrior: I actually think this is a bug in 1.12 now that I think about it [15:14] marcoceppi, damn right [15:14] which was fixed in later versions of the juju client [15:15] marcoceppi, but I think you also mean it must match patch aswell [15:15] marcoceppi, 1.16.0 must not select 1.16.3 [15:15] sinzui: right, has that always been in core? X-warrior is seeing different results [15:17] marcoceppi, no. juju-core has always selected the latest. a recent change made it match minor to avoid pyjuju fiascos. juju-qa reported a bug that our testing tools don't like getting 1.16.3 when we are testing 1.16.2 [15:18] uhmm [15:19] X-warrior, Bug #1247232 is the issue we reported [15:19] <_mup_> Bug #1247232: Juju client deploys agent newer than itself

[15:19] sinzui: that's uncomfortable story for people with production deployments using older Juju versions [15:20] yep [15:20] any suggestions? Ultimately my mind jumps to "spin up lxc to manage multiple juju-cores" [15:20] I remember, back when pyjuju was fun and still installed, you could install versions of juju and use update-alternatives, but I don't think that exists anymore [15:21] X-warrior, marcoceppi. an even more uncomfortable/unintuitive work around is to use "juju upgrade-juju --version=1.16.2" to force a downgrade immediately after bootstrap [15:21] sinzui: that sounds scary and awesome [15:22] marcoceppi, it does exist, and I am working on the devel packaging fix to ensure 1.17.0 doesn't have a regression [15:23] sinzui: Oh, okay, so you could theoretically install 1.16.3, maybe compile it somewhere, then use update-alternatives to switch back and forth? [15:24] * marcoceppi considers a blog post for this [15:24] marcoceppi, update-alternatives is provided by the package, not juju-core [15:25] sinzui: right, so you've installed juju-core 1.12, but also want 1.16.3, you'd need to compile 1.16.3 since the apt package would just remove 1.12 from the system [15:25] unless there's some debian way to not have juju-core package remove the previous version [15:26] marcoceppi, oh that is right [15:26] marcoceppi, but there is another way [15:26] * marcoceppi is excite [15:26] * X-warrior still around here [15:26] you can download the new package and install it in another root [15:26] * sinzui searches for the option [15:27] sinzui: ahh, this sounds way better than compiling [15:27] Is the 'juju upgrade' for a production environment too risky? [15:27] X-warrior: yes! sorry, have not forgotten you, want to make sure we can switch back and forth [15:27] X-warrior: I've seen a few people do it, 90% positive working, with a 10% failure rate [15:28] because I think it is better to update now from 1.12 to 1.16 then later from 1.12 to 2.xx for example [15:28] or maybe 1.50 [15:28] marcoceppi, X-warrior dpkg --instdir=/opt for exampe will change the root dir [15:29] sinzui: X-warrior awesome, I'll give that a go and create a blog post on how to manage multiple juju installs on a machine [15:29] anyway it is a little scary to try to update from 1.12 and maybe screw everything :X [15:29] that is awesome [15:31] marcoceppi, X-warrior for the last two month I have use lxc to maintain a container that has all the stable tools. My own computer is on trusty and bleeds. since I mount my home dir in the container, both stable and devel have the same juju-configs. I test upgrades and compatibility that way [15:33] so in my case if I would like to update my juju version should I upgrade my local version from 1.12 to latest, and then run juju upgrade-juju to update the tools on my aws? [15:33] X-warrior: the upgrade is a bit hairy, I'll try to find a 1.12 deployment and see if it upgrades OK [15:34] though, sinzui might be able to speak to it better than me [15:37] marcoceppi, I wasn't testing back then. X-warrior your concerns about upgrade are legitimate. We only promise upgrades from stable to stable 1.12.x to 1.14.x. Going to 1.16.x find the tools, but no one has tested we can leap that far [15:38] s/16.x find/16.x will find/ [15:39] so the best approach for future project is keep it update on every stable version? I mean, if I had upgraded it from 1.12 to 1.14 later I could update from 1.14 to 1.16... [15:40] That is right [15:46] sinzui: so what about using 'juju upgrade-juju --version=1.14' to upgrade from 1.12 to 1.14 and then 'juju upgrade-juju' to get latest stable release from 1.16? [15:47] X-warrior, that will work [15:47] oh, nice. [15:48] but when using upgrade-juju it will just update the environment tools not my local ones right? So if I would like to do that, I must update my local juju to 1.14 then run upgrade-juju and then update my local to 1.16 and use the upgrade-juju again? [15:49] I'm not really sure about how local juju installation is related to remote/upgrade-juju [15:58] how can i add the 'juju-core' lp to my apt sources. cloud-tools only has 1.16.0 [16:06] context: let me check, cloud-tools should have 1.16.3 [16:07] X-warrior: it's only the remove juju [16:07] X-warrior: apt-get is for upgrading the client [16:08] marcoceppi: my client is 1.12 version, can I use 'upgrade-juju --version=1.14'? Or do I need to update my client to 1.14 first for example? [16:08] context: you're right, it only has 1.16.0 sinzui who's responsible for updating the cloud-tools archive? jamespage ? [16:09] X-warrior: you should be able to do that from 1.12 without issue, since it's like juju deploy, it's just telling the bootstrap node what to do. I'm not sure if there are incompatiblities between 1.12 and 1.14 [16:10] context: if you can, ppa:juju/stable has the latest juju-core; sudo add-apt-repository ppa:juju/stable; however, if you're using the cloud-tools archive you're probably doing so for a reason [16:10] marcoceppi: i did that 'status error on juju status' ticket, which might have in fact been an issue regarding dns. i get an unsupported protocol 'sftp' now. [16:11] trying again to get it running :) i replaced /usr/bin/jujud with the 1.16.2 its trying to use but still tries to fetch it. is it trying to install it somewhere else? [16:12] context: the tools on the server aren't installed from the cloud archive [16:12] they're pulled from a public bucket [16:13] yeah, do you know where juju bootstrap tries to install it ? [16:13] one of the places is the juju-dist bucket on s3 [16:13] context: what cloud are you using? [16:13] func SharedToolsDir(dataDir string, vers version.Binary) string { return path.Join(dataDir, "tools", vers.String()) [16:14] marcoceppi: manual (yeah i know, highly unstable) [16:14] context: then it's probably coming from the juju-dist bucket [16:14] yeah, but where is it trying to install the jujud [16:15] context: it will try to pull down the latest tools tgz, extrac, and install it to /var/lib/juju/agents [16:17] context: http://juju-dist.s3.amazonaws.com/ [16:17] yeah thats where it pulled from [16:17] but when it tries to install its trying to do sftp:// [16:17] so im trying to install it 'manually' so bootstrap can skip over that [16:18] or even just some how 'bootstrap' manually on the server so then i can do the rest of the juju stuff locally [16:18] marcoceppi: i want to fix whats already known broken manually, so i can move forward and see what else is broken :) [16:19] context: whatever you're up to sounds crazy ;) [16:19] im new to Go but not programming, just hard to read through the juju code sometimes :x [16:20] marcoceppi: where would i look for what exactly it wants in /var/lib/juju/agents i made it /var/lib/juju/agents/jujud but it still tries to install [16:20] marcoceppi: sorry if my being a bother, you can feel free to ignore me ;) [16:20] context: nope, it's versioned [16:20] context: it's okay, I've got 40 mins before the conference opens up [16:21] versioned as in /var/lib/juju/agents/1.16.2 or :x [16:21] * context opens the juju-local vm he has [16:22] context: /me checks [16:22] there's a few symlinks too [16:24] marcoceppi, thats correct - but it has to go through Ubuntu SRU for saucy first [16:24] and I've not had time todo taht [16:24] jamespage: gotchya, good to know [16:24] its in the stable ppa if you really need it [16:25] context: this is a slightly older machine, but /var/lib/juju tools like this: [16:25] context: you just need to update the tools directory, not the agents dir [16:25] http://paste.ubuntu.com/6411417/ [16:30] kk [16:30] * context plays around [16:33] grr !@# still dont work :-/ i guess ill leave it be for now :( [16:33] oh oops [16:42] cant even juju bootstrap manual provision with bootstrap-host: localhost [16:43] context: that's a really bad idea [16:43] as it will clobber your local host [16:43] oh thats fine [16:44] but nothing happens cause you still get screwed on unknown protocol sftp [16:44] * context adds ppa [16:45] yeah i guess im just stuck [16:46] it confuses me more cause i got passed this point once. i actually got bootstrap to succeed [16:48] ¯\_(ツ)_/¯ [16:49] yeah. thnx for the help, again [16:49] looks like fix is committed but not released yet [16:50] context: ah, 1.17.0 will probably bring a lot of good to this story [16:50] yeah [16:50] ive been keeping an eye on the milestone [16:50] wish i knew Go more to be able to help out [16:50] or the juju codebase for that matter. its a pretty big beast [16:51] context: it's quite a large project [16:51] one of the largest open source golang projects iirc [16:54] i am so confused [16:54] jujud-machine-0 start/running, process 17240 [16:54] grrrr !@# [16:54] all i did was rm -rf /var/lib/juju [16:55] AND juju status works [17:04] now attempting to add-machine [17:05] W00t W00t [17:17] marcoceppi: just to let you know, I installed the 1.16 version on a vm, and deployed the bootstrap and postgresql to the same machine, that error didn't happen [17:17] X-warrior: interesting [17:18] I mean deployed from vm to aws both of then on machine 0. [17:19] and the status of postgresql is running and logs doesn't have any similar message to that one [17:20] trying to deploy juju-gui i get this error: [17:20] 2013-11-13 17:15:42 INFO juju.worker.uniter context.go:255 HOOK ImportError: No module named yaml [17:20] trying to run the install hook [17:25] context: did you use any non-default charm option? [17:25] how do i 'redploy' a charm [17:25] frankban: nope. just did a manual apt-get install python-yaml to hopefully fix it [17:27] things dont like to die it seems :-/ [17:27] context: can you paste the whole log somewhere? anyway, you can try "juju resolved --retry juju-gui/0 [17:28] i did destroy-service and it just sits at life: dying [17:28] context: try now "juju resolved juju-gui/0" [17:29] context: but the whole log would really help investigating the isuue [17:29] yeah trying to get a clean slate :x [17:29] context: cool thanks [17:29] doesnt seem to be any 'forcively destroy-service' [17:31] so now the service just sits at 'dying' and no way to get rid of it [17:31] oh nm gone now [17:32] frankban: http://pastie.org/8478000 [17:35] context: looking [17:35] w00p w00p ! [17:35] frankban: manually install python-yaml fixed it [17:35] context: what provider are you using? [17:36] frankban: manual [17:36] :D [17:37] context: ok thanks for the feedback, we will release a new version of the charm soon, with a fix included [17:50] starting to like juju more and more [18:08] marcoceppi, sinzui, I'm leaving now, thanks for all the help, have a good one :D [18:08] thank you X-warrior === CyberJacob|Away is now known as CyberJacob [19:19] hmm, i deploy mysql and it says success but mysql is not running [19:25] damn, some charms are really touchy [19:29] jcastro: boo for not bundles beta in your juju updates :P [19:29] it's not available for people yet [19:29] random devel PPA doesn't count! [19:29] jcastro: sure it is, it's in the charm you go get right now if you juju deploy juju-gui [19:29] it's just 'in beta' [19:30] and an update coming later today [19:30] with jujucharms.com getting updated tomorrow hopefully [19:30] ok so next week's update [19:30] gotcha [19:30] side note, thanks for the emails. try to keep up [19:30] that is, I use them to try to keep up [19:33] ok so update me [19:33] when can people deploy the cloudfoundry bundle? [19:33] all the stuff should land tomorrow with the jujucharms.com update? [19:33] * rick_h_ goes to dbl check the quickstart ppa [19:33] jcastro: yes, everything should be up to date tomorrow me thinks [19:34] any word on better URLs in general? [19:34] I am trying to explain to kirkland how to deploy the bundle and he wants to punch himself in the face [19:35] bundle: is supported in the ppa release today or tomorrow [19:35] will need a follow up to update the url in the deploy tab [19:35] so bundle:~jorge/cloudfoundry ? [19:35] bundle:~jorge/cloudfoundry/3/cloudfoundry [19:35] ugh [19:35] dude, you are killing me [19:35] unfortunately you can have multiple bundles in there [19:35] we can't make it shorter than that and have them work like they do man [19:36] go back and talk to the original people that designed the deployer files and such [19:36] hazmat, surely there's something we can do here [19:42] jcastro: k, well fyi updated the quickstart and juju quickstart bundle:~jorge/cloudfoundry/3/cloudfoundry works [19:42] at least it's running the install on cf-release right now [20:13] jcastro, yeah.. there's several sane things we can do.. like omit the deployment name within the bundle when its the only one.. omit the version and get the current one.. [20:14] would minimize nicely to bundle:~jorge/cloudfoundry [20:14] yeah it just needs to be something rememberable by the user [20:18] rick_h_, confirm, the bundle works fine here [20:18] jcastro: woot [20:19] this bundle/charm is deceptive though [20:19] since it's doing so much if you don't debug-log there's no way to know what it's doing [20:19] jcastro: yea, definitely [20:20] I wonder if there's a way to echo "Go have a smoke, it's going to be a while." somewhere [20:20] like a louder version of juju-log [20:20] heh, in the gui we do that with all bundles. I guess it'd be something to note in the charm readme [20:20] or summary/etc that's somewhere visible [20:20] yeah [20:20] since it's really the charm that's the long-runner [20:20] right === BradCrittenden is now known as bac [21:44] Hi [22:40] jcastro: just thought you would like to know, askubuntu q's are *finally* in the review queue. === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying