=== deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck [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] 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] bcsaller, np.. sorry i've been hit or miss on internet this week, currently working out of a library [21:30] bcsaller, was there anything you wanted to discuss re standup? [21:30] ouch [21:30] bcsaller, mostly been using my android hotspot functionality for basic access [21:30] no, I pushed some small branches for review, but don't have final signoff on the sspec [21:31] still the work moves forward [21:31] 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] okay.. off to lunch.. ttyl [21:32] 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] bcsaller, isn't the plural of formula .. formulas ? [23:14] not important.. just reading through [23:14] what did I say? [23:15] formulas or formulae [23:27] formula [23:27] bcsaller, it just says formula [23:27] but it looks like its contextually trying to refer to a plural [23:48] bcsaller, so there's no typing information in config.yaml? [23:49] gustavo said that was still to be debated, he has some other ideas there but didn't tell me what [23:49] I think its a game we can't win as the values are more about semantics than type [23:52] we have two different audiences setting and consuming values, typing would allow for them both to interop on expectations w/ validation [23:52] else, someone sets a port to an empty string, where the formula expects an integer value. [23:53] or additional context information like description on a option, to allow better understanding of what it controls [23:56] 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] If everyone wants type validation though its fine with me, I just think its of less value [23:57] we don't really have a notion of required, and we don't know that name/password both need to be set [23:57] for the change to be good [23:58] a human readable desc. would help, but trying to cover those cases, I'm not sure [23:58] if we can fine a nice 80% rule though [23:58] sounds good, expanding from a list of names, to a list of dictionary allows typing, description, and sane defaults [23:59] rather than formulas trying to cope with missing values and embedding defaults inline. [23:59] well, its still defaults in the formula, config.yaml is part of it [23:59] looks good though, most of my review comments are on improving readability.. i'm going to switch locations and post