=== CyberJacob is now known as CyberJacob|Away === timrc-afk is now known as timrc === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === mwhudson is now known as zz_mwhudson === tim is now known as thumper === tim is now known as thumper === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === zz_mwhudson is now known as mwhudson === freeflying_away is now known as freeflying === CyberJacob|Away is now known as CyberJacob === mwhudson is now known as zz_mwhudson === dosaboy_ is now known as dosaboy [09:42] arosales: pong [09:45] hi, I'm running juju on a virtual machine that I connect to through a vpn [09:46] if I run an apache-server on this virtual machine I am able to connect to it through the vm's ip [09:46] but when I run a service through juju, I don't know how to connect to it from my computer (that is, not from the virtual machine) [09:47] is it possible to make some sort of redirection so that when I go to the vm's ip in the browser the vm redirects me to the correct service (for example juju-gui) === CyberJacob is now known as CyberJacob|Away [09:56] hazmat, do I need to bump juju-deployer in trusty to matchup with 1.17.0? seeing some odd issues [10:37] Should charms be running apt-get upgrade, or is that left to other mechanisms like Landscape? === timrc is now known as timrc-afk [10:47] jona_, your question needs a bit of clarification. Are you looking for a way to route to a juju lxc container inside of the virtual machine? or are you looking to reach a LXC on the HOST from the vm? [10:48] Or am I inferring too much, and there are no containers, just a service on a manually provisioned VM? [10:54] hi lazypower [10:55] I want to reach the lxc container inside of the virtual machine [10:55] the VM is on an openstacks-server, and I connect to the VM with ssh and a vpn [10:56] I am using the VM as a development environment, and juju seemed easy to use :) [10:56] when I hosted a plain apache-service on the VM I was able to connect to it by just putting the VM's ip in the browser [10:56] Withing knowing much of your network topology, i'm going to make recommendations based on what i feel is the path of least resistance [10:57] okay [10:58] Juju by default does not use a routeable IP schema, it creates a bridged network interface to handle the IP routing of the local machine to the LXC containers. It doesn't sound like you have a setup that will lend itself easily to altering this bridged device for public/lan ip assignment, so you will need ot create a tunnel through your tunnel to reach the containers. [10:58] This is largely untested through a VPN tunnel, but in theory it should work without a problem. There's an app called sshuttle that will allow you to create a virtual VPN within your VPN (man this seems heavy handed) [10:58] jona_: did juju create the openstack vm? or did you provision it in horizon? [11:04] actually I'm not the openstacks admin, the admin created the VM for me, and it's running ubuntu, and on the VM I installed juju [11:05] jona_: gotchya [11:06] I see, a vpn in the vpn was actually what I had in mind, but I'm rather new to these kinds of things [11:06] I'm more of a developer than a networking guy [11:07] jona_, well after conferring with Marco we both agree you can do this with just SShuttle. Let me fish up some docs for this, as its been a while since I had to do this. [11:07] oh all right [11:07] http://blog.utlemming.org/2013/12/beta-cross-platform-juju-development.html [11:07] utlemming did a great write up, its listed under (optional) SSHuttle [11:07] oh okay [11:08] I'll take a look [11:08] jona_: vpn is the way to go, its not as painful as you might think, just needs the right configuration options [11:08] now replace the user@localhost bits accordingly with proper end points, ports, and users and you should be able to reach those LXC containers. [11:08] oh all right [11:09] seems doable :D [11:09] I'll try it [11:09] juju seems reaaally neat so I'd like to get to know it better :D [11:10] I tried the demo on the page and read a bit about it [11:10] and at least deploying the charms(?) is super practical, hehe [11:10] jona_: once you get it installed, replace vagrant@localhost:2222 with the ssh address for your ubintu machine === timrc-afk is now known as timrc [11:11] I'm supposed to do this on the VM right? [11:11] jona_: if you can install virtualbox, you might want to use the vagrant image. it'll install an Ubuntu vm on your desktop with the local provider already configured [11:12] jona_: well. for testing, sure! but juju runs best against a cloud environment like open stack for production stuff [11:13] oh okay, so if I actually want to use vm I should just get my admin to install it directly on the openstacks-server? [11:14] jona_, in regards to the VM talk, marco was speaking about pulling down the vagrant image on your workstation for testing purposes [11:15] you already have juju installed and functioning in that VM, so you're good to go once you get your VPN or SSHuttle configured. [11:15] jona_: he would give you an account on the openstack install. you put your account details in juju then juju will spin openstack vms when you deplpy charms [11:15] ^ that is the most desireable outcome from this talk, as you're getting the integration juju provides out of the box. [11:16] ah I see [11:16] juju supports multiple types of clouds. aws, openstack, azure, lxc, bare metal, etc [11:16] yeah I noticed [11:17] hm, I'm not sure if I misunderstood something, when does sshuttle do the shuttling? when I ssh to the VM's ip? [11:18] Correct [11:18] jona_: from your desktop to the vm [11:19] I ran this command [11:19] sshuttle -e 'ssh -o UserKnownHostsFile=/dev/null ubuntu@192.168.10.222:22' 10.0.3.0/24 [11:19] once you run that sshuttle command, your desktop will forward the request over that SSH tunnel to the VM, and route to the addresses of the LXC containers provisioned by juju/lxc. [11:20] or wait, I'm not supposed to touch the ports ? [11:20] I figured I'd set them to the port I use when SSHing [11:20] that's correct [11:20] :22 [11:20] the :2222 is vagrant specific [11:22] hm okay, but when I ssh'd to the ip it connected me to the VM as usual [11:22] run juju status, and find the IP of the deployed apache charm [11:22] sure [11:23] I should put that in instead? [11:23] Yep, try to ping it, or plug it into your browser [11:24] it doesn't seem to find a connection [11:24] no ping packages received [11:25] but just so I understand the steps [11:25] I ran [11:25] sshuttle -e 'ssh -o UserKnownHostsFile=/dev/null ubuntu@192.168.10.222:22' 10.0.3.0/24 [11:25] then I ssh'd again to the VM, where I ran started sshuttle [11:25] 192.168.10.222 is the IP of the VM? [11:25] then I tried pinging the ip for juju-gui (10.0.3.23) as provided by juju status [11:25] yes [11:28] thinking, 1 moment [11:29] jona_: if you put 10.0.3.23 in your browser after running sshuttle, do you get the GUI? [11:30] nope, it just gets stuck on trying to conenct [11:31] and you're running sshuttle from your desktop? [11:31] no on my VM [11:31] jona_: ah, there we go [11:31] run sshuttle from your desktop [11:31] I actually asked about that :D [11:31] okay [11:31] jona_: sorry we didn't make that more clear [11:32] no biggie ^^ thanks for helping me at all, haha [11:33] btw I run arch locally, and it just claimed "Errno 2 no such file or directory", maybe it's empty in /dev/null? [11:33] good call marco [11:33] it wasn't [11:33] hm, it says no such file or directory when I run sshuttle -e 'ssh -o UserKnownHostsFile=/dev/null ubuntu@192.168.10.222:22' 10.0.3.0/24 locally [11:34] jona_: is sshuttle installed? [11:34] yes [11:34] http://pastebin.com/dCHD5JSJ [11:34] this is an error sshuttle generates, I think [11:35] jona_: feel free to remove the '-o User.../dev/null' stuff from the -e parameter [11:35] and give that a whirl [11:35] weird, it still gives the same error [11:36] try giving the entire path to ssh [11:36] ie, /usr/bin/ssh [11:36] still same error :S [11:36] really weird [11:38] I am able to run ssh-V and sshuttle -V so they're both runable [11:38] can you run sshuttle -v for more verbosity? and paste the entire output [11:39] oh I googled the error [11:39] apparently I needed net-tools [11:39] though now I get some other errors [11:39] iptables v1.4.21: can't initialize iptables table `nat': Table does not exist (do you need to insmod?) [11:40] I guess you need insmod? Sorry haven't run arch in quite a while ;) [11:40] I tried running it but it said "missing filename" [11:40] I actually don't know what insmod is [11:40] it loads modules into the kernel space [11:42] hm [11:42] I'm just gonna try rebooting brb [11:43] hello! [11:43] it works now [11:43] huzzah [11:43] boom [11:44] at least sshuttle does [11:44] now I'll try connecting with firefox [11:44] hmm [11:44] it doesn't seem to work [11:44] oh wait [11:44] I forgot [11:46] hmm [11:46] nope still doesn't work [11:46] now I've started sshuttle locally, connected to the VM, and tried pinging both 10.0.3.23 and 10.0.3.0 [11:47] might it have with the ports to do? and does the /24 after 10.0.3.0 in the sshuttle command matter? [11:47] the /24 defines the CIDR range you want to route through that tunnel [11:48] 10.0.3.0/24 will route everything from .0 to .255 on the 10.0.3 block, if that makes sense. [11:48] but no, the ports shouldn't be a problem. So long as sshuttle is actively running when you try to ping those ip's, or pull them up in a browser. [11:49] hm okay [11:50] http://pastebin.com/bWxzhKsC [11:50] got these warnings [11:50] don't know what they mean [11:52] well those are good signs, it means sshuttle is establishing a connection with the server. It may not be active, but its trying [11:52] kill it and restart it, do you still get the warnings? [11:53] the server or shuttle? [11:53] sshuttle [11:53] brb [11:53] ok [12:01] hm, it seems to give the warning after like 5 minutes or so [12:01] afk for a while [12:07] jona_: can you try running sshuttle with the -v flag, might illuminate what's going on [12:09] http://pastebin.com/PBm45Wbq [12:09] the last row appeared when I entered 10.0.3.23 in my browser [12:10] I have to eat now, but I'll write again when I'm back [12:11] jona_: cool, it seems to be working :\ [12:37] jamespage, i've had a bunch of similiar issue reports in the last week relating to the same watcher error, rogpeppe1 added some additional logging, and i was going to have a look this week, would be good to confirm we're referencing the same issue. the ppa needs updating though [12:37] hazmat: i've fixed that in trunk [12:37] rogpeppe1, logging or watcher error? [12:38] hazmat: both [12:38] rogpeppe1, what was the issue for the watcher? [12:38] hazmat: FWIW the additional logging *was* very useful for diagnosing the problem [12:38] rogpeppe1, awesome [12:38] hazmat: the client watcher wasn't pinging [12:38] hazmat: (i updated the bug report) [12:39] rogpeppe1, cool.. i thought that might be the case and commented on the bug to that effect.. [12:39] hazmat: https://codereview.appspot.com/53810045/ [12:40] hazmat: yeah - i'd actually merged the fix before you commented there :-) [12:40] :-) [12:40] strange normally i get a bug email from lp [12:40] hazmat: it was a bit of a giveaway that the client connection was closed after exactly 3 minutes [12:41] hazmat: a quick grep of the source for "3 \* time.Minute" found the source of the problem immediately... [12:41] rogpeppe1, given a synchronous client not sure how to make that nicer.. outside of background threads..... ideally the ping timeout could be client configured [12:42] hazmat: i don't think we care about the client pinging [12:42] rogpeppe1, umm.. i think you do.. guard against bad clients. [12:42] rogpeppe1, your saying just wait for socket close? [12:42] hazmat: we should probably set SO_KEEPALIVE if it's not set already [12:42] hazmat: yeah [12:44] hazmat: but anyway, you should definitely make your client library concurrent-safe, because at the moment it wouldn't be possible to send a ping request in general, even if you wanted to [12:44] hmmm.. so alternatively for a sync client, i can hold store pings, and send opportunistic pongs [12:45] hazmat: that's not a good idea [12:45] rogpeppe1, without concurrency how else to do that? [12:45] hazmat: use concurrency [12:45] :) [12:46] hazmat: or callbacks, or something [12:46] rogpeppe1, concurrent safe / concurrency.. mean event loop/scheduler.. i'm happy to do that, but the majority of users want idiomatic not framework [12:46] hazmat, that sounds like what i see [12:46] hazmat: the main point is: clients need to be able to make concurrent calls on the same connection, however you allow that [12:47] seems like something for the plain ride, a subclass that plays nice with gevent/eventlet [12:47] hazmat: yeah, you could have subclasses for various kinds of concurrency framework (twisted, gevent, callback) [12:48] hazmat: you could layer them all on top of a callback-based base layer [12:49] not doing callback oriented api, twisted and gevent can both do non-callback base, and i want the normal python usage to be non call back based. [12:49] hazmat: fair enough === gary_poster|away is now known as gary_poster [13:07] I am back marcoceppi [13:08] this is how the log looks now: [13:08] http://pastebin.com/GtnnbTuy [14:14] is this the place to ask juju-deployer questions? [14:26] josepht, its as good as any - hazmat wrote it :-) [14:28] Hi, I'm having troubles with juju, I'm just trying to do my first: `# juju bootstrap` (on ubuntu) but I'm getting the error: "ERROR no reachable servers". If I see through the `# juju status -v` I can see it stucks on "INFO juju.state open.go:68 opening state; mongo addresses: ["10.0.3.1:37017"]; entity """. === freeflying is now known as freeflying_away === rogpeppe2 is now known as rogpeppe [14:45] I'm using canonistack. I've sourced my novarc. I get this: http://paste.ubuntu.com/6797562/ when I run: juju-deployer -bdv -c juju-deployer/webui.yaml, where webui.yaml's content is: http://paste.ubuntu.com/6797578/ [14:50] josepht, so your probably using juju switch.. there's like 4 different ways that juju-core can lookup its env to operate on..deployer supports 3.. there's a bug outstanding for juju-core that it should just pass the env unambigiously to the plugin via env variables.. in the meantime.. you can just set JUJU_ENV env var to the env your using. [14:53] core bug is https://bugs.launchpad.net/juju-core/+bug/1246156.. arguable deployer should just support the four different ways till its done. [14:53] hazmat, I don't know if you see my message, did you?, I can't solve that :( [14:55] NemesisMate, that sounds like bootstrap never succeeded.. which provider are you using.. juju-core trunk has already changed provisioning to be synchronous so that these sorts of things are more obvious/easier to diagnose. [14:55] er.. changed s/provisioning/bootstraping [15:00] what do you mean with provider? [15:03] hazmat: thanks, that was it. [15:04] NemesisMate, like openstack, ec2, etc.. your environment is configured to use which provider? [15:04] in environments.yaml .. its the 'type' key on the environment config [15:05] `# juju version` gives me: 1.16.5-quantal-amd64. I just installed it with an apt-get install from "ppa:juju/stable", I made a `juju init`, after that I changed to "default: local" on "~/.juju/environments.yaml", I made an apt-get install mongodb-server and a juju bootstrap [15:05] It's a local one [15:07] NemesisMate, ic.. do you have a firewall setup on your local machine? [15:08] NemesisMate, normally a local env bootstrap requires sudo .. [15:08] No, even I get "[initandlisten] connection accepted from 127.0.0.1:35831 #1" on /var/log/mongodb if I change mongodb port to 37017, but juju bootstrap hangs on that line [15:08] yes, I'm using sudo [15:08] NemesisMate, juju will setup and install its own mongodb on a different port [15:09] NemesisMate, typically you can just disable shutdown the package one unless your using it for other things [15:09] if I let it without initializing mongo-db, I get the error I comment at start [15:09] NemesisMate, the issue is what's happening to the separate mongodb process that juju is trying to setup [15:10] NemesisMate, ie ls /etc/init/juju* should show juju-db in addition to the machine agent [15:10] NemesisMate, so starting back at square one.. i'd sudo service mongodb-server stop [15:11] oh.. the juju jobs are prefixed with user name in the local provider case [15:13] Ok, I stopped mongodb, and I "juju destroy-environment -y" and try the "sudo juju bootstrap --verbose" and it ended with: http://pastebin.com/rT1zDDnY [15:16] I just have this file: "/etc/init/juju-db--local.conf" from juju there [15:25] If I try to execute the command on that file (on the "exec" parameter) I get "error command line: unknown option sslOnNormalPorts". Maybe I need another mongodb version? [15:27] When deploy on Amazon AWS is it OK to use our own AMI or must use precise, saucy,etc? [15:27] ok, thanks, that was it. I did again an apt-get mongodb-server install and this time it updated again.... (Why it didn't installed this version before?). This time is working great [15:35] NemesisMate, cool.. yeah.. mongodb needs ssl support [15:35] Ming_, juju is setup to use pristine cloud-images [15:35] NemesisMate, what distro version are you on? .. if your on precise.. the typically way to get that is via the cloud-archive tools ppa [15:37] NemesisMate, there's also a mongodb with ssl in the juju stable ppa, but if you installed mongodb prior to adding and updating from the ppa you would have gotten the distro version (sans ssl) [15:48] rogpeppe: still getting watcher was stopped using 1.17.1 [15:48] marcoceppi: can you paste me the machine-0.log ? [15:48] marcoceppi: i suspect you're not actually using 1.17.1 [15:49] rogpeppe: mbruzek ran in to it ^^ [15:49] rogpeppe: http://pastebin.ubuntu.com/6797420/ (not machine-0.log) [15:49] rogpeppe, how to get machine-0.log [15:49] ? [15:49] mbruzek: ~/.juju/local/log/machine-0.log [15:49] mbruzek: how do you know you're running 1.17.1 ? [15:49] That is on my local filesystem somwhere right? [15:50] mbruzek: what does "sudo which juju" print? [15:51] /usr/bin/juju [15:51] sudo juju version [15:51] 1.17.1-trusty-amd64 [15:51] rogpeppe: he installed the trusty binary that james put out [15:52] marcoceppi: from which revision? [15:52] mbruzek: please paste machine-0.log - that will tell me which version is actually running, and whether the issue is the same one [15:53] rogpeppe: I have no idea which one james cut that release from [15:53] http://pastebin.ubuntu.com/6797873/ [15:53] mbruzek: right, that's not the version with the fix in [15:54] rogpeppe: ah, sorry, we'll go back and compile/test again [15:54] mbruzek: erm [15:54] Which line tells you that? [15:54] mbruzek: maybe it is! [15:54] mbruzek: i'm not sure. [15:55] mbruzek: i see it has the log fixes, but i still see the connection termination [15:56] mbruzek: it would be good to know which revno james cut that version from [15:56] I still have the .deb [15:56] How can I get you that information? [15:56] mbruzek: i'm not sure i can easily find that info from the deb [15:56] mbruzek: that just has the binary in, right? [15:57] mbruzek: actually, perhaps you could send me the .deb? [15:58] doing that now [15:58] mbruzek: thanks [16:00] * mbruzek is slowly uploading the file... [16:00] * mbruzek curses his slow upload speed! [16:01] rogpeppe: it's on the juju list [16:02] maybe...it's not? [16:06] marcoceppi: was it jamespage that put the binary out? [16:06] idk now, mbruzek where did you get that trusty.deb file? [16:06] rogpeppe, the note is sent [16:06] mbruzek: thanks [16:06] let me check my notes [16:07] mbruzek: i'm still suspecting it's built from a revision earlier than 2219 [16:08] mbruzek: got your email and downloaded, thanks [16:08] I don't think it was james [16:08] I was pointed to the jenkins site, [16:11] oh, shoot, I was confused, it's from the ci [16:11] sinzui [16:12] hi mbarnett [16:12] sorry mbarnett . hi mbruzek [16:12] :) [16:12] hello anyways! [16:12] We were trying to locate the origin of the new-trusty.deb that was built [16:13] sinzui, I am still seeing the wait problem with the 1.17.1 version of juju local that I have [16:16] mbruzek: have you tried building from tip? [16:16] mbruzek: perhaps i could send you a binary and you could replace /usr/bin/jujud with it and see if you still get the problem? [16:17] That would be fine, otherwise Marco showed me how to complile the go code [16:17] But others had problems getting the right jujud tool installed [16:17] mbruzek, rogpeppe: CI build binaries using the release tarball and the source package branch. They are stored at http://162.213.35.54:8080/job/prepare-new-version/lastSuccessfulBuild/artifact/ [16:18] The ones there are from r2239 according to http://162.213.35.54:8080/job/prepare-new-version/ [16:18] sinzui: great. [16:18] mbruzek: could you try using one of those and see if you can reproduce the issue? [16:19] Downloading it now, but that link appears to already be visited. [16:19] I will diff them [16:19] mbruzek: FWIW i was able to reproduce the issue from your instructions, but with the fix applied it all seemed to work [16:19] Ok [16:20] The files are different [16:20] c45da6c0387f2452a9f28a65a6577a5dbb9f585c new-trusty.deb [16:20] mbruzek@skull:~/Downloads$ sha1sum new-trusty2.deb [16:20] e4907880eefa931ed63bdb85bb3cf6eb49b315f2 new-trusty2.deb [16:21] mbruzek: let me know how you get along with the new version. i will keep my fingers crossed :-) [16:21] doing that now rogpeppe [16:22] sinzui: i wonder if it might be good to bake the current bzr revision (long version) into the binary when building it [16:22] sinzui: particularly for dev versions [16:22] sinzui: since the debs are used, would it be wise to update the versions [16:22] right, what rogpeppe said [16:23] well, this isn't even a dev version, it's an arbitrary snapshot of tip [16:24] marcoceppi, rogpeppe. We are testing what will be released. we create actual deb versions as a part of the test. The names you see are symlinks to proper names. I don't know how to include the revision in the version without corrupting the test [16:24] * sinzui has pondered using the real package names instead of the simplified names [16:25] sinzui: i wouldn't include the revision in the version [16:25] That breaks the test [16:25] sinzui: but i would try to embed it in the binary [16:25] rogpeppe, we are really testing the packaging. [16:25] sinzui: so, in other words, don't install this debs? [16:25] rather, install at your own risk [16:26] I did say it was bleeding edge. I didn't put them in a ppa [16:26] true [16:26] * marcoceppi didn't even know they existed until this morning [16:28] marcoceppi, I have had to tell a lot of people about them recently and I also need to talk about tools-url/tools-metadata-url. I think I need to post going out to all the juju emos who want to cut themselves [16:29] sinzui: CI can be very sharp ;) [16:35] rogpeppe: looks like the bug is fixed, sorry about that [16:35] thanks again! [16:36] mbruzek: did your tests succeed with the new binary? [16:36] yes it did [16:36] marcoceppi: cool [16:36] I am in a hangout with marco [16:36] ah === avoine1 is now known as avoine [16:41] marcoceppi: ping [16:45] marcoceppi (or anyone else), how do I determine which openstack version the charms are installing? [16:46] specifically, the openstack-dashboard one [16:47] the installed Horizon code is using a Django 1.4-ism alongside Django 1.5, and code goes boom :-) [16:55] teknico: juju get openstack-dashboard [16:55] teknico: that'll show your the optoins, including the openstack-release (I think that's the config option name) [16:56] pong mhall119 [16:58] marcoceppi, openstack-origin is cloud:precise-grizzly, thanks [16:58] teknico: there ya go :) [16:58] and how does the charm know which django version to install? can't find it [16:58] teknico: isn't that a dependency on the package? The pocket cloud has a django version that matches each release of openstack [16:59] ie, doesn't horizon in grizzly require django X and havana django Y, in that case django will be in the cloud archive for each version of openstack release [17:03] marcoceppi, so in this case will it be http://cloud-tools.archive.ubuntu.com/ubuntu/dists/precise-backports/ ? [17:04] teknico: depends, precise-grizzly maps to another cloud archive, not nessiarily the cloud-tools archive [17:04] where is that mapping defined? [17:06] teknico: jamespage would probably be better at illuminating it [17:06] * marcoceppi goes and looks [17:07] teknico, you are hitting a bug in the fact that juju adds the cloud-tools repository to all precise instances [17:07] cloud-tools has a newer version of django that precise-grizzly - #boom [17:08] teknico, bug 1240667 [17:08] https://bugs.launchpad.net/juju-core/+bug/1240667 [17:10] jamespage, so it's known, ok, thanks [17:11] and there's even a workaround on the bug :-) [17:11] sinzui, mramm: any chance https://bugs.launchpad.net/juju-core/+bug/1240667 could be bumped in priority [17:24] marcoceppi: since jcastro isn't around, can you do a juju update on the ubuntu engineering live call in 30 minutes? [17:27] mhall119: uh, sure [17:57] Hi Antonio...Can I interrupt for a few minutes..? [17:59] juju-deployer respects JUJU_REPOSITORY, right? [17:59] ev: it /should/ [18:00] * marcoceppi checks code [18:02] I don't see any explicit mention of it, ev [18:03] marcoceppi: as in it doesn't override it or affect juju underneath juju-deployer's ability to use it, right? [18:03] ev: I assume it doesn't affect juju underneath, but hazmat would know more about that [18:03] ev, it doesn't.. there's a bug and branch outstanding [18:04] d'oh [18:04] bug number? [18:04] ev https://bugs.launchpad.net/juju-deployer/+bug/1229390 [18:04] thanks [18:06] i've got some deployer items to merge later today, i'll add that to the list, just need to get out from under some sisyphean work === CyberJacob|Away is now known as CyberJacob === zz_mwhudson is now known as mwhudson === fcorrea__ is now known as fcorrea [20:19] marcoceppi: I got an approve from sid-nei here: https://code.launchpad.net/~davidpbritton/charms/precise/haproxy/fix-service-entries/+merge/202387, then I think he added another review. Is that normal? [20:20] dpb1: looks like it's always been assigned to charmers? I'll do a cursory review of it in a few mins and merge if there's no major issues [20:21] marcoceppi: thx === BradCrittenden is now known as bac [21:40] using juju test, is there a way to use an environment that has an existing bootstrap, and leave it up? === gary_poster is now known as gary_poster|away [22:05] dpb1: yes [22:05] dpb1: err, there was a way [22:08] dpb1: could you file a bug? [22:08] marcoceppi: ok [22:08] dpb1: I'll have that rolled out very soon [22:16] marcoceppi: where do I file it? [22:16] charm-tools [22:17] k [22:22] marcoceppi: https://bugs.launchpad.net/charm-tools/+bug/1271745 [22:41] marcoceppi, do you know if we can export a bundle from the CLI yet? [22:41] dpb1: thanks [22:42] jcastro: not off the top my head [22:43] https://bugs.launchpad.net/juju-core/+bug/1267518 [22:43] aha! [22:43] jcastro: we could pluginize one [22:44] wouldn't be too hard [23:01] WARNING no tools available, attempting to retrieve from https://streams.canonical.com/juju [23:01] ERROR bootstrap failed: cannot find bootstrap tools: XML syntax error on line 9: element

closed by [23:01] anyone see this today? [23:02] jcastro: yeah, this has been happening for a while [23:02] jcastro: what version? [23:03] 1.17, doing an --upload-tools worksaround [23:03] I was just wondering if we were tracking it somewhere [23:03] jcastro: use 1.17.1, I think it automatically uses upload tools now [23:03] jcastro: it's def known [23:03] ack [23:03] (when stream isn't found) [23:09] jcastro, i've seen that on ec2 for a while when i forget --upload-tools [23:09] running with trunk === timrc is now known as timrc-afk