[12:58] <niemeyer> Hello there!
[13:00] <TheMue> niemeyer: moin
[13:31] <niemeyer> mthaddon: ping
[13:32] <mthaddon> niemeyer: hi hi
[13:32] <niemeyer> mthaddon: Yo
[13:32] <niemeyer> mthaddon: How're things going in the store?
[13:32] <mthaddon> niemeyer: I posted an update to the RT with the things we still need to look at (mostly around deployments and mongo authentication)
[13:33] <niemeyer> mthaddon: I've seen it
[13:33] <niemeyer> mthaddon: re. auth, you can actually put auth data in the command line arg already
[13:33] <mthaddon> ah cool - how do we do that? and will that mean the auth info shows up in "ps"?
[13:37] <mthaddon> niemeyer: ^
[13:37] <niemeyer> mthaddon: Hmm, yeah, potentially
[13:38] <niemeyer> mthaddon: You can use a URL such as mongodb://foo:bar@address/juju
[13:38] <mthaddon> niemeyer: can we pull from a config file instead? otherwise it kind of defeats the point of having any auth info :)
[13:39] <niemeyer> mthaddon: Yeah, of course
[13:39] <mthaddon> great
[13:39] <niemeyer> mthaddon: Will have that ready to go in a moment.. have your read about protecting a db?
[13:40] <niemeyer> mthaddon: You can workaround it, btw.. even if it's boring.. but I'm happy to make that saner for you
[13:40] <mthaddon> niemeyer: I'm happy to work around it if there's a good way of doing that - what is that?
[13:47] <niemeyer> mthaddon: Just testing now to see if I'm not speaking crack
[13:48] <mthaddon> k, thx
[13:48] <niemeyer> mthaddon: Nevermind, I am crazy
[13:48]  * mthaddon not minding
[13:48] <niemeyer> mthaddon: Either way, I'd be unhappy with such a hack.. I'll have a more proper fix
[14:16] <niemeyer> mthaddon: Btw, meanwhile, have you read about the auth stuff on dbs?
[14:26] <mthaddon> niemeyer: the docs don't seem very in depth, but I have read http://www.mongodb.org/display/DOCS/Security+and+Authentication
[14:27] <mthaddon> why on earth you'd have an "auth = True/False" and a "noauth = True/False" option in the configs seems beyond me...
[14:30] <niemeyer> mthaddon: Cool, that should be enough
[14:30] <niemeyer> mthaddon: You mean to have both, or to have it at all?
[14:31] <mthaddon> niemeyer: having both - can only lead to confusion
[14:31] <niemeyer> mthaddon: Yeah, I'd guess it's something to do with the overriding of defaults
[14:31] <niemeyer> mthaddon: But, I've never used both, so have no idea really
[14:32] <TheMue> so, leaving today for my Go talk at the GTUG
[14:33] <niemeyer> TheMue: Ah, super, good luck there, and please let us know how it goes
[14:33] <TheMue> niemeyer: sure, and I'll add the presentation to slideshare later
[14:35] <niemeyer> TheMue: Sweet
[14:35] <niemeyer> robbiew: Is your wifi going bad as well?
[14:48] <hazmat> jimbaker, ping
[14:48] <jimbaker> hazmat, hi
[14:49] <hazmat> hi jimbaker just going through rel hook context, looks good, but one question i had was if there was testing around rel mutation during the execution
[14:49] <hazmat> ie. a new rel added post the invoker setup, or one removed
[14:49] <jimbaker> hazmat, there's testing of adding a relation. there should be one for removing a relation, as you mention
[14:50] <jimbaker> hazmat, i can readily add that
[14:50] <hazmat> jimbaker, can you point me to it?
[14:50] <hazmat> jimbaker, the add one that is.. i'm also wondering about membership consistent views on membership mutation
[14:50] <hazmat> like if one relation has a unit, and another should have it, but its been removed during the execution.
[14:51] <jimbaker> hazmat, see test_get_relation_hook_context
[14:51] <jimbaker> i didn't address membership
[14:54] <hazmat> jimbaker, yeah.. its tricky, we don't want to fetch all units of all rels for each hook exec, but it does make a hook's perspective on membership possibly inconsistent when working across multiple relations
[14:54] <jimbaker> hazmat, yes
[14:58] <hazmat> jimbaker, so effectively we do already know the memberships
[14:58] <hazmat> their in the respective schedulers
[15:03] <niemeyer> Oops.. no  Go reviewers..
[15:03] <jimbaker> hazmat, the scheduler does pass in the membership to the implied relation hook context
[15:04] <jimbaker> my proposal continues the current practice of caching it on first read, in this case as would be done with relation-list
[15:11] <niemeyer> mthaddon: Can you please check this out and include a LGTM in case it actually Looks Good To You? https://codereview.appspot.com/5967064
[15:11] <mthaddon> niemeyer: can you update the RT with what you want me to do? - currently otp
[15:12] <niemeyer> mthaddon: Cool, nevermind.. will just submit as I have to leave for lunch in a few minutes
[15:12] <hazmat> jimbaker, sure.. but we could have consistent membership if we could pass the other schedulers membership sets to their respective hook contexts.
[15:13] <hazmat> jimbaker, i'm fine with that being in another branch, but what do you think of the approach?
[15:20] <jimbaker> hazmat, there's still no guarantee that you have a consistent view of membership - only that you have the other schedulers cached membership
[15:21] <hazmat> jimbaker, the schedulers cached membership is point in time consistent with what the unit has been informed of to date
[15:23] <hazmat> its altered as various hooks are executed.. hmm.. although the execution representing the membership change may merely be queued, such that the membership change notification is pending but not actualized/known to the charm even though its represented in the cached set.
[15:26] <jimbaker> hazmat, right, scheduling is occurring differently than membership watches - there are effectively 2 queues here
[15:28] <hazmat> jimbaker, um.. not true per se.. scheduling is the target of the membership & change watchers, but that's separate from execution. the cache is consistent wrt to execution of hooks for a single context, but its altered prior to the execution.. that's a trivial to fix.. it can do the cache alteration after successful exec and pass in the modified set to the execution, and then it could be used as a membership set for other contexts.
[15:28] <hazmat> jimbaker, but yes there are two queues.. the scheduler queue, and the hook executor queue
[15:29] <niemeyer> mthaddon: Change submitted, config file support is ready, RT updated
[15:29] <niemeyer> and lunch time
[15:29] <niemeyer> biab
[15:29] <mthaddon> niemeyer: cool, thx
[16:23] <niemeyer> mthaddon: np, I'm back too
[16:23] <niemeyer> mthaddon: Let me know how it goes, please
[16:52] <hazmat> jimbaker, is there a reason why the relation-id-option has a merge target of the relation-hook-context?
[16:54] <hazmat> bcsaller, this reitveld diff looks borked.. like trunk hadn't been merged yet to the parent/prerequisite https://codereview.appspot.com/5845061/
[16:54] <jimbaker> hazmat, that's mysterious to me... i simply used lbox propose -req to specify that it required lp:~jimbaker/juju/relation-ids-command as prereq
[16:54] <jimbaker> does lbox work with multiple levels of prereqs?
[16:55] <jimbaker> that was my assumption, since we use that in lp
[16:55] <bcsaller> hazmat: yeah, it was merged before, but I'll look at it again, I noticed this this morning as well
[16:56] <hazmat> jimbaker, it justs a pre-req, and does the diff against that, but it does have a -target option that result in changing the merge target from its default, but the default may indeed be the branch's pull location
[16:56] <hazmat> not sure
[16:57] <jimbaker> bcsaller, have you been able to use lbox for stacked branches?
[16:58] <bcsaller> jimbaker: my branches got so tangled up its hard to know where the issue is :-/
[16:58] <bcsaller> jimbaker: so maybe... :)
[16:59] <jimbaker> bcsaller, understood
[17:02] <hazmat> jimbaker, are you using bzr-pipeline?
[17:02] <jimbaker> hazmat, i do not
[17:02] <hazmat> bcsaller, the status changes look very nice
[17:02] <bcsaller> hazmat: cool
[17:03] <hazmat> bcsaller, can you re propose it via lbox to clean up the diff?
[17:03] <bcsaller> I don't know if that will clean it up, but I can try
[17:03] <hazmat> bcsaller, assuming the parent/pre-requisite has parent merged, it should
[17:04] <hazmat> er.. has trunk merged
[18:13] <hazmat> off to an appt, bbiab
[20:02] <jimbaker> biab, my son fractured his wrist and needs a cast put on
[21:27] <niemeyer> Time to reboot..
[22:11] <niemeyer> Hmm.. things looking better in Unity now
[22:11] <niemeyer> I wonder if the network issues have been fixed too