[00:08] marcoceppi, lazyPower: the latest merge into python-django charm, is that fully backwardly compatible? [00:08] as in, as a user of the charm, there should be no change>? [00:08] thumper: link? [00:09] lazyPower: didn't marcoceppi update it? [00:09] lazyPower: in an email to the juju list today [00:09] looking [00:09] https://code.launchpad.net/~charmers/charms/trusty/python-django/trunk [00:09] last commit 19 hours ago [00:10] thumper: no serious change to config - you should be fine. I would recommend you simulate a deploy in a staging env before you do this on anything you have in production [00:11] it changed some of the defaults, but theory states you already have these values set on your charms in the wild. so again, looks g2g at first glance [00:11] * thumper twitches [00:11] * thumper grabs the code and proposes a fix [00:11] if you're relying on unit-config - it will block you from upgrading. [00:12] as that config option was removed, so i stand corrected [00:13] lazyPower: how do I run the tests on this thing? [00:13] thumper: make a virtualenv, pip install bundletester into that virtualenv and just run bundletester from the charm root. [00:13] ti will execute against your currently active juju env [00:15] marcoceppi: added an inline diff comment on that python-django merge that thumper is talking about - this merge violates policy [00:16] lazyPower: it doesn't anymore, juju handles this now as well as removing relations [00:16] marcoceppi: our policy docs clearly state that its violated [00:17] included for easy ref. [00:17] it has to be maintained until the next series release [00:17] so if this was going to vivid, sure [00:17] but not according to policy today [00:17] s/vivid/vivid or utopic/ [00:17] or even trusty [00:18] unless im' mis-reading policy [00:18] which is possible [00:39] lazyPower: my first charm patch https://code.launchpad.net/~thumper/charms/precise/python-django/tweaks/+merge/245807 [00:41] thumper: no tests to validate? :( [00:41] lazyPower: no behaviour has changed [00:41] so all tests should be the same, no? [00:42] I've not added any functionality, just pulled four copies of code into one place [00:42] ah i see what you did here [00:46] tvansteenburgh: oh man, we got lazr authentication pulled in pip proper now? no more crazyness with --alow-unverified and --allow-unsigned? Very nice! [00:50] thumper: something is hozed in my env, waiting on automated tests [00:50] lazyPower: no rush [01:21] noodles785: hey this is cool, the /etc/ansible/host_vars/localhost - i had no idea we were storing all this data - makes it kind of handy to access via current_relation['var']. well played sir. [01:29] lazyPower, arosales: I do object to the auto-merging of thos [01:30] lazyPower, arosales: after working with Matt with some of them, not all of them are acceptable as-is. Some charms will not be satisfied with an autogen, since they force you to set an specific key, or maybe need an specific setup that's specified in the readme and not the metadata [01:30] lazyPower, arosales: so, yes, I would test *all* of them and if tests pass then merge it, as I've been doing lately [01:31] jose: seems like something as simple as setting a key could be updated in the test during the merge [01:31] are there other scenarios? [01:32] jose defaults for a charm ~should~ work correct? [01:32] lazyPower: needing to *create* the key somewhere else, and as I said, specific deployment [01:32] arosales: not always [01:33] jose: thats policy. sane defaults. the charm should deploy without any user intervention, and if it requires user intervention - it must be clearly outlined in teh readme. which means we can set it. [01:33] e.g. the newrelic charm, I had to create an account and add my key to the tests in order for them to pass, otherwise I would get a clear failure [01:33] unless its something like pagekite where it requires an account - and thats iffy at best putting test credentials in a charm. [01:33] smells of abuse [01:33] pagekite is not in the store yet :) [01:33] its a valid point but I think we should take that as the exception and not the rule to the pending MPs [01:34] jose: indeed - but it was an example case. [01:34] jose: do you see any of the charms currently in the queue? [01:34] if you get them all in and then start to find failures, warned you [01:35] arosales: I did, yes. newrelic-php and another couple I saw before the holiday break [01:35] jose: also one action lazyPower was going to take is to file a bug against the charm that is failing [01:35] jose: if you could add a comment to those MPs that would be greatly appreciated [01:35] I am curently going through them too. [01:35] yep, I've been working on newrelic-php and trying to check how can I fix it since it's a bit weird [01:35] ie https://code.launchpad.net/~marcoceppi/charms/precise/seafile/tests/+merge/240964 [01:36] I was going to propose a fix [01:36] seafile... I believe there is an incoming MP to fix the non-deployment? [01:36] even for the point you outlined I think it is good to accept these tests [01:36] sure [01:36] it brings up points and possible bugs that would not have been noticed had the autogen charm test not been there [01:36] so I am commenting on the MPs. [01:37] I'll leave it up to the charmers team to make the final decision. [01:37] thus far 4 +1 to accept and your -1 to nack [01:37] if they're going to be tested at the end, I'd say run the test and if there's an error *because of the test* then nack [01:37] take it as a 0, not as a -1 [01:38] half/half in with the proposal [01:39] we lose the unit logs with auto charm testing [01:39] for the ones I can tell if the test is failing though we should note that [01:39] very good point jose [01:39] arosales: btw, that seafile error, if the queue follows its natural flow the fix should land before the test [01:39] ah very nice [01:40] I am going to get some dinner, but I'll return later tonight and keep commeting on these outstanding test MPs [01:40] cool :) [01:40] and looking for the ones that have charm tests that may need updating [01:40] also, when I run bundletester over here and something fails, everything is kept as is [01:40] jose: thanks for your reply on the matter [01:40] sure. === kadams54 is now known as kadams54-away [01:41] enjoy your dinner [01:41] arosales: i'm getting close to being at a point i can transition to helping with the queue, in a furious debug session with racing config between two hosts [01:41] jose: thanks [01:41] but this is looking awesome and should give lamont a good basis to look at for sep. of concerns on a host vs its subordinate [01:42] lazyPower: I've gone back to the queue after a 'discussion' with my ISP and my connection being off [01:42] jose: are you getting throttled already? [01:42] lazyPower: I was. couldn [01:42] couldn't stay online for more than 5mins or it'd kick meoff [01:43] thats the pitts, i know it bothers me when comcast gets nosey in my bidniss and throttles me during the day because i'm pushing volumes of data related to builds [01:43] After 3 months of back and forth i gave up and they won, i get throttled from 10am => 5pm [01:46] jose: however - if you get to those MP's before me - just make sure you file bugs against the ones with failing tests you ack - so we have a point of reference when the problem surfaced, and how long we have to make it correct. The mail to the list of status will serve as the first step in its trajectory [01:46] not getting this... are you asking me to merge all of them? [01:48] jose: there's a 20 minute scrollback worth of conversation about it. if the test fails, and its not an edge case merge that requires crednetials - yes. [01:48] *credentials [01:48] and filing of a bug against the charm that it has failing tests, tagged audit. [01:49] I'll leave that to you. [02:17] marcoceppi: ping === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [03:32] hey thumper, you still kickin around? [03:32] yeah, in a call now [03:34] thumper: when you get a moment - i'm attempting to send relationship data out of a relationship context - i have a dependent service that needs to update config based on values being passed from a different context, and i have no way of triggering that manually that i'm aware of , but i have this bit of shell in my head that i should be able to do this... [03:34] https://gist.github.com/chuckbutler/443777748984e3673925 [03:34] using relation-set -r docker:8 foo=bar - i thought i could push data out of band and trigger the relationship-changed hook on that relation id, no? [04:09] lazyPower: sorry, not sure [04:09] ill sync up with marcoceppi tomorrow - thanks for taking a look thumper [04:09] kk [04:09] nigth [07:01] Is there any way to reset the positioning of all the icons in juju-gui? It's totally mental, and getting lots of NaNs [07:52] X-Rob: Yeah, i ran into that myself [07:52] let me find the snippet for you [07:53] X-Rob: are you familiar with the browser console and how to get to it? [08:21] lazyPower: extremely [08:22] X-Rob: this will reset every last charm you have in your gui (up to 100 services) to teh same X/Y [08:22] https://gist.github.com/chuckbutler/edf2efe5a426b62b1e1b [08:23] shoudl get rid of those nasty NaN errors as well - this happens during a botched upgrade of juju-gui releases as i understand it. Its really rare though - so if this doesn't persist - reach out to hatch and he can get you locked down. there was some additional steps I had to take in teh end to fully resolve it [08:24] but that might fix you up with no additional work required [09:05] I actually gave up, lazyPower. 'juju destroy-environment' and I'll just start again === rcj is now known as Guest49344 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === Guest49344 is now known as rcj === rcj is now known as Guest58831 === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [14:49] wwitzel3: know how to fix this? http://pastebin.ubuntu.com/9693080/ [14:50] (or anyone else) [14:57] tvansteenburgh: looking [15:00] gnuoy, https://code.launchpad.net/~james-page/charm-helpers/kilo-enable/+merge/245870 [15:01] tvansteenburgh: can you pastebin the output of: go env [15:03] wwitzel3: http://pastebin.ubuntu.com/9693183/ [15:06] tvansteenburgh: going in to my standup, I would try deleting that pkg folder and attempting re go get [15:06] wwitzel3: k, thanks [15:15] marcoceppi: i have a test that i kicked off from RevQ that finished, but RevQ status didn't get updated: http://juju-ci.vapour.ws:8080/job/charm-bundle-test/10878/console [15:16] marcoceppi: it's http://review.juju.solutions/review/1893 in the RevQ [15:23] tvansteenburgh: all test results are giving a 404 [15:23] Did the URL change? [15:25] marcoceppi: example? [15:25] actually, it's not getting the URL back at all [15:25] tvansteenburgh: did the jenkins test change? [15:26] curl http://review.juju.solutions/review/1893/ctb_callback/344 --data-urlencode status=PASS --data-urlencode result_url=http://reports.vapour.ws/charm-tests/charm-bundle-test-10878-results [15:26] tvansteenburgh: this is in the database: http://paste.ubuntu.com/9693288/ it's got the callback, but hte url wasn't recorded [15:27] yeah, it's still looking for that. Let me add some debug information in [15:27] well that is weird? there were many yesterday that *did* work [15:28] omg [15:30] weird === roadmr is now known as roadmr_afk [15:35] tvansteenburgh: this is why [15:35] tvansteenburgh: http://reports.vapour.ws/charm-tests/charm-bundle-test-10878-results/json [15:35] that result url doesn't work [15:36] hey marcoceppi, have you seen an error where Amulet tries to relate yet-to-be-deployed services? [15:37] jose: that should never happen unless the d.add for the service is executed after the initial d.setup [15:37] jose: could you be more explicit, like witha test file and the output of the test run? [15:37] marcoceppi: sure, I have the test file but not the output (that was yesterday night), I'll run again [15:37] sec for link [15:38] https://code.launchpad.net/~mbruzek/charms/precise/oops-tools/tests/+merge/240997 to be specific [15:39] what did I do? [15:40] mbruzek: autogen tests are throwing an unexpected amulet error, sorry for the highlight :) [15:41] jose: that is fine, probably due to bad test author [15:41] (me) [15:41] well, this time Amulet is to blame :P [15:41] but *only for this time* [15:42] Have you *met* Marco? He is never wrong! [15:42] I have [15:43] I believe that was... 2012 [15:43] jose marcoceppi the reason that test is failing is because I misspelled postgresql [15:44] jose postresql [15:44] mbruzek: oooh, good catch! [15:44] why did the autogen misspell? [15:44] Autogen didn't do that, that was a *human* error [15:44] fixing now [15:45] * marcoceppi is always right, yet again! ;) [15:49] :P [15:50] tvansteenburgh: did that resolve your issue? [15:53] wwitzel3: which dir were you suggesting i delete? [16:07] tvansteenburgh: GOPATH/pkg/linux_amd64 folder [16:07] tvansteenburgh: just delete the whole thing and retry [16:10] when I try to run tests for a charm I get an import error due to yaml; however, yaml is installed === roadmr_afk is now known as roadmr [16:10] is hte python path getting munged by bundletester in some way? I haven't used it before now [16:12] skay please paste errer [16:12] error [16:12] wwitzel3: what is your GOROOT? [16:13] tvansteenburgh: mine is /home/wwitzel3/opt/go .. I built go from source [16:14] tvansteenburgh: http://paste.ubuntu.com/9693519/ [16:15] tvansteenburgh: I imported it from a shell for a sanity check http://paste.ubuntu.com/9693523/ [16:17] skay: are the tests using py3 perhaps? [16:17] facepalm [16:17] tvansteenburgh: yes, thanks for the tip :) [16:17] forgot to check [16:18] np :) [16:19] tvansteenburgh: what's the common practice -- do people usually have a readme that explains how to run the tests for the charm that is being worked on, and have a testing requirements.txt file for people to use? [16:19] that's something I have when I'm creating things, but I'm making a small change for the first time to a charm, and I've never gonet hrough the process before [16:19] skay: usually a Makefile [16:20] with a test target [16:20] make test is most common for unit teste [16:20] tests [16:20] oh, is that not this? [16:20] oh I see. there's a makefile with the test target commented out [16:20] no, i'm just slow [16:21] I wasn't sure what to do, so I gave up and decided to see what commands jenkins would call so I could mimic it [16:21] I saw that it was running a bundletester command and tried to use that [16:22] yeah that is what you should do [16:22] so, for this charm, the test target is commented out. there is an integration-test target, and there's nothing that creates a virtualenv to install the testing dependencies and such [16:22] is it common practice for people to set all that up using some other method? [16:23] or should I plan to edit the Makefile to do what I think is probably good practice? [16:23] the latter [16:23] bundletester will call `make test` [16:23] and execute anything in tests/ [16:24] so just make sure that your test target has a prereq that sets up deps [16:24] tvansteenburgh: is there an exemplar project with a makefile and such that follow best practices? [16:25] there are several, let me find one... [16:25] I'd like not to make newbie mistakes, though I know it is inevitable [16:27] I am thinking about a guide: So you want to contribute to an existing charm! here's what you do [16:28] and then later: So you want to make a charm that is easy for new contributors to hack on! here's what you do [16:28] skay: trusty/haproxy [16:28] look at test, .venv, and lint targets [16:30] that's standard setup [16:30] then put amulet tests in tests/ [16:30] tvansteenburgh: thanks! checking my assumptions -- bundletester will kick off by creating a container or vm and then run make test for me? [16:31] I want to make sure I'm not clobbering my system [16:31] bundletester does not create a container yet, although it is planned [16:32] hence the .venv target [16:32] tvansteenburgh: okay, so I wouldn't want to do .venv that way for my system, since I install virtualenv from pip and not the apt package. [16:32] but I would guess standard practice must be to use system dependencies where they exist? [16:33] thus I should probably make a container when I do this [16:34] tvansteenburgh: thanks for the help. I am grateful for it! [16:34] I am also very happy that people have done a lot of work in the review queue [16:34] sure thing, any time :) [16:36] wwitzel3: http://pastebin.ubuntu.com/9693596/ [16:37] wwitzel3: should i need sudo for that? [16:41] tvansteenburgh: umm shouldn't since it is in your home, you might if you attempted to sudo go get anything. [16:42] tvansteenburgh: /home/tvansteenburgh/src/go/pkg/linux_amd64/ that is the folder you want to delete [16:43] i did, see paste [16:43] the place it's installing is not in my home [16:44] it's under /usr/lib/go [16:44] i tried unsetting GOROOT but it still used that path === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [17:03] jamespage, Ian Rossi here, long time no see. I was wondering if you could help direct me to the right person at Canonical that can delete an ubuntu pastebin [17:17] can anyone recommend a dirt-simple charm that exposes a website relation? like just a hello-world page… so far i'm just finding things like wordpress that are too complex for my simple bug repro'ing use === kadams54 is now known as kadams54-away === roadmr is now known as roadmr_afk === wwitzel3_ is now known as wwitzel3 === roadmr_afk is now known as roadmr [18:10] hey cory_fu, have a min? [18:11] Sure [18:12] cory_fu: I see you opened an MP against a branch I already merged, mind opening it against the parent branch? [18:12] https://code.launchpad.net/~johnsca/charms/precise/couchbase/fix-install/+merge/243575 [18:14] jose: I did mention that MP on the original MP. I had hoped that mbruzek would have a chance to merge my fix into his branch, or that the person merging the original MP upstream would include mine to fix the tests. [18:15] cory_fu: that's why I'm asking if I you can open an MP over there, so I can take a look in a while [18:15] jose: That said, sure I can resubmit against the parent. :) [18:15] Sure [18:15] \o/ [18:16] thank you! [18:17] jose: https://code.launchpad.net/~johnsca/charms/precise/couchbase/fix-install/+merge/245892 [18:17] Thanks for taking a look at those [18:17] yep, got the email [18:17] will look after I'm done with a couple more tests [18:18] I wish we had a better or more defined procedure for submitting fixes against other people's MPs [18:18] jose: I'm open to ideas for the future. :) [18:19] The review process could certainly use some stream-lining [18:19] yeah, my fault over there - saw you reported the bug but didn't see the other branch [18:20] Meh. MPs against MPs seem prone to getting missed like that. I don't think it's a great method, but it was all I could come up with at the time. [18:21] if I do an MP against an MP I tend to contact the owner of the branch to see if I can get it merged before it's reviewed [18:21] Hi guys. When I'm doing amulet tests, how can I print to stdout? Plain print() produces no output. [18:21] take 2: can anyone recommend a dirt-simple charm that exposes a website relation? like just a hello-world page [18:22] jose: Yeah, I think I did mention it to mbruzek at the time, but he's a busy guy and he added tests to a lot of charms. :) [18:23] noise][: the pubphoto charm does a good job over there [18:24] Mmike: are you running that test individually? if so, a print('Hello!') should write Hello! on the console [18:24] Mmike: Well, I would expect that to depend on your test runner, but if you're using print to debug, I would recommend trying out pdb (or ipdb, if you want to be fancy), since it gives you an interactive session that is more flexible than just prints [18:25] pudb is actually the neatest I found :) it's ncurses based [18:25] Interesting. I'll have to check that out. :) [18:25] but, during the test I want to print stuff on stdout like 'creating habooka', 'testing against habooka', and stuff like that [18:25] jose: thx [18:25] jose, I do: juju test 02_my_habooka_test.py [18:25] and print('mario is super!') prints me nothing [18:26] Mmike: try running ./02_my_habooka_test.py [18:27] jose, when I do so then jujuj-deployer complains about not being able to find condiguration in /tmp/amulet-blahblah... [19:13] Mmike: if you're using the juju test runner, i believe it traps output unless you pass teh verbose flag [19:23] lazyPower, tried that , no dice. [19:24] dunno what's the issue, I see that amulet has raise_status method which uses print too, but using it also produces no output [19:24] Mmike: somethings trapping your stdout - if you run the test directly you say juju-deployer raises errors? [19:26] yup, I'm assuming 'juju test' creates deployer config or something... [19:26] its coming from amulet, amulet wraps juju-deployer [19:26] what version of amulet are you running? [19:26] 1.9.0 [19:27] with juju 1.21-beta4 [19:27] tvansteenburgh: any thoughts on Mmike's issue above? amulet shouldn't be crying wolf about deployer on latest packaging [19:27] \quit [19:29] I created a simple test script which just does print('wonka!') [19:29] and when I juju test it, nothing is printed [19:30] Mmike: tvan is the current maintainer of our testing tools - give him a bit to come aroudn and he should be able to get you lined out. [19:30] but you're right, the fact you're getting no output and directly running the tests with exceptions bubbling up about juju-deployer smells of a local configuration problem [19:30] ack, no rush [19:31] maybe it's because i'm using juju 1.21, But I can't have my lxcs in /var/lib/lxc, and with juju 1.20 I can't use local envs when I tell lxcs NOT to be placed in /var/lib/lxc [19:31] lazyPower: not sure if you saw it but I added easy repro steps for that HAProxy relation bug, still makes no sense though [19:32] noise][: i actually haven't been tracking it as closely as i should be - a bit scattered since i got back from break. I can give it a look later today when i context switch to the queue [19:33] lazyPower: cool, no rush since it's easy to avoid, but damn if it isn't a weird one [19:33] yeah, enabling debug changes behavior of the charm - i dont like that at all [19:38] Mmike: try using bundletester instead; pip install bundletester; then run it in your charm dir [19:44] tvansteenburgh, is bundletester replacement for amulet? [19:44] no, for juju test [19:45] amulet is a testing library, bundletester is a test runner === hasp-air is now known as hasp-air[afk] [19:51] oh, I see [19:51] neat [19:56] thumper: oh buddy oh pal [19:56] o/ rick_h_ [19:56] thumper: frankban asked me to poke you about his branch and some 'naming of things' questions he had when you showed up [19:56] so /me pokes you about all that [19:56] kk === roadmr is now known as roadmr_afk [20:18] marcoceppi: ping [20:18] o/ jose [20:18] marcoceppi: hey, I was checking on one of your MPs but turns out it has conflicts [20:19] oh, which? [20:19] https://code.launchpad.net/~marcoceppi/charms/precise/thinkup/tests/+merge/240894 [20:19] ^ [20:19] jose: I'll rectify [20:20] thank you :) [20:20] please let me know once it's done so I can re-verify the merge [20:41] lazyPower, https://github.com/juju-solutions/juju-solutions.github.io/pull/20 [20:48] jcastro: missing the directive in _config.yml [20:48] jcastro: commented === kadams54 is now known as kadams54-away [21:00] lazyPower, done, I fixed it just forgot to push, thanks === roadmr_afk is now known as roadmr [21:20] jcastro: just make sure you frontload your page with a permalink to get the proper page location [21:20] jcastro: eg: permalink: /containers.html [21:21] ack === Guest58831 is now known as rcj === rcj is now known as Guest69248 [21:36] lazyPower, is layout: post fine too? [21:37] You'll inherit stuff from teh blog post layout. I can build another layout tonight if you need one. [21:37] but to get you moving - yeah thats fine [21:37] nah, I think we're fine for now [21:37] the idea is for this content to be moved to the real site anyway [21:37] so we don't need to spend a ton of time making it pretty [21:39] Fair enough === hasp-air[afk] is now known as hasp-air === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away