[01:50] <hazmat> SpamapS, i've got releases out on pypi for it (needs to be updated).. but else its legit
[08:10] <_mup_> ensemble/config-set r241 committed by<EMAIL_ADDRESS>[08:10] <_mup_> last review changes pending merge
[08:11] <_mup_> ensemble/config-set r242 committed by<EMAIL_ADDRESS>[08:11] <_mup_> merge trunk
[08:14] <_mup_> ensemble/trunk r248 committed by<EMAIL_ADDRESS>[08:14] <_mup_> Merge config-set [r=niemeyer] [f=778685]
[08:14] <_mup_> Provide an `ensemble set` command.
[08:14] <_mup_> Allow formula to contain an options specification as a YAML file
[08:14] <_mup_> Validate user input relative to options configuration
[08:14] <_mup_> Extend formula state to include config options
[08:20] <_mup_> ensemble/config-example-changes r232 committed by<EMAIL_ADDRESS>[08:20] <_mup_> forward merge (trunk)
[09:06] <kim0> Morning everyone
[12:27] <kim0> Ensemble is written in python, uses twisted, txAWS and zookeeper
[12:28] <kim0> did I miss any core technology ensemble uses ?
[14:12] <hazmat> kim0, that's the run of it.. we also use yaml for config
[14:12] <hazmat> kim0, txaws/ec2 are part of a pluggable machine provider architecture
[14:12] <hazmat> though till we support additional providers.. its a debateable if thats claimable
[14:13] <kim0> hazmat: cool thanks
[14:26]  * niemeyer waves
[16:13] <_mup_> ensemble/bootstrap-shutdown-environment r249 committed by<EMAIL_ADDRESS>[16:13] <_mup_> shutdown operates and on only one environment, and prompts for confirmation.
[16:28] <_mup_> ensemble/trunk r249 committed by<EMAIL_ADDRESS>[16:28] <_mup_> merge update-install-docs [r=niemeyer][f=788950]
[16:28] <_mup_> Updated install docs referencing the PPA as the preferred installation method.
[16:29] <kim0> hazmat: shouldn't 792540 be fix released ? my branch was merged
[16:31] <hazmat> kim0, oh.. wasn't sure.. the review looked it was approved, it wasn't clear that it was merged.. if its merge, feel free to update the status
[16:31] <hazmat> ^like
[16:31] <kim0> um
[16:31] <kim0> I might be the one imagining things
[16:31] <hazmat> kim0, hmm.. actually i might be.. odd
[16:31] <kim0> hazmat: Merged into lp:ensemble at revision 244
[16:32] <kim0> that means it was really merged right ? :)
[16:32] <hazmat> kim0, on the merge proposal it notes that its merged, on the bug report it just says its approved
[16:32] <hazmat> odd indeed
[16:32] <hazmat> oh.. that's just me.. being odd its correct
[16:32] <kim0> okie dokie
[16:32] <hazmat> kim0, updated to fixed released
[16:32] <kim0> cool
[16:41] <_mup_> ensemble/expose-provision-service-hierarchy r277 committed by<EMAIL_ADDRESS>[16:41] <_mup_> Removed unnecessary workaround for agent restart scenario
[16:46] <hazmat> lp seems rather slow today
[16:49] <_mup_> ensemble/expose-provision-service-hierarchy r278 committed by<EMAIL_ADDRESS>[16:49] <_mup_> PEP8
[16:55] <_mup_> ensemble/expose-provision-service-hierarchy r279 committed by<EMAIL_ADDRESS>[16:55] <_mup_> Observer cleanup
[16:58] <hazmat> lunch bbiab
[17:04] <_mup_> ensemble/expose-provision-service-hierarchy r280 committed by<EMAIL_ADDRESS>[17:04] <_mup_> Relaxed assertion on teardown cleanup (need to make watches more deterministic...)
[17:07] <niemeyer> hazmat: Initial review of sec-spec delivered.. nice stuff there
[17:07]  * niemeyer => lunch too
[17:19] <SpamapS> hazmat: sweet!
[17:19] <SpamapS> hazmat: if you are going to be releating on pypi then I can add a watch file .. which would be nice.
[17:19] <SpamapS> releasing even
[17:20]  * SpamapS waits patiently for the caffeine to kick in
[17:21] <_mup_> ensemble/expose-watch-exposed-flag r244 committed by<EMAIL_ADDRESS>[17:21] <_mup_> Doc string for watch_exposed_flag, removed obsolete version of function
[17:22] <_mup_> ensemble/expose-provision-service-hierarchy r281 committed by<EMAIL_ADDRESS>[17:22] <_mup_> Merged upstream expose-watch-exposed-flag
[18:09] <hazmat> SpamapS, there's an old release on pypi atm, after i finish up the session event handling work, i'll push an updated release there
[18:09] <hazmat> SpamapS, there was some talk a few months back about sending the whole project upstream to zk contrib
[18:10] <hazmat> i've got a little wary of that in the interim.. its just rather nice to be able to fix things as needed, than push to the upstream bug tracker and wait for a committer to respond on it
[18:10] <SpamapS> hazmat: that would be cool, since thats where python-zookeeper lives too right?
[18:11] <hazmat> SpamapS, it does indeed
[18:11] <SpamapS> I think until its been stable and unchanged for some time.. you're right in keeping it
[18:11] <SpamapS> yesterday's license fix is an example of the kind of thing that makes me want you to keep it forever. ;)
[18:11] <SpamapS> thanks again btw. :)
[18:11] <hazmat> :-) np
[18:14] <_mup_> ensemble/expose-hook-commands r245 committed by<EMAIL_ADDRESS>[18:14] <_mup_> Added missing assertion on whether port is an integer in hook commands
[18:16] <koolhead17> hello all
[18:19] <_mup_> ensemble/expose-hook-commands r246 committed by<EMAIL_ADDRESS>[18:19] <_mup_> Merged trunk and resolved conflicts
[18:29] <SpamapS> hazmat: FYI, I'm taking the man pages bug .. as its part of what I'm working on today (packaging ensemble for Ubuntu/Debian)
[18:34] <jimbaker> so what's up with the test failures in trunk - are there any dependency updates i should be aware of, or is that what's covered in the debug-hook-fixes branch?
[18:36] <jimbaker> i will hold my expose-hook-commands branch for the moment...
[18:45] <hazmat> SpamapS, cool
[18:45] <hazmat> jimbaker, what failures on trunk?
[18:45] <jimbaker> hazmat, one moment for a paste
[18:46] <hazmat> hmmm.. those are odd, they weren't there yesterday
[18:46] <jimbaker> http://paste.ubuntu.com/622740/
[18:48] <jimbaker> hazmat, i just wonder if this is related to what bcsaller was talking about in standup
[18:48] <hazmat> bcsaller, afaics those errors where introduced by the config-set merge.. before that rev i can do full trunk test runs without error
[18:48] <hazmat> now i get about 21 errors
[18:49] <hazmat> jimbaker, yeah.. probably.. i hadn't realized the problem was so widespread though
[18:49] <bcsaller> hazmat: I cannot, trunk did that for me before the merge
[18:49] <bcsaller> run in isolation different sets of those test will pass
[18:49] <hazmat> bcsaller, ugh
[18:50] <bcsaller> thats what I was talking about
[18:50] <bcsaller> there is bleeding in some of the setup/teardown
[18:50] <hazmat> bcsaller, i updated to before the config-set merge, and was able to run all the tests on trunk... this much breakage on full test runs is a problem
[18:50] <hazmat> bcsaller, yeah... perhaps some environment / global stomping
[18:51] <hazmat> bcsaller, it looks like a good number of the failures are because the logging config is changed, and expected outputs dont match anymore
[18:52] <bcsaller> hazmat: hmm, I thought even some of those passed in isolation, have to check that again
[18:52] <jimbaker> at this point to prevent bleeding, i'm always running tests w/ -u
[18:53] <jimbaker> not perfect, but catches some bad assumptions about teardown
[18:53] <hazmat> so this needs some better resolution and practice than merging a branch which breaks a bunch of tests
[18:53]  * hazmat pokes at the diff
[18:54] <bcsaller> hazmat: again, I was seeing this in trunk as well
[18:55] <hazmat> bcsaller, ok, but we need to escalate it then.. i think i asked what sort of failures you where seeing on the call yesterday
[18:56] <hazmat> bcsaller, the diff looks totally innocous
[18:57] <hazmat> jimbaker, if you update to before config-set ( bzr up -r 247) and run trunk tests, do you see failures?
[19:01] <hazmat> ugh.. i really need to be doing reviews as well
[19:03] <jimbaker> hazmat, i will check that too
[19:05] <hazmat> okay found a few review items, and the problem
[19:06]  * hazmat does a full test run to confirm
[19:07] <hazmat> bcsaller, when you say you had the same problems on trunk... you mean you had the same failures on full test runs.. are you sure it wasn't that you tried to merge, did a test run, reverted the merge, and did another test run
[19:07] <hazmat> bcsaller, trial has the unfortunate habbit of not ignoring/removing stale bytecode
[19:07] <jimbaker> hazmat, r247 works just fine
[19:08] <hazmat> jimbaker, thanks for confirming.. i've got the fixes for trunk
[19:08] <jimbaker> i'm going to run it with -u now just to see how that works
[19:08] <jimbaker> actually running it now like that
[19:08] <jimbaker> hazmat, sure, once you have them i will certainly review
[19:08] <hazmat> jimbaker, i get occasionally a failure about subprocess when looping tests on trunk in one test i forgot which
[19:08] <hazmat> bcsaller, jimbaker, niemeyer standup?
[19:09] <jimbaker> hazmat, on the second run of -u for r247, i got ensemble.agents.tests.test_unit.UnitAgentResolvedTest.test_resolved_stopped
[19:09] <jimbaker> (failure in that)
[19:09] <bcsaller> when I hit problem after a merge from trunk in my branch I  ran it from trunk proper. When I saw issues there I was confident it wasn't in my code
[19:09] <niemeyer> hazmat: Yeah
[19:09] <hazmat> bcsaller, well that's the thing.. you have to clean out all the bytecode on trunk after reverting the merge
[19:10] <jimbaker> hazmat, sounds good about standup
[19:10] <hazmat> bcsaller, else you'll get stale bytecode... we have multiple confirmations now that b4 the merge this didn't exist
[19:10] <bcsaller> hazmat: I didn't revert a merge, I merged to branch, saw issues I wasn't having before and then ran it on trunk (w/o the merge)
[19:10] <hazmat> bcsaller, ah
[19:10] <hazmat> wierd
[19:10] <bcsaller> yeah
[19:11] <bcsaller> and its order dependent like I was saying, sometimes running the module alone doesn't produce an issue
[19:33] <jimbaker> eventually i do get an error on looping ensemble.hooks.tests.test_invoker, which looks like the log question we just talked about in standup
[19:43] <jimbaker> so this is the relevant paste: http://paste.ubuntu.com/622776/
[19:44] <SpamapS> oo.. learning about Go.. I like the defer statement
[19:55] <niemeyer> SpamapS: +1
[19:55] <jimbaker> however, i did confirm that the save/reset logging can work successfully w/ -u (in looking specifically at test_invoker.PortCommandsTest)
[19:57] <jimbaker> doesn't change the need to make this fix, it's still tech debt
[19:57] <jimbaker> SpamapS, definitely agreed about go
[20:03] <niemeyer> jimbaker: Not just the fix, but it'd be good to have in the ML an explanation about why it worked like that, and a suggested way for everyone to implement equivalent logic the proper way
[20:06] <jimbaker> niemeyer, sounds good
[20:21] <hazmat> jimbaker, the question i had is why is it needed at all.. is there something internal to the app code that manipulates logging channels on the fly?
[20:22] <jimbaker> hazmat, indeed, i will investigate that
[20:35] <_mup_> Bug #795233 was filed: Investigate use of save_logging, reset_logging and remove them from tests <Ensemble:New> < https://launchpad.net/bugs/795233 >
[20:37] <jimbaker> biab, also my home internet connection is now down after last night's thunderstorm, need to look into it
[20:47] <hazmat> niemeyer, bcsaller can i get a +1 on this fix for the trunk tests... i leaked some pep8 cleanups and the fix to use a cli util function into it https://pastebin.canonical.com/48373/
[20:48] <hazmat> still pretty small though
[20:53] <niemeyer> hazmat: Looks good
[20:53] <niemeyer> hazmat: +1
[20:54] <hazmat> niemeyer, thanks
[21:00] <_mup_> ensemble/trunk r250 committed by<EMAIL_ADDRESS>[21:00] <_mup_> [trivial] fix for unit test failures due to spurious reset logging invocation [r=niemeyer]
[21:12] <_mup_> ensemble/set-transitions r232 committed by<EMAIL_ADDRESS>[21:12] <_mup_> adding service to missing hookcontext init and various pep8 cleanups
[21:19] <niemeyer> bcsaller, hazmat, jimbaker: Btw, now that we have the 2 reviews rule, the workflow is a little unclear. It seems like the _second_ reviewer should be careful to move the branch to "Work in progress" or "Approved"
[21:19] <niemeyer> I'm still a little wary of the additional delay the process will impose, but am keen on trying it out too
[21:39] <_mup_> txzookeeper/session-event-handling r43 committed by<EMAIL_ADDRESS>[21:39] <_mup_> pull in the managed zk abstraction from ensemble
[21:40]  * kirkland high fives niemeyer
[21:42] <niemeyer> kirkland!
[21:42] <niemeyer> kirkland: Welcome!
[21:51] <niemeyer> hazmat: I've reserved a review re. the watch conversation for you
[21:51] <niemeyer> hazmat: On jim's branch, that is
[21:58] <_mup_> ensemble/expose-hook-commands r247 committed by<EMAIL_ADDRESS>[21:58] <_mup_> Merged trunk
[22:04] <_mup_> ensemble/set-transitions r233 committed by<EMAIL_ADDRESS>[22:04] <_mup_> merge trunk
[22:08] <jimbaker> hazmat, just to make certain i got the new process - expose-hook-commands is ready for release with one review; this along with silence-deprecation-warnings are the last branches that only require one review, from niemeyer
[22:45] <niemeyer> jimbaker: That sounds good, unless hazmat would like to have a look at it
[22:49] <jimbaker> niemeyer, sounds good. i need to take off now, hopefully internet service is resumed at home
[23:37] <SpamapS> hey guys I don't know if I agree that the debug-log should show all relation-sets ..
[23:37] <SpamapS> re bug #766317
[23:37] <_mup_> Bug #766317: debug-log should show relation settings changes <Ensemble:New for jimbaker> < https://launchpad.net/bugs/766317 >
[23:37] <SpamapS> That should be entirely optional to the formula author.
[23:38] <SpamapS> I'd concede showing which values were changed, but not the values themselves. At some point, you'll want to contain those information leaks to the members of the relation and zk/bootstrap.. debug-log is free for anybody.
[23:39] <hazmat> hmm
[23:39] <hazmat> SpamapS, its a question of debug utility vs. white noise and security?
[23:40] <hazmat> SpamapS, from a security perspective .. its not  a free for all
[23:40] <hazmat> SpamapS, any admin using the ensemble cli.. atm is considered a root.
[23:40] <hazmat> hmm
[23:40] <SpamapS> debug-hooks should remain unrestricted... but debug-log actually sticks it in a log file on disk on the sender..
[23:40] <SpamapS> Yeah *that* may also be a bad idea.
[23:40] <hazmat> niemeyer, i totally skipped multiple ensemble users and stack delegation in the security doc
[23:40] <SpamapS> think about LOSA's ... they're not root but they can enact change.
[23:41] <hazmat> SpamapS, yeah.
[23:41] <SpamapS> hazmat: I think its totally fine to say that for now.. and add it to the "TODO" list. :)
[23:41] <SpamapS> hazmat: but putting all that info in the log is my only concern
[23:41] <hazmat> SpamapS, if your interested i put together a security overview.. and some of ensemble's next steps on security
[23:41]  * hazmat digs up a link
[23:41] <SpamapS> This may be a bit of sysadmin dogma seeping through, so I think a good logical analysis is in order, not an outright rejection of the idea.
[23:42] <SpamapS> Yes very interested
[23:42] <SpamapS> I imagine we'll get lots of questions at bofs and such
[23:42] <hazmat> SpamapS, at the bottom of this https://code.launchpad.net/~hazmat/ensemble/security-specification/+merge/63921
[23:42] <hazmat> its pretty high level
[23:42] <SpamapS> bcsaller: I forget, are you talking at devops days or doing a velocity bof?
[23:42] <SpamapS> high level is all we need for answering questions
[23:43] <bcsaller> SpamapS: I am talking at Structure, I sent in a proposal at devop days but they didn't get back to me
[23:43] <hazmat> its more vulnerability assessment that adaptation to multi-user or org workflows
[23:43] <hazmat> s/that/than
[23:43] <SpamapS> bcsaller: ah ok
[23:43] <SpamapS> bcsaller: when is structure?
[23:43] <hazmat> my plumbers talk bit the dust as well
[23:44]  * hazmat wanders off into the night
[23:44] <bcsaller> 22nd/23rd
[23:52] <niemeyer> hazmat: That's fine.. we're not considering the multi-user scenario at this point
[23:52] <niemeyer> hazmat: I mean.. there's no security separation between different users
[23:53] <niemeyer> hazmat: So the implications for a single user and for multiple users are the same
[23:55] <jimbaker> hazmat, are ok with my releasing expose-hook-commands, or do you want to review it too