[00:01] in the phpmyadmin charm? there is no line 3 [00:01] yeah, so I deployed it naming the phpmyadmin service "myphp" [00:01] 6 [00:01] sorry, not config-changed, but db-admin-relation-changed [00:02] it creates a database "phpmyadmin", but operates on the (nonexistent) "myphp" database [00:02] Ah, it's left over from when mysql charm created the db [00:02] meta/192.168.122.243 contains "server_db=myphp" [00:02] I'll fix that in the charm. I also found another bug [00:03] ok, I'll note it in the review... thanks, just didn't know which of those behaviors you wanted to happen [00:04] Yeah, if you join multiple mysql services, it'll always use the last one as it's database server, needs to just use the first one and not create a phpmyadmin control db on each server [00:05] actually, no that's right [00:05] but the item you pointed out is correct, I'll throw that up in a min [00:06] yeah, it's ok to marry one phpmyadmin instance to one mysql instance... just note it in the docs [00:06] lots of charms have a similar limitation [00:07] indeed, haproxy suffers from this too [00:07] you can't load balance two services behind one haproxy without knowing the hostnames they need to be known by externally [00:08] m_3: What do you mean "it's okay to marry one..." [00:11] m_3 is saying that some services shun paligamy [00:11] marcoceppi: if you have two mysql services around... wiki1db and wiki2db [00:11] it's ok to have a wiki1webdb and wiki2webdb [00:12] 1 for 1, no need to have a single wikiwebdb that connects to both mysql instances [00:12] Sure, it is. But you could also have one that connects to both, right? [00:13] don't actually know if phpmyadmin supports that, but if it did yes [00:13] It does, and the charm does as well [00:13] just saying it's extra work to make the charm handle that [00:13] it's ok if it doesn't [00:13] but it already does :) [00:13] oh, meta/ip-address has the instance-specific data [00:13] gotcha [00:14] which actually reminds me, is there a way to get the name of the service from the db-admin-relation-joined? [00:14] Like if I join phpmyadmin service with dbwiki1 - can I get the name "dbwiki1" from a magic command? [00:14] which service? local is ${JUJU_UNIT_NAME//\/*} [00:14] The remote service [00:14] remote is ${JUJU_REMOTE_NAME//\/*} iirc [00:14] JUJU_REMOTE_UNIT [00:14] * m_3 checking [00:15] SpamapS: thanks [00:15] so ${JUJU_REMOTE_UNIT//\/*} [00:15] Fantastic! Does //\/* work in dash? [00:16] had problems with that before, but haven't looked into what the deal is... it's posix and it should support it [00:16] typically use bash as a consequence [00:17] m_3: // is not posix IIRC [00:17] ## and %%, but not // [00:17] ${JUJU_REMOTE_UNIT%%/*} works in dash [00:18] m_3: next charm will probably be bash if not in php [00:18] m_3: http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html .. no // [00:19] I sit corrected :) [00:19] You guys can overrule my shell code edict. I feel like charm-helpers should be posix only just so that if somebody has a mountain of ksh or csh stuff, they won't have to fight with charm helpers. [00:19] Cool, %% works [00:20] SpamapS: I agree on that level :) [00:20] no, I'm fine... happy with %% [00:22] I do only think we have to care about shell *in charm helpers*. Write your hooks in bash or scala for all I care. :) [00:22] * SpamapS ponders running the test suite with all the other shells just to see if it works [00:23] * SpamapS is still not sure how comfortable he is writing enough shell code to need a test suite. ;) [00:23] wow, yeah, I know what you mean [00:23] still its kind of cool that we have one. [00:24] m_3: Did switching "upstream" work in your tests? [00:24] * m_3 flashbacks to manual rsnapshot before rsnapshot but after dump was no longer useful [00:25] marcoceppi: still running... had to wipe my env a little bit ago [00:30] marcoceppi: beautifully [00:30] m_3: Do you have any opinions how templating might work? I wrote a templating engine using bash that I put in file.sh however, I was thwarted when I found out bash/dash can't handle assoc arrays and passing them to functions as parameters [00:31] I guess you would pass two arrays to the function, one with keys and one with their respective replacement values. Though I'm not sure if bash/dash maintains insert orders in arrays [00:32] I really think cheetah from the command-line is a great option... it really was simple to do: https://gist.github.com/1402941 [00:34] my only concern is how sensitive it is to general markup being interpreted as special, but it would be dead-simple to manage from a charm-helper wrapper [00:34] But, how do we build that into a charm-helper-sh function [00:34] You'd still need to pass key/value pairs. Unless you did it one at a time? [00:35] nope, just have it use the current shell's env [00:35] set vars [00:35] You mean, just call it globally? [00:35] then call ch-template(template_file) [00:35] Ugh, I could have done that with the bash function as well [00:35] I think I deleted that code too. [00:35] that's what a heredoc does in shell [00:36] it'd be really equiv, just easier to manage the template part in the files [00:36] right [00:36] more powerful too... looping constructs, etc in the template itself [00:36] I <3 tpl files [00:36] I'll look into starting file.sh with this [00:37] Suppose charm-helper-sh will just need to depend on cheetah as well [00:37] Is this channel logged anywhere? [00:37] yup [00:37] dunno where [00:38] marcoceppi: why not just pass the resolved heredoc to the templating function? [00:38] but I've seen people pull logs of it [00:38] heredocs are hard to assign [00:38] ch_replace_file /etc/foo.conf < there's an exec trick to do it but it's ugly [00:39] I don't actually know if shell functions can have different stdin's tho [00:39] I think I must not be understanding heredocs [00:39] exec is fine [00:39] we are not working on sub-second charm hooks as a goal ;) [00:39] 'ch_replace_file file < yeah, exec is fine in the ch method [00:40] but having to exec a heredoc to assign it to a variable to pass to the ch func is ugly [00:40] we can figure it out [00:41] just putting another tool like cheetah out as a first choice [00:41] for more powerful templates [00:41] cheetah has enough power, it doesn't need a helper [00:41] then we're not gluing heredocs and snippets "pre-this and post-that" together for one config file [00:42] if you have a cheetah template sitting in your charm, the cheetah executable can take all the inputs as a heredoc, and the output file, and will do an atomic replace for it [00:42] m_3: ch_append_file file < ok, I'd be fine with just using straight cheetah in charms w/o a helper [00:42] appending works for looping too [00:42] I actually find pre/loop/post to be just fine. [00:43] appending works, it's just ugly to manage the config in its entirety [00:43] I like loops in templates :) [00:43] its a style thing [00:43] yup [00:43] do what makes you happy, I say [00:43] the goal of charm helpers is to help people get back to what they enjoy [00:43] not to keep them away from what they want to do [00:44] yeah, I wouldn't oppose any particular approach in charm-helpers... just putting ideas out there [00:44] * SpamapS dons cheesy voice and powder blue knit sweater [00:44] nice [00:44] Because you're good enough to find your passion and your fire [00:44] it's a beautiful day in the neighborhood [00:44] * SpamapS lights sweater on fire [00:45] I thought the goal of charm helpers was world domination [00:45] ha [00:46] I really like phpmyadmin as part of a demo [00:47] spin up a decently-mature stack around mysql [00:47] then add that on in conversation as an afterthought [00:47] it gives a great feeling of power [00:47] marcoceppi: no that is the goal of SpamapS... it just so happens that charmers is one of SpamapS's tools [00:47] and the speed with which this can be done is a _real_ distinguisher [00:48] jcastro: note for blogging about it ^^ [00:48] m_3: yeah, its pretty cool. We should try to get phppgadmin charmed up too [00:48] SpamapS: I liked the 'minions' MP approval note :) [00:48] m_3: and then maybe get a few of the things that can optionally use mysql | postgresql working that way so we can show how easy *that* is to switch out. [00:48] m_3: hahaha. :) [00:49] yeah, I did that with rails when I was putting together the basic pgsql charm [00:49] * SpamapS was distraught that he mispelled it minons .. glad somebody noticed it [00:49] swapped them out [00:49] m_3: I'm looking over the review, what's wrong with the env/xxx files? They're just variables - I wasn't sure how else to switch between variables for each of the functions in common.sh [00:49] is it minons? not minions? [00:49] m_3: the real kicker would be to also have a "mysql2pg" charm that does a migration for you [00:49] ha! [00:50] marcoceppi: it's no biggie at all.. just a mention that there are a lot of moving parts in the current setup [00:50] those files are sourced only from common.sh [00:50] so they could easily be functions inside of common.sh [00:50] So, if I put them in a fucntion, like source_upstream, and they weren't local, would they overwrite the global scope? [00:50] yes [00:50] shell's global [00:51] 1 → 75 of 43799 results [00:51] scoping in shell rubs me backwards [00:51] Hmm.. how long will it take me to triage all of these bugs.. :) [00:51] scoping in shell was an afterthought at best [00:51] it's biggest criticism in general [00:51] m_3: Thanks, I'll just throw them in functions, it'll look nicer since functions names are easier on the eyes than . env/upstream [00:52] heh.. and really.. scoping.. shell.. get a real language people :) [00:52] don't have to at all... just a style note [00:52] oosh? Object Oriented SHell? [00:52] _One day_ [00:52] oosh [00:52] and the windows version, woosh [00:52] now you're stepping into religion [00:52] and the darwin version.. oh [00:53] woosh... sounds like a commode flushing :) [00:53] rofl [00:53] * SpamapS wants to see a shebang, #!/bin/doosh [00:53] totally [00:53] * m_3 crying now [01:00] Doosh, Doing Object Orientation in SHell [01:02] marcoceppi: all it needs is an editor, and you can self-publish on Kindle and Nook. ;) [01:20] ooo, cacti would be an interesting charm.. and would get even more interesting as subordinate charms were added for things like snmpd [01:21] wow cacti is like.. dead.. :( [01:59] dumping snow! [02:00] haven't played with cacti in a while... usually just been nagios and ganglia... eager to try sensu [02:05] Another good sub-ordinate would be Splunk [05:22] is anyone writing docs for the lxc provider? [05:23] ah some in https://code.launchpad.net/~bcsaller/juju/local-troubleshooting/+merge/79193 [06:08] poolie: the main docs are at https://juju.ubuntu.com/docs/provider-configuration-local.html [06:08] got it thanks [06:09] poolie: of course, patches accepted. :) that is generated from lp:juju/docs [06:09] so it's now apparently stuck with just 'lxc-wait -n mbp-local-udd-0 -s RUNNING' waiting for something [06:09] poolie: that shouldn't need to wait too long [06:10] poolie: there are copious amounts of logs in the directory you've specified with 'data-dir' [06:10] https://code.launchpad.net/~mbp/juju/mbp-doc/+merge/86651 [06:10] :) [06:10] poolie: I think you want container.log or master-customize.log [06:11] The review queue is pretty long at the moment [06:11] * SpamapS takes a gander [06:11] i see [06:11] it's ok [06:11] hm so it just has "Starting container" as the last message... [06:11] there's no rush on the mp [06:13] poolie: has the container "booted" already? [06:14] in what sense? [06:14] poolie: like, does it have an 'init' and subprocesses like getty and such? [06:14] lxc-start's only child would be init [06:18] hm, lxc-ps --name mbp-local-udd-0 shows nothing [06:19] do you see any children of lxc-start at all? [06:19] there is no lxc-start (any more) [06:19] maybe i'll try running it again [06:20] poolie: interesting [06:20] poolie: is there an lxc-create running? [06:20] poolie: or lxc-clone ? [06:21] just lxc-wait [06:21] poor thing [06:21] stood up [06:21] just sitting there, nibbling on bread, with high hopes [06:24] poolie: usually the error will be found in container.log or master-customize.log [06:24] hm, run by hand i can see an error [06:24] not a very useful one [06:25] ah, container.log does have it [06:26] lxc_start - failed to spawn 'mbp-local-udd-0' [06:26] thanks [06:27] poolie: multiple users have reported odd issues where something bad happens to the lxc cache, which makes it fail to start all containers.. the resolution is to clear out /var/cache/lxc entirely.. though that does mean re-building all the master containers with debootstrap [06:28] I fear we haven't really spent enough time triaging that problem. [06:28] ok, i can do that [06:30] maybe there should at least be an error or if lxc-start exits [06:31] poolie: I think thats actually half the problem.. that lxc-start's errors aren't reported. [06:31] poolie: the other half is that lxc-start gets broken somehow [06:31] yeah; that may be out of scope for juju propery [06:31] *proper [06:31] but perhaps the docs can give a tip about it [06:31] shall i file a bug? [06:34] yes, give a look at the current bugs.. I *think* there may already been a report that just needs some more priority [06:34] poolie: and thanks for playing. :) [06:34] np [06:36] k https://bugs.launchpad.net/juju/+bug/907655 [06:36] <_mup_> Bug #907655: hangs when lxc fails to start < https://launchpad.net/bugs/907655 > [06:37] <_mup_> Bug #907655 was filed: hangs when lxc fails to start < https://launchpad.net/bugs/907655 > [06:38] i love 'destroy-environment' as a command name [06:39] it is juju's homage to the industrial revolution [06:39] juju hate-freedom [06:40] the go version will have juju club-baby-seals [07:00] SpamapS, so i guess 'ssh' to lxc won't work? [07:03] failed to spawn again, even after blowing away the cache [07:04] yes ssh'ing to them should work fine [07:05] poolie_: something else must be wrong [07:05] time for strace [07:07] poolie_: even the console of the container is logged, so I'd be surprised if strace helps more than that. [07:08] poolie_: but ultimately, you should be able to 'lxc-start -n mbp-juju-local-0' and see what happens [07:08] that's what i'm tracing [07:08] it also fails [07:08] it's not obvious to me why [07:08] i need to go in a sec [07:10] poolie_: me too.. hopefully we can figure it when you pick it back up. :-P [07:14] 'no distribution series: lucid' pushing a charm? [07:23] poolie_: the juju agents have some problems w/ python 2.6 [07:24] poolie_: oneiric is the first series that I *know* works.. natty also should probably work. [07:24] ok [07:34] and at some point in the very near future, I'll be officially opening up the "precise" series. :) [08:33] nijaba: heh, FTBFS .. oops, I forgot that you did that apt-get in the tests.. thats going to have to go away [08:33] * SpamapS fixes the build [08:57] SpamapS: ah, didn't think of that. easy to fix though, I just used pwgen to generate random files, I'll just grab bytes from /dev/urandom [08:58] nijaba: there are other things broken when running these tests in buildds [08:58] nijaba: $HOME is not always available [08:58] really? [08:58] indeed [08:58] SpamapS: what should I use? [08:58] I'm not sure thats the problem [08:58] :/ [08:59] there's some really really confusing double-negative logic that I can't tell is failing or not [08:59] [ ! something ] && something else && another [08:59] SpamapS: in my test result analysis? [09:01] nijaba: yeah, the tests fail after the pwgen thing.. but I can't tell why [09:01] (which may suggest that the error reporting on the code is poor) [09:01] SpamapS: log? [09:02] nijaba: standby [09:03] http://paste.ubuntu.com/778398/ [09:03] nijaba: thats after patching to do a mkdir -p $HOME/.ssh [09:03] + cat /tmp//tmp/juju-helpers-tmp.yTZqTrA/result [09:03] that looks odd [09:04] SpamapS: the failure is in the function, you do not get to the test of the results [09:04] heh.. mktemp -d alreayd has a /tmp prefix ;) [09:04] nijaba: ah, so the function isn't printing its errors? [09:06] ch_peer_scp -r -p $CH_portnum -o "-q" "$CH_TEMPDIR/sourcedir/*" "$CH_TEMPDIR/destdir/" > $CH_TEMPDIR/result 2> /dev/null [09:06] no, you're just redirecting them to dev null!! [09:07] SpamapS: that was just to keep the output "pretty" [09:07] lost connection [09:07] nijaba: the output should be pretty already, shouldn't it? [09:11] SpamapS: please see pm [11:12] hey everyone, actually off on my holidays now; have good ones one and all [11:13] * nijaba loves launchpad estimates: "6 minutes ago (estimated)" [11:56] Would anyone know why I get a make error 255 on a line that invokes sshd, while I can see in my build log that openssh-server has been installed? https://launchpadlibrarian.net/88141044/buildlog_ubuntu-precise-i386.charm-tools_0.2%2Bbzr102-4~precise1_FAILEDTOBUILD.txt.gz [14:08] jcastro: around? [14:55] jcastro, ping [15:22] hazmat: CONGRATS btw! [15:22] nijaba: reading your FTBFS .. are you still redirecting stdin/stdout to /dev/null? [15:23] SpamapS: nope. see my buildd-fixes branch [15:23] SpamapS: but I am stuck on this issue [15:24] which occurs before doing any tests [15:24] basically error 255 means "command not found" which is illogical since I added openss-server to the build deps and I can see in the log that it installs [15:25] off topic: Anybody have a preference of a hosting provider for hosting some Django code? [15:25] mchenetz: AWS? [15:26] hehe… It's too expensive for me [15:26] Or appengine [15:26] Any cloud based engine seems too expensive for me… My sites get about 6000 hits a day [15:27] mchenetz: appengine is free for quite a few more hits than that IIRC [15:27] hmmm… I thought i looked at that [15:28] LEtm e take another look [15:29] 5GB of bandwidth, 657,000 blob store API calls / day, 3,000/minute... [15:29] http://code.google.com/appengine/docs/quotas.html [15:29] 1GB of free data [15:29] you know what… I was thinkinging of Engine yard… I never looked at app engine [15:31] My fear about cloud services is that i am ring to get some hugh spike one month and owe a fortune. It may not be a valid fear, but i just don't know. [15:31] mchenetz: the free tier on appengine will just stop working before it charges you [15:32] Spamaps: even better… I will definitely try it out. :-) [15:32] SpamapS: I removed the need for pwgen in the test script btw [15:32] nijaba: ok [15:32] nijaba: the 255 may be sshd's exit code, not the shell's btw [15:33] SpamapS: hmm, did not think of that. But why? [15:34] nijaba: not sure.. but its a possibility [15:35] SpamapS: I wonder if they did not block the possibility to run sshd on buildds for security reasons [15:37] SpamapS: regarding your option to (keep|remove) the ssh keys, how would you see that? An additional explicit param to the copy functions? [15:40] nijaba: no just an additional step in the relation where it would be removed from authorized_keys after the copy [15:41] SpamapS: yes, but if I want to keep them, how do I say I do [15:41] oh, yeah another arg [15:41] or, more useful probably is to split the key exchange into its own set of functions [15:42] SpamapS: because without the keys, no possibility to issue a ch_peer_rsync/scp in a config-changed [15:42] SpamapS: again, I won't be able to do the key exchange outside of a peer-relation [15:43] so it is either you keep them, and you can do a copy in config-changed event, or you don't [15:44] You can though, in config-changed [15:44] You can just move the key into some other holding area [15:44] and only when the "copy stuff freely" config parameter is on, do you enable the key [15:45] SpamapS: how? every units receives the config-change event at once. you would then need to issue to set configs to do one copy [15:46] nijaba: if they're slaves, they move the key into authorized_keys. If they're masters, they try to do the copy over and over until it works. [15:46] SpamapS: hmmm... can try this. [15:47] nijaba: lets not try to solve all the world's problems right now though. :) [15:47] hehe [15:48] nijaba: do you have sbuild setup where you can try your build locally? [15:49] SpamapS: nope [15:49] pointers? [15:52] SpamapS, thanks :-) [15:54] mchenetz, heroku seems to be getting more popular, and works for django/python apps [15:59] hazmat: Very expensive when you scale workers and such [16:00] mchenetz for vms, linode and rackspace cloud are also competitive [16:00] about 20usd/month [16:00] hazmat: i had my credit card out for linode… I am still debating on it… I like that they are about 40 minutes from me [16:01] appengine is very nice if you don't mind platform tie in [16:02] hzamat: i am definitely considering app engine for my django stuff… I know you guys are ubuntu, but red hats open shift looks nice and give you a lot too... [16:02] with django-nonrel going out of style (not developed anymore), long term it probably makes sense to use the appengine sql support, though it also prices out a bit more. [16:03] I am surprised ubuntu doesn't have their own cloud based services yet [16:04] mchenetz, we do.. ubuntu is one of the most widely deployed operating systems in the cloud [16:04] yeah i know, but no infrastructure to sign up for as a service [16:04] mchenetz, you mean your surprised ubuntu doesn't have a free cloud hosting offering ? [16:04] yes [16:05] redhat and openshift are late to the game, their trying to catch up by offering free PAAS hosting [16:05] both appengine and heroku have a free tier [16:05] i agree [16:05] and AWS as well for new customers [16:06] I like the way you deploy to Heroku… I use Heroku fro my rails stuff [16:07] AWS is too slow with their micro nodes (Free tiers) [16:10] I think i am going to try app engine for my Django stuff and maybe Linode for all of my other traditional sites [16:10] I appreciate the comments and opinions. Thanks... [16:15] alternative to django-nonrel: http://django-mongodb.org/ ??? [16:38] lynxman: nijaba: either one of you planning to go to FOSDEM? Wondering if we can get a juju demo done in the “Open Source Virtualization and Cloud” (OSVC2012) devroom -> http://osvc.v2.cs.unibo.it/index.php/Main_Page#Call_for_Presentations_and_Workshops [16:40] of course the cfp deadline is...today :) [16:40] no..tomorrow [16:40] plenty of time! [16:40] robbiew: looked into it but can't go, I have my kis that we [16:40] they can come too! [16:40] lol [16:40] no worries [16:42] * robbiew will try to guilt lynxman into repaying the favor for LISA BoF ;) [17:35] hazmat: is there a weekly G+ this week? [17:52] * SpamapS is going to guess "no" [18:05] jcastro: no...unless you want to watch hazmat change diapers or something [18:06] lol [18:06] well you never know, the other guys might be doing stuff without hazmat around [18:06] I mean, things don't stop around here when clint goes on holiday [18:06] (or do they?) :) [18:06] they don't? [18:07] lol [18:12] in retrospect, we totally should've used 'charmers' for the more open team [18:13] charm-managers or charm-administrators is a better name for the other one [18:13] oh well [18:17] m_3: its a fair point. Unfortunately, charmers is encoded into charms now with the ppa.. so.. hindsight. ;) [18:24] http://www.moodlerooms.com/moodle-on-a-cloud/ [18:33] nijaba: around? [18:36] SpamapS: was about to leave [18:36] SpamapS: what's up? [18:37] nijaba: I think we have to break the API that you created with ch_peer_scp. echoing results is not a good plan for boolean pass/fail logic [18:37] nijaba: and that way, we can regain the -x for debugging [18:37] SpamapS: sure, what do you suggest? [18:38] nijaba: if you're ok with that, I'm going to press forward with it.. I'd rather break it now and fix the tests than have to rip it out so we can get charm-tools building again. [18:38] nijaba: just change the 'echo $result' to 'return $result' [18:38] SpamapS: go for it [18:38] nijaba: but that means all consumers of the function need to be updated if they are checking the echo'd result [18:38] nijaba: we also have to take out the 'exit's [18:38] turn those into return's [18:39] SpamapS: for now only one consumer, and it's not released [18:39] * SpamapS should have caught all this in reviewing, but was so enthralled with a working implementation, he missed it ;) [18:39] nijaba: ok cool [18:40] * nijaba leaves for dinner. back later [18:52] <_mup_> juju/ssh-known_hosts r458 committed by jim.baker@canonical.com [18:52] <_mup_> Merged trunk [18:59] hmm.. we may need to build our own clean $HOME for the tests.. I think that makes sense given ch_peer_scp's desire to populate $HOME with stuff [18:59] I think thats the issue actually [19:10] hrm, or it was *my* issue... not *the* issue [19:25] argh, ssh commands don't seem to care what $HOME is set to [19:28] jcastro: was there anything about that rails charm? I don't see anything back on it yet. [19:28] (although my scrollback is having issues with a few other channels) [19:36] jrgifford: did you submit it for review? [19:36] SpamapS: no. i was trying to figure out what the status of the rails charm here - https://code.launchpad.net/~mark-mims/charm/oneiric/rails/trunk [19:39] looks pretty out of date [19:39] still back in "ensemble" land :) [19:39] jrgifford: are you interested in trying to revive it? [19:39] SpamapS: that is correct, i am interested in trying to revive it. [19:40] do you recommend that I start with that, or start over from scratch? [19:41] * jrgifford has no clue what he's doing, but knows it needs to be done. [19:41] m_3: hey ^^ is that the latest rails charm you have? [19:42] jrgifford: it looks like a pretty decent start [19:42] jrgifford: charms for frameworks like that are really just scaffolding... you'll likely have to mod them up a bit to work with any real rails app [19:42] nijaba: are you back [19:43] except for one problem... it doesn't actually install rails, it just sets everything up for rails to be installed. ;) [19:43] SpamapS: yup, was planning on reviving it over the holidays [19:44] m_3: you should work w/ jrgifford [19:44] sure [19:44] m_3: oh, and don't use libmysqlclient16-dev .. 'libmysqlclient-dev' will always get you the latest one. [19:44] that charm installs rails through bundler [19:44] then it gets the version your app depends directly on [19:44] ok. so it does it from a gemfile then? [19:44] yup [19:45] ok. that's actually how i was going to do it. [19:45] it installs gems, then bootstraps gems to be able to use bundler, then installs your bundle [19:45] so that means i'm not completely insane with that idea. [19:45] teh only thing that's totally not done but should be is to use rvm [19:45] well, or it's shared insanity :) [19:46] well... i was working on that originally. [19:46] (rvm) [19:46] was using the railsready script as a starting place to kinda hack it together. [19:46] heck, I even have lots of rails apps that almost all use different versions of rails [19:46] so marrying that to the gemfile makes sense [19:46] thats true. [19:48] jrgifford: well you wanna work on that one together? [19:48] m_3: you betcha [19:49] BTW, I was planning on switching the charm itself over to ruby [19:49] to show juju to ruby/rails groups [19:49] that'd be slick. [19:50] appeal to the chef/puppet crowd, right? [19:50] similar to what I've done in lp:~mark-mims/charm/oneiric/varnish/trunk [19:50] m_3: why should it use rvm? ;-) [19:50] plan to extract the lib/charmtools out to charm-helpers-ruby [19:51] or perhaps using the chef gem to do most of it [19:51] m_3: like, is rvm really necessary for everybody? or just for those who like to marry themselves to one version? [19:52] rvm is really pretty common now [19:53] during the transtion between ruby 1.8 and 1.9, it's a pretty good idea to lock it down [19:53] common, but why? [19:54] perhaps less useful in another 6mos or so [19:54] because we'll have 1.9.3 in precise? [19:54] don't the vas majority of ruby users end up using 1.8 still anyway? [19:54] just a wild-guess, but I'd think half the rails apps deployed in the wild are on each [19:54] newer rails takes advantage of 1.9 [19:55] there're lots of motivations (speed) to move to 1.9 [19:55] Ok, but why do you need rvm for that? [19:55] you don't... rvm just makes it easier to say "my app depends on x.x.x version of ruby" [19:56] like gemfiles do with rails versions (and gem versions in general) [19:56] Heh.. which, btw, turns into a wonderful messy stew of requirements. ;) [19:56] like npm files do for node apps [19:56] yes, true [19:56] * jcastro comes back in [19:56] m_3: yeah, do it in ruby [19:56] but yeah, rvm is the way people do things [19:56] we need some more language diversity [19:57] but it manages to resolve them for the most part... just have to wait for the 'bundle install' to finish [19:57] Indeed, and rails devs will appreciate the hooks being in ruby [19:57] actually, let me rephrase, we need to have charms in the language that people who care about that service would be familiar with. [19:57] right [19:57] not just bash bash bash [19:57] hence the rails charm in ruby [19:57] m_3: we should consider making it easy to build debs of any version of ruby/php/etc. [19:58] m_3: just so that you can deliver a binary via apt, rather than bundler which may take a bit to get thigns done [19:58] I really liked your gem2deb [19:58] debigem [19:58] gem2deb is something else [19:58] oh, gotcha [19:58] perhaps somewhat inspired by debigem ;) [19:58] that worked really well with rails3 packages [19:59] yeah, gem2deb is now the standard way all ruby packages are built in Debian and Ubuntu [19:59] only problem is it bypasses the debian upstream versions [20:00] some people consider that a feature! [20:00] I'd be a big fan of tools that'd let us have more choice of ruby/php versions [20:01] m_3: so ruby in 11.10 and later *does* let you choose which interpreter handles /usr/bin/ruby [20:01] right... alternatives [20:02] Its meant to work a lot more like java.. where you just pick your jvm [20:02] That's pretty foreign to osx peeps though? do they have anything like /etc/alternatives? [20:03] don't know myself... still need to resurrect the tv for juju osx testing :) [20:03] speaking of, mchenetz [20:04] ready for wider testing? I want to tell the world! [20:04] whoohoo! [20:04] m_3: no, but I think at this point OSX people are used to things working vastly different on their real servers from their dev env. :) [20:04] yeah, good point [20:04] Hence vagrant and all the other ways to run VMs on OSX [20:05] just make it really easy to manage alternatives from capistrano, vlad, et al [20:05] good point... perhaps the charm should use version config settings and alternatives [20:06] talked to wayne (rvm guy) about packaging rvm... he wants to help [20:06] but that's a seeparate thing [20:07] jcastro: the easy_install version works pretty well… I am working on a slicker install though… I will probably have a new version over the weekend. I got a little tied up with work. Unfortunately, this isn't my full time job. :-( [20:07] cooh cooh [20:08] ok I'll just play it safe and not announce anything until the new year [20:08] unless you tell me otherwise [20:08] jcastro: As soon as i have a great install for everyone, i will help you announce it. :-) [20:08] \o/ [20:09] SpamapS: love to get your input sometime on what we've learned about packaging packaging tools like pear,cpan,cran,ctan,gems,npm [20:09] seems like it's a tough line to maintain [20:10] m_3: its not really.. [20:11] m_3: you package stuff when you want to stabilize it and support it [20:11] m_3: you let people use the tools when things are still in flux [20:11] Can I trigger a state in a charm? [20:11] Like an install error? [20:11] heck, it's the ruby community... constant flux [20:11] marcoceppi: exiting install with return code != 0 will trigger install_error [20:12] m_3: but there are tons of awesome ruby tools that use gems, like sup :) [20:12] SpamapS: What about during a config change which is doing an install? Should I just exit > 0 and walk away as the explosion goes off in the background? [20:12] m_3: so there is a need to stabilize and support those tools while not hampering people using gems. Thats why gems puts stuff in /usr/local :) [20:12] marcoceppi: that will be config_error then [20:12] marcoceppi: that'd be a good feature in general... the ability to set status... far wishlist though [20:13] Okay, I'll just exit 2 or something [20:13] * m_3 likes the visual of calmly walking away from the explosion [20:15] marcoceppi: can you explain further what you're trying to accomplish? [20:16] SpamapS: I see... so the process of taking a gem and stabilizing it into a package is the key [20:16] SpamapS: During phpMyAdmin charm, if you switch to or from upstream it essentially reinstalls PMA and sets it up again. I want to capture an "Install Fail" [20:16] we talked about manually poking transitions/states but backed off as it was very implementation oriented [20:17] hazmat: gotcha [20:17] m_3: http://devastatingexplosions.com/ [20:17] favorite [20:17] site [20:17] ever [20:18] blows away jono's sad trombone... literally [20:19] how is this not hooked up to juju destroy-environment yet? [20:19] just open the browser and do it [20:19] +1 [20:19] nice [20:19] * marcoceppi aliases command [20:23] so hey guys I had a new thought as I read jelmer and poolie talking about a launchpad charm [20:24] a use case I don't think we've put alot of concious effort into so I thought I'd just put it out there. [20:24] Charming a complicated service -> lower entry for contribution [20:24] so like if you ever remember LP hacking in the old days, vs. what a full charm would look like [20:25] yeah, they were talking about a pushbutton ec2 lp test env... perfect for a charm [20:25] right, but usually with charms I am thinking "if you make a charm, users can use your service quickly." [20:26] jcastro: oh, saw you filed the bug [20:26] and I rarely think about using it as a way to get a project's code in contributor hands [21:09] nijaba: so.. the tests are destructive to $HOME/.ssh (if they fail halfway through you get weird stuff in known_hosts and authorized_keys) [21:09] nijaba: ssh makes it near impossible to override ~/.ssh ... so I'm going to just skip all peer tests if ~/.ssh exists. [21:11] Dash experts, for dash functions, if you call $1 and there is no param passed will it go nuts? [21:12] Er, nvm [21:12] I'm having a hard time figuring out what this error means: lib/common.sh: 1: 1: parameter not set [21:12] with -u, yes [21:12] OH [21:13] ${1:-''} [21:13] pft, -u [21:13] Thank you! [21:13] Its silly, but it forces you to think about whether or not it is optional. [21:14] in this case, it is [21:14] but still, good to know [21:15] I've been so honed in on this issue, I forgot what I was testing originally [21:15] -u forces shell to be at least a *little* more like a real language [21:16] marcoceppi: try and test that, you're bound to get served [21:17] SpamapS: it works now :) [21:17] SpamapS: lovin... is what I got [21:18] totally stuck in my head now, thanks [21:19] * SpamapS can play the m_3-tar like a mutha-#$@!in riot! [21:19] unhuh [21:23] m_3: rvm or rbenv? I only use rvm, apparently rbenv is "nicer" though. . . [21:26] jrgifford: either... same here, I've heard good things about rbenv but haven't used it yet myself [21:33] man, I kind of want to write a charm in ruby now just because I'm tired of shell [21:36] yeah, it's nice to have hashes, scope, and real fn args [21:37] https://code.launchpad.net/~clint-fewbar/charm-tools/buildd-fixes-part-deux/+merge/86753 [21:37] Would appreciate a second pair of eyes on this [21:37] nijaba: ^^ changes ch_peer_scp's API [21:38] m_3: Finally, phpmyadmin is done! [21:38] marcoceppi: rockin! [21:38] I'd love a final look-over if you don't mind, before doing all that prog stuff [21:40] love those commit msgs that start with "Apparently I smoke crack now..." [21:41] :) [21:41] * SpamapS would like to remind everybody that bzr *does* have a rebase plugin if you accidentally "drunk commit" [21:44] SpamapS: I thought drunk committing was the whole use case for DVCSes ? [21:45] jelmer: its a corner case I'd say.. though, quite a lively corner. [21:46] SpamapS: It's too, non-intuitive. I like the way git handles it :) [21:46] Furthermore, all of my commits are drunken. [21:47] * SpamapS has yet to find something he likes in git [21:47] :-/ [21:47] I feel like I'm the only one. [21:47] SpamapS, you're the only one :) [21:48] +1 [21:48] git fanboy parade [21:48] some day you guys can show me why it doesn't suck :P [21:49] git tulez! [21:49] rulez! [21:49] marcoceppi: so, in meta/, you use "server_name" [21:50] what you assign to it isn't a hostname though... it's the _service_ name [21:51] Right, it still uses the IP [21:51] I thought you could put a "nickname" for servers in PMA but you can't [21:51] so it's moot to have it, for now [21:51] but service name is better verbiage [21:52] but server_name=${JUJU_REMOTE_UNIT%%/*} isn't going to be any kind of address [21:52] right, it's just the service name [21:55] m_3: I've renamed it to service_name [21:55] Though, it still not currently used. It's just there for future ideas [21:55] ah, ok I was digging around through phpmyadmin config to see where it was used [21:57] m_3: I could have sworn you could set the "name" of a server in PMA config, but alas you can't [21:58] When/if I figure out a way I'd like upgrading to be easy for people :) [21:58] actually, maybe the file should be the name of the service. [22:03] SpamapS: I approved https://code.launchpad.net/~clint-fewbar/charm-tools/buildd-fixes-part-deux/+merge/86753 [22:13] marcoceppi: cool... looks good [22:13] Cool, I'm out for a drink, when I get home I'll prog it up, blog it up, and ping jcastro [22:13] marcoceppi: I'll be in the usual places [22:13] SpamapS: you still owe me a blog! [22:17] jcastro crackin da whip! [22:23] jcastro: its in draft :) [22:23] marcoceppi: finished... go ahead and promulgate please [22:23] jcastro: phpmyadmin is out the gate [22:25] \o/