=== CyberJacob is now known as CyberJacob|Away === vladk|offline is now known as vladk === CyberJacob|Away is now known as CyberJacob === vladk is now known as vladk|offline === vladk|offline is now known as vladk === vladk is now known as vladk|offline === Ursinha is now known as Ursinha-afk === vladk|offline is now known as vladk [09:46] Error: worker: exited "environ-provisioner": failed to process updated machines: cannot start machine 1: no matching tools available === Ursinha-afk is now known as Ursinha === timrc-afk is now known as timrc === mbruzek changed the topic of #juju to: Weekly Reviewer: mbruzek || Welcome to Juju! || Docs: http://juju.ubuntu.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://goo.gl/9yBZuv || Unanswered Questions: http://goo.gl/dNj8CP === timrc is now known as timrc-afk [13:29] Hi, I have a few questions about customizing a deployment of mongodb with mongodb charm [13:29] Like what would be the recommanded way to add authentication? Should I clone the mongodb charm, include the keyFile in it and modify the install hook to copy the file to the right place? === timrc-afk is now known as timrc [13:40] Tug, keyfile being ssl? [13:40] Tug, ideally that would be config [13:40] Tug, but yeah.. in general fork, modify & test, submit pull request/merge proposal [13:41] hazmat, yeah ssl [13:41] hazmat, you mean modify the config-changed hook ? [13:42] Tug, yeah [13:42] Tug, and config options on the charm [13:43] Tug, config.yaml [13:43] hazmat, yeah add a new config option for the path of the file for instance right ? [13:44] Tug, for the contents of ssl cert / ssl key / ssl ca [13:44] Tug, the config-hook drops those onto disk, and configures mongodb to use ssl if their present.. [13:44] hazmat, the content directly into the config.yaml you think ? [13:45] Tug, no.. config.yaml is the schema, but yeah.. the service config would have the ssl key/cert config.. [13:46] hazmat, ok I see. Well why not. Not sure how it's going to render on juju-gui :) [13:46] Tug, not to pretty, but should be fine, just gets collapsed into a text field i've done this with some of the other charms [13:47] Ok thx, I'll try this then ;) [13:47] Tug, there's one ancillary alternative which is having the mongodb service act as its own ca, but that implementation is a bit more advanced (have to replicate the ca files across replicaset and potentially to shard servers). [13:48] the config options for key/cert/ca usage is pretty straightforward [13:49] hazmat, Mmm I see, but I guess I would have to play with openssl to have this right ? [13:50] and add multiple hooks [13:50] Tug, don't worry about the service being its own ca.. its complicated.. there's some helpers in charm-helpers.. [13:50] ok hazmat [13:51] hazmat: ping [13:51] Tug, the config option around ssl is pretty straight forward.. add additional options to config.yaml for key/cert/ca .. detect those in config-changed and configure mongodb for ssl.. also probably one more.. which is for clients to pass the ca [13:51] unless its a system recognized ca [13:51] lazyPower, pong [13:51] lazyPower, yeah.. i'm on it :-) [13:51] lazyPower, re DO [13:51] hazmat: I did some work on that api parser actually [13:52] lazyPower, oh? [13:52] its made me realize how weak i am with regex :P [13:52] lazyPower, api parser? [13:52] oh sorry, context [13:52] hazmat, out of curiosity, do you have a link to the charm-helpers you were talking about ? [13:52] i'm working on exact matches so we dont match their prefab app boxes. [13:52] eg: 12.04 dokku [13:52] lazyPower, if you mean jujuclient.. rog has something that will use parse the golang client api to json [13:53] Hello Tug [13:53] lazyPower, ah.. so i'm not quite sure what the best option is.. i was thinking of a unit test that verified all the default images chosen [13:53] i want to abstract away the list if i can, because it wont scale. They deprecate the vanilla images pretty often. [13:53] lazyPower, and then tossing it into ci [13:53] Hi mbruzek [13:53] lazyPower, basically i want to avoid clients having to do the api call, call its time consuming, but still keep constant check that the images are valid.. [13:53] Tug, sorry I was catching up I see that hazmat answered your questions. [13:54] it does sort of assume that clients get updated when images are invalid [13:54] lazyPower, i just pushed a quick change that gives a nicer error message then just the traceback on api error (ie tell the user what the do said was in error) [13:54] awesome [13:54] do i need to rebase? or are you going to handle that? [13:55] lazyPower, new output is http://pastebin.ubuntu.com/7299388/ [13:55] lazyPower, i'll handle.. i'm adding support to the mini do client for image fetching so i can add a unit test to verify the default image selection, and then merge your mp [13:55] + 1 on the new response message. [13:55] ack. Thanks for taking a look [13:56] lazyPower, np.. thanks for the mp [13:57] Tug, http://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/contrib/ssl/service.py [13:57] Tug, its used in a few charms for generating server and client certs for mutual auth with tls [13:58] thank you hazmat [13:58] * hazmat makes a note to add some charm-helper docs [13:58] yeah it's not so simple but it might not be impossible to adapt it for mongo [13:59] I'll have a look [14:09] lazyPower, yeah.. i was hoping to avoid the image check on every plugin invocation. its only about 1.5s though.. so probably worthwhile to just bake it in. [14:09] hazmat: would probably be prudent to cache the response and expire every N hours? [14:10] unless it reaches a 404 on image creation, then refetch, THEN throw exception? [14:10] lazyPower, that sounds pretty reasonable [14:10] albeit more complexity [14:10] i agree that it adds complexity but it enhances the UX [14:11] lazyPower, the issue is that we get user images/backups as well in that api call [14:11] yeah [14:11] yeah, i was considering that.. i wonder if this is where we dont explore an opportunity presented by other mediums, and interrupt with an interactive list and let the user choose [14:12] that deviates pretty far from the vanilla juju ux, but makes sense [14:13] argh.. battery dying.. back in a bit [14:19] sinzui: re: https://bugs.launchpad.net/juju-core/+bug/1309805 - shall i re-open the bug with my output or file a new bug? [14:19] <_mup_> Bug #1309805: LXC / Local provider machines do not boot in 1.18 / 1.19 series [14:20] will juju support spot instances? [14:22] fro0g: on AWS correct? [14:25] lazyPower, The bug isn' [14:26] t closed. There is no information for en gineer to reproduce the bug and make a fix [14:26] sinzui: ok, i was asking because it looked like a community member was trying to help by adding their output and it wasn't helping. [14:26] I'll attach machine agent logs + commands. I can reproduce this on 2 systems [14:26] lazyPower, The other error in the bug is not about tools [14:26] thank you lazyPower [14:27] np, thanks for taking a look sinzui [14:34] has anyone else bootstrapped on hpcloud today? Looks like i'm seeing a new bug here as well: https://bugs.launchpad.net/juju-core/+bug/1310645 [14:34] <_mup_> Bug #1310645: Bootstrapping on HPCloud fails with package Hash Sum Mismatch

[14:38] lazyPower, abentley reports the same issue on joyent and azure [14:38] ack. looks like monday hasn't lost its edge [14:44] lazyPower: yes [14:45] fro0g: i'm not aware of any active efforts to support spot instances. You can request spot instances and work them into your environment with the manual provider - but i do not believe that juju supports provisioning spot instances as a provider option. [14:47] sinzui: attached logs to https://bugs.launchpad.net/juju-core/+bug/1309805 [14:47] <_mup_> Bug #1309805: LXC / Local provider machines do not boot in 1.18 / 1.19 series [14:47] i have mbruzek doing the same [14:48] lazyPower: ok [14:48] thank you lazyPower [14:48] lazyPower: thanks! [14:49] Np problem fro0g. if you'd like to see it as a feature, i would open a feature request against juju-core. I can't promise anything above the core-team will take a look at it and triage it appropriately. but you'll be the first to know if it lands by doing so. [15:01] Hey guys it seems I have got past the "pending" problem on Trusty, just now. Talking about https://bugs.launchpad.net/juju-core/+bug/1309805 lazyPower and cory_fu [15:01] <_mup_> Bug #1309805: LXC / Local provider machines do not boot in 1.18 / 1.19 series [15:01] mbruzek: randomly started working or did you do something specific? [15:02] I destroyed my environment, ran the cleanup script that removed lxc containers. But I think what solved it was running juju sync-tools before my bootstrap [15:02] I am able to get a charm to started this morning. [15:02] ah, excellent. Let me try syncing tools and trying again [15:02] I believe it was due to the juju sync-tools, can lazyPower or cory_fu confirm? [15:03] How do I add the dev ppa to get juju 1.19? [15:03] cory_fu: sudo add-apt ppa:juju/devel [15:03] s/add-apt/add-apt-repository [15:03] Ah, right, of course. Thanks [15:04] I may have claimed victory too soon guys, I got the "ubuntu" charm to start, but my other tests are still in pending. [15:04] Try a charm other than "ubuntu" [15:04] please [15:04] ack, i'll deploy a bundle [15:05] however it appears my ubuntu charm is still pending... and i'm geting the same output in machine-0.log [15:08] I got the ubuntu charm to start...because that one is trusty ? [15:09] mbruzek: it didn't appear to fix it. bundle:mediawiki/single is pending. with the same scrolling log output [15:09] mbruzek, lazyPower do either of you specify the default-series in your env? [15:10] no I do not [15:10] sinzui: i have specified precise in my local env config, yes. [15:10] I do, I local: [15:10] type: local [15:10] default-series: precise [15:10] lazyPower, fwiw. i eschewed the regex .. http://pastebin.ubuntu.com/7299864/ [15:11] hazmat: nice approach. I didn't think to look at the public: flag in the json output [15:11] s/flag/property [15:12] does it match on their single-click-deploy appliations? wrt dokku-wiki and gitlab? That was my other concern was matching on those and potentially launching an application along with juju. [15:12] oh line 10 takes care of that. awesome. great work hazmat [15:13] sinzui, I am setting that and testing it now [15:15] ah i apologize i jumped the gun, i set default-series on everything but local provider. [15:20] sinzui, That seems to work for me [15:21] sinzui, I have found a new problem however, and I need guideance on where to open it against. [15:21] Setting the default series as trusty or precise? [15:21] precise [15:21] I don't think local was uploading the tools for precise [15:21] mbruzek, interesting. does : trusty work? [15:21] sinzui: are a lot of these problems related to the fact that we now have 2 LTS's to track? Where default-series wasn't mandatory before, but is now? [15:21] sinzui, I was able to deploy tomcat and ubuntu [15:22] sinzui, Both charms deploy. tomcat failed in the install hook doing a apt-get update. [15:22] I sshed to ubuntu charm and ran apt-get update and that fails in the same way. [15:22] mbruzek, my logs claim they were upload both tools...and since I know I don't have precise, It should have gone to the network to get them...there is no guarantee that the series and archs have the same tools [15:23] oh snap, that did appear to fix it. bundle:mediawiki/single is now deploying as expected. [15:23] lazyPower, In my release notes for 1.18.1 I recommended default-series because I was getting a lot of issues that were caused by ambiguous envs [15:24] sinzui: i remember that email now that you call attention to it. Sorry for not heeding the advice earler. Do we have default-series being added to the boilerplate environment config for new users now? We should probably add a ticket for that if not. [15:25] lazyPower, I have not seen it yet. I think it is the sane thing to do. [15:26] sinzui, I believe apt-get update is failing for trusty charms. What component would that be against? [15:26] mbruzek: is the output the same as i linked you earlier about a hash-sum mismatch? [15:27] Yes [15:27] mbarnett, That's ubuntu, not charms or juju [15:27] mbruzek: elmo pushed a fix for that, its propigating - i can confirm it resolved my issues on hp-cloud.... [15:27] lazyPower: I am getting the hash-sum mismatch on local, now, yes [15:27] however that was a precise host - do you know if that fix was pushed for trusty as well sinzui? [15:28] mbruzek, lazyPower I believe the same package in in both series [15:28] And the local-machine that go the error was precise... Is there a way I can... encourage the propagation? [15:29] cory_fu: speak with a stern voice and shake your finger at it profusely [15:29] lol [15:29] I meant, is there any caching done by the LXC that I could explicitly expire? [15:29] its not an image update, it was a fix server side on the SUM file that apt uses for CRC checking. [15:43] so lazyPower I don't understand how the fix will be delivered. If it is fixed on the server side how did I get it just now? [15:44] mbruzek: apt fetches the CRC during apt-get update and validates teh package list against that CRC file. It wasn't something that was pushed out to clients. So when it propigates to your apt mirror it will be available to you. [16:22] lazyPower: that bug in wordpress is fixed, MP is up [16:28] when amulet deploys a charm, where does it get the config.yaml from? [16:28] i have a config.yaml that i've updated on disk, but amulet isn't using it [16:29] tvansteenburgh: afaik it's the config.yaml file that's on the charm, but you can specify options by doing d.configure('servicename', {'option': 'value', 'option': 'value'}) [16:30] jose: that's what i assumed too, but that's not what i'm seeing. [16:31] tvansteenburgh: oh, I'm not sure if it deploys the local charm, I think it gets it from the charm store [16:32] well i have JUJU_TEST_CHARM set, which is supposed to make it deploy the local copy, but i'm not sure if it's working or not [16:32] i guess i'll continue my debugging there [16:33] for now I suggest you go ahead and set the options where needed [16:34] tvansteenburgh: when you run the test from the command line: eg ./100-deploy - it uses the charm store, if you're using the testing harness charm test -e it will deploy teh local charm. [16:35] not sure if that helps or answers the question but i thought maybe it would. [16:35] jose: woot. if its in the queue mbruzek will be taking a look at it. [16:36] awesome, then :) [16:42] jose: lazyPower we're mailing the list in a little bit, but future doc contributions should be done in the src/en/ markdown files [16:42] marcoceppi, I am confused [16:42] https://github.com/juju/docs/blob/master/src/en/charms-constraints.md [16:42] juju bootstrap --constraints "cpu-power=0 cpu-power=0 mem=512M" [16:42] is entirely correct in the MD [16:42] marcoceppi: ack, will re-do my stuff and commit as soon as I get home [16:43] marcoceppi: thanks for the update. I'll keep that in mind when accepting PR's. [16:43] jose, I'm fixing it now no worries [16:43] lazyPower: very soon the htmldocs will be gitignored, so it won't be a problem, but fyi until then [16:43] but from looking at the markdown source, it appears to be correct? [16:43] jose: he removed cpu-power from the output [16:43] in university I have only found a workaround to connect to IRC, so I can't do much [16:43] jcastro: ^^ [16:44] jose: sshuttle is your friend [16:44] jcastro: thank you :) [16:44] oh oh [16:44] so cpu-power=0 doesn't work anymore? [16:44] jcastro: it was duplicated. that was the fix [16:44] I could have sworn we used to not have it, and then at some point had to explicitly say 0 [16:44] jcastro: there's cpu-power and cpu-cores [16:44] marcoceppi, jcastro: I removed one of the cpu-power=0, it's doubled [16:45] oh! [16:45] now I see it' [16:45] jcastro: that had two cpu-powers vs one of each [16:45] juju bootstrap --constraints "cpu-power=0 cpu-cores=0 mem=512M" [16:45] would be the better update perhaps? [16:46] I can confirm "cpu-power=0 mem=512M" works, no need to specify cpu-cores [16:46] lazyPower: sshuttle? [16:46] ok cool [16:46] jose: https://github.com/apenwarr/sshuttle [16:46] lazyPower, new PR with fix incoming [16:46] lazyPower: dns servers don't work here and if i set 8.8.8.8 I cannot connect :P [16:47] jose: sshuttle creates a VPN tunnel to your host of choice - so you could route all your traffic around whatever barrier you've got via ssh. Assuming you can ssh out. [16:47] I cannot SSH out :P [16:47] but id ont know what your universities network policy is, so YMMV on if you're being a trouble maker [16:48] nah, sysadminds are good with me messing with networks, I'm going to try with a personal VPN later on [16:48] for now, /me runs to have lunch and take an exam [16:48] lazyPower, don't accept my PR yet, let me see what rick's does [16:49] Hi. within a hook, would there be a magic variable that has the name of the charm? [16:49] rick_h_, yours is more explicit so I think I'll do that [16:50] jcastro: up to you. I like the shorter, but was trying to get at what I think the original line was meant to be/demonstrate [16:51] ack [16:51] yeah longer, but better example [16:53] lazyPower, I can confirm rick's modifications to the command still fires up a t1.micro, so we're all set. [16:54] woo awesome [16:54] jose, oh, I only fixed your accepted PR btw [16:56] OMG [16:56] arosales, did you add the joyent page to every file by hand? === vladk is now known as vladk|offline [17:03] jcastro: ok, will fix as soon as I'm homr === timrc is now known as timrc-afk [17:10] jcastro: no, the make did that for me. [17:10] oh ok [17:10] lazyPower, mbruzek : I reposted the my default-series recommendations: http://curtis.hovey.name/2014/04/21/working-with-ubuntu-12-04-precise-and-14-04-trusty/ [17:10] arosales, I did another submission if you want to use that one [17:11] jcastro: for the joyent provider? [17:11] yeah [17:11] sinzui: reblogging now. thanks for this! [17:20] arosales, yeah [17:20] https://github.com/juju/docs/pull/70 [17:21] arosales, that's how you add a page, we can either fix yours or accept that one, up to you [17:21] <--- lunch [17:28] * arosales looking [17:30] jcastro: can you help me understand what is incorrect about https://github.com/juju/docs/pull/68 ? === natefinch is now known as natefinch-afk [17:37] hi, arosales. think he means that you added the html generated page. I'm guessing only the markdown is needed [17:38] yeah, but marcoceppi's .gitignore will fix that [17:38] arosales, basically, we don't generate the pages, the build system does [17:39] arosales, but we'll fix it so the generated html is ignored [17:43] hey, so anyone using http://cloud-images.ubuntu.com/vagrant/precise/current/precise-server-cloudimg-amd64-juju-vagrant-disk1.box lately? it's giving errors when bootstrapping [17:43] what are people using here for a vagrant jujubox? [17:43] renier, I just reported it's brokeness to the maintainer today [17:43] renier: do you have a paste for that? [17:43] but yeah, something changed in 1.18 that we need to fix and regen the boxes [17:44] utlemming, lazyPower was the one trying them out [17:44] utlemming, I think for starters it needs to explicitly install juju-local [17:44] which was causing some pain [17:44] jcastro, something changed in juju 1.18 you mean, or another piece? [17:44] utlemming, I'll get that for you [17:44] renier, I believe 1.18 [17:45] ok, yea, juju version 1.18.1 in the box [17:48] utlemming: do you need anything from me re: juju box investiation? [17:49] i can send logs and the vagrantfile if you'd like. what i saw was some missing components, and after installing them manually i ran into other issues with regard to missing a default-series in the environments.yaml (which we sussed out this morning) [17:49] Is it possible for a charm's config-changed hook to tell if it's being run as part of charm upgrade vs just a config-set? [17:49] cory_fu: set a sentinel file in $CHARM_DIR and act on it, when finished acting, rm said sentinel file? [17:50] Not sure I understand [17:51] cory_fu: during upgrade-charm at the end touch $CHARM_DIR/.upgrading [17:52] look for if [ -f $CHARM_DIR/.upgrading]; then #do stuff rm $CHARM_DIR/.upgrading fi [17:52] theres your idempotency guard against running said code if being called directly after upgrade-charm [17:53] Ah, I see [17:56] renier: Hello, and thanks for the feedback :-) [17:56] jcastro: understood, I think all your pull (re: 70) is missing the png [17:56] I just fixed it [18:00] bzr branch [18:01] wrong win [18:04] tvansteenburgh: bzr: ERROR: command 'branch' requires argument FROM_LOCATION [18:04] so i finally figured out how to get my amulet tests working [18:04] woo! [18:05] i had to bzr ci my local changes before amulet/juju-deployer will use them [18:05] jcastro: +1 for your commit then [18:05] tvansteenburgh: yeah [18:05] seems not good [18:05] that should be addressed in the next rlease of amulet [18:05] it's a known issue [18:05] ok cool [18:06] utlemming, https://gist.github.com/renier/11150973 [18:06] so now i have a patch for haproxy. do i file a bug against https://launchpad.net/~charmers/charms/precise/haproxy/trunk and push my changes to ~tvansteenburgh/charms/precise/haproxy/trunk ? [18:07] utlemming, that's what I saw upon vagrant up. let me know if you need logs of anything ^ [18:09] tvansteenburgh: indeed [18:09] you dont need to specify /trunk as your local branch through, you can name it whatever you like [18:09] lazyPower: thanks [18:21] lazyPower: do i need to subscribe ~charmers to this, or change the status? https://bugs.launchpad.net/charms/+source/haproxy/+bug/1310732 [18:21] <_mup_> Bug #1310732: Enable sticky sessions [18:22] tvansteenburgh: nah, create a MP for your branch and it will show up in the REV Q === sputnik1_ is now known as sputnik13net [18:44] anyone want to get on a hangout and discuss a good way to do a master election using peer relations? === vladk|offline is now known as vladk [18:49] haha [18:49] tvansteenburgh: I'd love to, but that's a long hangout [18:51] marcoceppi: i got nothin but time :P [18:52] even if we time-box it, i'd like to hear your thoughts [18:52] i need to find some way to solve my problem, even if it's not proper leader election [18:54] tvansteenburgh: there's an effort to resolve this for cassandra to [18:55] so let me know what your ideas are. I'll be assuming responsibility for that behemoth soon === vladk is now known as vladk|offline [19:32] jcastro, given juju 1.18 has that problem, should I use juju/stable or another branch? I'm going to try this on a trusty box === BradCrittenden is now known as bac [19:36] renier, trying with 1.16 might help [19:37] jcastro, ok. is that 'juju/unstable'? (not familiar with the branch names? [19:38] I can look it up. don't worry [19:39] 1.16 is old stable [19:39] 1.18 is current stable [19:39] 1.19 is current devel [19:39] ok, thanks === timrc-afk is now known as timrc === natefinch-afk is now known as natefinch [21:20] jcastro: are the juju docs good for translating? [21:20] because if so, I can try and translate them to spanish === CyberJacob is now known as CyberJacob|Away === CyberJacob|Away is now known as CyberJacob [21:26] jose, gimme a few days to sort out some minor issues first [21:26] we need to connect it to launchpad, etc. [21:26] no worries, just ping me once it's good to go and I'll do my best to translate them [21:44] er, so why would I be seeing this: "machine-0: 2014-04-21 21:40:53 ERROR juju.provisioner provisioner.go:175 environ provisioner died: failed to process updated machines: cannot start machine 1: no matching tools available" in the logs? [21:48] utlemming: it needs a default-series property in teh environment config [21:48] lazyPower: thanks [21:54] anytime === CyberJacob is now known as CyberJacob|Away