=== freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === timrc is now known as timrc-afk === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away === mwhudson is now known as zz_mwhudson [09:53] marcoceppi: Hi! So with 1.17.0 I get a bit further with amulet - now jujuclient is erroring with 'state watcher was stopped' - http://paste.ubuntu.com/6766988/ If that's familiar, let me know. I'll start digging. === rogpeppe2 is now known as rogpeppe === nate_finch is now known as natefinch [13:37] noodles775: it's a know dwployer/juju bug [13:39] marcoceppi: OK, so how are you working around it when you test amulet using juju 1.17.0?? [13:40] * noodles775 checks for the bug (sorry, the two ?? there is just because of net-lag :P) [13:40] just run the rest a second time without destroying env [13:42] noodles775: let me see if i can find it [13:44] marcoceppi: oh - as in, you write your first amulet test to simply create the environment, then other files in tests/* are run with the existing already-setup env? (I'd assumed each file would be run with a freshly-bootstrapped env) [13:45] noodles775: you /can/ do that, but juju-test is designed to destroy environment before each test file [13:45] noodles775: what you can do is just run the tests again without destroying environment, IE: tests/01-amulet-test-name [13:45] it'll fail with https://bugs.launchpad.net/juju-deployer/+bug/1269519 [13:45] <_mup_> Bug #1269519: Error on allwatcher api

[13:46] then just run the test again and deployer will pick up where it left off [13:46] marcoceppi: oh? Let me try that (I'd assumed it creates a separate deployment). [13:47] noodles775: no, juju test files expect to have a clean environment, they don't actually destroy anything [13:47] noodles775: since amulet uses deployer, deployer just picks up where it left off [13:48] Yeah, I was assuming that the test files expect a clean env (and wasn't doing any destroying), but didn't realise I could re-run the test and have it pick up where it left off. Great. Thanks! [13:52] noodles775: np! Just know that's not normal behavior of the juju test plugin, the test plugin (which executes each test file) does the destroying, bootstrapping, and log archival. The tests can be written in anything (amulet, for example) [13:56] marcoceppi: can you reproduce that bug? [13:56] marcoceppi: i really don't have much to go on until i see a way to reproduce it - nothing jumps out in the code [13:56] rogpeppe: not personally, but lazypower and mbruzek both can [13:56] and noodles775 just encountered the issue as well [13:57] Hello rogpeppe which bug are we talking about [13:57] lazypower, mbruzek: it would be great if you could add the way you can reproduce the bug to the #1269519 [13:57] <_mup_> Bug #1269519: Error on allwatcher api

[13:58] rogpeppe, I just did it today, it happens when I run an amulet test on my local juju environment [13:59] 1.17.0-trusty-amd64 === gary_poster|away is now known as gary_poster [13:59] I can send you the amulet test if you like? [13:59] mbruzek: if you could post a from-scratch way that you can reproduce it to that bug, that would be marvellous, thanks! [14:00] mbruzek: better to attach it to the bug report, i think [14:00] Yes absolutely. My only concern is there is nothing special I am doing, no complicated setup. [14:01] * noodles775 can do that too, I've got a public branch. [14:01] And I have not committed my amulet test [14:01] no wait it is committed just not pushed, will update bug [14:26] rogpeppe: my repro instructions too - I'll add them to the bug. http://paste.ubuntu.com/6768177/ === jam1 is now known as jam [14:55] What is best way to layout my charm source if I want to support multiple Ubuntu release? I see most charm has precise/. But seems I need change it saucy/ if want to deploy the charm on Ubuntu 13.10 [14:56] at lest with local provider [15:01] Ming_: that's correct, typically people will create ~/charms/{precise, saucy}, then put their charm in precise, and symlink it to saucy [15:03] k. thx [15:17] Does charm must use suggested template for the shape? Our company has rule on logo/icon. I have hard time to select background color. [15:18] I mean charm icon [15:21] Ming_: yes, if you want the charm in the charm store it should follow our charm icon guidelines. Depending on the icon we may be able to make exceptions [15:21] Ming_: you should email juju@lists.ubuntu.com about that [15:23] Thanks Marco. We talked before in the workshop you and Jorge provided. [15:23] o/ awesome welcome back === CyberJacob|Away is now known as CyberJacob === CyberJacob is now known as CyberJacob|Away [16:03] marcoceppi: after calling d.configure() to change some charm configs after an initial deployment, what needs to be called to do the juju set's? (I expected d.configure() to do that, but it just sets some state in a local dict). [16:13] d.setup() i believe [16:14] * noodles775 tried that, but the expected config change didn't happen... it works fine with juju set though. I'll keep digging, thanks lazypower [16:18] noodles775: this is a bug atm [16:20] So configure does not set the values? [16:25] Can I call "relation-get" and "relation-set" in config-changed hook? [16:27] mbruzek: it does, just not after deployment [16:27] Ming_: not easily [16:28] noodles775: https://bugs.launchpad.net/amulet/+bug/1270174 [16:28] <_mup_> Bug #1270174: Post deployment commands [16:28] Ming_, Its best practice to create relational hooks to work with any data coming over the wire for the relationship. [16:30] but I cannot configure our cluster when all nodes are ready. I want to manually trigger the action through configure-changed [16:31] Hello Juju. I am encountering a problem with my local LXC environment. When I run juju status I see [16:31] agent-state-info: '(error: container "mbruzek-local-machine-1" is already cr [16:31] eated)' [16:31] mbruzek: you had a dirty stage [16:31] I recognized this as a clean up error that jorge reportd in bug 1227145 [16:31] <_mup_> Bug #1227145: Juju isn't cleaning up destroyed LXC containers

[16:32] Marco I cleaned up since my last bootstrap and I watched the script remove those files [16:32] Ming_: there is a way to do this, the relation hooks set special environment variables, so you'll need to record these for each unit then when you want to run the commands you'll need to loop through the available units on the relation and set the -r flag for relation-get/set [16:33] Ming_: I don't know off the top of my head and I'm not at my main computer to get you exact details, you may want to mail juju@lists.ubuntu.com or ask on http://askubuntu.com/ with the tag juju and Ican get back to you (or someone else) with more details [16:33] marcoceppi, you are right I remembered to run the script [16:33] Sure. thx === rogpeppe1 is now known as rogpeppe [16:34] But I see they were directories rather than files [16:34] mbruzek: yes, they're the contents of the LXC container [16:35] my scritpt tried to rm those rather than rmdir or rm -rf [16:35] Thanks [16:35] fixing that [16:51] noodles775: i didn't get too far with your instructions - i get this error when trying to run 00-single-node-install: http://paste.ubuntu.com/6768907/ [16:51] noodles775: is "requests" a python module that i should apt-get from somewhere? [16:51] mbruzek: ^ [16:52] rogpeppe, sudo apt-get install python-requests [16:52] lazypower: ta! [16:53] rogpeppe, I don't have import requests in my code [16:53] Do I ? [16:53] mbruzek: the third line in 00-single-node-install ? [16:53] 00-single-node-install is not my code [16:54] Not the one I posted. basic_deploy_test.py [16:54] That is the one in the tests directory [16:54] mbruzek: I think it's a bad dep on the amulet package [16:54] OK [16:55] since amulet uses requests [16:55] yeah I got it [16:56] ha, it barfs on my environments.yaml [16:56] Is there a way to broadcast an event to every node? change configuration variable persist the change so is not desired in this case [16:57] HI Marco, I sent the email to juju@lists.ubunut.com [16:57] * rogpeppe hates yaml, once more [16:58] rogpeppe: when in doubt, just write json :) [16:59] mgz: i do, and i did [16:59] mgz: but the python yaml parser barfed on it [16:59] mgz: it didn't like my tab characters [16:59] mgz: perfectly valid json :-) [17:00] mbruzek: i was trying to follow Michael Nelson's (noodles775?) instructions, since they seemed a little more specific, but it's not working for me; i'll try yours [17:02] mbruzek: should i get juju-deployer via apt-get or branching a repo? [17:03] I am in a meeting, I didn't do anything to juju-deployer [17:04] I used apt-get to get juju-deployer [17:04] * mbruzek is in a meeting [17:07] mbruzek: thanks [17:08] mbruzek, noodles775: i got a traceback from the code, but the issue itself doesn't seem to have reproduced (i don't see the "state watcher was stopped" error mentioned in the bug description and logs) [17:15] ah, sorted that out [17:19] mbruzek, noodles775: reproduced! thanks v much for the test case [17:19] great [18:42] mbruzek, noodles775: found the bug, i'm pretty sure [18:42] Great [18:42] marcoceppi: ^ [18:42] rogpeppe: excellent!!!!! [18:43] marcoceppi: the issue is that if a client connection goes three minutes without sending a Ping, it gets terminated [18:43] i'm not sure that's actually what we should do for a client connection, but i'm pretty sure that's the culprit [18:47] rogpeppe: is it something we can patch in on jujuclient python lob? to juat send a ping [18:47] marcoceppi: probably [18:48] marcoceppi: except that the python library doesn't allow concurrent requests, which is a bit of a problem [18:48] marcoceppi: so no, i think it might not be possible to fix without fixing that client lib [18:50] marcoceppi: we could probably just turn off the ping requirement for non-agents. [18:50] marcoceppi: it's really there so that we know when agents are still alive [18:50] rogpeppe: thatd be great [18:51] marcoceppi: i objected to this feature when it was implemented originally FWIW [18:51] * rogpeppe likes naivity [19:07] Hello Juju. I am trying to use juju 1.17.0-trusty-amd64 with trusty and a local lxc environment. [19:07] I am aware of the clean up commands that Jorge put on askubuntu [19:08] When I bootstrap a clean local environment it comes up ok, but when I try the first deploy I see the following in my juju status [19:08] agent-state-info: '(error: symlink /var/lib/lxc/mbruzek-local-machine-1/co [19:08] nfig [19:08] /etc/lxc/auto/mbruzek-local-machine-1.conf: no such file or directory)' [19:08] I can paste bin the whole thing, if that helps [19:10] I am certain the /var/lib/lxc/mbruzek-local-machine-1 directory was cleaned up from the script [19:10] http://paste.ubuntu.com/6769679/ <- Whole juju status [19:10] Does anyone on the juju team have an idea? [19:10] of what is wrong [19:12] It looks similar to Jorge's bug 1227145 [19:12] <_mup_> Bug #1227145: Juju isn't cleaning up destroyed LXC containers

[19:12] But I used the commands he has to clean up after a destroy-environment and can not get anything to deploy on my local env [19:14] That bug is linked to 1238541 [19:16] mbruzek: yea, I have the same issue. I assumed it was trusty/lxc bits getting sync. Looking at that bug looks ilke it's set for 1.17.1 [19:16] is there any way I can get that version? [19:16] sinzui: what's the next release timeframe that might include that? [19:16] Can I add the dev repository ? [19:17] rick_h_, maybe next week. [19:18] What package is it in so I can watch for it? juju-core? [19:18] mbruzek, you can add the dev repo. 1.17.x does not work with 1.16.x and it is unstable; it is not suitable for production use yet [19:18] mbruzek, that's right, juju-core [19:19] I am trying to make progress on amulet tests for the eco team [19:19] mbruzek: bring up a non-trusty venv? [19:19] Right will do that. [19:24] Thanks for clarification rick_h_ and sinzui [19:24] I will look for this next week [19:24] and work on a different env in the mean time [19:25] mbruzek, I can provide precise, saucy, and trusty debs that we build for testing [19:26] mbruzek, http://162.213.35.54:8080/job/prepare-new-version/ always shows what we built for testing [19:26] That is great now I know where to look. [19:32] marcoceppi, this one is all you: http://askubuntu.com/questions/407010/413-request-entity-too-large-nginx-1-1-19 [19:44] mbruzek, marcoceppi: i've proposed a fix: https://codereview.appspot.com/53810045 [21:01] the mysql charm is not deployable on newer ubuntu versions. when can we expected trusty charms to start showing up? [21:55] adam_g, probably in the next few weeks === medberry is now known as med_ === gary_poster is now known as gary_poster|away [23:21] does anyone know what the tools-url for aws is off hand? [23:22] * arosales is working around https://bugs.launchpad.net/juju-core/+bug/1254401 [23:22] <_mup_> Bug #1254401: error reading from streams.canonical.com

[23:22] I thought it was tools-url: http://juju-dist.s3.amazonaws.com/tools [23:47] arosales: try http://juju-dist.s3.amazonaws.com/ [23:47] without the /tools at the end [23:48] wallyworld_, thanks I did get aws bootstrapped with tools-url: https://juju-dist.s3.amazonaws.com/tools [23:48] I needed to remove .juju/environments/aws.jenv first though [23:48] ok === scuttlemonkey_ is now known as scuttlemonkey