[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 === niemeyer_away is now known as niemeyer [16:02] niemeyer, glad to see the expose services spec has been approved. it was a good process [16:03] jimbaker: Indeed [16:03] jimbaker: Great spec [16:03] niemeyer, thanks! [16:08] Lunch, biab === niemeyer is now known as niemeyer_lunch === robbiew1 is now known as robbiew [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 === niemeyer_lunch is now known as niemeyer [16:50] 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] jimbaker, i'm having a last look over it now [16:52] hazmat, sounds good [16:56] 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] 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] 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] exposed hooks? [17:17] have you guys gone and changed everything? [17:18] SpamapS, not too much :) [17:19] 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] is this the implementation of the "virtual formula" idea? [17:20] SpamapS, no [17:20] * SpamapS has had *zero* time to look at anything you guys have done :-/ [17:21] 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] Sure it is. I think its very dangerous for ensemble to make decisions for formula writers. [17:23] 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] You saw my idea for machine config right? Just merge formulas with policy formulas. [17:24] SpamapS, yes, i saw that. in comparison, this is a very narrow change [17:24] I'm fairly certain that people will hand-merge formulas in their environment to achieve the same thing [17:25] 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] but other policy formulas might work out to be better [17:27] 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] 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] 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] niemeyer: yeah thats cool. I'm concerned that ensemble is going to try and figure out how to implement firewalls tho.. [17:38] Its like putting apparmor inside dpkg [17:38] SpamapS: Not implementing, but configuring. We can't avoid that. [17:40] 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] bcsaller, please take a look at https://code.launchpad.net/~jimbaker/ensemble/expose-services if you're now +1 on this branch [17:45] 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] natty lockup [19:14] kapil_, i got one of those so far === kapil_ is now known as hazmat [19:19] interesting.. http://melor.github.com/poni/ [19:43] niemeyer: right. I think Ensemble's job is to enable configuration. Not to do it. [19:44] SpamapS: That's exactly what we're doing. [19:45] I thought so.. but my fear was that it would be built in or something. [19:45] rather than just a default recommended formula that is easy to replace. [19:47] 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] niemeyer: I have no suggestions, and no time, so please pardon my interruption. :) [19:51] 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] SpamapS: It's fully documented in the specification which is http://j.mp/ensemble-docs [19:51] SpamapS: Your ideas and suggestions are always welcome, but we need more concrete feedback to be able to act on it [19:52] 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] s/Ubuntu/Ensemble/ ;) [19:52] SpamapS: Sweet [19:59] bcsaller, hazmat, jimbaker: Standup? [20:02] niemeyer, sounds good [20:02] one moment - on phone [20:05] ok, ready for standup [20:06] bcsaller, ping [20:07] spam can be so poetic [20:08] back [20:08] given its origins, how it could not - http://www.youtube.com/watch?v=g8huXkSaL7o ;) [20:08] street cleaning, had to move car [20:18] sup [20:19] http://sup.rubyforge.org/ [20:27] Continues to break for me.. :( [20:52] 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 === niemeyer is now known as niemeyer_bbl [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