[20:57] <_mup_> ensemble/formula-upgrades-spec r183 committed by kapil.thangavelu@canonical.com
[20:57] <_mup_> address review comments, add note regarding unit state carrying references to the current deployed formula.
[21:04] <_mup_> ensemble/formula-upgrades-spec r184 committed by kapil.thangavelu@canonical.com
[21:04] <_mup_> address bcsaller's review comments, additional formula spec link and remove extraneous relation-list reference
[21:04] <bcsaller> thanks
[21:20] <_mup_> ensemble/optional-hooks r183 committed by kapil.thangavelu@canonical.com
[21:20] <_mup_> allow for hooks to be specified optionally.
[21:30] <hazmat> bcsaller, np.. sorry i've been hit or miss on internet this week, currently working out of a library
[21:30] <hazmat> bcsaller, was there anything you wanted to discuss re standup?
[21:30] <bcsaller> ouch
[21:30] <hazmat> bcsaller, mostly been using my android hotspot functionality for basic access
[21:30] <bcsaller> no, I pushed some small branches for review, but don't have final signoff on the sspec
[21:31] <bcsaller> still the work moves forward
[21:31] <hazmat> bcsaller, cool, just finished looking over jimbaker's spec, i'll try and get to yours latter today.. i'm feeling a bit behind on the formula upgrade stuff, but hopefully a productive afternoon awaits :-).. 
[21:32] <hazmat> okay.. off to lunch.. ttyl
[21:32] <bcsaller> enjoy
[22:38] <_mup_> ensemble/config-get r184 committed by bcsaller@gmail.com
[22:38] <_mup_> Implement config_get for use in hooks
[22:38] <_mup_> Test that the communication between the client and server side
[22:38] <_mup_>  of the protocol is marshalling data as expected.
[23:13] <hazmat> bcsaller, isn't the plural of formula ..  formulas ?
[23:14] <hazmat> not important.. just reading through
[23:14] <bcsaller> what did I say?
[23:15] <bcsaller> formulas or formulae
[23:27] <hazmat> formula
[23:27] <hazmat> bcsaller, it just says formula
[23:27] <hazmat> but it looks like its contextually trying to refer to a plural
[23:48] <hazmat> bcsaller, so there's no typing information in config.yaml?
[23:49] <bcsaller> gustavo said that was still to be debated, he has some other ideas there but didn't tell me what
[23:49] <bcsaller> I think its a game we can't win as the values are more about semantics than type
[23:52] <hazmat> we have two different audiences setting and consuming values, typing would allow for them both to interop on expectations w/ validation
[23:52] <hazmat> else, someone sets a port to an empty string, where the formula expects an integer value.
[23:53] <hazmat> or additional context information like description on a option, to allow better understanding of what it controls
[23:56] <bcsaller> I'm not opposed to more human readable data, I think thats going to be needed. I just don't think there is a ton we can do if someone sets an apache.conf snippet they want injected or something. Saying "string" isn't all that helpful. 
[23:57] <bcsaller> If everyone wants type validation though its fine with me, I just think its of less value
[23:57] <bcsaller> we don't really have a notion of required, and we don't know that name/password both need to be set
[23:57] <bcsaller> for the change to be good
[23:58] <bcsaller> a human readable desc. would help, but trying to cover those cases, I'm not sure
[23:58] <bcsaller> if we can fine a nice 80% rule though
[23:58] <hazmat> sounds good,  expanding from a list of names, to a list of dictionary allows typing, description, and sane defaults
[23:59] <hazmat> rather than formulas trying to cope with missing values and embedding defaults inline.
[23:59] <bcsaller> well, its still defaults in the formula, config.yaml is part of it
[23:59] <hazmat> looks good though, most of my review comments are on improving readability.. i'm going to switch locations and post