[00:10] <_mup_> ensemble/expose-services r191 committed by jim.baker@canonical.com
[00:10] <_mup_> Further clarifications based on review points
[00:39] <_mup_> ensemble/expose-services r192 committed by jim.baker@canonical.com
[00:39] <_mup_> Added missing exposed key-value for ensemble status output
[00:44] <_mup_> ensemble/expose-services r193 committed by jim.baker@canonical.com
[00:44] <_mup_> Spell checked
[00:48] <_mup_> ensemble/expose-services r194 committed by jim.baker@canonical.com
[00:48] <_mup_> One last minor edit on what is output for ensemble status for showing a service is exposed
[16:02] <jimbaker> niemeyer, glad to see the expose services spec has been approved. it was a good process
[16:03] <niemeyer> jimbaker: Indeed
[16:03] <niemeyer> jimbaker: Great spec
[16:03] <jimbaker> niemeyer, thanks!
[16:08] <niemeyer> Lunch, biab
[16:30] <_mup_> ensemble/expose-services r195 committed by jim.baker@canonical.com
[16:30] <_mup_> Minor reworking of how ensemble status displays exposed services and their corresponding opened ports
[16:31] <_mup_> ensemble/expose-services r196 committed by jim.baker@canonical.com
[16:31] <_mup_> Merged trunk
[16:50] <jimbaker> hazmat, bcsaller - based on other conversations, i assume you're ok with merging my expose-services branch into trunk. if so, could you please explicitly approve the branch at https://code.launchpad.net/~jimbaker/ensemble/expose-services ? thanks
[16:51] <hazmat> jimbaker, i'm having a last look over it now
[16:52] <jimbaker> hazmat, sounds good
[16:56] <hazmat> jimbaker, +1.. one minor thing.. the ``exposed`` and ``unexposed`` hooks section doesn't have its __ covering the entire statement for valid rst output
[16:58] <jimbaker>  hazmat, actually rst is fine with that (otherwise it would have been obvious earlier), but it's definitely sloppy. thanks for pointing that out
[16:59] <hazmat> jimbaker, cool, i've had it barf on me in those cases before, the spec contents looks good though
[16:59] <_mup_> ensemble/expose-services r197 committed by jim.baker@canonical.com
[16:59] <_mup_> Fixed section heading for exposed/unexposed hooks
[17:17] <SpamapS> exposed hooks?
[17:17] <SpamapS> have you guys gone and changed everything?
[17:18] <jimbaker> SpamapS, not too much :)
[17:19] <jimbaker> SpamapS, an exposed hook runs upon a service being exposed, so it's just a way for a formula to respond (if at all, now that hooks are optional)
[17:20] <SpamapS> is this the implementation of the "virtual formula" idea?
[17:20] <jimbaker> SpamapS, no
[17:20]  * SpamapS has had *zero* time to look at anything you guys have done :-/
[17:21] <jimbaker> SpamapS, it's just supporting the ability for a service to expose it ports publicly. it's not ok for our machine instances to have an open firewall policy
[17:23] <SpamapS> Sure it is. I think its very dangerous for ensemble to make decisions for formula writers.
[17:23] <jimbaker> at some point, it was leaning to have more support for formulas being able to do machine configuration, but we decided this was too big of a change - at least as it would have meant for this particular case
[17:24] <SpamapS> You saw my idea for machine config right? Just merge formulas with policy formulas.
[17:24] <jimbaker> SpamapS, yes, i saw that. in comparison, this is a very narrow change
[17:24] <SpamapS> I'm fairly certain that people will hand-merge formulas in their environment to achieve the same thing
[17:25] <jimbaker> the problem with the exposer service idea is that it would have allowed it to be in a relation with any service. this seemed to be too loose
[17:26] <jimbaker> but other policy formulas might work out to be better
[17:27] <SpamapS> firewall was one of the first things I thought of, and the idea of a standard relation thats always available of 'exposed' is quite cool to me
[17:30] <jimbaker> i agree with the general attractiveness. however, in general, it can be easier to reason about and implement systems without that quality. or potentially even use them. and i think that's the case here
[17:32] <niemeyer> SpamapS: The expose feature is pretty simple for the moment, purposefully.. it's just a way for the formula author to let Ensemble know of which port it would like to open for the external world to use
[17:38] <SpamapS> niemeyer: yeah thats cool. I'm concerned that ensemble is going to try and figure out how to implement firewalls tho.. 
[17:38] <SpamapS> Its like putting apparmor inside dpkg
[17:38] <niemeyer> SpamapS: Not implementing, but configuring.  We can't avoid that.
[17:40] <niemeyer> SpamapS: dpkg isn't great at configuring things so they can run out of the box.  That's one of the reasons why Ensemble exists at all.
[17:45] <jimbaker> bcsaller, please take a look at https://code.launchpad.net/~jimbaker/ensemble/expose-services if you're now +1 on this branch
[17:45] <bcsaller> ok
[18:06] <_mup_> ensemble/trunk r186 committed by jim.baker@canonical.com
[18:06] <_mup_> merge expose-services [r=niemeyer,bcsaller,hazmat][f=736267]
[18:06] <_mup_>   
[18:06] <_mup_> Adds a specification and user guide on exposing services publicly.
[18:06] <_mup_> Introduces new ensemble commands ( ``ensemble expose``, ``ensemble
[18:06] <_mup_> unexpose``), hook commands (``open-port``, ``close-port``), hooks
[18:06] <_mup_> (``exposed``, ``unexposed``), and changes to ``ensemble status``,
[18:06] <_mup_> along with the supporting infrastructure for firewall configuration
[18:06] <_mup_> and management within ZK.
[19:14] <kapil_> natty lockup
[19:14] <jimbaker> kapil_, i got one of those so far
[19:19] <hazmat> interesting.. http://melor.github.com/poni/
[19:43] <SpamapS> niemeyer: right. I think Ensemble's job is to enable configuration. Not to do it.
[19:44] <niemeyer> SpamapS: That's exactly what we're doing.
[19:45] <SpamapS> I thought so.. but my fear was that it would be built in or something.
[19:45] <SpamapS> rather than just a default recommended formula that is easy to replace.
[19:47] <niemeyer> SpamapS: We're solving a real problem in a simple way so that we can move forward.  Any suggestions on how to do this in a different way with similar effort will be welcome.
[19:50] <SpamapS> niemeyer: I have no suggestions, and no time, so please pardon my interruption. :)
[19:51] <niemeyer> SpamapS: No problem.. I don't want to discourage you, but we've debated several approaches, faced problems in many of them, and opted for the current one with some ground.
[19:51] <niemeyer> SpamapS: It's fully documented in the specification which is http://j.mp/ensemble-docs 
[19:51] <niemeyer> SpamapS: Your ideas and suggestions are always welcome, but we need more concrete feedback to be able to act on it
[19:52] <SpamapS> Yeah, I have some major platform stuff to tend to the next 10 days.. but I hope to get some time to play with Ubuntu around 4/18
[19:52] <SpamapS> s/Ubuntu/Ensemble/ ;)
[19:52] <niemeyer> SpamapS: Sweet
[19:59] <niemeyer> bcsaller, hazmat, jimbaker: Standup?
[20:02] <hazmat> niemeyer, sounds good
[20:02] <jimbaker> one moment - on phone
[20:05] <jimbaker> ok, ready for standup
[20:06] <hazmat> bcsaller, ping
[20:07] <hazmat> spam can be so poetic
[20:08] <bcsaller> back
[20:08] <jimbaker> given its origins, how it could not - http://www.youtube.com/watch?v=g8huXkSaL7o ;)
[20:08] <bcsaller> street cleaning, had to move car
[20:18] <jimbaker> sup
[20:19] <jimbaker> http://sup.rubyforge.org/
[20:27] <niemeyer> Continues to break for me.. :(
[20:52] <bcsaller> lunch
[22:33] <_mup_> ensemble/unit-state-with-formula r191 committed by kapil.thangavelu@canonical.com
[22:33] <_mup_> update parse_formula_id usage by state domain objects with new exception.
[22:50]  * niemeyer steps out for some exercising
[23:56] <_mup_> ensemble/trunk r187 committed by kapil.thangavelu@canonical.com
[23:56] <_mup_> Merge unit-state-with-formula [r=niemeyer][f=748312]
[23:56] <_mup_> Unit states now track their formula id, which can be get/set on a unit state. Also introduce a utility
[23:56] <_mup_> function for parsing/validating formula ids.
[23:58] <_mup_> ensemble/trunk-merge r182 committed by kapil.thangavelu@canonical.com
[23:58] <_mup_> merge trunk