[00:02] jose: ping - you around? [00:04] jose: Re: https://code.launchpad.net/~jose/charms/precise/quassel-core/add-tests/+merge/246001 - I'm not familiar with amulet, so I have no way of gauging what the MP does. [00:04] jose: It all seems reasonable, but perhaps someone more skilled would be better to review it? I made the charm as a way of learning juju. [00:21] blahdeblah: this is a basic Amulet test, used to perform functional/integration tests [00:21] going forward we're going to require charms to have tests in order to continue being in the promoted/promulgated store (this doesn't effect personal branches) [00:22] blahdeblah: to help get authors jumps started with testing we've been adding these basic/simple amulet tests to give us a good idea of the charms that work and just deploy [00:22] marcoceppi_: Cool - if you're happy to +1 it, I can take care of merging [00:28] blahdeblah: it's fine, but comes wiht some implications [00:29] marcoceppi_: namely? [00:30] blahdeblah: well, you're charm is in precise, so the implications don't actually apply to you - at least not now [00:30] All of my recent testing was on trusty; should be listed in there as well [00:30] blahdeblah: but for charms in trusty, if authors don't respond with updated/better implemented tests charms may be unpromulgated/removed from the namespace [00:30] blahdeblah: ah, well, then this will apply to the trusty charm [00:31] tests allow us to validate and verify that charms work, as the author indends, on different versions of deployments (trusty, vivid, other linux) as well as different architectures (x86_64, ARM, Power8, etc) [00:31] blahdeblah: with tests, we will are automatically testing all charms in trusty and precise, to validate they do and help provide users with feedback on charms that will work in their deployments [00:32] I expect all of that will be pretty straightforward, since it's such a simple charm (which is why I chose it) [00:32] to do this we need authors to help flesh out the tests a bit, I use quassel all the time so for you, it'd would be adding things in the test that check for "after quassel is setup, does it actually listen on the proper port" or "is the quassel-core process running" [00:33] blahdeblah: totally [00:33] blahdeblah: we'll be publishing a few videos and blog posts to help bridge the gap between "I'm an author" and "what is amulet" [00:33] we have a lot available already, but they're pretty long and unweildy to consume [00:33] Yeah - video is definitely not my preferred learning format [00:33] blahdeblah: if you're not already, you may want to subscribe to our mailing list, lists@juju.ubuntu.com to keep up to date [00:34] Is there a lower-volume announce list? [00:36] blahdeblah: no, it's just that list at the moment, though traffic isn't/shouldnt' be too TOO high [00:37] marcoceppi_: Any other way to keep up with announcements? Let's just say I'm allergic to new mailing list subscriptions. ;-) [00:38] blahdeblah: not really :\ I'll propose a new juju-announce list tonight though, see if that takes hold [00:41] marcoceppi_: w.r.t. this MP, any suggested next steps? [00:42] blahdeblah: you can +1 it and it'll get it's way in to the store shortly [03:36] what's mean [03:36] ERROR there was an issue examining the environment [03:47] blahdeblah: heyo. sorry for not responding, was afk. If you're still around, I can go through and explain what they do step by step, for sure. [05:05] jose: No problems - did you see the backscroll of my chat with marcoceppi_ ? [05:05] blahdeblah: yeah, I did :) [05:06] It all seems pretty sensible to me, but because of my lack of expertise, I've requested marcoceppi_ to review it. [05:06] we do have some docs on Amulet, let me grab the link [05:07] https://juju.ubuntu.com/docs/tools-amulet.html [05:07] I'm in the middle of a stack deploy right now, so regardless, I won't have time to dig into it until the beginning of next week. [05:07] np [05:07] I'll be taking another look at the charm soon, so stay tuned! === zz_CyberJacob is now known as CyberJacob === CyberJacob is now known as zz_CyberJacob [11:11] my jujud is only listening on IPv6 for some reason. Anyone seen anything like that? [11:21] mthaddon: ::1 or some other address? [11:22] jrwren: tcp6 0 0 :::17070 :::* LISTEN 10231/jujud [11:22] mthaddon: i'm pretty sure that jujud just does a default listen on tcp with :17070 [11:23] rogpeppe: yeah, so that's why I'm wondering why it isn't doing that for me :/ [11:23] mthaddon: if you run some other local daemon, listening on any address, do you get similar behaviour? [11:29] sorry, distracted by a ping in another channel, will try to test soon [11:30] mthaddon: for example, if you run netcat -l 12345, then netstat -n -l | grep 1234, what do you see? [11:32] tcp 0 0 0.0.0.0:12345 0.0.0.0:* LISTEN [11:40] mthaddon: hmm, interesting [11:46] Hello Folks, This document on HA openstack deployments seems old. https://wiki.ubuntu.com/ServerTeam/OpenStackHA [11:46] Does anyone have any pointer where can i find the latest docs on OpenStack HA [11:47] Precisely, On Deploying HA OpenStack with Juju. [11:50] mthaddon: can you compile a small Go program and run it on one of your machines? [11:50] rogpeppe: er, I can if you can point me at instructions as to how :) [11:51] mthaddon: sudo apt-get install golang-dev [11:51] rogpeppe: where would I get that from on trusty? [11:52] so squid does a combined listen on its ports, and it shows up as only tcp6 in netstat but you can reach it on ipv4 [11:52] I'd have thought this was the same [11:52] mthaddon: oops, sorry, wrong package. [11:52] mthaddon: golang-go [11:52] mthaddon: or actually [11:52] mthaddon: just apt-get install golang [11:52] mthaddon: with sudo [11:53] Spads: I assumed I couldn't contact it because "juju status --debug" was timing out - let me try from the machine itself to check it's not a connectivity issue [11:53] yeah just telent and see what you get [11:54] ugh, sorry for the noise [11:54] heh [11:54] I only knwo this because I hit it only yesterday with squid :) [11:54] so it's working on both 127.0.0.1 and the external IP from the instance itself, so it must be a connectivity issue. I'll dig a bit further [11:55] and of course, now my juju status is working fine. Double sorry for the noise [13:38] hello everyone i have an error when i write on terminal linux bootstrap ERROR there was an issue examining the environment [14:04] i have an issue with juju bootstrap [14:04] anyone can help me [14:25] o/ alexis7 [14:25] what is your issue? [14:26] when i write juju bootstrap on terminal linux [14:27] for example : ERROR there was an issue examining the environment: open /home/john/.juju/environments.yaml: no such file or directory [14:28] alexis7: have you run `juju init` yet in the terminal? [14:32] appears for example A boilerplate environment configuration file has been written to /home/john/.juju/environments.yaml. [14:33] Edit the file to configure your juju environment and run bootstrap. === nottrobin_ is now known as nottrobin [15:40] https://code.launchpad.net/~evarlast/charms/trusty/elasticsearch/add-version-config/+merge/237916 [15:41] lazyPower, ^ === roadmr is now known as roadmr_afk [15:44] whit: like the comment re: backporting changes in ~charmers - good point. I'll mark that as a talk point for the charmers meeting this week. [16:12] hazmat: got a new comment on the Juju DO plugin over on the DO community page, *and* the user said they answered themselves with the docs. hi5 === roadmr_afk is now known as roadmr [16:33] which is the error for example: [16:33] ERROR there was an issue examining the environment: open /home/john/.juju/environments.yaml: no such file or directory [16:35] alexis7: Seems like you need to run `juju generate-config` to create the environments.yaml - I suggest starting with the documentation here: https://jujucharms.com/docs/ [16:47] yo tvansteenburgh [16:47] yo [16:49] hey, i was taking a look at this MP - https://code.launchpad.net/~jacekn/charms/trusty/squid-reverseproxy/squid-reverseproxy-nrpe-fix/+merge/245312 - and it seems liek an unrelated failure is causing the MP to not be merged thanks to some CI schenanigans. [16:49] yeah [16:49] looks like we just need to sneak in an update to the make test target according to the feedback? [16:49] yes [16:49] I dont necessarily want to sneak things in however - would you be allright with me filing a bug and testing the MP based on the merit of the changes for now? [16:50] i was planning to do that but have not gotten to it [16:50] i hear ya :) its in "the stack" [16:50] lazyPower: yes, please do, that would be great [16:50] cheers dude [16:51] ta! [16:51] solid mbruzek beat me to it : https://bugs.launchpad.net/charms/+source/squid-reverseproxy/+bug/1401323 [16:51] Bug #1401323: The squid-reverseproxy charm fails automated testing

=== kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [17:21] hey cory_fu [17:21] on a scale of 1 to 10, how well would you consider DHX documented? [17:21] Hey [17:23] Well, `juju dhx --help` is pretty complete, but doesn't give a good description of why you would want to use it. But then there's the blog post. *shrug* Why? [17:23] we have a card to better document debugging [17:25] Ah. It could definitely use some better narrative documentation (what to use it for, why, and how in a more example oriented way). The blog post is a decent start, but if it's going to be recommended, then it should be in the docs. [17:25] jcastro: dhx is one part of debugging, it's not a complete solution for debugging, but makes it really really easy [17:25] Really, dhx just augments the existing debug-hooks [17:25] yeah so have we decided that DHX is going to be the one true way forward? [17:25] basically, should it be in the docs is my question. [17:25] yes [17:26] but [17:26] so should vanilla debug-hooks [17:26] Honestly, I'd prefer to see some of the features make their way into core, eventually [17:26] cory_fu: that would be the best outcome [17:26] cory_fu: we should start making bugs for features that core could implement citing dhx as how it should be implemented [17:27] Good point [17:28] marcoceppi_, normal debug hooks is documented already [17:28] jcastro: then add dhx [17:28] ok, I am just wondering, like; we consider dhx stable/useful enough to be in the docs? [17:29] aka. I can go ahead and port his blog post to the docs? [17:39] jcastro: I think there have been several people, including myself, using it pretty regularly. I think it's pretty stable and useful. +1 to adding it to the docs [17:41] cory_fu, ok I'll take that as a task then, <3 [17:41] +1 for it being useful and stable [18:42] * skay likes suggesting makefile target that will handle installing/building dependencies [18:43] * skay has seen makefile that will fail if dependencies are not installed and will ask the user to run the target to install them [18:43] * skay goes back to work === kadams54 is now known as kadams54-away [18:50] skay: my only request would be ensuring that those dependency targets are either "idempotent" or do proper checking that they have/have not being run [18:50] one of my projects has this horrid makefile with no way of ensuring a dep is more recent so it ends up trying to clobber already-downloaded files, it's quite messy [18:51] the first time it runs fine, but subsequent runs tend to bork things [18:51] I dread horrid makefiles [18:52] skay: you could just make a bunch of bash scripts that are invoked from make targets [18:52] skay: nothing wrong with that [18:53] marcoceppi_: that sounds reasonable. though could get unwieldy [18:53] skay: how so? [18:53] lets configuration manage our configuration management [18:54] and i'm not even kidding about that - bash patterns for these things exist as marco is suggesting. [18:54] won't I run the risk of having some very long messy bash scripts? [18:55] skay: if you do a bash script per task, it should be simple and easily digestable. Also, python scripts could work as well [18:55] yes, potential for craziness exists, but these tasks, test, dep-install, lint, etc should be pretty straight forward [18:56] I suppose having multiple reviewers will help keep things from being unwieldy [18:56] I'm happy that the discussion came up in the mailing list [18:57] I want to make MRs to the python-django charm and wasn't sure how best to handle the dependency question [18:57] i've been working with a branch of it for now and applying a sledgehammer approach of standing up and tearing down everything when I wanted to check if it did what I expected [18:59] skay: we're approaching the same problems using containers to solve the isolation testing as well, not sure if you're groovy with a docker file to run the testing in isolation (in tandem with a cloud provider - we haven't resolved local provider in docker yet) but i can certainly send over the work + context when we've hit a stable milestone. [18:59] e.g. make a change? run http://paste.ubuntu.com/9797121/ [18:59] then clean with: for p in $(mojo project-list | cut -d ' ' -f 1 | sed 's/\://'); do sudo mojo project-destroy -y ${p}; done [18:59] lazyPower: I have more experience with lxc than docker but wouldn't mind seeing how you do things with docker [19:00] Its not that different than using lxc with bind mount volumes :) [19:02] ...and buzzwords [19:02] lazyPower: I see [19:02] haha === kadams54-away is now known as kadams54 === hasp-air is now known as hasp-air[afk] [19:04] anyway, marcoceppi_ and lazyPower, once I am outside of work and get a moment, I'll clean up my charm MR to add a dep target to the makefile, perhaps and then be sure it passes the tests properly. (I know its bad hygeine but I've been using the script above to see that things work. it's fairly quick) [19:05] skay: there's literally many ways to cook a soup - and whatever method works for you shouldn't be shamed - that was part of the purpose of the mail to the list, was getting methods people are using so we can introspect and adjust tooling/documentation [19:05] and if one suggested pattern rose above the rest - that we would champion it as ~charmers === kadams54 is now known as kadams54-away [19:26] hey guys [19:26] so the debugging page is kind of long [19:26] would it make sense to have 2 top level debugging pages? [19:26] "Debugging with debug-hooks" and "Debugging with DHX" ? [19:28] jcastro: i think the DHX page would be more about the express lane that dhx exposes with sync'ing stuff and what not - and sure it does make sense to have it as a topic page all to itself , gives it room to grow. Core debugging concepts are going to apply across the board regardless of juju debug-hooks or juju dhx [19:28] ack === kadams54-away is now known as kadams54 === roadmr is now known as roadmr_afk [20:14] cory_fu, hey quick question, for the dhx import id's [20:14] what library are you using for that? [20:15] * jcastro is wondering if github id's are also doable [20:15] They are. It's just using `juju authorized-keys import` [20:16] jcastro: Which in turn uses ssh-import-id which supports launchpad and github [20:16] (On Ubuntu, at least) [20:17] ah, neat! [20:17] juju dhx -i gh:castrojo should work then [20:24] https://github.com/juju/docs/pull/230 [20:24] first cut, reviews welcome! === kadams54 is now known as kadams54-away [20:53] arosales: howdy; once a charm has passed charm store review, how are future updates to it handled? do they need to be reviewed before being accepted too? [20:54] jhobbs: hello [20:54] jhobbs: once a charm has passed policy review, all subsequent reviews also have to be reviewed before they are applied to the "recommended" charm [20:54] arosales: cool, thanks [20:55] sorry all subsequent updates, that is === hasp-air[afk] is now known as hasp-air [21:13] jiasir: are you on here? [21:15] nofdev: anyone from nofdev online? [21:22] jiasir: ????? [21:22] nofdev: anyone from nofdev online????? === kadams54-away is now known as kadams54 === lazyPower is now known as lp|outy5000 === roadmr_afk is now known as roadmr === Tug is now known as onurrrr === onurrrr is now known as Tug === Tug is now known as onurrr === onurrr is now known as Tug === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === Tug is now known as onurrr