=== kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away [08:32] jamespage, I'm guessing you don't have anytime today but if you do I'd love to get https://code.launchpad.net/~gnuoy/charm-helpers/current-dc-leader/+merge/259123 reviewed [08:39] gnuoy, aside for a constant for 'DC' lgtm [08:42] jamespage: ping [09:36] apuimedo, hello [09:40] jamespage: I am making the changes to neutron-api so that it installs the right repos and it uses the neutron credentials from identityservicecontext ;-) [09:44] apuimedo, +1 === liam_ is now known as Guest15928 === Murali_ is now known as Murali [15:00] stub: you are ready for the new trusty/cassandra charm to enter the charm store correct? double-checking before i do it === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [19:03] Is it possible to configure juju to use specific maas zone for auto selected nodes ? [19:32] maas tagging should give you that [19:32] constraints="tag=zone" [19:32] as an example [19:33] there may be another tag thats more specific to the zoning integration... [19:33] natefinch: ericsnow ^ any ideas on this? I'm pretty sure that tags are the only maas specific constraint supported... [19:39] hmm [19:40] you can do juju deploy some_charm --to zone=foo [19:42] There's no way to set up a default zone right now, though [19:53] perfect, thanks natefinch [19:53] elurkki: ^ [19:54] lazyPower: Ahaa, ok. Thanks a lot [19:56] Will try this. Currently juju bootstrap errors on mongodb. Wrestling with that first [19:58] elurkki: whats teh stacktrace? [19:58] The last error I get is : "ERROR juju.cmd supercommand.go:430 cannot initiate replica set: cannot get replica set status: can't get local.system.replset config from self or any seed (EMPTYCONFIG)" [19:58] Not sure if this is from stacktrace [19:59] i just recently encountered that [19:59] what my problem was, is it used the public interface that was firewalled and unable to initate itself. let me fish up teh bug i commented on [19:59] Not sure if this is related to fact that DNS can not resolve the node name [19:59] this was however in an AWS VPC [19:59] yeah, if its using the nodename that will be it [20:00] lazyPower: I am totally newbie with maas & juju (second day here) [20:00] lazyPower: Not sure even if I have to manually add the DNS entry for DHCP reserved node [20:01] if you're using maas you shouldn't have to [20:01] it should be communciating with your region-server, and getting dns info w/ resolveable config back from that [20:01] lazyPower: That is what I thought. I am using Maas yep [20:02] unless you're using external dns [20:02] MaaS DNS is used [20:02] ok, yeah it should all be peachy [20:02] lazyPower: Ok. I will check system logs for possible problems [20:03] https://bugs.launchpad.net/juju-core/+bug/1340663 [20:03] Bug #1340663: bootstrap issue with replicasets on 1.20.1 with VM on MAAS provider [20:04] lazyPower: Ok, that looks a bit different than mine here. I will compare these a bit. Thanks a lot for pointer [20:04] np === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [21:22] it feels like I'm asking a pretty stupid question, but I just don't get it. where does juju search for jujud when bootstrapping with --upload-tools? [22:11] Argon]: your path [22:12] perrito666: $PATH? and there it's searching for the appropriate tgz? hm, then I have to double check it again, the files are in my path [22:13] Argon]: i believe it looks for jujud bin in your path [22:13] in my case /home/hduran/gocode/bin/jujud [22:13] in mine it's /usr/lib/juju-1.24-beta2/bin/jujud [22:13] so I just go install github.com/juju/juju/... and then run the upgrade [22:13] marcoceppi: showoff [22:14] ;) [22:14] perrito666: you're the one running from source, I'm just using the stable/devel ppas [22:15] :/ both, jujud and the tarball are in my path but "no matching tools available" [22:15] marcoceppi: there is no good reason for using upload tools if you are not running from source [22:15] Argon]: what command are you running? [22:15] perrito666: true, I'm just saying [22:15] juju bootstrap --environment amazon --constraints "cpu-power=10 cpu-cores=1 mem=768M" --upload-tools [22:16] and I loaded an appropriate jujud from http://streams.canonical.com/juju/tools/devel [22:16] (this is supposed to be a test, going to use a different jujud later on) [22:17] throw a --debug in there and paste the result in a pastebin [22:18] oh there's debug? I wondered why -v doesn't work [22:19] there is --show-logs and --debug which are in turn like -v and -vv [22:20] https://gist.github.com/Argon-/a74263ba5a9309a0a5b4 [22:21] I should run it without --upload-tools to see what's "new", I guess === kadams54 is now known as kadams54-away [22:24] Argon]: it is not working actually [22:24] you should see 2015-05-15 22:23:12 DEBUG juju.environs.sync sync.go:304 Building tools [22:24] try having constraints as the last param [22:25] I don't want to build them, though. just pass a already built binary. at least who I understood it: https://github.com/juju/juju/blob/master/cmd/juju/upgradejuju.go#L56 [22:25] ok [22:25] *that's how [22:25] Argon]: I think build refers to the targz [22:26] I know for a fact that what I just ran did not actually built it or it would have failed since my code does not compile right now [22:28] nope, no "Building tools", errors out with "no matching tools available" even without --constraints [22:30] (the debug output is exactly the same) [22:31] :|