[00:38] <_mup_> ensemble/expose-services r187 committed by jim.baker@canonical.com
[00:38] <_mup_> Initial draft of service unit setting as the means to describe what ports to be exposed
[00:56] <SpamapS> kapil_: interesting re the munin-node example...
[00:57] <SpamapS> kapil_: I have thought of things like this in the past... I think this is where we start stepping all over puppet and chef's toes. ;)
[00:59] <SpamapS> kapil_: I would call it a "machine formula" rather than a "service formula"
[00:59] <SpamapS> OR.. you just build this into formulas as a setting
[01:00] <SpamapS> ensemble deploy mediawiki --extra-package=munin-node
[01:00] <SpamapS> kapil_: would love to sit down and think through how best to do it.
[01:37] <_mup_> ensemble/expose-services r188 committed by jim.baker@canonical.com
[01:37] <_mup_> Additional edits to remove obsolete text and describe the exposed flag and how it is set, removed, and watched
[01:43] <kapil_> SpamapS, we were having a talk regarding earlier about making machines like units, to enable something unrelated (exposing ports/service outputs), but there's a bit of mismatch mapping them over.
[01:43] <kapil_> the machine formulas map pretty well to this sort of thing though
[01:43] <kapil_> this being monitoring
[01:43] <kapil_> or enabling machine level policies managed by ensemble
[01:43] <kapil_> be it landscape or what have you
[01:43] <kapil_> ie. you could deploy landscape and relate to it machine
[01:43] <kapil_> but say you don't want all your machines managed by landscape..
[01:43] <kapil_>  a machine agent isn't really  a service unit, so some of the existing useablility breaks down.. if we want to implement machine formulas for machine policy, they'll probably be spelled a little differently.
[01:43] <kapil_> SpamapS, yeah.. it is very much overlapping with puppet and chef.
[01:44] <_mup_> ensemble/expose-services r189 committed by jim.baker@canonical.com
[01:44] <_mup_> Clarification of when the exposed hook runs
[07:46] <_mup_> ensemble/config-pipeline r183 committed by bcsaller@gmail.com
[07:46] <_mup_> updates based on niemeyers review
[13:51] <niemeyer> Morning all!
[14:31] <niemeyer> Bandwidth is really bad to certain regions :-(
[15:19] <niemeyer> Can't access gmail.. :/
[15:33] <niemeyer> Ok, can't access Google either, but Launchpad works fine.. how's that for a change? ;_)
[15:48] <niemeyer> biab
[15:49] <niemeyer_> Phew.. ok, reestablishing the ADSL connection seems to have helped
[16:42] <hazmat> SpamapS, how you liking sup?
[16:43] <jimbaker> hazmat, were you able to try running the wp example against trunk on ec2?
[16:44] <hazmat> jimbaker, i wasn't, my plate is overfull atm
[16:44] <jimbaker> hazmat, np
[16:44] <hazmat> jimbaker, do you think you could dig into it?
[16:45] <jimbaker> hazmat, sure
[16:49] <jimbaker> hazmat, actually i think it's quite simple - r180 of trunk changed the semantics of relation-get, but the examples were not updated at the time
[16:49] <jimbaker> ok, that feels much better
[16:50] <hazmat> jimbaker, awesome, thanks for digging into it
[16:51] <SpamapS> hazmat: I am *loving* sup
[16:51] <hazmat> SpamapS, out of curiosity what's your setup look like? 
[16:51] <SpamapS> hazmat: I still have some 40,000 total emails that aren't moved out of my inbox.. but I drop that by 100 or so every day. ;)
[16:51] <hazmat> SpamapS, i've been trying to figure out if i should use procmail or imapfilter to pre label things
[16:52] <SpamapS> hazmat: I have offlineimap pulling from my personal and canonical email accounts.
[16:52] <SpamapS> hazmat: I have just 2 procmail rules to classify bugmail and srumail
[16:53] <hazmat> SpamapS, cool, how do you get procmail invoked on mail sync'd by offlineimap?
[16:53] <SpamapS> hazmat: no I'm doing that on the server
[16:53] <hazmat> ah
[16:53] <SpamapS> hazmat: specifically so that my iphone doesn't ever see bugmail or sru mail :)
[16:59] <SpamapS> hazmat: so about "policy formulas" .. or "machine formulas" .. I was thinking how they'd work in the model.. and wouldn't it be cool if the service unit sort of married the policy formula and the main service formula into one that had all the relations from both?
[17:00] <SpamapS> it would still have to run the install/start/stop for both..
[17:01] <SpamapS> but otherwise.. they'd work like one formula.    ensemble add-relation munin-master-service myblog:munin-node
[17:01] <SpamapS> hazmat: and for added fun... 
[17:01] <SpamapS> ensemble add-relation myblog:website myblog:munin-http-response-graph
[17:02] <SpamapS> hazmat: that would probably be fairly tricky for you guys to work into the agent, but from a user standpoint, would make the most sense
[17:03] <hazmat> SpamapS, that almost looks like some sort of formula inheritance.. i guess its more of a containment thing in this context
[17:03] <hazmat> interesting
[17:05] <_mup_> ensemble/trunk r183 committed by bcsaller@gmail.com
[17:05] <_mup_> Merge config-specification [r=niemeyer,kapil] [f=736321]
[17:05] <_mup_> Outlines the direction of future Service Configuration work. This document defines how services define options, how to modify those settings and how formula authors interact with such a system.
[17:06] <SpamapS> hazmat: I think this is going to come up rather quickly as people deploy ensemble
[17:06] <SpamapS> hazmat: they'll do it by manually merging two formulas together.
[17:12] <_mup_> ensemble/trunk r184 committed by bcsaller@gmail.com
[17:12] <_mup_> Merge rename-amp [r=niemeyer] [f=746688]
[17:12] <_mup_> Rename AMP commands used to communicate between hook utilities and the unit agent. These commands used generic names like `get` and `set` which limited clarity when the set of commands expanded to include more than just relation oriented commands. This simple change renames get to relation_get allowing for easy inclusion of things like config_get in a future branch.
[18:18] <_mup_> ensemble/trunk r185 committed by kapil.thangavelu@canonical.com
[18:18] <_mup_> merge optional-hooks [r=niemeyer]
[18:18] <_mup_> This change allows formulas to optionally implement any formula hooks instead
[18:18] <_mup_> of requiring all hooks to be implemented.
[18:19] <_mup_> ensemble/trunk-merge r181 committed by kapil.thangavelu@canonical.com
[18:19] <_mup_> merge trunk
[19:06] <hazmat> SpamapS, so the only real difference underlying the policy/machine formula is that they live outside of an lxc container, which is effectivley what we do now. That behavior could be
[19:06] <hazmat> preserved via some formula type distinction, it might have some additional functional distinction later, but for now it would just be a distinction to whether a formula lived outse of a container. 
[19:06] <hazmat> For service units liviing inside a container, when establishing a relation, the additional syntax could be used to apply a policy formula as a secondary/global relationlookup after the service unit formula relations
[19:06] <hazmat> are considered. 
[19:08] <niemeyer> hazmat: When you have a moment, would you mind to have a look at jimbaker's branch which is pending in the review queue?
[19:08] <niemeyer> hazmat: I had a look at it, but would appreciate a second look from you there
[19:11] <hazmat> niemeyer, sure
[19:11] <hazmat>  the issue i see atm with this is that the service's formula authors needs to avoid associating persistent state in service data denoting between the relationship between the two unit instances, unless we're also willing to for ensemble to introduce a unit 2 machine container or a unit 2 unit relations, which is rather tight coupling
[19:28] <hazmat> niemeyer, jimbaker, bcsaller standup?
[19:29] <niemeyer> hazmat: Sounds good
[19:31] <niemeyer> hazmat: I'm up
[19:32] <hazmat> bcsaller, skype?
[19:35] <jimbaker> sounds good, just made some hot chocolate here
[19:36] <jimbaker> uhoh, my natty laptop is unresponsive... need to reboot it
[19:39] <jimbaker> hazmat, are we having the standup?
[19:40] <hazmat> jimbaker, just waiting on ben to get a full house
[19:40] <jimbaker> i noticed no one liked my logical grouping of hooks being executed with respect to the event, although it might have helped if i had made an explicit comment
[19:41] <hazmat> jimbaker, hmm. true
[19:41] <hazmat> jimbaker, it is a logical grouping.. a comment would have made it more clear, and the grouping is removed latter in the branch stack isn't it?
[19:41] <hazmat> except for join/changed
[19:41] <jimbaker> for departed, yes, but joined has the multiplicity as you mentioned
[19:42] <hazmat> jimbaker, i'm fine with that.. but you should note the event/change -> hook mapping
[19:42] <jimbaker> when i was working through it, the grouping was important to understand what was going on
[19:42] <hazmat> as a comment
[19:42] <jimbaker> hazmat, agreed, that would have been helpful
[19:42] <jimbaker> so i will add that in assuming niemeyer is ok with it
[19:43] <niemeyer> jimbaker: Clearly it didn't serve its purpose.. :-)
[19:44] <hazmat> jimbaker, niemeyer you guys up for doing a 3 way standup, i'll give the summary to bcsaller  latter.
[19:44] <niemeyer> hazmat: Yeah, let's do it
[19:46] <bcsaller> sorry, just got back
[19:46] <hazmat> bcsaller, skype?
[19:47] <bcsaller> yeah
[19:57] <hazmat> niemeyer, any word on logging this channel?
[19:57] <niemeyer> ubuntulo1: meet hazmat
[19:58] <hazmat> niemeyer, aweseome
[19:58] <hazmat> and logs http://irclogs.ubuntu.com/2011/04/06/%23ubuntu-ensemble.txt
[21:47] <_mup_> ensemble/expose-services r190 committed by jim.baker@canonical.com
[21:47] <_mup_> Review edits
[23:08]  * niemeyer steps out for the day