=== ahs3` is now known as ahs3 [03:29] m_3, gluecon looks awesome [03:29] m_3, pls do a write up [03:29] * hazmat is wishing he had gone [03:31] hazmat: yup will do... it was great [03:31] wish they would've accepted my talks... [03:32] m_3, "RT “@adrianco: If your instance AMIs depend on an external repo to configure post boot you have a big SPOF.” <- Bingo.." [03:32] hopefully that'll be different next year though... juju came up in a couple of presentations... and I talked to folks a lot [03:33] m_3, right on [03:33] s3 repos hopefully ftw [03:33] that guy's talk rocked! [03:34] they manage lots of static amis though... they're quite ripe for something like juju [03:34] and it was nice to realize we'd been just playing with more scale than they usually use for one app [03:35] (most of their load is really in big CDNs... not on ec2 proper) [03:40] m_3, did you see derek richardson's talk? [03:41] er.. collison [03:54] * hazmat googles for all the slides he can find [05:07] guys, is there an indirect way to deploy joomla through juju? [05:11] JoseeAntonioR: My cousin might bring me some Brazillian Pisco ;) [05:12] bkerensa: what the... I think there's no brazilian pisco! [05:12] :D [05:13] we shall see [06:41] JoseeAntonioR: somebody wrote a joomla charm once.. its been a while though === popey_ is now known as popey === elmo_ is now known as elmo [13:35] SpamapS: happen to know a list of deps for charm-tools ? finally getting it ported to osx today ( or trying ) and seems to be missing a few things, works over all but like proof gets this [13:35] bholtsclaw@ares:~/Projects/local/charms/precise/newrelic$ charm proof [13:35] abort: Unknown script hl [13:35] usage: charm [ --help|-h ] [ script_name ] [13:35] script choices are: [13:35] /usr/bin/charm: line 14: exec: list_commands: not found [13:36] most of it looked to be bash when i perused the source, but i dident inspect everything [13:38] ohh nevermind [13:39] its fskin bsd's readlink is broken [13:39] and thus OSX's [13:39] i always forget that [13:39] * imbrandon patches [14:27] imbrandon: the readlink thing can be solved by installing GNU coreutils IIRC [14:27] imbrandon: we need to get rid of the readlinks I think [14:28] imbrandon: I was thinking I'd switch charm-tools to work like juju-jitsu, with autotools setting the dirs, rather than trying to be all clever :) [14:32] yea, that would rock, there is a bit more too but i'm on the phone [14:32] one secd [14:32] and yea i installed coreutils via brew [14:32] to semi solve it === mbarnett` is now known as mbarnett [14:58] anyhow yea, sed is diffrent etc too but gnused is installed via brew too [14:59] problem is without autotools its a PITA to switch everything cuz the gnu coreutils are prefixed with g on osx [14:59] so ginstall gsed etc [14:59] you CAN put them in the path before the BSD ones but it breaks other things [14:59] sooo i'd rather not do that, esp in a package i plan to distriubute [14:59] :) [15:00] * imbrandon is trying to think of the best way, but i think a ./configure that has some if/else for the platform will likely be the best [15:00] then i dont have to maintain a patch, and it can be "upstreamed" except for the install forumla like juju [15:02] ideally i've been working on a way to upstream it ALL if possible but in a way that the current ubuntu devs / maintainers dont have to care it is or really even realize it [15:02] etc [15:02] still a WIP :) [15:08] oh hey SpamapS , thought of something new, with the Author spec just now going in, would it be wise to diffrentiate the Author and Maintainer like git ( and i assume others like bzr but do not know ) seperates the author and commiter for commits ( e.g. a sponsored commit ) in the metadata , i think that would allow for something akin to what we're wanting to do with per-charm-commit access to be a little clearer too that way, kinda like the diffre [15:08] not 10000% sold on it, but figured now would be the time to bring it up rather than later [15:13] hrm , ok totally seperate train of thought here, back on my coreutils and other gnu/bsd tools "issue", how far fetched do you think it would be to have on install the juju and related tools create a chroot env or something like the python virtualenv that puts the gnuutils and the many other things i've come accross so far that would be ok to hack on MY machine but not good for long term or wide use, so a terminal could be fired up on osx and then [15:14] sounds complicated but i think it would be a lot less complicated than the current hacks i'm contemplating and would work other distros too with very little care for their current setup that way [15:15] because really in every context juju cares about OSX is just a BSD* distro [15:37] Author spec? [15:38] err the maintainer field [15:38] got myself mixed up [15:40] i'm not sure if a separate author spec is adding significant value [15:40] yea [15:40] not really a whole spec [15:40] just mean while were adding maintiner field to the meta data it mighjt be good idea to add author also [15:41] as to have a clear seperation [15:42] and really was just a passing thought, it might not be all that great, but it is done in other things like RCS and debian packing so not tooo far fetched [15:42] but figured now instead of a month from now would be the time to think about it [15:42] I think, for the most part (and quite some time) the author will be the maintainer [15:43] likely so for 99% of them [15:43] was more of to not have to change it later and go though a change again since we;re making one similar change now [15:43] tis all [15:43] but yea your likely correct [15:44] btw heya marcoceppi , hear you had some of that nasty bug too, hope ya feelin better [15:44] much [15:44] :) [15:45] i got it pretty bad for a few days but i dont think near as bad as you from what jorge said [15:45] btw that tillo mashup thing is slick , nice job :) [15:45] twillo* [15:47] trello? [15:47] :) [15:47] oh yea twillo is the sms thing [15:47] i always mix them up [15:48] marcoceppi: yeah, I agree, your mashup is cool [15:48] strapello? [15:48] yup [15:48] yea [15:48] thanks :) need to push up some caching so Jorge's page doesn't take three years to load [15:48] hahaha [15:51] todays goal for me is to finish wrangling the kickstrap ubuntu them into a sphinx theme and base django app for the ubuntu-community-themes pkg, i'm like 99% done , well i am done with the django one , sphinx close but its a weird templating lang [15:53] hazmat: latest plan on fixing the oneiric stacked branches was to rename the base (precise) branches back, then fixing the stacking, then renaming the precise branches again. This sounded like a complete clusterquack to me... I'm gonna explore other options. nothing new from the lp team, they were mostly focused on lp changes to prevent problems in the future. I'll chase clint down and brainstorm once there's more caffeine in the mix. [15:54] SpamapS: please budget a little time to discuss ^^ later today [15:57] m_3, hmm.. yeah.. that seems like a reasonable solution, cluster quacky indeed.. but we need to restore access to fix.. er break.. and then rename. [15:58] that's all kinds of retarded i agree [15:58] * hazmat dons a PC hat [15:58] no offense intended [15:59] m_3: I think thats actually an ok plan. [16:00] Its just a result of the weird distro model which we've inherited. We won't repeat the problems with quantal [16:01] this weekend then [16:01] SpamapS, you mean do the invalid restack, to only temporarily make the branches in accessible prior to renaming.. [16:02] maybe we can even arrange to have a lp superpower person available too [16:02] the ideal solution james_w pointed out was stacking on the id [16:02] er. the branch id [16:02] so it doesn't die on rename [16:02] hazmat: bugs are in to fix that going forward [16:02] but it won't help now [16:02] well... maybe it would [16:03] there is a way to avoid breaking all the precise branches while doing it [16:03] but it's more work [16:03] oh? [16:03] james_w: do tell [16:03] hazmat: yes, that would be good. Another good solution would be to fix the charm store/charmworld to not care about the branch name for official branches [16:03] the stacking could be fixed directly, but someone would have to work out the branches they were supposed to stack on, and find out the ids of them [16:04] james_w: oh... that doesn't seem to bad then [16:04] james_w: is the ID not accessible via LP API/ssh+bzr ? [16:04] SpamapS, hmm, maybe it is [16:04] james_w: and a _whole_ lot safer [16:04] i.e., can be done right now [16:04] not directly that I know of, but it's possible it's available [16:05] m_3, its not something we can use right now [16:05] m_3, even if it was available [16:05] what would renaming the precise branches break? [16:06] james_w: access via the lp:charms/precise aliases... as well as access via the store ( juju deploy mysql ) [16:06] james_w, long term nothing, temporarily it would break anything looking for charms, and existing branches that want to pull/push [16:06] er.. on the push side it might get uglier [16:06] if somebody pushes in the middle of this op.. [16:06] james_w, m_3, it won't break the store [16:07] scheduling it over the weekend is just a crapshoot [16:07] huh? [16:07] the store assembles zipfiles for download [16:07] sure it will... the store is looking for [16:07] it doesn't serve directly from bzr [16:07] oh, you mean the store has it cached [16:07] ok [16:07] the store won't see anything new, but it's not going to delete all the charms is it? [16:07] it polls bzr to look for new revs [16:07] james_w, no the store and charm browser never delete things === wrtp is now known as rogpeppe [16:07] and it would presumably pick up again when they were renamed back [16:07] the lp:charms/precise aliases won't break [16:08] hmm.. actually the charm browser will.. on the assumption that the upstream branch changed.. but it will fetch them again when their back in place.. the metadata would remain though [16:08] and modern bzr uses those I believe, so most pulling and pushing would still work I think [16:08] well maybe I'm just being a panty-waiste then [16:08] * m_3 puts on _his_ PC hat [16:09] not renaming would be better [16:09] but likely needs help from someone with lots of LP internals knowledge, and probably a web-ops too as it will probably require some db/fs syrgery [16:10] the rename is API doable [16:10] as is the stacking change [16:10] so we'd have, what, 15 minutes of exposure? [16:10] I say do it [16:10] yup [16:11] its not ideal as a long term solution for other rels, but it works for restoration [16:11] ok, I'll test it out on a single branch and then go from there if that works [16:11] SpamapS, the stacking change can be done over the API? [16:11] james_w, so if we wanted to do this in the future with out running branch-distros.. could we just push the branches and then set some api flag to mark the series active? [16:12] ie.. bypass most of branch-distros [16:12] hazmat, yeah, you could [16:12] you can't manipulate the series, but that's disjoint anyway [16:13] once the series is created, you can push the branches, then use the API to make the official branch links [16:13] but it's a one-line fix to branch-distro to avoid this [16:14] it doesn't get the new branch names "right" but I understood that was going to be changed in the charm store anyway [16:16] james_w: well not API, but we can bzr reconfigure and push, right? [16:16] SpamapS, I don't know if that will change it to stack on the id rather than the name [16:16] we can experiment [16:16] SpamapS: that's my understanding of the current plan... still needs to be tested [16:16] Oh I was thinking of just changing the stacked on name. [16:17] there are a couple of scripts we can run to definitely fix it up from the LP size while the precise branches are renamed [16:17] we rename the base, then bzr reconf, then push that back up, then rename the base back to trunk [16:17] the ID is a nice idea, but if I can't get it, I'd rather have a solution for today and then fix the net distro branching. [16:17] you can't reconf to a name that doesn't exist [16:17] hmm [16:17] s/net distro/next distro/ [16:17] how about this [16:17] right, so we rename /trunk back to /precise (the base braches) [16:17] 1. branch from the correct name to the wrong name for the branches for precise [16:17] james_w: heh right, so we rename, branch, rename, reconf, push [16:17] 2. done [16:17] _then_ we should be able to reconfigure [16:18] james_w: Ahh so just fake it basically? [16:18] * SpamapS tries that [16:18] SpamapS, it's perfectly valid from bzr's point of view, just a bit messy [16:18] might confuse a few people [16:19] it could be cleaned up, but there would be working branches with no interruption [16:19] oh, so you mean we create new /precise's instead of renaming from /trunk? [16:19] * SpamapS tries it w/ hadoop-slave [16:19] cool [16:19] m_3, yeah, they will stack on trunk, which will make for slower access to the oneiric branches, but it should fix them [16:19] since that one is borked in precise anyway [16:20] works [16:20] james_w: I knew we gave you a laptop for a reson. [16:20] reason even [16:20] so we still bzr reconfigure those branches too? [16:20] somebody give me a new keyboard ugh [16:20] heh [16:20] m_3, that would be good [16:20] or just leave the fake-out in place? [16:20] lp:charms/oneiric/hadoop-slave works [16:20] whoohoo! [16:21] well that was a lot easier than we were making it :) [16:21] I don't know if it will stack on the id at that point, so no-one is allowed to rename the precise branches again [16:21] all I did is push lp:charms/precise/hadoop-slave -> lp:~charmers/charms/precise/hadoop-slave/precise [16:21] right [16:21] bzr branch -d lp:charms/precise/$charm lp:~charmers/charms/precise/$charm/precise [16:21] but we really should bzr reconf, then we can remove the extra /precise branch [16:21] someone in ~charmers can put that in a for charm in $charms loop [16:22] m_3, +1 [16:22] james_w: does that pull/push automatically or does it happen all on the other side? [16:22] stacked on: /~charmers/charms/precise/hadoop-slave/precise [16:22] still stacked on the name :) [16:22] SpamapS, it's client side, it's just easier to type :-) [16:22] james_w: gotchya. Doing that now [16:23] err, I probably got the paramters the wrong way round [16:23] bzr branch lp:charms/precise/$charm lp:~charmers/charms/precise/$charm/precise [16:23] or whatever works, you get the idea :-) [16:23] bzr reconfigure --stacked-on lp:charms/precise/$charm lp:charms/oneiric/$charm is the next step I think [16:24] james_w: yeah the -d was wrong [16:24] Ok thats running [16:24] the oneiric branches should be resurrecting one by one :) [16:24] then deleting all the /precise branches [16:24] m_3: can you verify alice-irc works? [16:25] which can be scripted, but last I looked it wasn't directly available from Launchpadlib [16:25] james_w: or maybe --stacked-on lp:~charmers/charms/oneiric/$charm/trunk? [16:25] SpamapS: checking [16:25] m_3, yeah, that's probably better, you're right [16:26] * james_w -> lunch [16:27] james_w: thanks! [16:27] np [16:28] SpamapS: can branch lp:charms/oneiric/alice-irc, which shows parent_location = bzr+ssh://bazaar.launchpad.net/+branch/charms/oneiric/alice-irc/ [16:29] but don't know how to see what that's stacked on [16:30] m_3, bzr info lp:charms/oneiric/alice-irc should show it [16:33] m_3: Stacking is unchanged at this point [16:33] ok, as expected, still stacked on /precise [16:33] right [16:34] its slow going [16:34] I'm up to hadoop-mapreduce [16:35] 'morning all [16:35] is there a hdfs charm yet ? i seen a nice addon for that , that adds a external REST api to do crud ops on it [16:35] moins [16:36] imbrandon: well really the hadoop charm is deploying HDFS [16:36] so how do we tell http://paste.ubuntu.com/1006653/ to stack upon itself? [16:37] m_3: I think we want it to stack on precise [16:38] m_3: just.. the precise we have.. not the precise we renaemd away from. :) [16:38] ohhh... [16:39] SpamapS: nice, i may poke that rest api later then and see if it will make a good sub charm for hadoop [16:39] ok, so what happens in q? we change everything to stack on top of ....../trunk for quantal? [16:39] so the base is follwing series going forward? [16:39] anything different for LTS? [16:40] m_3: I'm not sure. We need to think about this. We haven't really given thought to how we'll do updates. [16:41] m_3: My thinking is we'll just evaluate changes to make sure they won't break existing deployments, and then just push them into the branches. [16:41] SpamapS / m_3 : this is where i said the drupal branch model would work better [16:41] let me see if i can find a good infographic and real example and show yall. cuz i'll never sell/explain it right [16:42] and its really just a minor change but signifgant one [16:42] imbrandon: yeah, we need good ideas [16:42] otherwise we'll put our brains on it.. [16:42] and then.. well.. thats going to get ugly ;) [16:42] lol [16:43] well its one of the things that came from drupal with their "not invented here" mentality that actually is better than most anywhere else [16:43] unlike most of the stuff thats half baked [16:43] at this point I'm leaning towards let's backport changes manually and not use any _help_ that stacking might give us for this process [16:44] tl:dr its basicly flip the charmname and the series in the url ( that also means the series is a branch ) [16:44] tried bzr reconfigure --stacked-on lp:~charmers/charms/precise/alice-irc/trunk lp:~charmers/charms/oneiric/alice-irc/trunk [16:44] but there is lots of good reasons why [16:44] bzr: ERROR: Lock not held: LockableFiles(lock, bzr+ssh://bazaar.launchpad.net/~charmers/charms/oneiric/alice-irc/trunk/.bzr/repository/) [16:44] maybe [16:44] i need to do it locally then push [16:45] soo all the charms become like this lp:~charmers/charms/alice-irc/precise , and trunk is the current DEV series , like right now Q but each series gets a branch of the charm not a LP series [16:45] make sense ? [16:46] nope, still could not acquire remote lock when trying to push the changes... locally restacked though [16:46] might need lp for that [16:47] http://paste.ubuntu.com/1006670/ looks like exactly what we want [16:47] thats how the few k modules on drupal.org do their thing, each one has http://code.drupal.org/// [16:47] m_3: stacking doesn't really help you. Its just an efficiency play for Launchpad IIRC [16:48] so like drupal.org/views/views/7.x [16:48] nice [16:49] imbrandon: so there's a branch per charm, and the one people push to (lp:charms/foo) is the current dev series? [16:49] imbrandon: thats *exactly* how it works now. [16:49] alias bbranch='bzr branch --dont-you-dare-stack-anything-ever' [16:49] imbrandon: sorr, there's a branch per charm, per series [16:49] m_3: don't crush LP just because you don't like stacking. :) [16:50] * m_3 is just a hater :)... need more coffe [16:50] e [16:50] SpamapS: http://drupal.org/node/1015226 [16:51] SpamapS: no reversed from now [16:51] SpamapS: where the series is set by the charm as a branch [16:51] imbrandon: but its conceptually identical [16:51] SpamapS: yes but fixes the problems like this [16:51] seriously though, I'm talking out of ignorance and need to take more time to learn the tool [16:51] that link is their policy [16:51] SpamapS: http://drupal.org/node/1015226 [16:52] imbrandon: the only problem we have now is that the LP tools and the charm store don't jive [16:52] take a gander real fast [16:52] SpamapS: right, but there are other small nuances that make it nicer too [16:52] like being able to share merges easier [16:52] beteween serises [16:52] You can do that w/ the current system too [16:53] SpamapS: so when your run is done, we should get #lp to unlock the series so we can push up the restacking changes, then remove the extra /precise branches [16:53] sure, i dont mean you cant, just a nicer workflow that happens to fix this seris lp issue too [16:53] is what i ment [16:53] worth a look at least [16:53] Like, how hard is it really to type 'bzr merge lp:charms/precise/foo' to get the latest goodness from precise in your branch? [16:53] What you want is git [16:53] we've talked about this [16:53] its up for discussion [16:54] well yea but it could be done here too [16:54] when i thought about it later [16:54] manual backport by the maintainers is cool for now [16:54] whether I type bzr merge lp:charms/foo/precise or lp:charms/precise/foo .. matters not. Right? [16:54] As long as they share ancestry [16:54] so it goes smoothly [16:54] sure sure, i am not trying to say the way we have is totaly or even in any way broken [16:54] then we can automate it [16:55] just that there is "this other way thats cool and not tooo much of a change for some added stuff" [16:55] I'm suggesting that their policy, and ours, are not really different at all. [16:55] they arent [16:55] Theirs is just optimized for git [16:55] thus why i said a small change but really in overall it is signifigant [16:55] well the way they use named branches its really alot like bzr too [16:56] as it WAS based on cvs [16:56] hehe [16:56] or feature branches , howeever you call them, same thing [16:56] anyhow it boils down to one main thing, trunk or master or whatever is never the branch that is published from [16:57] ever [16:57] this declaritively saying in the branch what its for [16:57] not just what series on LP its pushed to [16:57] thus would work on any hosting service [16:58] and in out situation that would make branchname === series name [16:58] m_3: Ok, I'm going to bzr reconfigure all the stacking now in oneiric, MMkay? [16:59] I think what james_w put out should work without having it locally [16:59] imbrandon: branchname is basically immaterial in the current system. The fact that the charm store chose 'trunk' was arbitrary. Its really "the series+charm official branch" [16:59] we just gotta get the series open for pushing [16:59] SpamapS: ok, i'll stop now, but please do read over that link a little sometime even in passing, just cuz ytou konw i dont explain things the best either on irc [16:59] SpamapS: i fully realize that [16:59] SpamapS: i'm saying about how it COULD be , and the good things it brings if dione that way [16:59] SpamapS: i.e., `bzr reconfigure --stacked-on lp:~charmers/charms/precise/alice-irc/trunk lp:~charmers/charms/oneiric/alice-irc/trunk` [16:59] like i said i dont mean its broken now [16:59] imbrandon: so whats the advantage of swapping series and charm name in the path, which is all I see. [17:00] SpamapS: ive been trying to explain that but your equating to whats there now insead of looking over all what it would mean i think [17:00] and yes thats technically all it would be [17:00] Because to me, there is a psychological benefit to grouping all of the charms together as a single entity per series, something that we make sure all works together. [17:01] well you still have that [17:01] you dont loose it [17:01] what do I gain? I see nothing in this policy that changes anything we're doing [17:01] you just may need a diffrent view to see it [17:02] you gain the control in the charm branch its self over the series AND you lose the headache of LP not jiving [17:02] think about it like this [17:02] when you fix a bug in juju core [17:02] you push it to lp as lp:juju/some-named-fix [17:03] because that has value in the name, same thing for the series instead of trunk becomming rolling [17:03] and then the headaches now [17:03] we have charm/series-aka-branch [17:03] not trunk [17:04] and again i dont mean the way we have is broken, just that there really is value in the other small change [17:07] but yea i'm terrible about explaining concepts on irc , so glance over the link as you have time and i'll slap a quick image in gimp togather that will i think illistrate it better too, as its not an urget thing, it could be done anytime in the next 6 months before q releases and still have the same impact, no need to rush it [17:08] that way i can present it to the list too , hopefully in a cohearant manner [17:11] imbrandon: no, I push the fix to lp:~clint-fewbar/juju/some-named-fix [17:13] imbrandon: and with charms, I push to lp:~clint-fewbar/charms/precise/foocharm/some-named-fix as well.. and then propose for merging into lp:charms/precise/foocharm [17:13] imbrandon: and then if that fix is good, and introduces no regressions/etc, and the branches have not diverged, it can be directly pushed to lp:charms/oneiric/foocharm [17:14] imbrandon: if they have diverged, at worst, I must bzr merge it into oneiric.. a workflow that I do not love the mechanics of, but works fine in terms of how straightforward it is [17:18] umm you just said the same thing i thought i just had [17:19] but if thats not how i said it thats exactly how i mean, yes , thats the current flow and is exactly right and exactly shows what i mean with the other but ... yea , i need to get better at abstract --> real value conversion articulation [17:20] Sure, a picture may help. :) [17:20] james_w: when I tried using bzr reconfigure on one of the branches I got this: If your kernel is 2.6.30+, you don't need to follow this guide anymore as the kernel includes a proper driver. [17:20] dohhh [17:20] james_w: take-2 .. when I tried using bzr reconfigure on one of the branches, I got THIS: bzr: ERROR: Lock not held: LockableFiles(lock, bzr+ssh://bazaar.launchpad.net/~charmers/charms/oneiric/hadoop-slave/trunk/.bzr/repository/) [17:25] SpamapS, heh, I was going to say that was a very unexpected message from bzr! [17:25] SpamapS, would you run again using "bzr -Derror -Dlock" please? [17:26] it should spit out a traceback, and the last stanza of your ~/.bzr.log should have some information on the locks that are being taken and released [17:27] james_w: http://paste.ubuntu.com/1006739/ [17:28] SpamapS, try "bzr break-lock bzr+ssh://bazaar.launchpad.net/~charmers/charms/oneiric/hadoop-slave/trunk/" and then try again [17:30] Break held by clint-fewbar@bazaar.launchpad.net on crowberry (process #1853), acquired 11 minutes, 15 seconds ago? ([y]es, [n]o): [17:30] Broke lock bzr+ssh://bazaar.launchpad.net/~charmers/charms/oneiric/hadoop-slave/trunk/.bzr/branch/lock [17:45] james_w: lock broken, same issue [17:46] SpamapS, do you have a traceback? [17:46] http://paste.ubuntu.com/1006767/ [17:46] james_w: ^^ [17:47] james_w: almost like its a deadlock or something [17:48] SpamapS, if you break-lock again and do the bzr info, does it show the old or new stacked location? [17:54] SpamapS, ah, it may work better if you call "reconfigure" with the sftp:// URL rather than the lp: or bzr+ssh: one [17:59] Any good examples of how people are integrating juju and chef? My google-fu isn't working for me right now. [18:02] Urocyon: not yet... we've got tasks for charms that call chef-solo recipes, and a subordinate charm that might be able to register a service-unit as a node in a role with a chef server [18:03] Urocyon: also probably a charm to help deploy chef-server [18:03] Urocyon: it should be easy to call recipes from within charm hooks... the trick is splitting up the logic into "installation" logic -vs- "relation" logic [18:04] I don't see any chef related charms in jujucharms.com/charms/precise is there someplace else I should look for those? [18:05] Urocyon: no, they don't exist yet... was just mentioning the todos :) [18:07] Urocyon: we have tons of ideas, but very little time. Are you interested in experimenting? [18:07] yes, please help! [18:09] i've just started getting my feet wet here. But I have some time today to experiment. [18:11] Urocyon: you can see somewhat similar things done for puppet... lp:~michael.nelson/charms/oneiric/apache-django-wsgi/trunk, and lp:charms/puppetmaster [18:12] Urocyon: do you have an existing chef system that you're interested in hooking up to juju? [18:14] james_w: weird, sftp does seem to have worked. [18:15] james_w: though I think stacking is now borked [18:15] ha! nice [18:15] SpamapS, it's a bzr bug then, it's missing some required handling for smart servers [18:15] sftp://clint-fewbar@bazaar.launchpad.net/~charmers/charms/oneiric/hadoop-slave/trunk/ is now stacked on ../../../precise/hadoop-slave/trunk [18:15] double bug! [18:15] but now I can't 'bzr info -v lp:charms/oneiric/hadoop-slave [18:15] actually, that's correct right? [18:16] relative path for the ~charmers user [18:16] hadoop-slave may be a bad example [18:16] since we sort of half unpromulgated it [18:16] bzr info lp:~charmers/charms/oneiric/hadoop-slave/trunk looks fine though [18:17] m_3: hm [18:17] so, the other ones don't stack on ../../.. [18:17] and I can branch it from there, so it's behaving ok [18:18] they stack on an explicit /~... [18:18] m_3: can you branch from lp:charms/oneiric/hadoop-slave? [18:18] bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/precise/hadoop-slave/trunk/". [18:18] I get that because the stacking is relative [18:18] instead of absolute [18:19]