[00:00] <SpamapS> just fire up a merge proposal for the drafts directory?
[00:01] <jimbaker> SpamapS, that would be a normal process. and this info would be really cool to have, and a nice way to integrate w/ puppet too
[00:16] <hazmat> SpamapS, write a rest formatted specification, put in docs/specifications of a branch, and propose on list
[00:16] <hazmat> SpamapS, alternatively just start the discussion on list
[00:17] <SpamapS> I may try my hand at implementing it too... it should be pretty easy, as there's no data storage requirement.. just a proxy to the real info really
[00:37] <hazmat> SpamapS, to save time/effort, i'd try'd to start the discussion b4 impl
[00:41] <SpamapS> hazmat: but I wanna play with my six-guns!
[00:43] <hazmat> SpamapS, word.. i've been thinking about plugin apis
[00:43] <hazmat> probably wouldn't help here.. but it would be nice to have
[00:44] <hazmat> i'd like to keep playing with the auto-resolve  i put together... which might work as a plugin
[00:44] <SpamapS> yeah actually thats probably the right way to go since there are some murky aspects of what we actually want auto-resolution to do
[00:44] <hazmat> SpamapS, course there's always room for a BFG  ;-)
[00:46] <hazmat> SpamapS, minus the remote repo stuff, the one committed, is pretty solid.. takes into account env, pull extra deps and adds any needed relations (including against existing services).. but that's pretty trivial.. multiple providers in the environment and the formula are pretty much random selection.. remote should be straightforward.. still needs some tweaks on the repository lookup order (using the repository found for a dep as the primary lookup f
[00:46] <hazmat> or the next dep for any formulas from that repo)
[00:47] <hazmat> with the remote repo the sharing store should be pretty nice
[01:01] <SpamapS> hazmat: I think we need a new way to express "recommends" and "suggests" type relations in formulas. I don't want to force people to use munin, just because mysql supports it.
[01:01] <hazmat> SpamapS, i don't think that should be in the mysql formula
[01:01] <hazmat> its not core to its responsibilties
[01:01] <SpamapS> agreed, its a policy thing :)
[01:01] <SpamapS> but it needs to be *doable* before I can take it out
[01:01] <SpamapS> because I want to graph stuff, damnit. ;)
[01:02] <SpamapS> also mediawiki works great w/o memcache
[01:02] <hazmat> either inheritance, possibly containment based (pull additional stuff from env) or policy formulas.. policy formulas are a little better in avoiding possible tight association to a machine
[01:02] <hazmat> yeah.. graphing stuff is required..
[01:02] <hazmat> first rule of devops.. measure
[01:03] <SpamapS> I was thinking maybe the answer to the policy thing is to have a way to model your desired machines much the same way you model your services
[01:03] <SpamapS> which is sort of like inheritance
[01:04] <SpamapS> like, inherit this class "ubuntu::mymachine" and morph it into ubuntu::mymachine::mysql
[01:13] <hazmat> SpamapS, tight machine coupling to units is best avoided
[01:13] <hazmat> it makes unit migration much harder
[01:14] <hazmat> either for scaling up compute capacity available to a unit.... or resurrection in the case of a dead machine
[01:15] <SpamapS> hrm, I guess what I mean is, I want to be able to say two things.. 1) I want my machines to look like X, and 2) I want my service to be deployed on my machines.
[01:15] <SpamapS> Right now we're saying "I want my machine to look like a bare bones Ubuntu machine"
[01:24] <hazmat> SpamapS, true.. the question of what to do with 1) is basically how does ensemble handle machine configuration management
[01:24] <hazmat> 2) is a little dangerous.. because if the service depends on the machine configuration than we loose reuse
[01:25] <hazmat> re 1) we either adopt an existing configuration management system, adopt policy formulas, or grow our own declarative config
[01:27] <hazmat> pretty much every corp env.. i've seen has a bunch of policy associated to a machine.. nfs mounts to sans, auth mech integration, monitoring/alerting.
[01:37] <SpamapS> hazmat: I'd say that we should make sure we have a hand in the machine config, as that way we can at least have a chance at early warning that a formula and a machine policy conflict
[01:38] <SpamapS> hazmat: most of what is "machine policy" in big corp environments tho, is to get around how hard it is to deploy things. :)
[14:43] <kim0> niemeyer: morning :)
[14:43] <niemeyer> Good morning!
[14:44] <kim0> niemeyer: I noticed your debug-hooks branch .. is it in a useable state ?
[14:44] <niemeyer> kim0: It actually is!
[14:44] <niemeyer> kim0: I'll be finishing it within the next hour or so, so any input you have will be welcome
[14:45] <kim0> niemeyer: well I tried using it 
[14:45] <kim0> but it blocks on "connecting to remote machine ... "
[14:45] <kim0> I killed it multiple times .. always the same
[14:45] <niemeyer> kim0: Have you tweaked your configuration to actually use the branch in the server side as well?
[14:45] <kim0> ah :)
[14:45] <kim0> nope
[14:45] <niemeyer> kim0: Yeah, that won't work
[14:46] <kim0> ok I'll do it
[14:46] <kim0> thanks
[14:46] <niemeyer> kim0: ensemble-branch: lp:~niemeyer/ensemble/debug-hook-fixes
[14:46] <niemeyer> kim0: next to type: ec2
[14:46] <kim0> Yeah thanks .. I did that one before
[14:48] <kim0> Q: does relation-get foo, have a non-zero exit status if foo has not been set yet?
[14:54] <niemeyer> kim0: IIRC, no.. for relation-get, not setting is equivalent to the empty value
[14:54] <niemeyer> kim0: So much so that relation-set foo= will erase the value
[15:18] <_mup_> ensemble/debug-hook-fixes r243 committed by gustavo@niemeyer.net
[15:18] <_mup_> - Don't overwrite config if it exists.
[15:18] <_mup_> - Tests work again, even though a bit difficult to test the shell
[15:18] <_mup_>   scripts themselves without a real run.
[15:18] <_mup_> Now, for some real world testing.
[15:19] <niemeyer> kim0: Just pushed the RC (Review Candidate ;-), if you want to test it
[15:19] <niemeyer> I'm doing the same here
[15:19] <kim0> great .. pulling
[15:37] <_mup_> Bug #792406 was filed: "Will wait" never returns <Ensemble:Confirmed> < https://launchpad.net/bugs/792406 >
[15:42] <niemeyer> kim0: There's a bug on it, btw
[15:42] <kim0> niemeyer: it's not finish initialization ?
[15:43] <kim0> finishing*
[15:44] <niemeyer> Yep
[15:44] <niemeyer> kim0: Am on it
[15:45] <_mup_> ensemble/debug-hook-fixes r244 committed by gustavo@niemeyer.net
[15:45] <_mup_> Forgot to rename the control import after the rename of
[15:45] <_mup_> the debug_hook file to reflect the actual debug-hooks
[15:45] <_mup_> command name.
[15:45] <niemeyer> kim0: ^
[15:45] <niemeyer> Pushing
[15:46] <kim0> niemeyer: is there some way for drupal/0 to talk to drupal/1 ? 
[15:46] <kim0> as in tell it, "I already did the DB setup .. just use it"
[15:53] <niemeyer> kim0: That's not a task for them
[15:54] <niemeyer> kim0: The mysql units are the ones doing the database setup
[15:55] <kim0> niemeyer: I kinda meant .. I populated the DB tables
[15:55] <hallyn> hey - i'm trying to set up relations between a master and new slave node in jenkins.  Is there a definitive order in which the master and slave's -joined hooks fire?
[15:56] <niemeyer> hallyn: Hey Serge!  Very happy to see you're experimenting with it
[15:56] <hallyn> actually, maybe i'm being silly.  i guess one of the steps i wanted to sync doesn't need to wait
[15:56] <hallyn> niemeyer: i'm really enjoying it!
[15:56] <niemeyer> hallyn: Woot!
[15:56] <niemeyer> hallyn: There isn't an order
[15:56] <niemeyer> hallyn: On purpose, mostly
[15:57] <hallyn> ok
[15:57] <kim0> niemeyer: currently this is done by drupal/0 .. I'd like to tell drupal/1 to skip creating the tables and part and just connect (I could ofc check if the tables exist, just wondering if there's a better way)
[15:57] <niemeyer> hallyn: But you can create the ordering by setting/getting relation settings as you see fit
[15:58] <hallyn> what do you mean?  in particular - i think i don't need this after all, but am wondering - waht if i need to do a 5-way protocol between master/server?
[15:58] <niemeyer> hallyn: We should document better that feature, actually.
[15:58] <hallyn> master/slave, that is
[15:58] <niemeyer> hallyn: That's fine
[15:58] <hallyn> oh, i can use relation-{set,get} as sync points?
[15:58] <hallyn> suddenly i'm using Ada!
[15:58] <niemeyer> hallyn: Yeah.. you can do something like this:
[15:59] <niemeyer> hallyn: if [ -z "relation-get someinfo" ]; then exit 0; fi # Data isn't there yet
[15:59] <niemeyer> hallyn: Ensemble guarantees that when anything on the relation is changed, the hook is called again
[15:59] <hallyn> aaah
[15:59] <hallyn> makes sense
[15:59] <hallyn> meanwhile, -joined gets called for both ends, right?  
[15:59] <niemeyer> Sorry, that should be backticks, but you get the idea
[15:59] <hallyn> yup :)
[15:59] <niemeyer> hallyn: Yeah, joined is a single shot
[16:00] <hallyn> cool.  thanks.  i'm off to try and finish this then
[16:00] <niemeyer> hallyn: That's awesome, please let us know how it goes
[16:01] <niemeyer> kim0: There is something for exactly this case, but we haven't put much work on it yet
[16:01] <niemeyer> kim0: Besides client/server relations, we have something called peer relations
[16:01] <niemeyer> kim0: Their use is precisely for that kind of thing
[16:01] <kim0> a ha 
[16:01] <niemeyer> kim0: You can talk to the other units of the node
[16:02] <kim0> ok np
[16:02] <niemeyer> kim0: Be aware though, we need to test it :-)
[16:02] <kim0> I'll just interrogate the DB
[16:02] <niemeyer> kim0: That's a good way for the moment
[16:02] <niemeyer> kim0: peer relations will be perfect for that in the near future
[16:02]  * kim0 proceeding to torture the debug-hooks branch
[16:02] <niemeyer> kim0: Sweet :-)
[16:02] <kim0> hehe
[16:03] <niemeyer> jimbaker: ping
[16:03] <kim0> can you guys silence the txaws warning :)
[16:03] <niemeyer> kim0: Which warning?
[16:03] <kim0> /usr/lib/pymodules/python2.7/txaws/ec2/client.py:223: FutureWarning: The behavior of this method will change in future versions.  Use specific 'len(elem)' or 'elem is not None' test instead.
[16:03] <niemeyer> kim0: Weird.. I'm not seeing that
[16:03] <kim0> I'm probably using an old version
[16:09] <kim0> niemeyer: I though tmux was using screen cli shortcuts ?
[16:09] <kim0> thought*
[16:11] <kim0> niemeyer: also, is it normal that I don't see ensemble-log messages from install hooks
[16:13] <niemeyer> kim0: Which shortcuts are you missing?
[16:13] <kim0> Ctrl-A " ?
[16:14] <niemeyer> kim0: re. logs, what's the context?
[16:14] <niemeyer> kim0: What does that do?
[16:14] <kim0> niemeyer: shows a list of windows .. allowing visual selection
[16:14] <kim0> it was just the first thing I tried .. I see now it's not that bad :)
[16:15] <jimbaker> niemeyer, hi
[16:15] <niemeyer> kim0: CTRL-A 1?
[16:15] <niemeyer> jimbaker: Hey jim
[16:15] <kim0> niemeyer: using deploy drupal .. the install hook fires, calls ensemble-log .. but that doesn't show in my debug-log session
[16:15] <kim0> jimbaker: morning o/
[16:15] <niemeyer> jimbaker: Ensemble needs some more love on the connection establishment front
[16:15] <kim0> any default filters exist ?
[16:15] <jimbaker> kim0, beautiful morning here
[16:15] <kim0> :) sweet
[16:16] <niemeyer> jimbaker: Are you sure you want to continue connecting (yes/no)? yes
[16:16] <niemeyer> ProviderError: Interaction with machine provider failed: ConnectionTimeoutException('could not connect before timeout after 1 retries',)
[16:16] <niemeyer> 2011-06-03 12:02:44,706 ERROR ProviderError: Interaction with machine provider failed: ConnectionTimeoutException('could not connect before timeout after 1 retries',)
[16:16] <niemeyer> etc
[16:16] <niemeyer> jimbaker: It fails in different ways in different cases, doesn't wait properly, etc
[16:16] <kim0> Would be awesome if we could reuse connections as well :)
[16:16] <niemeyer> jimbaker: After you're done with exposure, it'd be good to spend some time actually trying to use it for real
[16:17] <niemeyer> kim0: Just got my time machine.. ensemble open-tunnel
[16:17] <kim0> have no idea what does that do ?
[16:17] <niemeyer> kim0: What you asked for :)
[16:17] <kim0> oh!
[16:17] <jimbaker> niemeyer, ok. from what you posted, seems like a matter of tuning, but i'll look at it in depth as you suggest
[16:18] <niemeyer> jimbaker: Yeah, tunning/bug fixing/polishing.. whatever we want to call it.. we just need a smoother experience on connection establishment
[16:18] <niemeyer> jimbaker: How's that exposure stuff going?
[16:18] <jimbaker> niemeyer, agreed. probably bumping the retries would suffice
[16:18] <jimbaker> niemeyer, bumping up that is
[16:19] <niemeyer> jimbaker: No, it likely wouldn't..
[16:19] <niemeyer> jimbaker: I'm pretty sure *1* retry isn't the number we have today
[16:20] <bcsaller> bug #792406 sounds like the halting problem ;)
[16:20] <_mup_> Bug #792406: "Will wait" never returns <Ensemble:Confirmed> < https://launchpad.net/bugs/792406 >
[16:20] <kim0> bin/ensemble debug-log -i '*'   →  still doesn't show ensemble-log messages fired at install/start stage ?!
[16:20] <niemeyer> bcsaller: Hey!
[16:20] <jimbaker> niemeyer, exposure is going fine - i have hook commands working, just need some more testing; and i'm waiting on the review of the expose-provision-service-hierarchy review
[16:20] <bcsaller> hey
[16:21] <kim0> bcsaller: hi there
[16:21] <niemeyer> jimbaker: You have an open review on the pre-requisite branch
[16:21] <niemeyer> jimbaker: I'm waiting for you to address this one before looking at the next one
[16:21] <niemeyer> jimbaker: The branch is pretty simple, so I was expecting you'd get through it quickly
[16:21] <jimbaker> niemeyer, ahh, ok, i will work on that now then
[16:22] <niemeyer> jimbaker: Are you doing debug-log + debug-hooks?
[16:23] <niemeyer> Sorry
[16:23] <niemeyer> kim0: Are you doing debug-log + debug-hooks?
[16:23] <hallyn> all right, if i have formulas 'x' and 'x-slave', with x providing master: x and x-slave providing slave:x (and each requiring the other), should the forumales be called 'x-relation-joined' or 'master-relation-joined'?
[16:23] <kim0> niemeyer: yeah
[16:23] <kim0> is there some conflict
[16:23] <jimbaker> niemeyer, yes, it is really a matter of determining some code patterns you were asking about to see what's going on - most of that came from the waiting for godot redux work
[16:23] <niemeyer> kim0: Yeah, the output from the hook on debug-hooks is your terminal, so you won't see it in the logs
[16:24] <jimbaker> as in, presumably already vetted code, i wanted to see if i made some mistake in applying the pattern, and if not, how else is it used
[16:24] <niemeyer> kim0: I'm not touching that area on this branch, and I'm not aware of any issues on debug-log, so if you have any known issues on debug-log, please bring them up
[16:24] <kim0> niemeyer: sorry, in the install hook stage .. I hadn't opened debug-hooks yet 
[16:24] <kim0> niemeyer: Also .. once a window opens in tmux .. it cds to /usr/lib/ensemble/txzookeeper .. not where the hooks are
[16:24] <niemeyer> kim0: Do note, however, that today debug log only starts logging after you execute the command
[16:25] <niemeyer> kim0: Yes, we talked about that yesterday
[16:25] <kim0> should I open a bug on that
[16:25] <niemeyer> kim0: As I pointed out yesterday, this is a more general issue.  All hooks are executed in another directory. We have to fix that generically, and put the hooks to execute with curdir set to the formula dir.
[16:25] <niemeyer> kim0: I _think_ we already have a bug open for that
[16:26] <kim0> ok got you
[16:26] <niemeyer> kim0: That said, please do check it out and file if you can't find it
[16:26] <niemeyer> kim0: This feels like something I can address right after this is finished
[16:26] <niemeyer> kim0: This first one, on debug-hooks, that is
[16:26]  * kim0 nods
[16:27] <kim0> cd to hooks dir .. ok
[16:29] <kim0> getting strange debug-log output → 2011-06-03 17:22:51,493 unit:drupal/0: hook.output ERROR: /tmp/tmpe7x6qc-db-relation-joined: line 37: kill: (2378) - No such process
[16:33] <jimbaker> niemeyer, SSHClient.connect controls this with a timeout parameter. maybe this should be exposed to our commands as a  standard param or env var. right now it defaults to 30s.
[16:34] <jimbaker> niemeyer, there is some testing to verify that the timeout actually is effective (and so can have more than one retry), but it is mock testing.
[16:35] <niemeyer> jimbaker: Please do finish the expose stuff before working on this
[16:35] <kim0> niemeyer: please check that kill error ^ looks weird
[16:35] <jimbaker> niemeyer, sounds good
[16:36] <niemeyer> kim0: Indeed, that sounds quite interesting
[16:36] <niemeyer> kim0: Investigatingt
[16:36] <niemeyer> Actually, I'll just merge a branch before that
[16:39] <hallyn> ambiguous endpoints
[16:41] <kim0> Writing formulas is much fun :)
[16:41] <_mup_> ensemble/trunk r240 committed by gustavo@niemeyer.net
[16:41] <_mup_> Merge close-zk-port branch [r=jimbaker,hazmat]
[16:41] <_mup_> This prevents a very silly security issue which allows external people
[16:41] <_mup_> to dial into the zookeeper port.
[16:41] <_mup_> The expose+open-port work in progress at the moment will address this
[16:41] <_mup_> in a better way, and the follow up work on ZK ACLs will close the door
[16:41] <_mup_> more properly.
[16:41] <kim0> I am genuinly happy btw :) no sarcasm
[16:42] <SpamapS> kim0: +1 .. :)
[16:42] <kim0> SpamapS: morning o/
[16:43] <niemeyer> hallyn: When establishing a relation?
[16:43] <niemeyer> SpamapS: Yo!  Awesome news re. the talk approval
[16:44] <niemeyer> kim0: Aha, thanks for the warning re. kill
[16:44] <niemeyer> kim0: It wasn't a bug, but rather a message we shouldn't print
[16:44] <SpamapS> niemeyer: just a bof, but definitely should be cool. I actually hope the puppet and chef guys will be there (they're all speaking at oscon).
[16:44] <niemeyer> kim0: kill -0 was expected to fail at some point there
[16:44] <SpamapS> no surprise that puppet labs would be there.. given its in Portland where their home office is.
[16:45] <kim0> niemeyer: cool .. another suspicious message would be → 2011-06-03 17:22:51,565 unit:drupal/0: hook.output ERROR: duplicate session: drupal/0
[16:46] <niemeyer> kim0: Hah, cool, same case
[16:46] <niemeyer> kim0: That's actually one of the bugs being fixed
[16:46] <niemeyer> kim0: Before it would simply create the two sessions
[16:47]  * kim0 nods
[16:49] <niemeyer> kim0: Ok, both fixed locally.. will do a last run after lunch, and then submit for review
[16:49] <SpamapS> niemeyer: how do I take advantage of the open-tunnel command btw?
[16:49] <niemeyer> kim0: Thanks a lot for your help
[16:49] <kim0> niemeyer: aye aye 
[16:50] <niemeyer> kim0: Please ping me if you find anything else you feel would need attention
[16:50] <niemeyer> SpamapS: Just open it in a different terminal
[16:50] <kim0> niemeyer: I'm running it in bg & 
[16:50] <niemeyer> SpamapS: While the command is open/executing, every other command will make use of the tunnel if possible
[16:50] <kim0> niemeyer: doesn't make status faster ?
[16:50] <SpamapS> niemeyer: I was thinking it would give me some sort of indication its working. I tried reading the code and I have *no* idea how it can possibly work. ;)
[16:51] <niemeyer> SpamapS: It's actually fairly simple.  We make heavy use of a feature of SSH which is not very explored, which is why you don't find much logic in there.
[16:51] <niemeyer> SpamapS: The best indication is that your commands will be blazing fast :)
[16:52] <SpamapS> niemeyer: is it using the Master/Slave stuff?
[16:52] <hallyn> niemeyer: oh, yes.  when establishing relation.  probably my extraneous statements inthe metadata.yaml.  trying again
[16:53] <niemeyer> SpamapS: Yeah
[16:53] <niemeyer> SpamapS: Check prepare_ssh_sharing, under ensemble/state/sshforward.py
[16:53] <niemeyer> hallyn: Ah, that's fine
[16:53] <niemeyer> hallyn: In general it just means there are multiple possible ways to make the relation
[16:54] <niemeyer> hallyn: You can disambiguate by providing the relation name in addition to the service name
[16:54] <niemeyer> hallyn: e.g. add-relation myservice1:therelationname service2
[16:54] <niemeyer> hallyn: For instance
[16:55] <hallyn> oh, will try that if it fails again, thaks.  but i was specifying 'provides: slave: x', which probably is confusing
[16:55] <SpamapS> the mediawiki formula has two mysql interface requires relations, so one always has to specify whether they want the 'db' relation or the 'slave' relation.
[16:55] <niemeyer> Ok, lunch!
[16:55] <niemeyer> biab
[16:58] <kim0> niemeyer: is there a good way to "debug-hooks" before "install" hook fires .. other than launching debug-hooks in the nick of time
[16:58]  * SpamapS notes that ensemble should Recommend: python-pydot
[16:59] <_mup_> txzookeeper/session-event-handling r42 committed by kapil.foss@gmail.com
[16:59] <_mup_> watch wrapper that diverts session events to a session event callback set on a connection.
[16:59] <kim0> SpamapS: what does that do
[17:00] <SpamapS> kim0: bzr status --format dot
[17:00] <SpamapS> err
[17:00] <SpamapS> haha
[17:00] <SpamapS> ensemble status --format dot
[17:00] <SpamapS> I keep mixing those two up. :-P
[17:01] <kim0> installing
[17:01] <SpamapS> hmm doesn't seem to work ...
[17:01] <SpamapS> bcsaller: having trouble using ensembl status --format dot ..
[17:02] <SpamapS> http://paste.ubuntu.com/617639/
[17:02] <bcsaller> ensemble status --format svg --output /tmp/status.svg ; eog /tmp/status.svg
[17:02] <SpamapS> Oh!
[17:03] <bcsaller> though that error is confusing, it looks like there is some other issue
[17:03] <SpamapS> same error
[17:04] <kim0> bcsaller: wow that rox :)
[17:04] <bcsaller> SpamapS: can you email me the dot file, it seems like there is some version error happening here, I want to see if I can find it 
[17:05] <SpamapS> bcsaller: where would the dot file be?
[17:05] <bcsaller> hmm. nowhere if you can't even generate it I guess :-/
[17:07] <SpamapS> bcsaller: Here's my status output... http://paste.ubuntu.com/617644/
[17:07] <SpamapS> You can reproduce very easily with the mediawiki test from principia-tools
[17:07] <bcsaller> the first error listed a tmp file, is that left around or cleaned up?
[17:07] <SpamapS> bcsaller: if you have a quick answer that would be awesome.. trying to put together a "WTF is ensemble" blog post
[17:07] <SpamapS> cleaned up
[17:42] <_mup_> Bug #792448 was filed: status dot ouput fails with errors <Ensemble:New> < https://launchpad.net/bugs/792448 >
[17:43] <kim0> Is it ok to put template files besides hooks .. and use them from the hooks ?
[17:43] <SpamapS> yep
[17:43] <SpamapS> kim0: the whole formula dir is zipped up and sent to the machine
[17:43] <kim0> cool
[17:44] <kim0> trying to embed php code in bash scripts is no fun :)
[17:52] <SpamapS> Yeah I just went ahead and wrote a few hooks in PHP ;)
[17:53] <SpamapS> so I could extract stuff from includes/settings files.
[17:53] <SpamapS> PHP actually has a quite rich set of capabilities for file manipulation
[17:54] <SpamapS> Hmm ok so if I wanted to spawn m1.small's instead of t1.micro's ... anybody have a clue how I might do that?
[17:54] <SpamapS> I thought changing environments.yaml to add 'default-instance-type: m1.small' would do it, but still seem to be spawning t1.micro's
[17:56] <hazmat> SpamapS, hmm
[17:56] <hazmat> default-instance-type should do it
[17:56]  * hazmat digs
[17:57] <SpamapS> environments:
[17:57] <SpamapS>   sample:
[17:57] <SpamapS>     type: ec2
[17:57] <hazmat> SpamapS, default-instance-type: m1.small after that should do it
[17:58] <hazmat> hmm.. oh against an existing environment
[17:58] <SpamapS> right
[17:58] <SpamapS> can I specify it to add-unit/deploy ?
[17:58] <SpamapS> that would be t3h awesome
[17:59] <SpamapS> also before I go and try it, would you expect an instance that reboots to re-join ensemble properly?
[17:59] <SpamapS> because I can always convert t1.micro's to m1.small's
[17:59] <hazmat> SpamapS, no re rejoin.. not until we do upstart integration
[17:59] <SpamapS> so on boot up it won't get run?
[18:00] <hazmat> SpamapS, yeah
[18:00] <SpamapS> doh
[18:00] <hazmat> SpamapS, the config setting change locally to environments.yaml is  propagated to the provisioning agent on deploy
[18:00] <SpamapS> so .. that would be something that needs to be overridable at runtime with a cmdline switch
[18:01] <hazmat> making a provider image identifier part of the machine state would allow for the cmd line switch, to be processed by the provisioning agent.
[18:02] <SpamapS> no offense, but all I see there is "eep opp glorp cmd line switch ok gru blorg" ;)
[18:03] <jimbaker> hazmat, in the watcher function in this paste (http://paste.ubuntu.com/617670/), is it possible for the connection to be lost between the test in line 13 and the watch in line 16?
[18:03] <SpamapS> hah, just got my AWS bill for May.. $67 .. a new record!
[18:04] <hazmat> SpamapS, i think i got to the 200s playing around with cloudformation.. that was painful
[18:04] <hazmat> SpamapS, fair enough re klingon speak
[18:04] <SpamapS> hazmat: just giving you a hard time because I am too lazy to read the specs. ;)
[18:05]  * niemeyer waves
[18:05] <niemeyer> kim0: We have plans for that
[18:06] <niemeyer> kim0: We discussed a bit the idea of having something like deploy --debug-hooks
[18:06] <SpamapS> You know.. t1.micro's are really unpredictable for performance at all. :-P
[18:06] <niemeyer> kim0: To fire a new unit with debugging on
[18:06] <niemeyer> SpamapS: Yeah, I think we should switch back to small by default
[18:06] <SpamapS> I have 6 in a mediawiki right now.. sometimes its *FAST* .. then a few of them just *stall*
[18:06] <niemeyer> SpamapS: Otherwise Ensemble will end up being blamed for this
[18:07] <hazmat> jimbaker, its concievable, but if your getting that, there's background activity when the test closes.. which we're trying to avoid.. typically the teardown closes a client, to kill watches before clearing out the tree
[18:07] <niemeyer> SpamapS: Yeah, that's exactly what they advertise them to be
[18:07] <SpamapS> niemeyer: agreed, especially since people can't take advantage of the reboot-into-something-bigger game of t1.micro
[18:07] <jimbaker> hazmat, this is in reference to https://code.launchpad.net/~jimbaker/ensemble/expose-watch-exposed-flag/+merge/63066, but the specific code is the watch_resolved function, which has the same guard
[18:07] <niemeyer> SpamapS: It can spike in performance, at the price of stalling completely
[18:07] <niemeyer> SpamapS: Cool, let's do this then
[18:07] <SpamapS> I'm going to re-run my tests with m1.small and compare.
[18:07] <SpamapS> They're, what, 2x the price?
[18:07] <niemeyer> SpamapS: Sweet, let us know
[18:08] <niemeyer> SpamapS: More
[18:08] <hazmat> jimbaker, yeah.. its possibly not relevant anymore post godot-redux
[18:08] <niemeyer> SpamapS: But it's worth it
[18:08] <SpamapS> I was thinking it would be cool if we can also add in spot pricing capabilities...
[18:08] <jimbaker> niemeyer, does that make sense to you?
[18:08] <niemeyer> jimbaker: What's that?
[18:08] <SpamapS> Since we can always add units.. spot priced units would be ideal for expanding beyond a certain level.. if they disappear.. oops, just add a full price unit.
[18:08] <hazmat> jimbaker, i added that in when doing looped tests of some of the watch apis
[18:08] <jimbaker> hazmat, correct, it's necessary to support such looped tests
[18:09] <hazmat> jimbaker, i guess the question is are you seeing a problem?
[18:09] <hazmat> and if so what is it
[18:09] <jimbaker> niemeyer, this in reference to your review of the expose-watch-exposed-flag branch, and asking why this guard was necessary
[18:09] <jimbaker> hazmat, i'm trying to investigate niemeyer'
[18:09] <niemeyer> jimbaker: and what's the conclusion?
[18:09] <jimbaker> s review point
[18:11] <jimbaker> hazmat says it is necessary, and that there should not be a scenario where the connection is in fact lost between the guard and the establishment of the watch
[18:11] <jimbaker> which was my concern
[18:12] <jimbaker> it would be nice if we could have the need for this guard tested outside of using -u loops
[18:12] <SpamapS> bcsaller: fyi, its something to do with the scale or make-up of the status.. if I do it with just the bootstrap node I don't get the dot error
[18:12] <jimbaker> maybe a separate branch for that, so we can do it for all the watches using this guard?
[18:14] <niemeyer> jimbaker, hazmat: I don't understand why this is necessary in this specific location, and not everywhere else in Ensemble
[18:14] <bcsaller> SpamapS: interesting. The test case for it uses a med. size multi-node topology so this is a little unexpected. I'll try to get to it later today
[18:15] <jimbaker> niemeyer, i understand the pragmatic reason for it. the tests otherwise fail. hazmat, anything else you would want to add?
[18:15] <niemeyer> jimbaker: Why do they fail?
[18:16] <jimbaker> niemeyer, for the same reason they always do - we are still doing something in the background when the tests are being torn down
[18:17] <jimbaker> niemeyer, so there is a probably a good solution in this case
[18:17] <jimbaker> write better tests :)
[18:18] <jimbaker> in thinking this through, what's confusing about the guard is that it is making an assertion about being connected which as you mention applies to any code hitting zk
[18:18] <niemeyer> jimbaker: Yes, please :)
[18:18] <jimbaker> niemeyer, do you want me to fix the other watches with this problem?
[18:19] <niemeyer> jimbaker: There shouldn't be background logic happening on tests in unexpected ways
[18:19] <niemeyer> jimbaker: Not in this branch
[18:19] <niemeyer> jimbaker: Just don't introduce more of it
[18:19] <jimbaker> niemeyer, ok
[18:20] <hazmat> jimbaker, if you remove the check, can you run the tests looped?
[18:20] <jimbaker> niemeyer, actually most of the work i spent on the corresponding branch (expose-provision-service-hierarchy) was cleaning up this problem. so certainly one that has a familiar quality
[18:21] <jimbaker> hazmat, no, they will always fail
[18:21] <jimbaker> hazmat, but the check should not be there at all, per what niemeyer has said
[18:21] <SpamapS> oh yeah, m1.small already just *feels* faster to navigate
[18:21] <jimbaker> since it is compensating for bad tests
[18:21] <niemeyer> Right
[18:21] <jimbaker> that don't properly clean up
[18:21] <hazmat> jimbaker, unless the watch is stopped there is always a chance for background activity on a watch
[18:22] <jimbaker> hazmat, what can we do to fix that then?
[18:22] <jimbaker> seems like a fundamental thing to get right
[18:23] <niemeyer> jimbaker: Don't allow a watch to stay alive after the test has finished, ever
[18:23] <hazmat> the state request protocol have lifecycle methods to control stopping them
[18:23] <hazmat> jimbaker, in the interim.. raising a stopwatcher from the callback is an alternative
[18:23] <niemeyer> hazmat: What about closing the connection?
[18:23] <jimbaker> hazmat, right, that's what i do to control such watches for the provision agent tests
[18:24] <jimbaker> niemeyer, that sounds like a good way to test this type of solution :)
[18:24] <niemeyer> jimbaker: We do this in several places already
[18:25] <jimbaker> niemeyer, sounds good, i will look for that code
[18:25] <niemeyer> jimbaker: and it's always worked for me in the places I had such logic
[18:26] <niemeyer> jimbaker: See tearDown of StateTestBase
[18:26] <jimbaker> hazmat, it seems to me that we are moving to supporting StopWatcher in all the watches. certainly the one that is to be fixed for now that's the case, in fact that's part of the changes in this branch
[18:26] <jimbaker> niemeyer, thanks
[18:26] <hazmat> niemeyer, that's part of the problem, connection close while the watch is firing in the background
[18:26] <niemeyer> hazmat: Well, that means a watch is firing as part of the test action itself
[18:27] <niemeyer> hazmat: Which falls back to the conversation we had before
[18:27] <niemeyer> hazmat: Currently we sleep in those cases, we need a way to sync up the zk connection
[18:28] <niemeyer> jimbaker: StopWatcher is unrelated, IMO
[18:28] <niemeyer> jimbaker: StopWatcher means the watch is being fired in the first place
[18:31] <_mup_> ensemble/debug-hook-fixes r245 committed by gustavo@niemeyer.net
[18:31] <_mup_> Send error output to /dev/null in cases we expect the
[18:31] <_mup_> command to fail.
[18:33] <niemeyer> Ok, I think I'm happy with this branch
[18:33] <niemeyer> Will push it for review
[18:37] <hallyn> jamespage: yay, we're in business.
[18:37] <SpamapS> You guys ready to submit to principia? ;)
[18:37] <hallyn> now my only problem is lp isn't letting me create lp:~serge-hallyn/principia/oneiric/jenkins-slave/trunk
[18:38] <hallyn> it let me create jenkins/trunk...
[18:38] <SpamapS> hallyn: you have to create a package called 'jenkins-slave' .. bug in LP
[18:38] <SpamapS> hallyn: why isn't your formula just 'jenkins' though?
[18:38] <hallyn> SpamapS: the one for jenkins is :)
[18:39] <hallyn> i used a separate one for slaves
[18:39] <SpamapS> I'm curious why
[18:39] <SpamapS> I'd think thats just a difference of relations
[18:39] <hallyn> uh
[18:39] <hallyn> well i install different packages
[18:39] <hallyn> at init
[18:39] <hallyn> i probably could just install all everywhere...
[18:39] <SpamapS> Right, or you could just install the packages you need at the time that the relationship is established.
[18:40] <hallyn> meh
[18:40] <SpamapS> I'm guessing a jenkins slave is way simpler than a jenkins master
[18:40] <hallyn> so, wehreas i now have 'jenkins-relation-joined' in both jenkins and jenkins-slave,
[18:40] <hallyn> would i call them master/slave?
[18:40] <hallyn> ok first step
[18:40] <SpamapS> thats what I did in the mysql formula
[18:40] <hallyn> how do i 'create the package'?
[18:41] <hallyn> ok.
[18:41] <SpamapS> upload a dummy package to a ppa anywhere on lp
[18:41] <hallyn> i'll try consolidating
[18:41] <hallyn> got it
[18:41] <SpamapS> the benefit of consolidating is that you have one place to gather all of the operational knowledge for jenkins
[18:41] <hallyn> yeah
[18:41] <kim0> niemeyer: relation-get in "upgrade-formula" seems to blow up spectacularly
[18:41] <hallyn> will do and get bck to you
[18:41] <SpamapS> the benefit of not consolidating is you have two simpler formulas instead of one possibly more complex formula
[18:41] <SpamapS> kim0: probably same problem as the blow up in install
[18:42] <niemeyer> kim0: I've reported this bug yesterday
[18:42]  * kim0 nods
[18:42] <SpamapS> hallyn: its been working great for mysql... I deploy a master-db, then slave-db .. then relate them
[18:42] <niemeyer> kim0: upgrade-formula is not part of a relation, so it doesn't make sense to call relation-get
[18:42] <hallyn> how do you deploy them?
[18:42] <niemeyer> kim0: relation-get shouldn't break that way, though
[18:42] <kim0> yeah exactly
[18:42] <SpamapS> lp:principia-tools/tests/wiki-slave.sh is an example
[18:42] <hallyn> i've not gotten around to using multiple instances of a formula, dunno how to name them :)
[18:43] <SpamapS> ensemble deploy mysql master-db  names the service master-db
[18:46] <hallyn> jamespage: so if a slave first does 'sudo apt-get install jenkins' that shouldn't be a big deal right?  do you think it's wroth doing apt-get remove jenkins before installing jenkins-slave when it gets related to a master?
[18:47] <hazmat> kim0, the relation cli api only works currently in relation hooks
[18:47] <hallyn> oh, why not
[18:47] <kim0> hazmat: yeah got that .. still a more graceful error would be nicer :)
[18:48] <hazmat> indeed
[18:53] <SpamapS> hallyn: is jenkins-slave way way simpler than jenkins?
[18:53] <_mup_> ensemble/debug-hook-fixes r246 committed by gustavo@niemeyer.net
[18:53] <_mup_> Self review:
[18:53] <_mup_> - Some additional comments.
[18:53] <_mup_> - Add new valid hooks on debug-hooks to tests, even though those tests
[18:53] <_mup_>   aren't really great. They will not break once we have more hooks.
[18:53] <SpamapS> hallyn: I mean, if you have to jump through hoops to morph it into something completely different, then I may say that its better to split them.
[18:56] <_mup_> ensemble/debug-hook-fixes r247 committed by gustavo@niemeyer.net
[18:56] <_mup_> Minor comment fix.
[19:03] <jamespage> hallyn: well you will end up with another running jenkins master node in that case
[19:09] <SpamapS> hrm.. wordpress's "<code>" tag kind of sucks in my theme. :-/
[19:09] <hallyn> jamespage: right so i'm just doing apt-get purge
[19:11] <_mup_> ensemble/micro-is-slugish r241 committed by gustavo@niemeyer.net
[19:11] <_mup_> Switch default instance type to t1.micro.  Does that work?
[19:11] <niemeyer> Erm
[19:11] <_mup_> ensemble/micro-is-slugish r241 committed by gustavo@niemeyer.net
[19:11] <_mup_> Switch default instance type to m1.small.  Does that work?
[19:14] <hallyn> SpamapS: gr.  well it shoudl be pretty simple, it just forces me to become more familiar with the terminology.  So, the consolidated version isn't working yet for me...  working on it
[19:14] <SpamapS> hallyn: what I mean is, if jenkins-slave is an entirely different piece of software than jenkins, I may have been wrong that they should be consolidated.
[19:15] <jamespage> SpamapS, hallyn
[19:15]  * hallyn listens up
[19:15] <jamespage> I was thinking that once we have this working well I might that a look at writing a Jenkins plugin to automagically add and remove slaves depending on demand
[19:16] <jamespage> using ensemble
[19:17] <SpamapS> NICE
[19:18] <niemeyer> Sweet!
[19:18] <kim0> niemeyer: btw the open-tunnel isn't really working for me
[19:18] <niemeyer> jamespage: ensemble add-unit jenkins FTW!
[19:18] <niemeyer> kim0: What happens?
[19:18] <kim0> niemeyer: I think it's just equally slow
[19:18] <niemeyer> kim0: When doing what?
[19:18] <kim0> status
[19:19] <kim0> niemeyer: status takes 5.4s 
[19:19] <niemeyer> kim0: status should definitely improve with the tunnel open
[19:20] <niemeyer> kim0: Let me try here
[19:20] <kim0> niemeyer: could u launch as enseble open-tunnel &
[19:20]  * niemeyer cranks another environment.. Amazon says Katching!
[19:20] <kim0> hehe
[19:21] <niemeyer> kim0: I'd recommned against it
[19:21] <niemeyer> kim0: Keep it open in the forefront
[19:21] <niemeyer> kim0: and put a warning in your wall saying "MY ENVIRONMENT IS EXPOSED"
[19:21] <kim0> the 2 times I tried it .. I bg'ed it
[19:21] <kim0> exposed ?!
[19:21] <kim0> isn't it only to my user?
[19:22] <niemeyer> kim0: You have a root tunnel to your environment's control machine
[19:22] <niemeyer> kim0: That's why we don't just do that magically for you
[19:22] <kim0> niemeyer: got it .. so no technical reason not to background, but a security one
[19:22] <niemeyer> kim0: It's neat and all, but be aware :)
[19:22] <kim0> hehe yeah :)
[19:22] <kim0> ok I'd love to have this working
[19:23] <niemeyer> kim0: It should be working.. trying right now
[19:24] <niemeyer> With tunnel:
[19:24] <niemeyer> bin/ensemble status  0.29s user 0.08s system 8% cpu 4.309 total
[19:24] <niemeyer> Without tunnel:
[19:24] <niemeyer> bin/ensemble status  0.34s user 0.05s system 5% cpu 7.033 total
[19:24] <niemeyer> kim0: Seems to work
[19:24] <niemeyer> kim0: If you want to be sure:
[19:24] <kim0> 0.3s! something must be wrong on my box (it's 5s)
[19:24] <niemeyer> kim0: 1) Open the tunnel
[19:25] <kim0> it's open
[19:25] <niemeyer> kim0: On another terminal, run this:
[19:25] <niemeyer> kim0: ensemble ssh 0
[19:25] <niemeyer> kim0: Then, close the tunnel with CTRL-C
[19:25] <niemeyer> kim0: What happened to your ssh?
[19:26] <niemeyer> kim0: You were looking at the wrong number.. it's 4.3s
[19:26] <kim0> niemeyer: it was terminated
[19:26] <niemeyer> kim0: Bingo
[19:26] <niemeyer> kim0: It was going through the tunnel
[19:27] <kim0> ah yeah .. You'd think the tunnel would make it even faster
[19:28] <niemeyer> kim0: That's the penalty of living at thousands of km from the DC
[19:28] <kim0> is it bandwidth limited
[19:29] <niemeyer> kim0: Latency
[19:31] <niemeyer> Okay!
[19:31] <niemeyer> m1.small works..
[19:31] <niemeyer> hazmat++
[19:34] <_mup_> Bug #792491 was filed: t1.micro is too sluggish <Ensemble:In Progress by niemeyer> < https://launchpad.net/bugs/792491 >
[19:35] <niemeyer> In review
[19:35] <niemeyer> kim0: I'll look at the problem of the default directory now
[19:36] <niemeyer> Actually.. standup..
[19:36] <niemeyer> Who's up for it?
[19:36] <niemeyer> hazmat, jimbaker, bcsaller: Yo?
[19:36] <hazmat> i'm game if need be.. almost done with session work
[19:37] <bcsaller> almost done addressing review
[19:37]  * hazmat parks in mumble
[19:38] <jimbaker> niemeyer, sounds good to me
[19:39] <niemeyer> jimbaker: We're all there
[19:39] <jimbaker> yeah, my laptop just needed to reboot... unity issues ;)
[19:39] <niemeyer> jimbaker: Heh, sure, blame unity :)
[19:39] <jimbaker> which features a need for daily reboots it seems, otherwise everything else is great
[19:40] <jimbaker> fortunately i know about alt-f1
[19:40] <jimbaker> so fewer reboots required
[19:40] <hallyn> SpamapS: lp:~serge-hallyn/principia/oneiric/jenkins works for me
[19:40] <hallyn> (jenkins/trunc, that is)
[19:40] <SpamapS> right
[19:41] <hallyn> still have some jenkins usage to learn to figure out how to use this to test kernel compiles
[19:41] <jimbaker> well it looks no sound for me
[19:41] <SpamapS> hallyn: for new formulas, I'm going to put together a "how to propose a new formula" document at some point. Right now I think you can just bug me.. eventually we'll need a "NEW" queue like thing.
[19:41] <hallyn> if it was all one bzr tree we could do merge requests...
[19:43] <hazmat> jimbaker, unity again
[19:44] <jimbaker> just one more reboot, now i have sound!
[19:54] <niemeyer> https://code.launchpad.net/~jimbaker/ensemble/expose-watch-exposed-flag/+merge/63066
[19:55] <SpamapS> http://fewbar.com/2011/06/so-what-is-ensemble-anyway/
[19:57] <hazmat> SpamapS, woot!
[19:59] <SpamapS> graph porn at the bottom. ;)
[19:59] <bcsaller> SpamapS: now I'm extra sorry status didn't draw properly for you
[20:02] <niemeyer> SpamapS: WOAH
[20:03] <SpamapS> bcsaller: I can always add it back in. ;)
[20:03] <niemeyer> SpamapS: Have you tweeted it yet?
[20:03] <SpamapS> niemeyer: my blog auto-tweets. :)
[20:03] <niemeyer> SpamapS: What your username there?
[20:03] <SpamapS> niemeyer: guess! ;) spamaps
[20:04] <niemeyer> SpamapS: Cool :)
[20:45] <koolhead17> SpamapS: is it your blogpage :D
[20:45]  * koolhead17 just did niemeyer RT :P
[20:47] <niemeyer> koolhead17: It is indeed
[20:47] <niemeyer> An awesome intro
[20:47]  * koolhead17 reading it
[20:53] <_mup_> Bug #792540 was filed: example mysql formula should publish details of precreated databases <Ensemble:New for kim0> < https://launchpad.net/bugs/792540 >
[20:55] <koolhead17> kim0: that website bug has been confirmed and assigned!! :D
[20:55] <kim0> koolhead17: Yeah it's important ! thanks :)
[20:56] <koolhead17> kim0: karma ++ :D
[20:56] <kim0> haha :) enjot
[20:56] <kim0> enjoy*
[20:57] <koolhead17> http://www.youtube.com/canonicalmatters  it needs to be populated :F
[20:57] <koolhead17> :D
[21:01] <kim0> Just fixed the mysql example formula to make it publish DB details of precreated formulas .. yaay
[21:01] <kim0> precreated DBs I mean .. yaay :)
[21:09] <robbiew> SpamapS: so when can we get the narrated screencast version?
[21:09] <robbiew> :P
[21:15] <SpamapS> kim0: how did you manage that, given that the password is encrypted?
[21:16] <kim0> SpamapS: caught it as it's being created and saved it in file like how the master password is?
[21:16] <SpamapS> kim0: ah, I went through great pains to avoid that in principia. ;)
[21:16] <SpamapS> kim0: but I'm not really sure why. ;)
[21:16] <kim0> hehe :)
[21:17] <kim0> I'm using those example formulas in tutorials .. so I value simplicity above all
[21:20] <SpamapS> The reality is you shouldn't ever have to re-use those users. You just have to keep track of two things. 1) does the db exist yet or not, and 2) has the relationship been completely severed or not.
[21:21] <SpamapS> as long as there is a relationship, the username/db doesn't have to change
[22:40] <_mup_> ensemble/expose-watch-exposed-flag r241 committed by jim.baker@canonical.com
[22:40] <_mup_> Removed unnecessary guard and separated out ports tests from ServiceStateManagerTest megatest
[22:47] <_mup_> ensemble/expose-watch-exposed-flag r242 committed by jim.baker@canonical.com
[22:47] <_mup_> PEP8
[22:49] <_mup_> ensemble/expose-provision-service-hierarchy r264 committed by jim.baker@canonical.com
[22:49] <_mup_> Merged upstread expose-watch-exposed-flag
[22:50] <kim0> SpamapS: I've written a drupal formula at https://code.launchpad.net/~kim0/+junk/drupal .. Mind importing to principia ?
[22:52] <SpamapS> kim0: reading now
[22:52] <kim0> cool
[22:52] <SpamapS> kim0: we had another guy submit one recently too.. ;)
[22:52] <kim0> it's pretty basic :)
[22:52] <kim0> oh np though :)
[22:54] <SpamapS> kim0: I love how all formulas start with at least 5 - 10 revisions. :-p
[22:54] <kim0> hahah :D
[22:54] <kim0> even as basic as this one
[22:54] <SpamapS> The other one had a good idea.. his was 201106011200
[22:54] <kim0> a ha .. yeah like DNS zone versions
[22:54] <SpamapS> Ok first off, descriptions shouldn't say what it "does", they should say what it "is".
[22:55] <kim0> It's a blant copy from the wordpress example .. so we probably should change both of em
[22:55] <SpamapS> Yeah
[22:56] <SpamapS> Been thinking about writing up a basic set of guidelines and sending it out for comment
[22:56] <SpamapS> drush?
[22:57] <kim0> drupal shell 
[22:57] <kim0> nice little tool that automates lots of things
[22:57] <SpamapS> kim0: right.. I'm not sure we're going to accept stuff in Principia that pulls things from archives other than Ubuntu...
[22:58] <kim0> it doesnt ?
[22:58] <kim0> drush is packaged
[22:58] <SpamapS> ensemble-log "Using drush to download latest Drupal"
[22:58] <SpamapS> 10	
[22:58] <SpamapS> cd /var/www && drush dl drupal --drupal-project-rename=ensemble
[22:58] <kim0> ah ..
[22:58] <kim0> hmm
[22:58] <SpamapS> The reason being, then we lose the security updates of the Ubuntu release.
[22:59] <SpamapS> Everything else looks fine for importing.
[22:59] <kim0> althogh I'd argue a deployed ensemble, won't upgrade itself yet :)
[22:59] <SpamapS> The drush stuff is *awesome* though.
[23:00] <kim0> It can auto-update core drupal 
[23:00] <kim0> and all modules/plugins/themes ..etc
[23:00] <SpamapS> kim0: one can at least ssh to it and upgrade, but yeah, this goes back to being able to enforce policy across the machines.
[23:00] <kim0> if ensemble would give me a hook to check/apply updates
[23:00] <kim0> it would probably be better than apt :)
[23:00] <SpamapS> we don't need a hook for that
[23:00] <SpamapS> install a cron job
[23:01] <SpamapS> But then you get into, why not just enable unattended upgrades
[23:02] <kim0> ok I'll probably tweak it later for apt .. 
[23:05] <SpamapS> We need to discuss this though
[23:05] <kim0> Yeah .. 
[23:06] <SpamapS> I don't feel adamantly opposed to having formulas that deploy software outside Ubuntu's archives in Principia.. but I do think we need to think about it.
[23:06] <kim0> agreed 
[23:06] <kim0> maybe start a thread
[23:07] <kim0> SpamapS: if I were to deploy a drupal cluster, I'd need a shared filesystem across all nodes ... what's your take on implementing this in ensemble ? an NFS formula ?
[23:07] <kim0> what about gluster on the same nodes
[23:07] <SpamapS> I want to do it with several options
[23:07] <SpamapS> gluster and NFS would be the simplest/safest
[23:07] <SpamapS> NFS would need to be failover/drbd or something like that.
[23:08] <SpamapS> gluster w/ a peer formula would be *pimp*
[23:08] <kim0> I suppose that's good :)
[23:08] <SpamapS> wordpress and mediawiki have the same needs
[23:08] <SpamapS> Tho.. I'd bet all 3 have S3 plugins
[23:08] <SpamapS> actually I *know* wordpress does because I use it
[23:09] <kim0> yeah, having one formula per instance sounds a bit limiting ? wish I could group more than one formula on a single instance
[23:09] <SpamapS> i totally agree
[23:09] <SpamapS> like as long as neither of them provide the same interface, it should be no problem
[23:09] <kim0> yeah
[23:10] <kim0> and while we're at it .. I think we'd need a documented "interface" for a formula
[23:10] <kim0> for example to write that drupal formula .. I had to read the mysql formula source, which doesn't sound scalable
[23:11] <kim0> basically documenting the wire protocol .. nothing more
[23:11] <SpamapS> Agreed, I think the providing formula should always document it. It would be great if ensemble even enforced/warned when something didn't follow the documented semantics.
[23:11]  * kim0 nods
[23:13] <SpamapS> http://pastebin.com/TqwWjgEB
[23:14] <kim0> will we need "gets" as well
[23:14] <SpamapS> http://pastebin.com/KaBHLnX9
[23:14] <kim0> and will we need "when" .. which hook .. does that make a difference
[23:14] <SpamapS> Yeah... s/expects/gets/
[23:15] <SpamapS> Maybe
[23:15] <kim0> good start though
[23:16] <kim0> It will need a description .. like memcached gets/sets "ip" which is totally different afaict
[23:18] <kim0> I was also thinking about the need to have "joined" when we have "changed" .. knowing that changed always fires after joined, and pretty much always has to detect whehter or not this is its first run!
[23:18] <SpamapS> hmm
[23:19] <SpamapS> I tend to find it easy.. if relation-get has values, configure things. If not, don't.
[23:19] <kim0> Yeah
[23:19] <SpamapS> then joined can just create data/etc. if need be
[23:20] <SpamapS> and departed/broken can clean up
[23:20] <SpamapS> though broken needs something to tell us which relation broke.
[23:21] <kim0> I feel like everything is still possible without joined
[23:21] <kim0> will think about it a bit more
[23:22] <SpamapS> well the idea is that joined *only* gets called when a new member arrives
[23:23] <kim0> changed, would still be called, so it'd need to do the right thing as well
[23:24] <kim0> any way .. it's past midnight for me .. nightie everyone
[23:25] <kim0> enjoy your weekend
[23:25] <SpamapS> kim0: will do, thanks for the formula work/ideas/everything :)
[23:26] <kim0> SpamapS: thanks man :)