| === TheMue_ is now known as TheMue | ||
| === bigjools-afk is now known as bigjools | ||
| === asavu_ is now known as asavu | ||
| niemeyer | Hello there! | 12:58 |
|---|---|---|
| TheMue | niemeyer: moin | 13:00 |
| niemeyer | mthaddon: ping | 13:31 |
| 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:32 |
| 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:33 |
| mthaddon | niemeyer: ^ | 13:37 |
| niemeyer | mthaddon: Hmm, yeah, potentially | 13:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| niemeyer | mthaddon: Just testing now to see if I'm not speaking crack | 13:47 |
| 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 | 13:48 |
| niemeyer | mthaddon: Btw, meanwhile, have you read about the auth stuff on dbs? | 14:16 |
| mthaddon | niemeyer: the docs don't seem very in depth, but I have read http://www.mongodb.org/display/DOCS/Security+and+Authentication | 14:26 |
| mthaddon | why on earth you'd have an "auth = True/False" and a "noauth = True/False" option in the configs seems beyond me... | 14:27 |
| niemeyer | mthaddon: Cool, that should be enough | 14:30 |
| niemeyer | mthaddon: You mean to have both, or to have it at all? | 14:30 |
| 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:31 |
| TheMue | so, leaving today for my Go talk at the GTUG | 14:32 |
| 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:33 |
| niemeyer | TheMue: Sweet | 14:35 |
| niemeyer | robbiew: Is your wifi going bad as well? | 14:35 |
| hazmat | jimbaker, ping | 14:48 |
| jimbaker | hazmat, hi | 14:48 |
| 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:49 |
| 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:50 |
| jimbaker | hazmat, see test_get_relation_hook_context | 14:51 |
| jimbaker | i didn't address membership | 14:51 |
| 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:54 |
| hazmat | jimbaker, so effectively we do already know the memberships | 14:58 |
| hazmat | their in the respective schedulers | 14:58 |
| niemeyer | Oops.. no Go reviewers.. | 15:03 |
| jimbaker | hazmat, the scheduler does pass in the membership to the implied relation hook context | 15:03 |
| jimbaker | my proposal continues the current practice of caching it on first read, in this case as would be done with relation-list | 15:04 |
| 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:11 |
| 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:12 |
| hazmat | jimbaker, i'm fine with that being in another branch, but what do you think of the approach? | 15:13 |
| 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:20 |
| hazmat | jimbaker, the schedulers cached membership is point in time consistent with what the unit has been informed of to date | 15:21 |
| 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:23 |
| jimbaker | hazmat, right, scheduling is occurring differently than membership watches - there are effectively 2 queues here | 15:26 |
| 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:28 |
| 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 | 15:29 |
| niemeyer | mthaddon: np, I'm back too | 16:23 |
| niemeyer | mthaddon: Let me know how it goes, please | 16:23 |
| hazmat | jimbaker, is there a reason why the relation-id-option has a merge target of the relation-hook-context? | 16:52 |
| 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:54 |
| 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:55 |
| 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:56 |
| jimbaker | bcsaller, have you been able to use lbox for stacked branches? | 16:57 |
| bcsaller | jimbaker: my branches got so tangled up its hard to know where the issue is :-/ | 16:58 |
| bcsaller | jimbaker: so maybe... :) | 16:58 |
| jimbaker | bcsaller, understood | 16:59 |
| 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:02 |
| 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:03 |
| hazmat | er.. has trunk merged | 17:04 |
| hazmat | off to an appt, bbiab | 18:13 |
| jimbaker | biab, my son fractured his wrist and needs a cast put on | 20:02 |
| niemeyer | Time to reboot.. | 21:27 |
| niemeyer | Hmm.. things looking better in Unity now | 22:11 |
| niemeyer | I wonder if the network issues have been fixed too | 22:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!