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