/srv/irclogs.ubuntu.com/2012/05/25/#juju.txt

=== ahs3` is now known as ahs3
hazmatm_3, gluecon looks awesome03:29
hazmatm_3, pls do a write up03:29
* hazmat is wishing he had gone03:29
m_3hazmat: yup will do... it was great03:31
m_3wish they would've accepted my talks...03:31
hazmatm_3, "RT “@adrianco: If your instance AMIs depend on an external repo to configure post boot you have a big SPOF.” <- Bingo.."03:32
m_3hopefully that'll be different next year though... juju came up in a couple of presentations... and I talked to folks a lot03:32
hazmatm_3, right on03:33
hazmats3 repos hopefully ftw03:33
m_3that guy's talk rocked!03:33
m_3they manage lots of static amis though... they're quite ripe for something like juju03:34
m_3and it was nice to realize we'd been just playing with more scale than they usually use for one app03:34
m_3(most of their load is really in big CDNs... not on ec2 proper)03:35
hazmatm_3, did you see derek richardson's talk?03:40
hazmater.. collison03:41
* hazmat googles for all the slides he can find03:54
JoseeAntonioRguys, is there an indirect way to deploy joomla through juju?05:07
bkerensaJoseeAntonioR: My cousin might bring me some Brazillian Pisco ;)05:11
JoseeAntonioRbkerensa: what the... I think there's no brazilian pisco!05:12
bkerensa:D05:12
bkerensawe shall see05:13
SpamapSJoseeAntonioR: somebody wrote a joomla charm once.. its been a while though06:41
=== popey_ is now known as popey
=== elmo_ is now known as elmo
imbrandonSpamapS: 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 this13:35
imbrandonbholtsclaw@ares:~/Projects/local/charms/precise/newrelic$ charm proof13:35
imbrandonabort: Unknown script hl13:35
imbrandonusage: charm [ --help|-h ] [ script_name ]13:35
imbrandonscript choices are:13:35
imbrandon/usr/bin/charm: line 14: exec: list_commands: not found13:35
imbrandonmost of it looked to be bash when i perused the source, but i dident inspect everything13:36
imbrandonohh nevermind13:38
imbrandonits fskin bsd's readlink is broken13:39
imbrandonand thus OSX's13:39
imbrandoni always forget that13:39
* imbrandon patches13:39
SpamapSimbrandon: the readlink thing can be solved by installing GNU coreutils IIRC14:27
SpamapSimbrandon: we need to get rid of the readlinks I think14:27
SpamapSimbrandon: 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:28
imbrandonyea, that would rock, there is a bit more too but i'm on the phone14:32
imbrandonone secd14:32
imbrandonand yea i installed coreutils via brew14:32
imbrandonto semi solve it14:32
=== mbarnett` is now known as mbarnett
imbrandonanyhow yea, sed is diffrent etc too but gnused is installed via brew too14:58
imbrandonproblem is without autotools its a PITA to switch everything cuz the gnu coreutils are prefixed with g on osx14:59
imbrandonso ginstall gsed etc14:59
imbrandonyou CAN put them in the path before the BSD ones but it breaks other things14:59
imbrandonsooo i'd rather not do that, esp in a package i plan to distriubute14:59
imbrandon:)14:59
* 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 best15:00
imbrandonthen i dont have to maintain a patch, and it can be "upstreamed" except for the install forumla like juju15:00
imbrandonideally 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 it15:02
imbrandonetc15:02
imbrandonstill a WIP :)15:02
imbrandonoh 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 diffre15:08
imbrandonnot 10000% sold on it, but figured now would be the time to bring it up rather than later15:08
imbrandonhrm , 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:13
imbrandonsounds 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 way15:14
imbrandonbecause really in every context juju cares about OSX is just a BSD* distro15:15
hazmatAuthor spec?15:37
imbrandonerr the maintainer field15:38
imbrandongot myself mixed up15:38
hazmati'm not sure if a separate author spec is adding significant value15:40
imbrandonyea15:40
imbrandonnot really a whole spec15:40
imbrandonjust mean while were adding maintiner field to the meta data it mighjt be good idea to add author also15:40
imbrandonas to have a clear seperation15:41
imbrandonand 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 fetched15:42
imbrandonbut figured now instead of a month from now would be the time to think about it15:42
marcoceppiI think, for the most part (and quite some time) the author will be the maintainer15:42
imbrandonlikely so for 99% of them15:43
imbrandonwas more of to not have to change it later and go though a change again since we;re making one similar change now15:43
imbrandontis all15:43
imbrandonbut yea your likely correct15:43
imbrandonbtw heya marcoceppi , hear you had some of that nasty bug too, hope ya feelin better15:44
marcoceppimuch15:44
imbrandon:)15:44
imbrandoni got it pretty bad for a few days but i dont think near as bad as you from what jorge said15:45
imbrandonbtw that tillo mashup thing is slick , nice job :)15:45
imbrandontwillo*15:45
m_3trello?15:47
m_3:)15:47
imbrandonoh yea twillo is the sms thing15:47
imbrandoni always mix them up15:47
m_3marcoceppi: yeah, I agree, your mashup is cool15:48
marcoceppistrapello?15:48
m_3yup15:48
imbrandonyea15:48
marcoceppithanks :) need to push up some caching so Jorge's page doesn't take three years to load15:48
imbrandonhahaha15:48
imbrandontodays 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 lang15:51
m_3hazmat: 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:53
m_3SpamapS: please budget a little time to discuss ^^ later today15:54
hazmatm_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:57
hazmatthat's all kinds of retarded i agree15:58
* hazmat dons a PC hat15:58
hazmatno offense intended15:58
SpamapSm_3: I think thats actually an ok plan.15:59
SpamapSIts just a result of the weird distro model which we've inherited. We won't repeat the problems with quantal16:00
m_3this weekend then16:01
hazmatSpamapS, you mean do the invalid restack, to only temporarily make the branches in accessible prior to renaming..16:01
m_3maybe we can even arrange to have a lp superpower person available too16:02
hazmatthe ideal solution james_w pointed out was stacking on the id16:02
hazmater. the branch id16:02
hazmatso it doesn't die on rename16:02
m_3hazmat: bugs are in to fix that going forward16:02
m_3but it won't help now16:02
m_3well... maybe it would16:02
james_wthere is a way to avoid breaking all the precise branches while doing it16:03
james_wbut it's more work16:03
m_3oh?16:03
m_3james_w: do tell16:03
SpamapShazmat: 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 branches16:03
james_wthe 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 them16:03
m_3james_w: oh... that doesn't seem to bad then16:04
SpamapSjames_w: is the ID not accessible via LP API/ssh+bzr ?16:04
james_wSpamapS, hmm, maybe it is16:04
m_3james_w: and a _whole_ lot safer16:04
m_3i.e., can be done right now16:04
james_wnot directly that I know of, but it's possible it's available16:04
hazmatm_3, its not something we can use right now16:05
hazmatm_3, even if it was available16:05
james_wwhat would renaming the precise branches break?16:05
m_3james_w: access via the lp:charms/precise aliases... as well as access via the store ( juju deploy mysql )16:06
hazmatjames_w, long term nothing, temporarily it would break anything looking for charms, and existing branches that want to pull/push16:06
hazmater.. on the push side it might get uglier16:06
hazmatif somebody pushes in the middle of this op..16:06
hazmatjames_w, m_3, it won't break the store16:06
m_3scheduling it over the weekend is just a crapshoot16:07
m_3huh?16:07
hazmatthe store assembles zipfiles for download16:07
m_3sure it will... the store is looking for16:07
hazmatit doesn't serve directly from bzr16:07
m_3oh, you mean the store has it cached16:07
m_3ok16:07
james_wthe store won't see anything new, but it's not going to delete all the charms is it?16:07
hazmatit polls bzr to look for new revs16:07
hazmatjames_w, no the store and charm browser never delete things16:07
=== wrtp is now known as rogpeppe
james_wand it would presumably pick up again when they were renamed back16:07
james_wthe lp:charms/precise aliases won't break16:07
hazmathmm.. 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 though16:08
james_wand modern bzr uses those I believe, so most pulling and pushing would still work I think16:08
m_3well maybe I'm just being a panty-waiste then16:08
* m_3 puts on _his_ PC hat16:08
james_wnot renaming would be better16:09
james_wbut 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 syrgery16:09
SpamapSthe rename is API doable16:10
SpamapSas is the stacking change16:10
SpamapSso we'd have, what, 15 minutes of exposure?16:10
SpamapSI say do it16:10
hazmatyup16:10
hazmatits not ideal as a long term solution for other rels, but it works for restoration16:11
m_3ok, I'll test it out on a single branch and then go from there if that works16:11
james_wSpamapS, the stacking change can be done over the API?16:11
hazmatjames_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:11
hazmatie.. bypass most of branch-distros16:12
james_whazmat, yeah, you could16:12
james_wyou can't manipulate the series, but that's disjoint anyway16:12
james_wonce the series is created, you can push the branches, then use the API to make the official branch links16:13
james_wbut it's a one-line fix to branch-distro to avoid this16:13
james_wit doesn't get the new branch names "right" but I understood that was going to be changed in the charm store anyway16:14
SpamapSjames_w: well not API, but we can bzr reconfigure and push, right?16:16
james_wSpamapS, I don't know if that will change it to stack on the id rather than the name16:16
james_wwe can experiment16:16
m_3SpamapS: that's my understanding of the current plan... still needs to be tested16:16
SpamapSOh I was thinking of just changing the stacked on name.16:16
james_wthere are a couple of scripts we can run to definitely fix it up from the LP size while the precise branches are renamed16:17
m_3we rename the base, then bzr reconf, then push that back up, then rename the base back to trunk16:17
SpamapSthe 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
james_wyou can't reconf to a name that doesn't exist16:17
james_whmm16:17
SpamapSs/net distro/next distro/16:17
james_whow about this16:17
m_3right, so we rename /trunk back to /precise (the base braches)16:17
james_w1. branch from the correct name to the wrong name for the branches for precise16:17
SpamapSjames_w: heh right, so we rename, branch, rename, reconf, push16:17
james_w2. done16:17
m_3_then_ we should be able to reconfigure16:17
SpamapSjames_w: Ahh so just fake it basically?16:18
* SpamapS tries that16:18
james_wSpamapS, it's perfectly valid from bzr's point of view, just a bit messy16:18
james_wmight confuse a few people16:18
james_wit could be cleaned up, but there would be working branches with no interruption16:19
m_3oh, so you mean we create new /precise's instead of renaming from /trunk?16:19
* SpamapS tries it w/ hadoop-slave16:19
m_3cool16:19
james_wm_3, yeah, they will stack on trunk, which will make for slower access to the oneiric branches, but it should fix them16:19
SpamapSsince that one is borked in precise anyway16:19
SpamapSworks16:20
SpamapSjames_w: I knew we gave you  a laptop for a reson.16:20
SpamapSreason even16:20
m_3so we still bzr reconfigure those branches too?16:20
SpamapSsomebody give me a new keyboard ugh16:20
james_wheh16:20
james_wm_3, that would be good16:20
m_3or just leave the fake-out in place?16:20
SpamapSlp:charms/oneiric/hadoop-slave works16:20
m_3whoohoo!16:20
m_3well that was a lot easier than we were making it :)16:21
james_wI don't know if it will stack on the id at that point, so no-one is allowed to rename the precise  branches again16:21
SpamapSall I did is push lp:charms/precise/hadoop-slave -> lp:~charmers/charms/precise/hadoop-slave/precise16:21
m_3right16:21
james_wbzr branch -d lp:charms/precise/$charm lp:~charmers/charms/precise/$charm/precise16:21
m_3but we really should bzr reconf, then we can remove the extra /precise branch16:21
james_wsomeone in ~charmers can put that in a for charm in $charms loop16:21
james_wm_3, +116:22
SpamapSjames_w: does that pull/push automatically or does it happen all on the other side?16:22
SpamapS  stacked on: /~charmers/charms/precise/hadoop-slave/precise16:22
SpamapSstill stacked on the name :)16:22
james_wSpamapS, it's client side, it's just easier to type :-)16:22
SpamapSjames_w: gotchya. Doing that now16:22
james_werr, I probably got the paramters the wrong way round16:23
james_wbzr branch lp:charms/precise/$charm lp:~charmers/charms/precise/$charm/precise16:23
james_wor whatever works, you get the idea :-)16:23
james_wbzr reconfigure --stacked-on lp:charms/precise/$charm lp:charms/oneiric/$charm is the next step I think16:23
SpamapSjames_w: yeah the -d was wrong16:24
SpamapSOk thats running16:24
SpamapSthe oneiric branches should be resurrecting one by one :)16:24
james_wthen deleting all the /precise branches16:24
SpamapSm_3: can you verify alice-irc works?16:24
james_wwhich can be scripted, but last I looked it wasn't directly available from Launchpadlib16:25
m_3james_w: or maybe --stacked-on lp:~charmers/charms/oneiric/$charm/trunk?16:25
m_3SpamapS: checking16:25
james_wm_3, yeah, that's probably better, you're right16:25
* james_w -> lunch16:26
m_3james_w: thanks!16:27
james_wnp16:27
m_3SpamapS: can branch lp:charms/oneiric/alice-irc, which shows parent_location = bzr+ssh://bazaar.launchpad.net/+branch/charms/oneiric/alice-irc/16:28
m_3but don't know how to see what that's stacked on16:29
james_wm_3, bzr info lp:charms/oneiric/alice-irc should show it16:30
SpamapSm_3: Stacking is unchanged at this point16:33
m_3ok, as expected, still stacked on /precise16:33
m_3right16:33
SpamapSits slow going16:34
SpamapSI'm up to hadoop-mapreduce16:34
negronjl'morning all16:35
imbrandonis there a hdfs charm yet ? i seen a nice addon for that , that adds a external REST api to do crud ops on it16:35
imbrandonmoins16:35
SpamapSimbrandon: well really the hadoop charm is deploying HDFS16:36
m_3so how do we tell http://paste.ubuntu.com/1006653/ to stack upon itself?16:36
SpamapSm_3: I think we want it to stack on precise16:37
SpamapSm_3: just.. the precise we have.. not the precise we renaemd away from. :)16:38
m_3ohhh...16:38
imbrandonSpamapS: nice, i may poke that rest api later then and see if it will make a good sub charm for hadoop16:39
m_3ok, so what happens in q?  we change everything to stack on top of ....../trunk for quantal?16:39
m_3so the base is follwing series going forward?16:39
m_3anything different for LTS?16:39
SpamapSm_3: I'm not sure. We need to think about this. We haven't really given thought to how we'll do updates.16:40
SpamapSm_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
imbrandonSpamapS / m_3 : this is where i said the drupal branch model would work better16:41
imbrandonlet me see if i can find a good infographic and real example and show yall. cuz i'll never sell/explain it right16:41
imbrandonand its really just a minor change but signifgant one16:42
SpamapSimbrandon: yeah, we need good ideas16:42
SpamapSotherwise we'll put our brains on it..16:42
SpamapSand then.. well.. thats going to get ugly ;)16:42
imbrandonlol16:42
imbrandonwell its one of the things that came from drupal with their "not invented here" mentality that actually is better than most anywhere else16:43
imbrandonunlike most of the stuff thats half baked16:43
m_3at this point I'm leaning towards let's backport changes manually and not use any _help_ that stacking might give us for this process16:43
imbrandontl:dr its basicly flip the charmname and the series in the url ( that also means the series is a branch )16:44
m_3tried bzr reconfigure --stacked-on lp:~charmers/charms/precise/alice-irc/trunk lp:~charmers/charms/oneiric/alice-irc/trunk16:44
imbrandonbut there is lots of good reasons why16:44
m_3bzr: ERROR: Lock not held: LockableFiles(lock, bzr+ssh://bazaar.launchpad.net/~charmers/charms/oneiric/alice-irc/trunk/.bzr/repository/)16:44
m_3maybe16:44
m_3i need to do it locally then push16:44
imbrandonsoo 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 series16:45
imbrandonmake sense ?16:45
m_3nope, still could not acquire remote lock when trying to push the changes... locally restacked though16:46
m_3might need lp for that16:46
m_3http://paste.ubuntu.com/1006670/ looks like exactly what we want16:47
imbrandonthats how the few k modules on drupal.org do their thing, each one has http://code.drupal.org/<project>/<module-name>/<drupal-target-major-release>16:47
SpamapSm_3: stacking doesn't really help you. Its just an efficiency play for Launchpad IIRC16:47
imbrandonso like drupal.org/views/views/7.x16:48
m_3nice16:48
SpamapSimbrandon: so there's a branch per charm, and the one people push to (lp:charms/foo) is the current dev series?16:49
SpamapSimbrandon: thats *exactly* how it works now.16:49
m_3alias bbranch='bzr branch --dont-you-dare-stack-anything-ever'16:49
SpamapSimbrandon: sorr, there's a branch per charm, per series16:49
SpamapSm_3: don't crush LP just because you don't like stacking. :)16:49
* m_3 is just a hater :)... need more coffe16:50
m_3e16:50
imbrandonSpamapS: http://drupal.org/node/101522616:50
imbrandonSpamapS: no reversed from now16:51
imbrandonSpamapS: where the series is set by the charm as a branch16:51
SpamapSimbrandon: but its conceptually identical16:51
imbrandonSpamapS: yes but fixes the problems like this16:51
m_3seriously though, I'm talking out of ignorance and need to take more time to learn the tool16:51
imbrandonthat link is their policy16:51
imbrandonSpamapS: http://drupal.org/node/101522616:51
SpamapSimbrandon: the only problem we have now is that the LP tools and the charm store don't jive16:52
imbrandontake a gander real fast16:52
imbrandonSpamapS: right, but there are other small nuances that make it nicer too16:52
imbrandonlike being able to share merges easier16:52
imbrandonbeteween serises16:52
SpamapSYou can do that w/ the current system too16:52
m_3SpamapS: 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 branches16:53
imbrandonsure, i dont mean you cant, just a nicer workflow that happens to fix this seris lp issue too16:53
imbrandonis what i ment16:53
imbrandonworth a look at least16:53
SpamapSLike, 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
SpamapSWhat you want is git16:53
SpamapSwe've talked about this16:53
SpamapSits up for discussion16:53
imbrandonwell yea but it could be done here too16:54
imbrandonwhen i thought about it later16:54
m_3manual backport by the maintainers is cool for now16:54
SpamapSwhether I type bzr merge lp:charms/foo/precise or lp:charms/precise/foo .. matters not. Right?16:54
SpamapSAs long as they share ancestry16:54
SpamapSso it goes smoothly16:54
imbrandonsure sure, i am not trying to say the way we have is totaly or even in any way broken16:54
SpamapSthen we can automate it16:54
imbrandonjust that there is "this other way thats cool and not tooo much of a change for some added stuff"16:55
SpamapSI'm suggesting that their policy, and ours, are not really different at all.16:55
imbrandonthey arent16:55
SpamapSTheirs is just optimized for git16:55
imbrandonthus why i said a small change but really in overall it is signifigant16:55
imbrandonwell the way they use named branches its really alot like bzr too16:55
imbrandonas it WAS based on cvs16:56
imbrandonhehe16:56
imbrandonor feature branches , howeever you call them, same thing16:56
imbrandonanyhow it boils down to one main thing, trunk or master or whatever is never the branch that is published from16:56
imbrandonever16:57
imbrandonthis declaritively saying in the branch what its for16:57
imbrandonnot just what series on LP its pushed to16:57
imbrandonthus would work on any hosting service16:57
imbrandonand in out situation that would make branchname === series name16:58
SpamapSm_3: Ok, I'm going to bzr reconfigure all the stacking now in oneiric, MMkay?16:58
m_3I think what james_w put out should work without having it locally16:59
SpamapSimbrandon: 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
m_3we just gotta get the series open for pushing16:59
imbrandonSpamapS: 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 irc16:59
imbrandonSpamapS: i fully realize that16:59
imbrandonSpamapS: i'm saying about how it COULD be , and the good things it brings if dione that way16:59
m_3SpamapS: i.e., `bzr reconfigure --stacked-on lp:~charmers/charms/precise/alice-irc/trunk lp:~charmers/charms/oneiric/alice-irc/trunk`16:59
imbrandonlike i said i dont mean its broken now16:59
SpamapSimbrandon: so whats the advantage of swapping series and charm name in the path, which is all I see.16:59
imbrandonSpamapS: ive been trying to explain that but your equating to whats there now insead of looking over all what it would mean i think17:00
imbrandonand yes thats technically all it would be17:00
SpamapSBecause 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:00
imbrandonwell you still have that17:01
imbrandonyou dont loose it17:01
SpamapSwhat do I gain? I see nothing in this policy that changes anything we're doing17:01
imbrandonyou just may need a diffrent view to see it17:01
imbrandonyou gain the control in the charm branch its self over the series AND you lose the headache of LP not jiving17:02
imbrandonthink about it like this17:02
imbrandonwhen you fix a bug in juju core17:02
imbrandonyou push it to lp as lp:juju/some-named-fix17:02
imbrandonbecause that has value in the name, same thing for the series instead of trunk becomming rolling17:03
imbrandonand then the headaches now17:03
imbrandonwe have charm/series-aka-branch17:03
imbrandonnot trunk17:03
imbrandonand again i dont mean the way we have is broken, just that there really is value in the other small change17:04
imbrandonbut 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 it17:07
imbrandonthat way i can present it to the list too , hopefully in a cohearant manner17:08
SpamapSimbrandon: no, I push the fix to lp:~clint-fewbar/juju/some-named-fix17:11
SpamapSimbrandon: 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/foocharm17:13
SpamapSimbrandon: 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/foocharm17:13
SpamapSimbrandon: 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 is17:14
imbrandonumm you just said the same thing i thought i just had17:18
imbrandonbut 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 articulation17:19
SpamapSSure, a picture may help. :)17:20
SpamapSjames_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
SpamapSdohhh17:20
SpamapSjames_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:20
james_wSpamapS, heh, I was going to say that was a very unexpected message from bzr!17:25
james_wSpamapS, would you run again using "bzr -Derror -Dlock" please?17:25
james_wit 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 released17:26
SpamapSjames_w: http://paste.ubuntu.com/1006739/17:27
james_wSpamapS, try "bzr break-lock bzr+ssh://bazaar.launchpad.net/~charmers/charms/oneiric/hadoop-slave/trunk/" and then try again17:28
SpamapSBreak held by clint-fewbar@bazaar.launchpad.net on crowberry (process #1853), acquired 11 minutes, 15 seconds ago? ([y]es, [n]o):17:30
SpamapSBroke lock bzr+ssh://bazaar.launchpad.net/~charmers/charms/oneiric/hadoop-slave/trunk/.bzr/branch/lock17:30
SpamapSjames_w: lock broken, same issue17:45
james_wSpamapS, do you have a traceback?17:46
SpamapShttp://paste.ubuntu.com/1006767/17:46
SpamapSjames_w: ^^17:46
SpamapSjames_w: almost like its a deadlock or something17:47
james_wSpamapS, if you break-lock again and do the bzr info, does it show the old or new stacked location?17:48
james_wSpamapS, ah, it may work better if you call "reconfigure" with the sftp:// URL rather than the lp: or bzr+ssh: one17:54
UrocyonAny good examples of how people are integrating juju and chef?  My google-fu isn't working for me right now.17:59
m_3Urocyon: 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 server18:02
m_3Urocyon: also probably a charm to help deploy chef-server18:03
m_3Urocyon: it should be easy to call recipes from within charm hooks... the trick is splitting up the logic into "installation" logic -vs- "relation" logic18:03
UrocyonI don't see any chef related charms in jujucharms.com/charms/precise  is there someplace else I should look for those?18:04
m_3Urocyon: no, they don't exist yet... was just mentioning the todos :)18:05
SpamapSUrocyon: we have tons of ideas, but very little time. Are you interested in experimenting?18:07
m_3yes, please help!18:07
Urocyoni've just started getting my feet wet here.  But I have some time today to experiment.18:09
m_3Urocyon: you can see somewhat similar things done for puppet... lp:~michael.nelson/charms/oneiric/apache-django-wsgi/trunk, and lp:charms/puppetmaster18:11
SpamapSUrocyon: do you have an existing chef system that you're interested in hooking up to juju?18:12
SpamapSjames_w: weird, sftp does seem to have worked.18:14
SpamapSjames_w: though I think stacking is now borked18:15
m_3ha! nice18:15
james_wSpamapS, it's a bzr bug then, it's missing some required handling for smart servers18:15
SpamapSsftp://clint-fewbar@bazaar.launchpad.net/~charmers/charms/oneiric/hadoop-slave/trunk/ is now stacked on ../../../precise/hadoop-slave/trunk18:15
james_wdouble bug!18:15
SpamapSbut now I can't 'bzr info -v lp:charms/oneiric/hadoop-slave18:15
m_3actually, that's correct right?18:15
m_3relative path for the ~charmers user18:16
SpamapShadoop-slave may be a bad example18:16
SpamapSsince we sort of half unpromulgated it18:16
m_3bzr info lp:~charmers/charms/oneiric/hadoop-slave/trunk looks fine though18:16
SpamapSm_3: hm18:17
SpamapSso, the other ones don't stack on ../../..18:17
m_3and I can branch it from there, so it's behaving ok18:17
SpamapSthey stack on an explicit /~...18:18
SpamapSm_3: can you branch from lp:charms/oneiric/hadoop-slave?18:18
SpamapSbzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/precise/hadoop-slave/trunk/".18:18
SpamapSI get that because the stacking is relative18:18
SpamapSinstead of absolute18:18
m_3nope... no love from lp:charms/oneiric/hadoop-slave18:19
SpamapSyeah thats borken18:19
m_3others look to be stacked on /~charme...18:20
m_3but I'm having problems with alice-irc...18:20
m_3bzr info lp:~charmers/charms/oneiric/alice-irc/trunk looks fine (abs path on base)18:20
m_3but bzr info lp:charms/oneiric/alice-irc is borked18:21
* m_3 more confused now18:21
* SpamapS considers just going --unstacked18:21
m_3oh!18:21
m_3didn't know that existed18:21
m_3of course18:21
SpamapSYeah18:21
SpamapSits simpler18:21
SpamapSfor this particular conundrum18:21
m_3plus like a hundred million18:22
SpamapSeventually we'll have to make it work stacked18:22
SpamapSbut Yeah, let me try that18:22
m_3I'd ask why, but...18:22
SpamapSm_3: it will be important when we have 1000+ charms with 1000+ revs each18:23
SpamapSm_3: but we'll probably be using git by then. :-P18:24
SpamapS;)18:24
* m_3 no comment18:24
* SpamapS hates relying on solutions that don't exist yet18:24
m_3I know!18:24
SpamapSalright18:24
SpamapSunstacked works18:24
SpamapSF it, I"m unstacking all oneiric branches18:24
SpamapSand then we can delete the extraneous 'precise' branches18:25
m_3ok18:25
SpamapSand then we can actually *MOVE ON WITH OUR LIVES*18:25
SpamapShrm, we need to fix charm list to show the non-dev-focus branches as aliases, that wuld be cool18:25
m_3oh, lp:charms/oneiric/<blah>?18:26
SpamapSyeah18:26
m_3does it matter?18:26
SpamapSyeah18:26
SpamapSso I can say "list all the oneiric charms"18:26
SpamapSright now I can't really18:26
m_3ugly multiple grep pipes18:26
m_3but yeah18:26
* m_3 likes charm list a lot18:27
SpamapSeven the grep pipes aren't "official"18:27
SpamapSsince in theory we could have a branch owned by ~charmers that has been unpromulgated18:27
SpamapS(which at this point is only ceremonial since the charm store does not delete.. but still)18:28
m_3oh, I see18:28
SpamapSsftp://clint-fewbar@bazaar.launchpad.net/~charmers/charms/oneiric/appflower/trunk/ is now not stacked18:28
SpamapSm_3: try appflower18:28
m_3yikes... no info from the alias18:29
SpamapSwtf18:29
m_3long-form gave info fine18:29
m_3branching now18:29
SpamapSperhaps have to repromulgate?! that looks really weird18:30
SpamapS  parent branch: bzr+ssh://bazaar.launchpad.net/~4-ja-d/charms/oneiric/appflower/trunk/18:30
m_3branched fine from both18:30
imbrandonSpamapS: but you could if you just said list all oniric charms in lp:charm/  with a oneiric branch :)18:30
* imbrandon stops18:30
m_3SpamapS: the orig author is still in the set of branches (not saying stack)... jorge was in alice18:31
SpamapSimbrandon: you're smarter than that. :)18:31
imbrandonheh18:31
SpamapSm_3: ah, so maybe hat branch got deleted?18:31
m_3hmmm... lemme dig18:32
SpamapSm_3: I don't think info works on any aliases18:32
SpamapSbzr: ERROR: Parent not accessible given base "bzr+ssh://bazaar.launchpad.net/+branch/charms/precise/alice-irc/" and relative path "../../../../../~jorge/charms/oneiric/alice-irc/trunk/"18:32
m_3works perfectly well on lp:charms/hadoop18:33
SpamapSyeah18:33
SpamapSbut I think thats only by mistake18:33
SpamapSm_3: I think thats just because the relative path matches18:33
Urocyonsorry, got distracted there for a minute.18:33
m_3SpamapS: yeah, I'm getting the same results for other oneiric aliases18:33
m_3Urocyon: np... nature of the medium :)18:34
m_3SpamapS: I guess it doesn't matter if we can branch18:34
m_3actually, bzr info lp:charms/oneiric/jenkins looks fine18:34
SpamapScharm list | awk -F/ '/lp:~charmers\/charms\/oneiric/ {print $4}'18:35
SpamapSbest I can do for a "list of oneiric charms"18:35
UrocyonYes, I have a chef server running currently.  I was looking at juju as a way to provide some orchestration for my deployments... like making sure servers came up in a paritcular order, or that existing servers could react automatically to say a new webnode coming on line, or to integrate a new database server into an existing cluster.18:35
m_3SpamapS: good enough18:35
m_3Urocyon: sounds like a perfect integration case18:36
m_3Urocyon: not nec the easiest _start_, but...18:37
SpamapSUrocyon: ordering is hard, and juju can't really help you with that..18:38
SpamapSUrocyon: juju can help you make your servers wait for their dependencies, so they in effect end up in the right "order"18:38
Urocyonthat seems sufficient, and maybe even preferable to specifying order.18:39
SpamapSUrocyon: Right, it usually is. :)18:39
m_3right... ordering between different service, no prob... within the units of a single service is hard18:40
SpamapSUrocyon: simplest thing you could probably do would be to have charms which feed data into databags and run chef in response to the changes in configurations.18:41
SpamapSUrocyon: one thing that may be difficult to get over is that juju wants to provision everything18:41
Urocyonm_3 I thought maybe juju's various hooks and event handling could help there.    When x happens, then add role y  to server Z .. sort of thing.18:41
SpamapSIMO, juju should decouple its provisioning parts from its event handling parts.. but thats a large discussion. :)18:42
m_3Urocyon: yeah, it's easier to add a juju machine to chef, than the other way around atm18:42
m_3Urocyon: so perhaps start with the specific case of adding a new db to an existing app18:43
SpamapSm_3: FYI, unstacking progressing on all branches18:43
UrocyonI was looking prevously at cloudformation, which has a similar limitation.18:43
m_3SpamapS: nice... you are a god among mere mortals18:43
* SpamapS deflects that comment to james_w18:43
SpamapSUrocyon: the reason for the provisioning "limitation" is that there is great power in knowing that you will have a clean box at the start of things. :)18:44
m_3you're just jealous of his new laptop18:44
SpamapSpretty much18:44
SpamapScarbon fiber > aluminum18:44
SpamapSUrocyon: eventually I think we'll have a mode for juju where you just install it on existing servers and they phone back home and start doing their orchestration duties.18:45
m_3yeah, I was pretty sad they didn't have extras for the judges18:45
SpamapSm_3: I'm just tired of being a walking billboard for Apple. ;)18:45
SpamapSBut damn.. System76 and ZaReason make, frankly, f'ugly laptops18:46
m_3SpamapS: that might not be too hard to get rigged up... enroll an existing machine with juju18:46
SpamapSm_3: we might even be able to do it w/ jitsu :)18:46
SpamapSm_3: just convince a machine it is running the local provider.. ;)18:46
m_3I'm tactile, so the aluminum just feels good18:47
m_3ha!18:47
SpamapSm_3: or maybe orchestra/maas18:47
m_3hmmmm18:47
SpamapSm_3: and then just plug in machine ids using our handy dandy zk admin privileges18:47
SpamapSjimbaker: ^^ get on it18:47
m_3really though, what's in the way of installing juju packages and passing it credentials in databag18:47
SpamapSm_3: haha.. "credentials"18:48
* m_3 sigh18:48
SpamapSmeaning, the address of ZK? ;)18:48
m_3yes, that18:48
SpamapSm_3: don't worry, we'll have ACLs soon18:48
SpamapSI think18:48
m_3zk's gotta get a new node put in, but jitsu can do that really18:49
m_3Urocyon: fun project :)18:49
m_3SpamapS: what sort of battery life are you getting nowadays on your little one?18:50
m_3I really was wishing I had that the past couple of days... we were short on juice at gluecon18:50
SpamapSm_3: 5.5hrs usually18:55
jimbakerSpamapS, unprovider sounds like a good idea to me18:55
SpamapSm_3: sometimes only 5 if I watch too many videos :)18:55
m_3wow18:55
SpamapSm_3: yeah, precise added the "deep" sleeping where it basically turns everything off if all I'm doing is staring at the screen for a few seconds18:56
SpamapSdeep C6 or whatever its called18:56
m_3oh nice18:56
SpamapSwhich realistically, we all do quite a bit of18:56
m_3was that a tweak of out of the box18:56
SpamapSits standard18:57
* m_3 looks the other way and whistles18:57
SpamapSthe only tweak I did was choose Unity 2D18:57
SpamapSseriously :)18:57
m_3my mbp13's still a hog... less than half that time18:57
=== Furao_ is now known as Furao
UrocyonWhere is the code for existing charms stored?19:00
m_3Urocyon: jujucharms.com has browsable links to code.launchpad.net/charms19:02
m_3Urocyon: sorry, the lp:charms/hadoop repo urls are actually "launchpad" shortcuts19:03
m_3we just get used to throwing "lp:" around in here without warning or explanation19:04
SpamapSUrocyon: the charms are stored/developed in bzr branches on launchpad. You can also use the built in "charm store" by just typing 'juju deploy foo' .. but there are issues with doing that in production (you can't change the charm for instance)19:05
m_3atp-get install charm-tools && charm getall && grab coffee19:07
UrocyonI haven't ever done any work with launchpad, but I'm guessing that's a bit like github, and that I should fork the charms I need and deploy using those?19:08
m_3Urocyon: in short, yes19:08
SpamapSm_3: ugh.. charm getall sucks man.19:10
SpamapS<-- author of charm getall19:10
m_3afaik, the biggest difference between launchpad and github is that lp has a lot of test/build-related stuff to make sure ubuntu packages are all green19:11
m_3otherwise, you can pretty much assume common features19:12
m_3Urocyon: btw, github.com/charms19:12
SpamapSUrocyon: we'd rather that you use the charms as-is, and feed back any changes you see necessary so that all can benefit19:12
SpamapSUrocyon: unlike chef, juju is designed for encapsulation so you don't have to fork (though you can of course)19:13
SpamapSm_3: I'm still not convinced that having a github mirror is a good thing. Just confuses people when they're ready to start doing real charm store dev.19:13
SpamapSm_3: think how hard its going to be for somebody who forks them on github to actually get that change back in to LP19:14
m_3SpamapS: true, and we haven't had that much call from users to have them hosted on github19:14
m_3SpamapS: pull requests were gonna be manual until we decided if it was worth it19:15
=== spladug is now known as SteveNewhouse
m_3I'm happy to just turn them into redirects whenever people think we should19:15
=== SteveNewhouse is now known as spladug
m_3happy with that being a ~charmers decision... and not just mine19:16
Urocyonsure, just trying to the the swing of launchpad here.19:16
m_3Urocyon: oh right... we're just off on a tangent :)19:16
SpamapS*DOH* .. just noticed that txzookeeper's packaging states MIT/X/Expat but txzookeeper is LGPL319:18
* SpamapS is undaunted by the Debian NEW rejection.19:18
Urocyonwhen contributing, is there an official way your hooks should be written? i.e. write hooks in bash.19:19
SpamapSUrocyon: nope19:20
SpamapSUrocyon: thats intentional. Write them howe you want. :)19:21
SpamapSwow unstacking is *slow*19:22
SpamapSJust realized its still going.. rabbitmq-server19:22
m_3I saw something about cycles in stacks being a problem... hope we haven't created any of them19:25
SpamapSm_3: the problem with unstacking is that now each branch gets bigger for launchpad to deal with. But thats ok in this instance where verything is just all screwed up19:27
UrocyonSpamapS: hmmm, just getting my feet wet, I see what you mean about decoupling provision and event handling...19:30
SpamapSUrocyon: yeah, it comes from the goal being to take advantage of the cloud's magic ability to give you lots of shiny clean servers. :)19:31
SpamapSUrocyon: but there's value in being able to use juju on dirty old servers too. :)19:31
* SpamapS wonders if that is a euphamism for waiters in tiki lounges19:32
* SpamapS heads to lunch19:32
UrocyonSpamapS: well I enjoy taking advantage of the magic shiny clean servers, I just am doing it with chef at the moment.   Most of the charms it seems overlap with chef though - with a focus on configuring a service.19:33
UrocyonI have chef to do that.  I just want to better manage relationships and add on event handling.19:33
UrocyonSpamapS: just seems like I'm not getting as much use out of the existing charms that way.19:35
hazmatSpamapS, yeah.. it basically has to copy the history back19:44
imbrandonSpamapS / m_3 : wait , did i miss something , i thought the plan was to move in the other direction ?19:56
hazmatSpamapS, ugh.. i thought i'd fixed that ..19:57
SpamapSimbrandon: whats the other direction?21:42
SpamapShazmat: you thought you had fixed what?21:43
hazmatSpamapS, the licensing stuff in txzk21:43
SpamapShazmat: oneiric branches should all be fixed now21:43
hazmatSpamapS, sweet21:43
SpamapShazmat: Yeah I think you fixed it in trunk, but I didn't fix it in the packaging21:44
SpamapShazmat: so it failed NEW review in Debian. :-P21:44
SpamapSI'll fix it. Should have double checked anyway21:44
hazmatSpamapS, james_w, m_3 thanks for fixing those branches21:50
SpamapShazmat: hey did you say you have sup working with ruby 1.9 ?21:54
hazmatSpamapS, yup21:55
SpamapShazmat: I had to make some.. evil symlinks to get it to start up21:55
hazmatSpamapS, i just run it from git .. with a -Ilib bin/sup and alias21:56
SpamapShazmat: Ok so "run it as crack"21:56
SpamapSgood idea :)21:56
SpamapShazmat: I'm running from an old git snapshot that I patched to work with gpgme221:56
hazmatSpamapS, well i'm on stable branch.. so not quite21:56
hazmatSpamapS, yeah.. that integration seems a little borked still to me21:57
hazmati've got the gem installed, but its not detecting it.. haven't really investigated21:57
SpamapShazmat: it is. Its just useful for reading encrypted and verifying signed messages. Sending, I still just pipe to clearsign21:57
hazmatSpamapS, by crack you mean running mostly unmaintained stuff like sup ;-)21:57
SpamapShazmat: gpgme2 has an entirely different API and sup has never been updated to use it21:57
hazmatgotcha21:57
SpamapShazmat: I keep meaning to try heliotrope21:58
hazmatSpamapS, i'm going to bite the bullet and do gmail21:58
hazmati like sup.. but having my email on all my devices and easy to check from anywhere is a huge win still21:58
SpamapShazmat: having *access* on all your devices you mean. ;)21:59
hazmatSpamapS, fair enough21:59
SpamapShazmat: I have to agree though. The web interface I do have is basically total crap.22:00
hazmatSpamapS, only downside is loss of gpg22:01
james_wI thought about setting up heliotrope the other day, but it looked a bit too rough22:01
james_we.g. I didn't see a mention of authentication22:03
SpamapSPerhaps the sup guy just gave up and started using gmail too? ;)22:03
james_whe doesn't appeared to have committed for a month :-)22:03
hazmator maybe its just done ;-)22:04
SpamapSSoftware that is "done" is so boring ;)22:15
imbrandonsoftware is never done22:17
=== andreas__ is now known as ahasenack
SpamapSwooot! txaws in Debian unstable. :)22:19
imbrandonsweet22:19
nathwillis there any way to inspect relation settings similar to the config settings accessed with juju get service? something like juju relation-get service1 service2 ?22:22
nathwilli know you can see them being set in debug-log, but not aware of a more ondemand kind of way to inspect...22:22
SpamapSnathwill: yes you can inspect all of them22:28
SpamapSnathwill: you'll need to tell relation-get where to find them, and which context you mean22:29
SpamapSnathwill: so you need to pass -s /path/to/agent/socket and -r relation:id22:29
SpamapSnathwill: you can get the relation:id from the 'relation-ids' command22:29
nathwillSpamapS, this is inside a hook?22:30
SpamapSnathwill: if you're already inside a hook, don't need to pass -s22:30
nathwillright. ok...22:30
SpamapSnathwill: and if you're in a *relation* hook, then you don't even need to pass -r22:30
nathwillum, how can i find the socket?22:30
SpamapSnathwill: lsof works :)22:31
SpamapSpython  4597 root   11u  unix 0xffff880065374000      0t0  10917 /var/lib/juju/units/vivo-1/.juju.hookcli.sock22:31
nathwillhaha, ok. sugarless solutions work :)22:31
SpamapShmm, dunno how to set JUJU_CLIENT_ID actually22:32
jimbakernathwill, an alternative is to use jitsu run-as-hook22:32
SpamapSnathwill: you can also use 'jitsu run-as-hook'22:32
SpamapSJUJUJITSUJINX22:33
jimbaker;)22:33
SpamapSsay that 5 times fast :)22:33
nathwilljitsu you say... i've heard about it, guess i'll have to go fiddle w/ it22:33
imbrandonheh22:33
jimbakerSpamapS, i gave up just saying juju-jitsu22:33
SpamapShrm looks like 0.6 never made it to the PPA22:34
jimbakernathwill, jitsu run-as-hook is good for inspecting settings. so you can do stuff like $ jitsu run-as-hook mysql/0 relation-get -r db:0 -22:34
jimbakerand if you had a service unit of mysql/0 with a relation of relation id of db:0, you would get those settings22:35
SpamapSahh right, they need to update launchpad so I can use '{latest-tag}' in bzr recipes22:35
nathwillk, thanks folks. i'm trying to ascertain the best way of setting a password for a default user in owncloud.22:35
nathwillowncloud doesn't separate the db config from the default admin config like WP22:36
jimbakeryou could do $ jitsu run-as-hook mysql/0 relation-ids db to get a relation id; juju status of course to get the service unit you wish to inspect; etc22:36
jimbakerwhere again i'm just some standard examples like db for a relation name22:36
nathwillso there's no automagical way to hide the db business if trying to use remote mysql host... i've got some ideas, just want to look at what the users are going to have to go through to get the pwd out of the settings22:36
jimbakernathwill, yes, the flip side is that this stuff is in ZK22:37
nathwilli'm almost thinking a config option is best, and forget the autogenerating bit22:38
SpamapSnathwill: this is a common enough problem, I think we need to solve this in juju core. type: password would be cool, where it just generates a random password on the first deploy, and then you can 'config get' to see it22:38
nathwillSpamapS, that would be amazing.22:39
SpamapSnathwill: another option is to just put it somewhere that the admin can access it through juju ssh22:39
nathwillyeah, i thought about writing it to a tightly perm'd file... it just feels kludgy to do that type of thing22:40
SpamapSI think juju needs more ways of feeding data back from charm->admin though22:40
SpamapSdebug-log is a really awful way of doing it22:40
nathwillmaybe a config-set option to create config parameters during hook execution?22:40
SpamapSconfig-set has come up a lot22:40
SpamapSand its my favorite option22:40
SpamapSbecause then charms can generate passwords that they know will work with the intended software22:41
* nathwill nods22:41
hazmatas long any hook set values are namespaced away from service config, sounds good22:55
hazmatSpamapS, nathwill its basically 'constant' as i recall22:56
hazmathave a good weekend folks22:56
nathwillditto hazmat22:56
SpamapSaye you too hazmat22:57
bkerensanathwill: someday you will be a jedi :)23:08
imbrandonnice, drizzel + nginx natively talking to it + nodejs taking the json output and turning it pretty with express templates23:10
imbrandoni think i might have found a reason to give up php23:10
nathwilloh dear. another one drank the koolaid23:12
imbrandonheh the only new thing in there that i havent been useing is express templates ( well and drizzel but right now its the same as mysql in my setup )23:12
imbrandoni just like the fact that nginx talks directly to drizzel/mysql, i dont mean proxying to it, i mean talks to it, then spits out cvs/json/etc23:14
imbrandon:)23:14
imbrandonoh and does it in a non-blocking way to the eventloop keeps going , meaning 10k+ connections and not blink23:14
nathwilli was referring to the nodejs koolaid. the other business sounds cool23:17
imbrandonahh well js koolaid maybe, node though is fskin FAST only thing i seen close it it is nginx and it still cant keep up23:20
imbrandonnathwill: trust me i was right with you about js/nodejs/jsp crap untill about ohhhhhh 2 months ago and did somehting with a co-worker by accident , then i had to give it a real look again, its a totaly diff landscape than 3 years ago even let alone 12 or 15 when i wrote off JS23:22
imbrandon:)23:22
nathwillimbrandon: i hope you're right. i fear what the js monkeys will do to the web when they have control of the backend. my experience to date has confirmed this; though i admit i have not investigated very deeply23:23
imbrandoni dont think its a good app platform, but its a good async utility / api one if each bit is kept self contained23:23
nathwillimbrandon, that makes sense.23:24
imbrandonoh and did i say fast23:25
imbrandonlol23:25
imbrandoni was pulling sql rows with selct * limit 0, 1000 earlier then spit it out as json and ran seige on it just for an unscientiffic test23:26
imbrandonand my cpu gave out before i could make it cause errors in the requests23:26
imbrandonand that was just with like 5 minutes and no optimizations etc etc23:27
imbrandoncurious to see how the disk io is on it tho23:28
imbrandonsomething to try out the next few days23:28
imbrandonbut i'm fairly sure all my php REST stuff is going to be replaced with small node apps over the next few months the way it looks23:29
imbrandonon the back end at least23:29
imbrandonpair that with nginx rev proxing all that apps from diff ports into one interface and microcache it , might be onto something big there :)23:30
imbrandonSpamapS: you realize that nginx will even act as a mongo or mysql proxy , you basicly just list the upstreams the same way we did the php-fpms23:33
imbrandonthis thing is starting to become a hammer and everyones got nails i need to pound on23:33
imbrandoni'm starting to think nginx is a tcp proxy first and httpd second23:34
nathwillwe use nginx for proxying imap. works pretty well23:39
SpamapSimbrandon: it doesn't really grok the mysql protocol tho23:58
SpamapSimbrandon: also, Drizzle has an HTTP+JSON plugin, so you don't really need nginx to translate23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!