[00:12] hrm.. I think we need a charm helper for dbconfig-common [00:12] marcoceppi: looks like you had to jump through some hoops to turn it off for phpmyadmin [00:13] SpamapS: It wasn't pleasent [00:13] the whole idea of dbconfig-common actually isn't very pleasant [00:13] its a constant source of bug reports [00:13] Trouble is, it'll likely be different for each service [00:13] SpamapS: that's why I wanted to use upstream install for the charm :) [00:14] The solution was easy enough after playing around for a while [00:16] So I'd like to reduce it down to 'ch_dbconfig_install packagename' and then in the hooks 'ch_dbconfig_config answer1=foo answer2=bar' [00:18] What would ch_dbconfig_install do? [00:18] marcoceppi: install it but leave it unconfigured [00:19] How would that be an advantage over this? https://gist.github.com/1557729 [00:22] marcoceppi: taking advantage of the packager's work to configure for the database seems useful. [00:23] marcoceppi: I suppose another option would be to ch_dbconfig_disable packagename .. and after that it would be up to the user. [00:23] marcoceppi: one can always assume $packagename/dbconfig-(install|upgrade|reinstall) for disabling [00:24] * SpamapS is still resisting the urge to use git. [00:24] I like the idea of having it simplified down to "auto-filling" based on package name, so ch_dbconfig_config selection1=value selection2=value which would just translate it out [00:25] I would have like to maybe used dbconfig and set db-host, db-user, db-pass when db-admin-relation-changed was fired, but it just seemed too... flaky to me [00:26] Not very idempotent [00:26] at least, from what I understand [00:26] postinsts and configs are idempotent by nature [00:26] so you would just re-run debconf-set-selections, and then 'dpkg --reconfigure foo' [00:26] err [00:27] might be --configure foo [00:27] * SpamapS is still re-learning his job after a week detached from the internets.. :-P [00:54] :) [01:42] hey. [01:42] wondering if someone could point me at what would be the most current instructions (or where i should start) for using the orchestra backedn [04:10] hi all [04:17] <_mup_> juju/ssh-known_hosts r460 committed by jim.baker@canonical.com [04:17] <_mup_> orchestra knows the dns_name; no need to look it up (and change corresponding mocks) [06:24] smoser: around now.. I think there are some instructions on wiki.ubuntu.com .. but I forget. They *should* be on https://juju.ubuntu.com/docs [06:29] <_mup_> juju/ssh-known_hosts r461 committed by jim.baker@canonical.com [06:29] <_mup_> Fixed bad mock setup [06:49] <_mup_> juju/ssh-known_hosts r462 committed by jim.baker@canonical.com [06:49] <_mup_> Properly mock saving launch state === TheMue_ is now known as TheMue === chuck_ is now known as zul [16:44] yikes the review queue is huge [17:27] hazmat: https://code.launchpad.net/~daker/juju/small-fix/+merge/68038 , should we mark that as WIP ? [17:33] SpamapS, i suppose, i ended up contributing the unit test there, but lacking the agreement its not clear that it can go in, its a trivial though [17:33] yeah [17:33] wip [17:34] hazmat: I have a better idea for how to automate destroy-environment btw [17:34] hazmat: -y is scary, like rm -rf. What about requiring UUID of some kind? [17:34] SpamapS, uuid? [17:35] like pass in a secret on the cli for confirmation [17:35] seems odd, the unix'e way is to just pass a flag [17:35] hazmat: not a secret.. [17:36] hazmat: the environment should have a UUID that is generated at bootstrap, and shown in status. Then you have to specify *that* UUID to destroy-environment [17:36] hazmat: that way you don't accidentally destroy an environment you didn't mean to destroy. [17:36] hazmat: if no UUID is expressed, then the y/n question is still asked (and if there's no TTY, then flat out refusal happens) [17:38] hazmat: I'm still worried about automated oopses [17:38] SpamapS, hmm.. as a check it seems sound, as for usage, it seems over wrought. i'd rather just spec the flag. [17:38] SpamapS, at the end of the day humans are always a weak link ;-) [17:38] hazmat: one other thought is to require the environment name be specified explicitly (ignore the default) [17:38] this is not humans, this is code [17:40] hazmat: I'm just concerned about automated scripts that have no idea whats in ~/.juju/environments.yaml and get run accidentally. [17:41] hazmat: effectively we are encouraging people to write scripts that do 'rm -rf .' [17:41] SpamapS, good point [17:41] but scripting environment destruction is what their trying to do [17:42] we can either make that command non orthogonal wrt to environment spec, come up with arbitrary uuid that's not used anywhere else, or just do the common thing which is request a flag for specifying force/assume yes [17:44] yeah, we should recommend that -e xxxxx always be used with destroy-environment [17:44] reminds me of gmail goggles [17:45] hazmat: training wheels off.. I think thats the way to go [17:45] * SpamapS wishes his man page had been accepted so he could update it.. ;) [17:45] SpamapS, that seems like a reasonable safety belt if using -f [17:45] SpamapS, is it in the review queue anymore? [17:45] no [17:45] it was rejected since we should, in theory, be able to coerce argparse into generating the man page [17:46] that was back from dublin days [17:46] ah [17:46] I sat down to do that a few weeks ago.. [17:46] and argparse made me throw up in my mouth a little [17:46] i think we've given up on that [17:46] SpamapS, yeah.. its not pretty to extend [17:46] I think actually what we *can* do is parse out the --help .. as its structured enough to be machine parsable [17:47] sometimes the way python classes are written makes me really really confused [17:47] coming from C++ -> java -> perl -> php .. extending and overriding is so much more natural in most cases. [17:48] python classes seem to just do weird stuff [17:49] SpamapS, i don't think you can use argparse as an exemplar. probably too much attempt in that codebase to support the old optparse approach however [18:33] $ juju deploy --help [18:33] error: Environments configuration error: /home/clint/.juju/environments.yaml: environments.sample.region: expected 'us-east-1', got 'sa-east-1' [18:34] Heh.. thats annoying. [18:34] --help shouldn't care. :) [18:36] <_mup_> juju/ssh-known_hosts r463 committed by jim.baker@canonical.com [18:36] <_mup_> Do not assume current test code is correct ;) [18:37] hazmat: https://code.launchpad.net/~nijaba/juju/autocomplete/+merge/86159 .. do you think that counts as a trivial? [18:37] * hazmat peeks [18:38] SpamapS, indeed [18:39] * nijaba frowns to see his first juju core contrib counted as trivial :D [18:40] we need to use a different word [18:40] how about 'elegant' ? ;) [18:40] hehe MUCH better [18:40] hazmat: ok I'll just commit that [18:40] <_mup_> juju/ssh-known_hosts r464 committed by jim.baker@canonical.com [18:40] <_mup_> Fixed remaining orchestra provider test [18:40] * SpamapS notices a second trivial change that is needed... remove --placement [18:43] nijaba: https://code.launchpad.net/~charmers/+archive/charm-helpers/+recipebuild/149052 [18:43] nijaba: cross your fingers! [18:44] m_3: so hey, crazy jorge idea validation time [18:45] I was reading on planet devops about this: http://newrelic.com/ [18:45] it's saas but it has agents and whatnot [18:45] https://github.com/newrelic/rpm [18:45] jcastro: a friend of mine has been using that and said its really nice. [18:45] right, ditto [18:46] <_mup_> juju/ssh-known_hosts r465 committed by jim.baker@canonical.com [18:46] <_mup_> Removed debugging [18:46] so my question is, is this a place where juju can help? [18:46] juju add-relation newrelic myservice does the magic and then you just go to the website and you have it all set up kind of thing. [18:47] jcastro: feels a lot like something you would subordinate into your machines [18:48] yeah so this is why I asked [18:51] SpamapS: http://www.jedi.be/blog/2012/01/04/monitoring-wonderland-moving-up-the-stack-application-user-metrics/ [18:51] then I started wondering how many of these are open and could be juju'ed [18:51] or if it's lower in the stack [18:52] "Part of their secret of success is the easy at how developers can get metrics from their application by adding a few files, and a token." [18:52] bad translation? [18:53] jcastro: we'd have to look into what they do, but if they are passive and just observe existing output of ruby/php/etc. apps, then it might be an easy win once we have subordinate services [18:53] statsd looks cool [18:54] hazmat: where are we with lp:juju/docs ? still generating from trunk or is it fully split now? [18:54] jcastro: didn't westby tackle that or something? [18:54] dunno, but it must be awesome, it's node.js [18:54] :) [18:55] sooooo hot [18:56] I'm working on the a charm and I'm not sure how much configuration I should add in the config.yaml. Is more is better then less? [18:56] for a public charm [18:57] avoine: depends entirely on the service. [18:57] what service? It would be nice to know so I can track it! [18:57] it's already there it's python-moinmoin [18:57] avoine: but for the most part, I say if it *is* tweakable, put it in config.yaml. [18:57] ok [18:58] avoine: if there are like, 100's of variables, then it may be best to have a single config option.. "override values" which users can just set after reading moinmoin's docs. But if there are only like, 20 or so, its nice to have them spelled out in config.yaml. [18:58] oh rock and roll, that would be a nice one [18:59] SpamapS: "override values" is a good idea [19:00] I'll do that [19:02] good one, captured! https://juju.ubuntu.com/CharmGuide [19:02] jcastro: ^5 [19:03] marcoceppi: I am pretty sure you have like, dozens of opinionated things you could add there, heh [19:03] jcastro: heh, yeah :) [19:04] please keep it to your charm opinions.. "And whats with Burritos? They're not little burros, so why burritos?!" [19:05] A charm review check list could be nice [19:09] jcastro: newrelic is ok... I used it for a couple of clients in the past. there're a few different tools in that space [19:11] jcastro: have to think about how juju could best help... the monitoring setup is pretty lightweight (it'd be a trivial charm) but the app integration is where the meat really is [19:12] don't even know if they have an option to set up your own monitoring service with it [19:12] i.e., your own mother ship [19:12] m_3: yeah as I peruse some of these I am seeing some that could be awesome, and some not. [19:13] I just hadn't thought of measuring tools in such a detailed way, now I am seeing all these tools and wondering. [19:14] also, the more I learn about things like this, the more I wish I could go back in time and fire myself from my old jobs for being dumb. [19:14] seems like sensu would be a better way to spin up your own... newrelic does the full saas package for you [19:14] ha! [19:14] yeah, hindsight huh [19:28] SpamapS, not sure its being generated at all atm [19:57] hazmat: oi. Ok, well there are a few docs/* things waiting to be merged.. we should make it clear where they go and get them merged and out of the queue. [19:59] SpamapS, i only see one from mbp? [19:59] * hazmat looks around [20:04] hazmat: there's one from Ahmed that I put back to WIP but will be simple to correct, and one from rog as well [20:04] anyway, I have to run, bbiab