=== almaisan-away is now known as al-maisan [09:51] m_3: its ready for the charm store and been reviewed :) [09:51] i have it manually mirror both places atm, and then i setup a juju-drupal project so it would pull every few minutes, but it pulls to a diffrent branch [09:52] soo === al-maisan is now known as almaisan-away === Guest394 is now known as jrgifford [13:04] hi, good afternoon [13:05] one question, how can i debug a db-relation-joined hook? it doesn't give any error, but the code in the hook doesn't seem to be executing [13:14] Yolanda: Which charm are you trying to use? [13:14] sc-rm, i'm building a new one [13:14] i'm adding a relationship to postgresql [13:14] and i have a hook db-relation-joined [13:15] yolanda: Which language do you code your charm im? [13:15] sc-rm, its' just bash [13:16] youlanda: okay, then I would just do some echo in the places I suspect to not get hit [13:17] sc-rm, but how can i reach to that relationship in debug? [13:17] youlanda: I guess you do something like juju add-relation postgresql you-charm? [13:18] sc-rm, hes, juju add-relation openerp postgresql:db [13:18] the relationship seems to be creating, doesn't give any error, but there is some code to change a config file and isn't triggered [13:19] yolanda: anything in juju debug-log [13:20] juju add-relation openerp postgresql:db -e local [13:20] 2012-04-10 15:20:06,162 INFO Added pgsql relation to all service units. [13:20] 2012-04-10 15:20:06,163 INFO 'add_relation' command finished successfully [13:20] nothing in logs [13:20] fun [13:20] youlanda: have you looked at https://juju.ubuntu.com/docs/write-charm.html ? [13:21] sc-rm: i'm fairly sure this is about yolanda's what the 3rd or 4th one :) [13:21] i've read it [13:21] i have successfully create the install, start and stop [13:22] but the db-relation-joined gives me problems [13:22] * SpamapS stretches and yawns [13:22] moins SpamapS [13:22] yolanda: have you used 'juju debug-hooks' yet ? [13:22] yolanda: I think its what you're looking for [13:23] SpamapS, yes, i used it, but how can i retry a relationship? i never get into the db-relation-joined hook [13:23] i remove the relationship, i add it again, but i'm not placed into the hook [13:23] yolanda: if the state is just 'up', you need to remove/add it again. If it is in error, you can use 'juju resolved --retry unit/X db' [13:24] yolanda: are you sure you're not still *in* the hook? [13:24] the status of the relationship is that: [13:24] relations: [13:24] db: [13:24] - openerp [13:24] and that for openerp: [13:24] relations: [13:24] db: [13:24] - postgresql [13:24] is that ok?= [13:25] yolanda: can you install 'pastebinit' and just pipe the whole output of 'juju status' to it [13:25] ? [13:25] bcsaller1: good morning? [13:25] ok [13:27] http://paste.ubuntu.com/923267/ [13:29] yolanda: thanks reading [13:30] thx [13:30] yolanda: so yeah I would expect remove/add to throw you back into db-relation-* [13:30] yolanda: perhaps you need to exit debug-hooks and go back in ? [13:30] SpamapsS, so i just do a debug-hooks openerp/0 [13:31] and then remove add relation? [13:32] it doesn't place me in the hook, i just remain in the initial screen [13:33] yolanda: it should definitely place you almost immediately in the joined hook [13:33] doesn't do it :( [13:33] yolanda: can you run debug-log in another window and confirm that joined is being executed? [13:34] nothing in juju debug-log [13:37] SpamapS, so something is wrong with my juju charm? seems that nothing is triggered [13:38] yolanda: can you pastebin metadata.yaml ? [13:40] sure [13:41] http://paste.ubuntu.com/923287/ [13:42] yolanda: I suspect there is something more sinister going on. Can you try 'juju resolved --retry openerp/0 db' [13:42] perhaps the new status output is not as obvious about errors [13:42] The relation 'db' has no unit state for 'openerp/0' [13:42] 2012-04-10 15:42:32,817 ERROR The relation 'db' has no unit state for 'openerp/0' [13:44] yolanda: is this right after you added it? [13:44] yolanda: can you run 'dpkg -l juju' on your machine, and on openerp/0 ? are they the same version? [13:45] SpamapS, yes, just after adding it [13:45] let me check the versions [13:45] mm, not same version [13:45] local is bzr504 [13:45] openerp/0 is bzr518 [13:46] but i'm using local containers in juju, why are they different? [13:50] i'm using ppa as juju-origin, perhaps i need to use repo? [13:50] yolanda: well technically there should be no incompatibility between those versions [13:51] but in reality, I've seen a lot of subtle breakage with stuff like this [13:51] yolanda: just upgrade your local machine. 518 just landed yesterday. [13:51] yolanda: if that fixes it.. please let me know. We really have to stop breaking things in backward incompatible ways. [13:52] let me see [13:53] do i have to regenerate all the environment? [13:59] yolanda: hopefully no [13:59] yolanda: you might want to destroy the existing services [13:59] yolanda: but I'd try just with a new client binary [14:00] SpamapS, it gave some error, i'm destroying environment and creating new [14:03] yolanda: could you pastebin the error? [14:03] Thats actually quite critical since we plan to land one more version in precise .. I think [14:03] too late... [14:03] i just destroyed it [14:03] i'm running it again, let me check if the error shows now [14:07] I wonder would a "good" feature be to bootstrap a remote environment locally? So in the environments.yaml EC2 stanza say "local-bootstrap: true". Juju would spin up an LXC container instead of doing so in the intended cloud [14:08] I know you loose portability, but you could save money that way [14:11] marcoceppi: you can save money with 'placement: local' [14:12] marcoceppi: just remember to remove it after the first deploy. ;) [14:12] SpamapS: that deploys to the bootstrap, correct? [14:13] marcoceppi: though I have thought a lot about how to do de-centralized juju.. and one way I was wondering about was to run the zookeeper locally and have juju agents just connect to 127.0.0.1:xxxx and have juju clients ssh in and "wake up" the agents with the port forwarded. Feels very hacky. [14:13] marcoceppi: correct [14:13] <_mup_> juju/ns-from-env r479 committed by kapil.thangavelu@canonical.com [14:13] <_mup_> merge trunk [14:14] SpamapS: Right, I've been pondering different de-centralized ways to manage juju this morning, at least at a high level, and I couldn't really fathom another way than what's running now [14:14] marcoceppi: I think ultimately zookeeper should be ditched for a map of the nodes kept somewhere (S3 for instance).. and agents should just be responsible for their own data, and use 0mq to talk to eachother and feed their status back to object storage per-unit. I'm not convinced anymore that zookeeper is needed, though it *does* make things simpler. [14:16] marcoceppi: It makes me nervous how much vital information is stored in ZK. [14:17] anyway, time to wake up the family [14:17] SpamapS: so, an alternative would be to just maintain a map in the bucket then all the relation based data that may or may not be sensative is on each node within the juju agent? [14:17] marcoceppi: right [14:18] interesting [14:19] basically juju client would just much with a tree of intent (much like it does now) but instead of having ZK there with all of the other resulting data (like relation-set produced data), the agents would just keep that to themselves and message it back and forth. [14:19] s/much/muck/ [14:20] that way there's no one server that you compromise to pwn the entire environment. [14:20] * SpamapS goes upstairs to start shaking his toddler awake [14:42] Is there any way to tell which unit is the "head" in a peer relation? [14:43] smoser, thanks for the clue yesterday re cloud-init, it appears that rsyslog fails to start in the lxc cloud-image [14:43] wonders what the heck /usr/bin/whoopsie is [14:44] hazmat: just don't step on it [14:49] hey SpamapS [14:49] let's talk store for precise now that contest is nearly done [14:53] yeah I started working on testing all the charms last week [14:55] SpamapS: anything sticking out as a problem? ie. do you think this will be a big deal or just flipping the switch? [14:58] jcastro: no, initially most work fine. :) [14:59] jcastro: we should have a period where we invite ~charmers to fix them all, and I need to ask the launchpad guys what will happen when there is already a branch present.. but i think we'll have this wrapped up by next week. [14:59] ok [15:04] hazmat, why no syslog ? [15:04] do you know ? [15:05] as i might have been about to ask SpamapS on a similar question [15:05] oh. [15:05] lxc [15:05] smoser, haven't really debugged it yet.. it fails to start [15:05] /dev/log [15:05] smoser, yup [15:05] probably [15:05] lxc container does not probably have access to that device node [15:05] does that make sense to you? would that be able to kick you in the right direction to fix it ? [15:05] or you want more direction [15:06] s/fix/test change/ [15:06] smoser, doesn't exist in the container [15:06] right. because it can't get created [15:06] because lxc wont let it. [15:06] er... app armour or what not. [15:07] hazmat have you found a bug about rsyslog on lxc? [15:08] I saw that because it prevent cloud-setup to be fire [15:08] avoine, well it doesn't start in particular on the cloud-image which causes issues for cloud-init's config which juju relies on. [15:09] smoser, at this point i'm just going to punt till after precise, it was a big change to even try at this point, even though the code delta is small [15:09] smoser, as far as hints.. though i'm all ears [15:10] oh. wait... maybe we can fix this via cloud-init data. [15:10] wait. [15:10] no [15:10] rsyslog is going to use /dev/log [15:10] we need access to that in the container [15:11] smoser, looks like just killing the app armor profile for rsyslog gets it to start [15:11] and then cloud-init config is happy [15:11] hm.. [15:11] iwould have thought youneeded access specifically to mknod from one of the lxc configs. [15:11] but... ok. [15:12] my suspicion is that /dev/log is not containerized [15:12] hallyn or stgraber can probably provide insight on what to do here. [15:13] smoser, not sure, i don't see the messages from the container in the host.. [15:13] oh. wait. [15:13] /dev/log is just a socket. [15:13] and rsyslog sets it up [15:14] so, yeah, containerized. [15:14] i was thinig it was a dev node. [15:16] smoser, so its just the app aromor pollicy [15:16] oh.. double typo, extra points [15:20] when i try to use 'juju bootstrap' with --constraints specifying more than one constraint i get errors: http://paste.ubuntu.com/923438/ [15:21] i'm following the example shown at https://juju.ubuntu.com/DeprecatedEnvironmentSettings [15:29] hazmat: smoser: could you tell me if you fill a bug about the rsyslog issue? I would like to follow it. [15:29] hazmat, ^ can you file one? open it against lxc. [15:29] i'd do it, but you ahve more context. [15:31] smoser, avoine sure [15:31] thank you [15:56] avoine, smoser its bug 978147 [15:56] <_mup_> Bug #978147: rsyslogd fails to start in cloud template < https://launchpad.net/bugs/978147 > [15:56] ok thanks again [16:21] SpamapS: man , dunno if your a rock fan or not , but I just bought the new Halestorm album, if you are even a little, dont hesiate get it now! dude most sophmore albums suck, or at least dont stack up to the first, this one blows the first out of the water [16:22] imbrandon: I'm disconnected from all new music unfortunately. I still just rock out to Pantera's Vulgar Display of Power when I need something with kick [16:23] yea definaltly along the same lines, dude i broke my nose at that tour [16:23] on* [16:23] in the moshpit [16:23] haha [16:23] Its my hockey music [16:23] :) [16:23] ONETWOTHREEFOUR!!! [16:23] hells yea there is some reason i knew i liked you hahahaha j/k [16:24] Honestly lately I just listen to Billy Joel. I need to chill more than I need to get amped up. [16:24] :) [16:25] they got a little chill on the album, like "heres to us" more like an 80's powerbalid [16:25] lemme see if i can find it on amazon, i think they let you preview it [16:27] http://www.amazon.com/Heres-To-Us-Explicit/dp/B0070R94SK [16:27] yea there is a preview [16:27] its the slower side of the album [16:28] this is the one that made me buy the album instantly http://www.amazon.com/American-Boys/dp/B007ONQC4Y [16:30] and of course i have the first album too and seen em in concert 2 times now at Rockfest KC, bigest one day music fest in america ( 55k people, one day, 12 hours, 2 stages, hell yea ) [16:36] err, I think you guys broke compatibility between juju versions 0.5+bzr504-1juju4~oneiric1 and 0.5+bzr518-1juju5~oneiric1 [16:37] In this case, should I just run a apt-get upgrade on the bootstrap? juju status is giving a weird error ATM and I think it's because the juju versions mismatch [16:39] marcoceppi: certainly worth a try. Can you maybe document the errors so we can try to avoid such madness in the future? [16:39] * SpamapS really really wants to implementat version stability [16:41] SpamapS: I understand I'm in the ppa version, so I expect some breakage. What would be best for you guys? [16:41] as far as documenting errors and giving enough details [16:42] <_mup_> juju/must-specify-relation-name r516 committed by jim.baker@canonical.com [16:42] <_mup_> Client side check [16:44] SpamapS: hey... so blacklisting charms from testing [16:44] I blacklist the openstack ones because they're already tested elsewhere [16:45] but take buildbot-slave for example... [16:45] it requires config to even install [16:46] m_3: should charms like that include a default.yaml for config then? [16:46] I can either blacklist such things or bump them back to the authors and require them to have enough default config to at least "start" [16:47] I'm tempted to bump them back, but just wanted peeps opinions on that... so we're requiring all charms to at least start when we're reviewing [16:47] marcoceppi: yeah, we haven't been too strict with it though [16:48] marcoceppi: really it's enough default values in the config.yaml... not a default.yaml to pass [16:48] that's more work for the testing framework [16:48] m_3: I think it's a good idea to have enough defaults in config.yaml then [16:48] yup [16:48] it's strange for some charms though... buildbot-slave is a perfect example [16:49] it's a general tool... defaults don't make sense really, they'd be put there _just_ for our testing purposes [16:49] I'm cool with that tho [16:50] SpamapS: http://paste.ubuntu.com/923559/ [16:52] SpamapS: so upgrading the bootstrap didn't work, I guess I'm just going to have to destroy/re-bootstrap? [16:55] * marcoceppi wonders how to best upgrade the omg env without downtime [16:55] marcoceppi: dang, we've got to stop breaking the api between the cli and existing bootstrapped environments [16:55] it's almost like you've gotta balance across two environments [16:55] m_3: I have a question, it might be easy to hold the package on my local machine, but doesn't each deployment/add unit install the current juju package? [16:56] So holding the package on my machine wouldn't really save me in the future from the units being out of sync with each other [16:56] I've never gotten a variation of that to work... always ended up having to destroy/reboostrap [16:57] marcoceppi: are you using origin: ppa? [16:57] or distro? [16:58] marcoceppi: right, the only way to make it truly repeatable is to stick juju in a bzr branch [16:58] well, even that's been changing [16:58] marcoceppi: we *must* change that [16:58] right... gotta freeze juju [16:58] I made a proposal for that [16:58] but its seen basically no response [16:58] m_3: ppa ATM [16:58] other tham +1's from hazmat here on IRC :) [16:59] with distro, will I be able to do placement: local and in subsequent upgrades of the distro what's to say it won't break the current deployment like the PPA did? [16:59] marcoceppi: do you still have the affected environment? [16:59] SpamapS: yes [16:59] it's the omgubuntu env [16:59] marcoceppi: can you do 'juju -v status' ? [16:59] oh [16:59] awesome! [17:00] [17:00] marcoceppi: deploy on new ones and swap the ip is the only other option, but use the elastic ip [17:00] for no downtime [17:00] SpamapS: it's okay, I can create a new env on the ohso AWS, bootstrap, deploy, add-relation, then move the elastic ip [17:00] imbrandon: yeah, that's the plan ATM [17:00] I think its time for a stable PPA [17:00] Been thinking about it for a long time [17:00] SpamapS: <3 [17:00] :) [17:00] with a ridiculous number of tests before upload [17:01] SpamapS: http://paste.ubuntu.com/923597/ [17:01] and one of them will need to be "works with the last version" [17:01] marcoceppi: might be worth really balancing (dns) between the two different environments... instead of just a manual failover [17:01] yeah [17:01] depends on the data [17:01] SpamapS: can we add works on osx too ? /me ducks [17:01] m_3 ? [17:02] looks like zookeeper was broken without bumping the version number [17:02] imbrandon: don't duck, stand tall.. and donate a mini? ;) [17:02] i actually probably could [17:02] i got an extra [17:02] whoohoo! [17:03] its an older one, but it will run 10.7 easy nuff ( intel core 2 duo ) [17:03] marcoceppi: m_3 i think that would require dood to be using route 53 dns [17:04] imbrandon: ideally we'd run a VM of Lion and Mountain Lion [17:04] marcoceppi: two different juju envs... A and B... name balances across elastic ips in both envs. Then you can make changes to one at a time and pull it out of rotation upon failure [17:04] it's more $$ tho [17:04] SpamapS: oh thats easy, got any actual vmware products running, osx will legitly load in those [17:04] from 10.7 on [17:05] m_3: then it's probably a no :) We're looking in to placement: local for mysql+bootstrap now to shave off another small [17:05] right [17:05] plus, not sure how the db sync would work [17:05] marcoceppi: replication :) [17:06] yea or rds [17:06] rds would be overkill for their use wouldn't it? [17:06] now sure how to configure that in the existing charm infrastructure since bootstraps can't talk to each other (yet) [17:06] yup [17:06] awy overkill [17:06] way* [17:07] SpamapS: dumb question. I am on precise, and using all "ootb" parts, like distro not ppa, etc. Since I can't deploy "juju deploy subway" since the precise store isn't open, should "juju deploy cs:oneiric/subway" work? [17:07] marcoceppi: no, the envs wwould be totally isolated [17:07] * imbrandon really needs to fingure out how to bootstrap into hp cloud then i can test all kinda finky configs [17:07] marcoceppi: oh wait, you're right... replication [17:08] we'd have to make it a config parameter... we want the environments as isolated as possible to provide availability [17:09] negronjl's done some stuff with this... it was mongo, not mysql replication, but something similar could be done for mysql [17:09] SpamapS: but yea the mini dshould be able to handle that no problem, it will just be choked on ram, i thnk 4gb is the max for that generation [17:10] SpamapS: but even today vmware has a special clause in their products with apple and can run osx, its how the big hosting companies get away with osx vps's [17:11] i know fusion, esx , vsphere and workstation all work, not sure a bout plain old player [17:11] marcoceppi, m_3: The db sync would have to be a completely different approach ... they're diff. monsters [17:12] This is all hypothetically not going to happen for the omgubuntu install, since it's more $$, btw [17:12] negronjl: 1-way, right... but the basic idea of adding the replica's ip addr as a config param to the master... [17:13] marcoceppi: understood... sorry, just brainfarting out-loud [17:13] m_3: yeah ... that principle could work [17:13] well sorta-outlound :) [17:13] heh [17:13] Feel free to keep farting, I just didn't want anyone to get too serious about ZOMG LETS DO THIS [17:19] wow Kubuntu was "picked-up" i think that might be bigger news than the post leads on [17:19] jcastro: you could just set default-series: oneiric too [17:20] SpamapS: yeah I was just wondering if I should just stick to all oneiric [17:20] but I want this precise hotness for LXC, etc. [17:20] will the charms roll over like packages do ? [17:20] or does that not matter, my host is precise right? [17:21] imbrandon: yeah clint just needs to finish off some testing and stuff on it [17:21] we need to do the rollover sometime soon [17:21] cool [17:21] jcastro: we'll fix this by opening the precise charm store soon [17:21] SpamapS: yeah it's just hard to demo the contest winners but having to put a "by the way if you're running 12.04 this won't work." [17:22] so I announced the winners and then later on I will do the demo commands and stuff for each one [17:22] jcastro: it will work, if they put 'default-series: oneiric' [17:22] jcastro: or 'cs:oneiric/foo' [17:22] jcastro: or you wait a week and we push hard to get it open [17:22] jcastro: charms are always developed against the current release, not dev [17:23] hey while i got everyone in the same room, m_3 anything special i need to do besides manually mirror for now ? jcastro will you promgstrangualte drupal and where do i start down the path to get my 2 acks myself [17:23] working against precise should be gravy at this point for charms.. not required [17:23] m_3: yeah I just wanted my cake [17:23] m_3: perhaps we should automatically push charms that have not diverged into the dev release when they pass tests on the dev release [17:23] SpamapS: hey so not doing a default-series:oneiric worked anyway [17:23] that would be simple logic [17:23] imbrandon: you still need a final review on the drupal charm before promuglation [17:23] SpamapS: but we probably don't want to tell people to do that [17:24] doh, marcoceppi sorry thought that was done [17:24] sorry [17:24] SpamapS: but then the author's automatically maintaining two releases of the charm? [17:24] m_3: not really. they only have to maintain when the tests start failing on the dev release. [17:24] m_3: they do with packages, i dont see that as a problem [17:24] imbrandon: It looks like you fixed the mysql error thing, so I'll spin it up one more time (didn't get the bug reply for somereason) if it runs then it should be ready to go [17:24] ok [17:24] hello from the subway charm! [17:24] marcoceppi: rockin [17:25] jcastro: sweeeeet [17:25] man subway is so sexy, it's my new demo charm [17:25] jcastro: how do you make subway persistant damn it, i had to go back to irssi [17:25] imbrandon: drupal'll be mirrored automatically in github.com/charms once it's in the store... then pull requests can go off of that mirrored branch [17:25] jcastro1 awesome! [17:25] imbrandon: run it on another machine you don't turn off [17:25] sure then i close browser and it d/c [17:25] no [17:25] node.js keeps running [17:25] its still online [17:25] oh, it's designed for multi user, you need to create an account on it [17:26] and just relogin next time [17:26] it was on me, i couldent reconnect [17:26] ohhh [17:26] i never made acct [17:26] yeah [17:26] ok thats my missing part [17:26] imbrandon: that's nice because you can have multiple people on one deployment [17:26] m_3: rockin, ok for now i've been manually pushing to both and have each in the others .ignore file [17:26] "here's my work IRC." done. [17:27] jcastro: yea i'll likely redploy it on the box i run irssi from , i love it, just condent figure that bit out [17:27] i was thinking it was a one user deal [17:27] alice irc in the charm store is the one user one [17:28] yea [17:28] SpamapS: yeah, I guess that makes sense once we hit some milestone like beta2, then all charms get promoted and tested against the dev release [17:28] so we're behind :) [17:28] SpamapS: btw i've had "walk" on repeat now for 45 minutes, lol , time to change the tunes [17:28] your fault [17:30] marcoceppi: yea it should have just been a matter of changing it to the mysql not mysqli driver on install [17:30] i got some more goodness in store but testing it on brandonholtsclaw.com now, as it breaks some of the default drupal functionality [17:30] as is [17:31] but takes it from 20 r/s to like 160 r/s ootb [17:31] :) [17:31] mysqli is *awful* [17:31] do not use it [17:31] mysqlnd ftw [17:31] yea i dont and will when 5.4 hits [17:32] 5.3 nd is awefull too [17:32] Tho I don't know if we have it enabled yet on 5.3 in precise :-P [17:32] imbrandon: it still beats mysqli [17:32] yea , just dont, its bad [17:32] i've been using the 5.4 ppa [17:32] apc is broken tho [17:32] thats bad [17:32] hey everyone [17:32] ello [17:33] the debian 5.4 ppa that is [17:33] something about it is breaking apc right now, not sure what though, i cant get past segfaults [17:33] thus the charm still using 5.3 [17:33] a few days ago I talked about promulgating my kusabax charm, but I'm not sure how to do it [17:34] but the 30% increase in perf would be nice [17:34] aargh! if I upgrade my cli, I can't talk to deployed envs... if I don't, I can't deploy new ones [17:34] i officially changed that command to promgustrangulate [17:35] imbrandon: haha [17:35] * m_3 groan [17:35] catch 22 [17:35] m_3: it's funtastic! [17:36] I'm gonna snapshot VMs to run the cli for each long-running env [17:37] and start freezing branches [17:37] i'm thinkign we;re gonna start to see that lots in here [17:37] the growing pains of rolling releases [17:41] actually, that sounds like a great role for wrap-juju in juju-jitsu... like a virtualenv [17:42] oh :( [17:43] read environments.yaml to get the branch for each environment and update path accordingly... hmmm [17:46] SpamapS: mmmm juju deploy osx/10.8 :) [17:55] SpamapS: m_3: you guys feel like hanging? [17:55] I have some questions about the documentation for review in that bug jdstrand filed [17:55] jcastro: in 10 [17:56] jcastro: sure [17:58] lemme grab some more coffee, then I'll be on [18:08] Is there a way to get peer-relation information in the install hook? [18:08] marcoceppi: with the new relation-ids thing, yes! [18:08] fantastic! [18:09] SpamapS, marcoceppi there's definite awareness of the foobar that is consistent versions... the bzr branch atm is the realistic option.. going forward, having bootstrap stick a code copy on provider storage, and deploying from provider storage is probably the right solution, package solutions get messy both for consistent versions and for cross release [18:09] SpamapS: can I bother you in the #juju-wordpress room for a few mins. Having a hard time figuring out the best way to proceed with something for omgwp [18:10] hazmat: that would be beneficial, if the bootstrap deployed the same juju version across all nodes. that way I can just hold the juju package on my desktop until a more "structured" release update schedule is created [18:10] imbrandon, that reminds there was a fun php article on hacker news today, in informed hater style, http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/ [18:16] Can you have more than one charm deployed to the bootstrap? [18:18]