/srv/irclogs.ubuntu.com/2014/11/11/#juju-dev.txt

ericsnowdavecheney: would you mind taking another look at http://reviews.vapour.ws/r/346/?00:09
davecheneywallyworld_: yeah, i can log a bug00:21
davecheneythere isn't much we can do about it00:21
wallyworld_yeah :-(00:21
wallyworld_except fix our test fixture maybe00:22
davecheneythe problem is there is no signal that says "the test suite is over, and there are no more test suites"00:22
davecheneythe last bit is missing00:22
=== kadams54-away is now known as kadams54
menn0wallyworld_, thumper: here's the other part of the upgrade steps work. http://reviews.vapour.ws/r/399/00:54
thumperack00:54
wallyworld_ok00:55
=== kadams54 is now known as kadams54-away
davecheneywallyworld_: https://bugs.launchpad.net/juju-core/+bug/139135301:04
mupBug #1391353: state: testing suite leaks ~35 mb (one mongodb database) per test run <juju-core:New> <https://launchpad.net/bugs/1391353>01:04
wallyworld_ta01:05
davecheneywallyworld_: i can think of two solutions, one that isn't possible with 1.401:10
davecheneyhow severe do you think this is ?01:10
davecheneythe other solution is a fair bit of work01:10
wallyworld_hmmm, well it fails out landing runs every so often01:10
davecheneynah, i think that is differnt01:11
* wallyworld_ has to but foo figher tickets NOW, can't talk for a bit01:11
davecheney35mb is peanuts compared to the 600 gb or something we get on /mnt on a c3 xlarge01:11
wallyworld_buy01:11
=== menn0 is now known as menn0-afk
waiganiyikes, big thunderstorm here, killed the power01:44
davecheneysooooo close01:53
davecheneyone failing test in state01:53
davecheneyand i can repropose my branch01:53
* thumper is crossing his fingers for 100Mb symmetric fibre UFB02:09
=== whit_ is now known as Guest44905
ericsnowthumper: thanks for that feedback02:14
thumpernp02:15
ericsnowthumper: even though davecheney has been made the point to me several times (thanks for your patience, Dave), it finally clicked for me today right before your review showed up :)02:15
ericsnowthumper: I'll be back online a bit later if you want to follow up02:15
thumperkk02:15
=== blackboxsw is now known as blackboxsw_away
=== menn0-afk is now known as menn0
menn0thumper: I still can't get fibre here in central christchurch02:48
menn0thumper: parts of chch have it, but not our area yet02:49
menn0wallyworld_: cheers for the review02:50
wallyworld_np02:50
=== kadams54-away is now known as kadams54
=== urulama__ is now known as urulama
ericsnowthumper: about backups CLI04:29
ericsnowthumper: is it worth finding an alternative to "juju backups ..."?04:30
=== kadams54 is now known as kadams54-away
dimiternmorning all07:21
fwereadedimitern, o/07:28
dimiternfwereade, heyhey07:29
dimiternfwereade, do we have a precedent for extending the meaning of an environment setting? I'm working on bug 1367863 and I'm thinking of changing "use-floating-ip" from boolean to string with "always|never|state-server" values07:32
mupBug #1367863: openstack: allow only bootstrap node to get floating-ip <hp-cloud> <landscape> <openstack-provider> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1367863>07:32
dimiternfwereade, or would you add a new setting instead?07:33
fwereadedimitern, hum, let me think07:45
fwereadedimitern, I *think* our upgrades are such that we could do that sanely now -- although we'd need to be prepared for the bools and able to convert them07:46
dimiternfwereade, yeah, so parsing needs to be a bit smarter07:47
fwereadedimitern, but would you double-check with menn0? I'm pretty sure everything'll go into upgrading mode before the changes start, and won't react until they have themselves upgraded07:47
dimiternfwereade, sure07:48
dimiternfwereade, upgrades do not change envs.yaml though.. how about when you try to upgrade an existing openstack environment using "use-floating-ip": true? After the upgrade it will effectively be the same as "use-floating-ip": "always", and if we change it to something else - then what?07:49
dimiternfwereade, it feels like this setting should be immutable once you bootstrap07:50
fwereadedimitern, well, envs.yaml becomes irrelevant once there's an env up07:50
fwereadedimitern, well *really* we should be assigning and unassigning them based on that setting and on services being exposed and unexposed07:51
fwereadedimitern, I don't suppose openstack does the floating-ip-on-expose thing yet though?07:51
dimiternfwereade, eventually yes, but for now I think it's safer not to allow changing the setting after bootstrap07:52
dimiternfwereade, yeah, it doesn't do it now07:52
fwereadedimitern, ok it mainly depends on the context of who needs it07:53
dimiternfwereade, so how about "always|never|state-server|auto" - the last meaning both "state-server" and add FIP on expose, remove it on unexpose?07:54
fwereadedimitern, that seems likely sanest, especially considering the reference to bug 1287662 in there07:54
mupBug #1287662: Add floating IP support <addressability> <canonical-is> <cts-cloud-review> <openstack-provider> <juju-core:Triaged by niedbalski> <https://launchpad.net/bugs/1287662>07:54
dimiternfwereade, it's a bit more work, but I think it's useful07:54
fwereadedimitern, I *am* raising a slight eyebrow at this being on the top of the list, given that the original bug is given a somewhat wooly "ehh this might be useful to some people" characterisation07:55
fwereadedimitern, and, hmm it looks like niedbalski just picked up that bug07:56
fwereadeniedbalski, ping07:56
dimiternfwereade, that's true, the auto-assignment is nice, but not a priority07:57
dimiternfwereade, and we better do it sanely for all providers than piecemeal like this07:58
fwereadedimitern, well, I think there's some potentially serious collision between what you're doing and niedbalski is, to begin with07:59
fwereadedimitern, but regardless, why is the state-server-only bit a priority?07:59
dimiternfwereade, the bug is triaged as high for 1.2108:00
fwereadedimitern, ISTM that it's really not -- while the manual floating ip assignment is a straight-up bad idea compared to assign-on-expose08:00
dimiternfwereade, and assign-on-expose *does* include the case for adding FIP for the state server, surely08:01
fwereadedimitern, and I'm  just looking at "Just to be clear, I think the current behavior is great, this would be just another option that some orgs may want." in the bug08:01
dimiternfwereade, for canonistack or similar OS clouds with limited FIP pools is very important, as it's barely usable otherwise (I can bootstrap, but can't deploy another node on lcy01 due to FIPs shortage and lcy02 is 200% slower for me)08:03
dimiternfwereade, and it's actually very easy to implement the assign-FIP-only-for-JobManageState08:04
fwereadedimitern, yeah, but that's a pretty arbitrary hack, *especially* given what niedbalski seems to be going off and doing08:04
dimiternfwereade, ok, I'll put it on hold until I have a chat with niedbalski then08:05
fwereadedimitern, cool, thanks -- tbh I feel like those two really come down to "do floating ips like we should have in the beginning"08:05
dimiternfwereade, :) well said sir08:06
fwereadedimitern, so we should default to giving state servers floating ips, but not give them to anything else until they're running a unit of an exposed service08:06
fwereadedimitern, please push back hard on the "juju add-floating-ip" thing08:07
fwereadedimitern, because that's either going to take serious work in the model or get a bunch of NOT LGTMs from me08:07
fwereadedimitern, and that won't make anybody happy08:07
dimiternfwereade, of course, I never considered that sane08:07
fwereadedimitern, <308:08
dimiternfwereade, it's a really ugly hack, and we did discuss having a better way to express this in the model, eventually08:08
fwereadedimitern, I *think* that expose is the right way to express it -- and I *think* that it's essentially consistent with the expose-as-relation plans too08:09
fwereadedimitern, so I'd really prefer to keep it under that umbrella until we've got really clear use cases that can't be solved that way08:09
dimiternfwereade, sure, we'll get there sooner or later08:10
=== alexlist` is now known as alexlist
fwereadedimitern, do you have a few minutes to review http://reviews.vapour.ws/r/403/ ?08:35
dimiternfwereade, sure, looking08:35
mattywmorning all08:46
dimiternmattyw, morning08:49
voidspacemorning all08:49
mattywdimitern, voidspace morning08:49
dimiternfwereade, reviewed; a few suggestions, but nothing blocking08:49
dimiternvoidspace, morning08:49
voidspacedimitern: saw the reviews from you and axw08:50
voidspacedimitern: I will look at the maas code and see if we need to call release on each one08:50
dimiternvoidspace, great, thanks08:51
voidspacedimitern: we could also ask *why* they won't release a node in disk erasing state08:54
voidspacedimitern: although the original bug was about a node that was commissioning08:54
voidspacedimitern: so we would still have to handle that08:54
dimiternvoidspace, well, strictly speaking until the disk is erased it still contains data relevant to the user that allocated it08:55
voidspacedimitern: but release could return as a no-op like it does when you call release on a node that is Ready08:55
voidspacedimitern: because it will return to the Ready state "soon"08:56
voidspacedimitern: I don't see what the benefit / purpose of the error 409 is08:56
voidspacedimitern: effectively the state is "releasing"08:56
dimiternvoidspace, is it?08:56
voidspacedimitern: isn't it?08:56
voidspace:-)08:56
dimiternvoidspace, so it's no longer Allocated?08:56
voidspacedimitern: it is "scheduled for release"08:57
dimiternvoidspace, right08:57
dimiternvoidspace, ISTM juju needs to grow the knowledge for all those states wrt StartInstance, StopInstance and AcquireInstance (as a special case of the former)08:58
dimiternvoidspace, but it doesn't have to happen all in once08:59
voidspacedimitern: we don't look at the status when we call StopInstances08:59
dimiternvoidspace, we don't because we don't really care - the only place we care about status is in the instance updater calling Instances() periodically09:00
voidspaceright, so why would we grow knowledge about those states if we don't care09:00
voidspacewe just care about success or fail09:01
voidspaceunless secretly we do care ;-)09:01
dimiternvoidspace, but yesterday as I was fixing that openstack issue, I would've wanted a way to trigger an update to the cached instance state, if I know something relevant happened (e.g. agent just got down)09:01
TheMuemorning09:02
voidspaceTheMue: morning09:02
dimiternmorning TheMue09:02
dimiternvoidspace, we only care if it helps juju handle better such corner cases, like "what does 409 mean in this context"09:03
voidspaceright09:03
voidspacedimitern: so we call StopInstances with multiple ids09:04
voidspacedimitern: which passes those ids (after converting to maas ids) through to MAASObject.CallPost("release", ids)09:04
voidspacedimitern: the MaaS code takes a *single* id09:04
voidspacedimitern: I can't yet see how the call is converted into multiple calls to release09:05
* TheMue things sometimes only time and a bit of sleep help. if I'm right I found why my vMAAS networking isn't working.09:05
dimiternvoidspace, what if we continue calling it with multiple ids, unless we get 409, then we retry by calling it for each id09:05
voidspacedimitern: do you know the mechanism09:05
voidspacedimitern: sure, I understand the suggestion09:05
dimiternvoidspace, what, what?09:05
dimitern:) let me see the maas source09:05
voidspacedimitern: src/maasserver/api/nodes.py09:05
voidspacedimitern: NodeHandler.release09:06
voidspacesomething turns a single api call into multiple calls to the nodehandler methods09:07
voidspaceit's not the operation decorator09:07
dimiternhmm.. still looking09:07
voidspaceurls_api.py RestrictedResource maybe09:07
dimiternvoidspace, btw which maas version are you testing on?09:09
voidspacedimitern: 1.709:09
voidspacedimitern: found it09:10
voidspacedimitern: there's a release method that handleds multiple nodes09:10
voidspacedimitern: it does them all separately09:10
dimiternvoidspace, and returns the first error?09:10
voidspacedimitern: so one failing will cause an error to be raised, but the others will be done09:11
voidspacedimitern: well, it concatenates messages09:11
voidspaceif any(failed): raise NodeStateViolation()09:11
voidspaceNodeStateViolation is error 40909:11
dimiternvoidspace, hmm.. so if we parse the response, can we tell which ones failed?09:12
voidspacedimitern: we could if we cared09:12
dimiternvoidspace, we should care if all the rest are unchanged09:12
voidspacedimitern: the rest have been released09:13
dimiternvoidspace, sweet!09:13
voidspacedimitern: error 409 means "Juju doesn't need to care about those nodes any more"09:13
voidspaceand the rest are done09:13
dimiternvoidspace, so we don't care then, but it deserves a comment about it09:13
voidspaceok, will do09:13
dimiternvoidspace, cheers09:13
dimiternfwereade, re bug 1301996 - I have a lingering feeling this is caused by service settings reference counting we implemented post 1.1609:15
mupBug #1301996: config-get error inside config-changed: "settings not found" <config-get> <cts-cloud-review> <landscape> <juju-core:Triaged by fwereade> <https://launchpad.net/bugs/1301996>09:15
fwereadedimitern, I think service settings refcounting has been around longer than that09:16
fwereadedimitern, I think I tried to track it down and couldn't09:16
fwereadedimitern, if you can that would *absolutely* be a good use of time though09:16
fwereadedimitern, and, yeah, it's a complex area, I won't swear to it being bug-free09:17
dimiternfwereade, when did we cache the settings in the context initially? at relation-joined?09:17
dimiternfwereade, hmm.. or maybe it was in EnterScope09:17
fwereadedimitern, config settings don't get cached except within a single hook execution09:18
fwereadedimitern, oo I just had a thought09:18
fwereadedimitern, order of execution in refcount ops interacting badly with ReadConfigSettings?09:18
dimiternfwereade, could be, but that would be hard to reproduce09:19
fwereadedimitern, new settings doc needs to exist before unit charm-url field changes; old settings doc needs to exist until after it changes; and we need to be prepared for a refresh/retry in ReadConfigSettings anyway09:20
fwereadedimitern, I bet we're missing one of those things09:20
fwereadedimitern, most likely the last one, I *think* I remember considering the first two when I wrote it09:20
dimiternfwereade, I'll have a deeper look09:20
fwereadedimitern, but I have seen arbitrary changes to order-of-operations landing too09:21
fwereadedimitern, so they're worth a look as well09:21
fwereadedimitern, tyvm09:21
dimiternfwereade, so it seems service.changeCharmOps shouldn't decref the old settings until service's charm url have changed09:29
voidspacedimitern: any chance of a ship it on the updated diff http://reviews.vapour.ws/r/397/09:29
voidspacedimitern: when you have a minute09:29
voidspaceand I'll get coffee09:29
dimiternvoidspace, looking09:30
dimiternfwereade, hmm.. but it does add the decref ops at the very end09:30
axwvoidspace: thanks for verifying the 409 thing.09:30
voidspaceaxw: no prob, thanks for the review09:30
fwereadedimitern, the unit is the tricky one re refcounting09:31
fwereadedimitern, the unit gets the settings according to its current charm url09:31
fwereadedimitern, not the service's09:31
dimiternvoidspace, ship it! :)09:31
dimiternfwereade, ok, I'll have a look there as well09:31
voidspacedimitern: thanks09:34
dimiternfwereade, just looking at the code I can see 3 potential issues: in changeCharmOps - 1) if the new settings do not exist yet, we'll generate an Insert op both with createSettingsOp and settingsIncRefOps(..., canCreate=true); 2) in SetCharm: the TODO comment from waigani is correct - an assert will trigger the code calling isAliveWithSession passing the service name as key to the settings collection, which will surely return an error09:45
dimitern; 3) in unit.SetCharmURL we're doing an incref(new settings) op, but not asserting the old settings hasn't changed09:45
fwereadedimitern, I don't see why 3 is a problem (*except* when we're creating the new settings)09:47
fwereadedimitern, (2) at least should be easy to repro with a TxnHook test09:47
fwereadedimitern, for (1) I can't remember if we have export_tests for actual settings refcounts but I think we do so that should be reproable as a unit test too09:48
dimiternfwereade, in unit.SetCharmURL we're never creating the settings, I suppose because we expect service.SetCharm to have done it09:48
fwereadedimitern, ahh, there could be some way to miss that, couldn't there09:49
dimiternfwereade, but what if the service charm url changes again during unit.SetCharmURL ?09:49
fwereadedimitern, would depend on a very annoying and quick sequence of service charm changes09:49
fwereadedimitern, I *think* that should never matter09:49
dimiternfwereade, right09:49
fwereadeonce a unit has set its charm url, it's got a ref to the settings, so the service changing charm url shouldn't be an issue, the refcount shouldn't hit 009:50
dimiternfwereade, so fixing these 3 issues and writing proper tests should fix the bug.. but I need to find a way to reproduce it first09:50
fwereadedimitern, well, if you can come up with a precise sequence of unit tests that will repro it -- which you should be able to with txn-hooks, I think -- that's good enough for me09:51
TheMuef**k09:51
TheMuesorry09:51
fwereadedimitern, trying to repro it in a running system will be insanely timing-dependent, I think09:51
dimiternfwereade, if the service changes the url again that will decref the old settings, and since a unit is still upgrading to the old url it will incref the old settings and they'll stay there forever... hmm or perhaps not, because next time the unit upgrades it will decref them09:51
fwereadedimitern, that's the idea, yeah09:52
dimiternfwereade, well, you can always add sleeps to trigger it :) I'll dig in some more09:53
dimiternjam1, jam3, standup?10:00
voidspacedimitern: TheMue: I just got dumped out10:05
voidspacedimitern: TheMue: I think I have to authenticate again10:05
dimiternvoidspace, ha, sorry10:05
voidspacejam1: ping10:08
voidspacejam1: standup?10:08
wallyworld_fwereade: you free now?11:00
fwereadewallyworld_, sure11:01
wallyworld_coolio, meet you in hangout11:01
fwereadewallyworld_, ah ffs, waiting for plus.google.com11:25
wallyworld_fwereade: connection sucks, but we had sorta finished anyway11:25
wallyworld_the url stuff looked ok at first go, so long as all existing tests are kept11:26
wallyworld_the existing test reflect what we want/need to do11:26
rogpeppefwereade: i know there was talk of allowing a charm to provide feedback to the client (eg. to indicate that something is wrong without necessarily entering a hook error state). has anything like that been implemented yet?12:15
=== liam_ is now known as Guest26825
voidspacedimitern: you're ocr today :-)12:53
voidspacedimitern: http://reviews.vapour.ws/r/404/12:53
voidspacemy PR is 404...12:53
dimiternvoidspace, sure, will look shortly12:54
voidspacedimitern: np12:55
voidspacedimitern: I'll be going on lunch in a bit, no hurry12:55
dimiternvoidspace, sorry I got distracted; you've got a review14:28
voidspacedimitern: thanks14:32
voidspacectrl-w in wrong window...14:32
=== robbiew is now known as robbiew-afk
=== robbiew-afk is now known as robbiew
mfoorddimitern: ping16:38
mfoorddimitern: the new maasEnviron.ListNetworks16:38
mfoorddimitern: other than the return type, how will it be different from maasEnviron.getInstanceNetworks ?16:39
mfoordand the fact that it takes an instance id rather than an instance.Instance16:40
=== kadams54 is now known as kadams54-away
=== LinStatSDR_ is now known as LinStatSDR
=== kadams54-away is now known as kadams54
dimiternmfoord, sorry, was afk; getInstanceNetworks is close to what ListNetworks needs, but there's some CIDR parsing/validation logic in maasEnviron.setupNetworks which I'd like to happen when ListNetworks processes the result of getInstanceNetworks18:28
mfoordg'night all19:09
hazmatsome strange relation behavior.. JUJU_REMOTE_UNIT is not in relation-list19:28
hazmathmm19:30
thumperfwereade: hey there19:52
thumperfwereade: we should set up regular calls again19:52
=== urulam___ is now known as urulama___
=== kadams54 is now known as kadams54-away
davecheneymenn0: thanks for offering to review that mega branch20:11
davecheneyi'll address the copywrite issues and push it again now20:11
=== kadams54-away is now known as kadams54
menn0davecheney: ok, let me know when it's there20:13
davecheneymenn0: done20:14
menn0davecheney: looking20:14
menn0davecheney: i don't see it on RB. it this a pre-RB branch?20:15
davecheneymenn0: nope20:16
davecheneyrb has shat itself20:16
davecheneysee email from wallyworld_20:16
davecheneywaigani_:20:16
menn0davecheney: ok. i haven't seen that yet.20:16
davecheneyit is possible that this branch was what caused the corronary20:16
thumperheh20:17
menn0davecheney: i don't have that email20:18
menn0davecheney: but i'll review on GH20:18
davecheneyJesse Meek20:19
davecheney6:28 AM (50 minutes ago)20:19
davecheneyReply to all20:19
davecheneyto juju-dev20:19
davecheneyThe latest three reviews on GitHub (#1103,#1102,#1101) I cannot see in Review Board. Do we have a loose wire?20:19
menn0davecheney: right, but you said wallyworld_  :)20:19
davecheneyyes, i corrected that on the next line20:20
davecheneysorry for the confusion20:20
menn0sorry, I thought you were intending to write something to jesse :)20:20
menn0anyway... reviewing!20:20
menn0davecheney: GH/my browser paused for much longer than normal when opening the diff :)20:21
waigani_davecheney: I don't think it was your branch, there are two PRs before yours that also have not popped up on RB20:22
=== kadams54 is now known as kadams54-away
davecheneymenn0: it's a mere 2,400 lines of change20:24
menn0davecheney: most of it is very mechanical though... you're wearing out my scroll wheel :)20:25
davecheneymenn0: juju.go and constants.go at the root are the only real changes20:25
davecheneyanything which referenced those types s/params/juju20:25
davecheneythere are no other non mechnical changes20:25
davecheneymenn0: oh, you found that20:27
menn0:)20:27
davecheneythere are only two of those20:28
davecheneyin the other places I jj "github.com/juju/juju"20:28
davecheneyplease don't mention the war20:28
davecheney(about packages020:28
* menn0 goes to install more ram just so he can finish this review20:30
davecheneydat pagination20:31
davecheneybtw, go imports is great20:31
davecheneyalias gi='goimports -w .'20:32
davecheneyedit edit,20:32
davecheneygi20:32
davecheneygo test20:32
davecheneynext package20:32
menn0yeah... I have it hooked up to Emacs when I save a .go file.20:32
menn0lifechanging20:32
cmarsdavecheney, waigani_ thanks for reviewing my id branch (#1081). i've pushed fixes but a couple of questions for y'all20:34
cmarsdavecheney, question for you here, http://reviews.vapour.ws/r/338/#comment289420:34
menn0davecheney: done20:37
davecheneymenn0: ta20:37
davecheneyi've fixed that nit20:37
* menn0 dips his mouse in a glass of water to stop the smoke20:37
cmarswaigani_, question for you, more of a general login security thing: http://reviews.vapour.ws/r/338/#comment346920:37
waigani_cmars: be with you in a sec20:38
waigani_menn0: http://reviews.vapour.ws/r/400/20:41
davecheneyhmm, have all our bots died ? https://github.com/juju/juju/pull/110320:43
davecheneycmars: good point20:44
davecheneygiven that it needs to exist in that odd form20:44
davecheneyjust reply to that comment and tell me to pull my head in20:44
waigani_cmars: replied. Wrapping in common.ErrBadCreds makes sense, agreed20:45
cmarsdavecheney, waigani_ thanks20:46
waigani_davecheney: have you tried using the rbt to push to RB?20:48
davecheneywaigani_: nup20:50
davecheneywaigani_: but the bot i was worried about is the commit bot20:50
davecheneywhich hasn't picked up the $$merge$$ in 10 minutes20:50
waigani_oh..20:51
waigani_I need to get out of this house, going to work in town. I'll be offline for 20min while I drive in.20:54
=== kadams54-away is now known as kadams54
davecheneythumper: i found a bug in set.Strings yesterday21:15
davecheneyhttp://paste.ubuntu.com/8948366/21:15
davecheneyhold21:15
davecheneythumper: http://paste.ubuntu.com/8948372/21:15
davecheney^ this one21:15
menn0davecheney: not sure if you've seen but looks like the build bot worked eventually but there's test failures21:25
davecheneyyeah21:26
davecheneylooking into the maas fialures now21:26
alexisbthumper, ping21:38
thumperalexisb: hey there21:38
alexisbhey thumper you have a second?21:38
alexisbfor a hangout21:38
thumperyep, just getting off with cmars21:39
bodie_anyone know how to use jc.TimeBetween?21:50
bodie_I think there might be a typo in its Check21:50
=== LinStatSDR_ is now known as LinStatSDR
davecheneythumper: ping, 08:15 < davecheney> thumper: http://paste.ubuntu.com/8948372/21:59
thumperyep... otp right now, with you very soon21:59
davecheneykk22:00
davecheneyjust found this bug is affecting the maas code22:00
thumperdavecheney: I need to go get my daughter from school - she is unwel22:09
thumperdavecheney: can we chat when I get back?22:09
davecheneysure22:09
thumperdavecheney: our regular 1:1 hangout22:23
davecheneythumper: coing22:28
thumperlike a bird ;-)22:28
davecheneyimma here22:29
davecheneydid you mean the standup hangout ?22:29
thumperhmm... I'm there too.22:29
thumperno, our 1:122:29
* thumper tries again22:29
=== kadams54 is now known as kadams54-away
menn0cmars: i'm looking at review 33822:47
menn0cmars: has the "juju server" command been given general approval?22:47
cmarsmenn0, might need more discussion, now that I think about it22:51
cmarsmenn0, how about I break out the subcommand into a separate PR?22:51
menn0cmars: or just disable it pending further discussion (but leave the code there)22:52
menn0cmars: just don't hook it up22:52
cmarsmenn0, it's currently not hooked up to the cmd/juju supercommand22:55
menn0cmars: ok, that's fine then. I haven't gotten to that part of the PR yet. I was asking based on the description of the changes.23:03
=== kadams54 is now known as kadams54-away
davecheneymenn0: waigani thumper https://github.com/juju/utils/pull/8423:23
menn0davecheney: still doing another review but will get there soon23:23
davecheneykk23:23
davecheneythere is no rbt on that repo23:23
davecheneyoh23:24
davecheneyactaully there is23:24
davecheneywadda you know23:24
davecheneyhttp://reviews.vapour.ws/r/406/23:24
waiganiyay, rb is over it's hangover23:24
davecheney\o/23:24
=== kadams54-away is now known as kadams54

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!