| davecheney | mgz_: thanks for your help | 00:16 |
|---|---|---|
| davecheney | this is working a treat | 00:16 |
| mgz_ | davecheney: ace | 00:16 |
| davecheney | a few small issues and i'll be able to land this branch | 00:16 |
| davecheney | thumper: a pint of grog for mgz_ ! | 00:16 |
| thumper | awesome | 00:21 |
| thumper | hmm.... | 00:43 |
| thumper | I'm seeing state/leadership package sometimes timeout after 20 minutes | 00:43 |
| * thumper smells race | 00:43 | |
| thumper | but my --race doesn't work | 00:43 |
| mwhudson | it's totally possible to have logical races without memory races | 00:59 |
| thumper | sure | 01:03 |
| axw | thumper: why discard that PR about server->controller? is that rename not happening anymore? | 01:57 |
| thumper | axw: it is, but I'm going to retarget it against the new 'controller-rename' feature branch | 01:57 |
| thumper | as I feel that I'm going to break CI | 01:57 |
| axw | thumper: okey dokey | 01:57 |
| thumper | especially as I change some of the command stuff | 01:57 |
| thumper | and remove the feature falg | 01:58 |
| thumper | so I thought I retarget it all | 01:58 |
| thumper | hopefully a very short lived feature branch | 01:58 |
| thumper | as conflicts against master are going to be a biatch | 01:58 |
| axw | thumper: did you see my latest email about multi-env vs. azure? | 01:59 |
| thumper | I think so | 02:00 |
| * thumper goes to look again | 02:00 | |
| axw | thumper: did not get a reply. just curious about how we're supposed to do create/destroy when an env has resources shared between machines | 02:01 |
| axw | setup/teardown, a la bootstrap/destroy | 02:01 |
| thumper | like what? | 02:01 |
| axw | thumper: in the case of azure: a resource group, subnet, network security group, storage account | 02:01 |
| axw | thumper: each env will have its own everything, except for a single virtual network that all envs are connected to | 02:02 |
| thumper | ok... | 02:02 |
| thumper | well, shouldn't we just hook into the create environment, and destroy environment endpoints? | 02:03 |
| thumper | when we destroy a controller, we take down all the hosted environments first | 02:03 |
| thumper | axw: waigani has been refactoring all our destruction code so it is nicer and more async | 02:03 |
| axw | thumper: yeah, but atm EnvironProvider just has "PrepareForCreateEnvironment" - I'm using htis but it doesn't feel quite right | 02:03 |
| axw | thumper: sounds good | 02:03 |
| thumper | you should use the create environment, not the prepare | 02:04 |
| axw | thumper: there is no "create environment" in EnvironProvider, at least not on master. maybe in a feature branch? | 02:05 |
| thumper | where are you looking? | 02:05 |
| thumper | hmm... | 02:05 |
| axw | thumper: https://github.com/juju/juju/blob/master/environs/interface.go | 02:05 |
| * thumper thinks... | 02:05 | |
| * thumper looks | 02:05 | |
| thumper | axw: actually, there is currently no function we call at all in the provider when creating a new environment | 02:07 |
| thumper | before there was never anything to execute | 02:07 |
| thumper | hmm... | 02:09 |
| axw | thumper: so I think we need a CreateEnvironment as well as a PrepareForCreateEnvironment | 02:09 |
| thumper | I think you may be right | 02:09 |
| * thumper greps for the Prepare... | 02:09 | |
| axw | thumper: PrepareForCreateEnvironment is called (twice), and it is usable | 02:09 |
| thumper | hmmm | 02:09 |
| thumper | yeah, checking for valid Config | 02:10 |
| axw | thumper: i.e. I've got multi-env working in azure | 02:10 |
| thumper | axw: it feels better to have a separate CreateEnvironment call | 02:11 |
| thumper | that we call just once | 02:11 |
| axw | thumper: +1 | 02:11 |
| axw | thumper: also, it's not obvious why Prepare is called twice (once before assigning UUID, once after) - would be good to have better docs on that | 02:12 |
| thumper | I believe it is the two step call we do | 02:12 |
| thumper | which we are looking to fix | 02:12 |
| thumper | the first is to ask for a config skeleton | 02:12 |
| thumper | and then the validation when the user passes it back | 02:13 |
| thumper | but to be honest, I'm not entirely clear | 02:13 |
| thumper | we are wanting to make the juju cli do the same as jem | 02:13 |
| thumper | and have all providers supply the configschema | 02:13 |
| thumper | oh... | 02:13 |
| thumper | can you make the new azure provider supply the configschema? | 02:13 |
| thumper | not sure if the old one did | 02:14 |
| axw | thumper: it didn't. I'll add it to the list. | 02:14 |
| thumper | axw: here is that branch retargeted to the controller-rename branch http://reviews.vapour.ws/r/3053/ | 02:37 |
| wallyworld | axw: small one if you have a moment https://github.com/juju/charmrepo/pull/36 | 02:54 |
| === natefinch-afk is now known as natefinch | ||
| menn0 | thumper: http://reviews.vapour.ws/r/3054/ | 03:44 |
| menn0 | thumper: adds "no tail" support to state.LogTailer | 03:44 |
| * thumper looks | 03:44 | |
| thumper | menn0: why do we need to call tailer.Stop when we said "don't tail" ? | 03:48 |
| menn0 | thumper: you don't ... | 03:50 |
| menn0 | thumper: it's just in case the tailer isn't working during tests | 03:51 |
| menn0 | thumper: like when I wrote the test but NoTail wasn't implemented yet | 03:51 |
| menn0 | thumper: happy to reemove it if you think it's confusing | 03:51 |
| thumper | perhaps just a comment would be enough | 03:51 |
| * thumper sighs | 03:52 | |
| thumper | state/leadership is failing for me again... | 03:52 |
| menn0 | thumper: i've responded to the review | 04:01 |
| axw | wallyworld: reviewed | 04:06 |
| wallyworld | ty | 04:06 |
| === Ursinha-afk_ is now known as Ursinha | ||
| === Ursinha is now known as Guest82331 | ||
| === psivaa_ is now known as psivaa | ||
| === Guest82331 is now known as Ursinha | ||
| === Ursinha is now known as ursula1234 | ||
| === ursula1234 is now known as Ursinha | ||
| thumper | waigani: http://reviews.vapour.ws/r/3056/ | 04:22 |
| thumper | waigani: it is the earlier branch retargetted and many of the missed systems renamed too | 04:22 |
| mup | Bug #1454466 changed: Deployment times out waiting for relation convergence - nvp-transport-node in installing state <deploy> <oil> <juju-core:Expired> <juju-deployer:Invalid> | 04:30 |
| mup | <neutron-gateway (Juju Charms Collection):Expired> <nvp-transport-node (Juju Charms Collection):Expired> <https://launchpad.net/bugs/1454466> | 04:30 |
| mup | Bug #1454466 opened: Deployment times out waiting for relation convergence - nvp-transport-node in installing state <deploy> <oil> <juju-core:Expired> <juju-deployer:Invalid> | 04:33 |
| mup | <neutron-gateway (Juju Charms Collection):Expired> <nvp-transport-node (Juju Charms Collection):Expired> <https://launchpad.net/bugs/1454466> | 04:33 |
| mup | Bug #1454466 changed: Deployment times out waiting for relation convergence - nvp-transport-node in installing state <deploy> <oil> <juju-core:Expired> <juju-deployer:Invalid> | 04:36 |
| mup | <neutron-gateway (Juju Charms Collection):Expired> <nvp-transport-node (Juju Charms Collection):Expired> <https://launchpad.net/bugs/1454466> | 04:36 |
| waigani | thumper: shipit with a question about "controller environment" | 04:39 |
| davecheney | thumper: menn0 axw http://reviews.vapour.ws/r/3057/ | 04:59 |
| axw | davecheney: shipit | 05:01 |
| menn0 | axw: that was awfully fast! | 05:02 |
| davecheney | boom | 05:02 |
| axw | menn0: awfully easy review :) | 05:02 |
| davecheney | -2700 lines -> ship it! | 05:02 |
| axw | heh | 05:02 |
| menn0 | I think axw has a bot that just automatically replies with ship it | 05:02 |
| axw | ;) | 05:02 |
| axw | in seriousness, I wish we had one for back/forwardports | 05:03 |
| axw | or a way to just not post to RB | 05:04 |
| wallyworld | axw: sorry, one more https://github.com/juju/charmrepo/pull/37 | 05:05 |
| axw | wallyworld: you should probably use yaml.v1, it's in dependencies.tsv | 05:08 |
| wallyworld | axw: ah, yeah, thanks | 05:09 |
| === bodie__ is now known as bodie_ | ||
| anastasiamac | ericsnow: ping? | 08:11 |
| fwereade_ | axw, I think you're probably right re manifold-in-different-package, but I'm really reluctant for some reason | 09:00 |
| fwereade_ | axw, possibly because so many others are not yet sufficiently separate from their worker packages as to cleanly accommodate that? | 09:01 |
| frobware | dimitern, dooferlad: standup? | 10:02 |
| axw | fwereade_: sorry, I was away from IRC. I'm of two minds. On the one hand, it's obviously inherently tied to the worker, but on the other, it has a separate role to play (policy over starting the worker, and connecting the worker to other things). I think having it in a separate package just keeps the responsibilities clearer | 11:10 |
| fwereade_ | axw, yeah, I think you're right. subpackage is probably not *really* the right place, but close enough for now | 11:31 |
| voidspace | perrito666: thanks | 12:16 |
| perrito666 | voidspace: yw | 12:18 |
| * perrito666 overslept, rainy day, fresh drapes, impossible not to | 12:18 | |
| frankban | cherylj: hi, could you please take a look at http://reviews.vapour.ws/r/3063/ when you have time? | 12:21 |
| jam | fwereade_: I realized late that alexisb moved our meeting time (relative to my tz at least). I need to take the dog out, but will try to be back for the meeting | 13:26 |
| === niedbalski_ is now known as niedbalski | ||
| alexisb | jam, we dropped but I am here if you want to chat post dog walk | 13:45 |
| Shawn_ | Hello, I am trying to build the packages from source, how can i download the dependency packages individually instead using the makefile ? | 13:45 |
| jam | alexisb: hiya. I don't have anything specific. You dropped the meeting for today? | 13:47 |
| alexisb | jam, fwereade_ and I met for a moment and then dropped | 13:47 |
| jam | alexisb: you realize you really have nothing to say to eachother without me ? :) | 13:50 |
| alexisb | jam, so very true ;) | 13:51 |
| cherylj | frankban: did you have any write up on using the new bundle support that can go out into the release notes for 1.26-alpha1? | 13:58 |
| fwereade_ | rogpeppe, do you recall why EnvironObserver has a mutex, and replaces its environ, instead of doing a SetConfig? environs are meant to be goroutine-safe... | 14:11 |
| fwereade_ | rogpeppe, (I know it's from, what, 20 months ago :)) | 14:12 |
| frankban | cherylj: no I don't but I can get it prepared | 14:19 |
| cherylj | frankban: that would be great. Just enough to tell people it's there and how they can use it. | 14:19 |
| frankban | cherylj: cool, Makyo ^^^ would you like to prepare something about bundle deployment in core? | 14:21 |
| frankban | cherylj: will you have time to look at the branch today? | 14:22 |
| rogpeppe | fwereade_: i'll have a look | 14:25 |
| fwereade_ | rogpeppe, cheers | 14:25 |
| rogpeppe | fwereade_: even if an Environ itself is goroutine-safe, a worker still doesn't want it changing underneath itself with no warning | 14:28 |
| cherylj | frankban: yes, I can. I see you have two ship it reviews already. Did you still want me to take a look? | 14:32 |
| frankban | cherylj: yes please, I need a review from a core developer | 14:33 |
| cherylj | frankban: ah, ok. Will look at it this morning | 14:33 |
| frankban | cherylj: ty! | 14:34 |
| fwereade_ | rogpeppe, sorry, why not? | 14:41 |
| fwereade_ | rogpeppe, isn't that the point of it being goroutine-safe, that someone updating the config should be no cause for concern? | 14:42 |
| fwereade_ | bother | 14:42 |
| fwereade_ | rogpeppe, sorry, bad timing before | 14:47 |
| rogpeppe | fwereade_: np | 14:48 |
| fwereade_ | rogpeppe, what's the problem with the environ config being updated under a worker? I rather thought that was the point of the boroutine-safety? | 14:48 |
| rogpeppe | fwereade_: if i'm writing a worker, i might be doing something on the basis of one attribute, but another attribute might change underfoot so it's inconsistent | 14:49 |
| rogpeppe | fwereade_: i think it's better if the config is treated as immutable | 14:49 |
| mup | Bug #1513084 opened: 1.20 cannot upgrade to 1.26-alpha1: run.socket: no such file or directory <1.20> <ci> <intermittent-failure> <run> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1513084> | 14:50 |
| fwereade_ | rogpeppe, that sounds like a problem with the Config method alone then? | 14:50 |
| fwereade_ | rogpeppe, (also: if a worker's depending on env config values from the env, not from state, isn't it already confused?) | 14:51 |
| rogpeppe | fwereade_: if that's an issue, why are we creating the env at all? | 14:53 |
| fwereade_ | rogpeppe, to call methods that do something to the substrate | 14:53 |
| rogpeppe | fwereade_: ok, so those methods will depend on env config values in the env, right? | 14:53 |
| fwereade_ | rogpeppe, yes, but that's the env's problem, not the client's | 14:54 |
| rogpeppe | fwereade_: so should the worker rely on two sources of truth for the config values from the state - the env and another watcher? | 14:54 |
| rogpeppe | fwereade_: currently a worker needs only to use the EnvironObserver, which gives it the config values from state (and an environment that can use them) | 14:56 |
| mup | Bug #1513096 opened: invalid agent version in environment configuration: "1.26-alpha1" <ci> <deploy> <juju-core:Triaged> <https://launchpad.net/bugs/1513096> | 14:56 |
| fwereade_ | rogpeppe, what's the overlap between worker-relevant values and env-relevant values? | 14:57 |
| rogpeppe | fwereade_: i don't know. but i wouldn't want to rely on there being none ever | 14:57 |
| rogpeppe | fwereade_: having a single place to watch seems like a reasonable thing to me | 14:58 |
| fwereade_ | rogpeppe, in practice, what the EnvironObserver is used for is to create an environ, hand it over to instancepoller, and never update it | 14:58 |
| fwereade_ | rogpeppe, the instancepoller doesn't remotely care about what wwe're doing in the background, it just wants its instancegetter to work | 14:58 |
| rogpeppe | fwereade_: i'm slightly surpised the provisioner worker doesn't use it | 14:59 |
| fwereade_ | rogpeppe, what would the point be? if it doesn't update the environ we still have to thread env-watching through every worker | 14:59 |
| fwereade_ | rogpeppe, if it simplified its clients, then it'd be great, but as it is there's no reason to switch implementations to use that afaics | 15:00 |
| rogpeppe | fwereade_: presumably the provision *does* update its Environ when the environ config changes? | 15:03 |
| rogpeppe | fwereade_: ah yes, it does | 15:03 |
| fwereade_ | rogpeppe, yeah -- and that one is also sl. different in that it has an interest in actual juju-model config as opposed to just the substrate config | 15:05 |
| fwereade_ | rogpeppe, but I'm pretty sure that if it's paying attention to the substrate config it's DIW somewhere | 15:05 |
| rogpeppe | fwereade_: "dead in water" "doing it wrong" ? | 15:06 |
| fwereade_ | rogpeppe, the latter was my intent :) | 15:06 |
| rogpeppe | fwereade_: it feels a bit racy to me | 15:06 |
| fwereade_ | rogpeppe, only if the environ itself is, surely? | 15:08 |
| rogpeppe | fwereade_: not really. | 15:08 |
| rogpeppe | fwereade_: i don't like state changing underfoot | 15:08 |
| rogpeppe | fwereade_: i mean, it's *probably* ok | 15:09 |
| fwereade_ | rogpeppe, I feel like the biggest worry is that few environs have ever been actually used from multiple goroutines, so their safety is not battle-tested | 15:10 |
| rogpeppe | fwereade_: there should be at least one cross-environment test that's designed to trigger the race detector in such cases | 15:11 |
| fwereade_ | rogpeppe, sure, but the number of ways to subtly break safety tends to overwhelm any but exhaustive/invasive testing, and I don't think we really have anything sophisticated enough | 15:13 |
| rogpeppe | fwereade_: ah, i was being confused by the configObserver - it's only there for testing | 15:13 |
| rogpeppe | fwereade_: if a provider doesn't simply use a mutex, it's probably doing it wrong | 15:13 |
| rogpeppe | fwereade_: and that simple mutex logic can be easily tested with the race detector | 15:14 |
| fwereade_ | rogpeppe, there's another way to approach it that I quite liked, but forget the details of | 15:14 |
| rogpeppe | fwereade_: i tend to just make a test like: go setConfig(); go getConfig(); go setConfig(); go getConfig() | 15:14 |
| rogpeppe | fwereade_: which will trigger a failure in the race detector if the appropriate mutexes aren't used | 15:15 |
| fwereade_ | rogpeppe, right, but that's just 2 methods and still rather luck-dependent | 15:15 |
| rogpeppe | fwereade_: true that it's only 2 methods (it should probably be all of 'em), but i don't think it's that luck dependent | 15:16 |
| fwereade_ | rogpeppe, I accept it'll probably fail most of the time, but I doubt it'll be 100% :) | 15:16 |
| rogpeppe | fwereade_: why wouldn't it be? | 15:16 |
| fwereade_ | rogpeppe, it might happen to run them all serially by sheer coincidence, and never happen to flag the issue -- is it smarter than that? I thought it erred in fvaour of false negatives | 15:18 |
| rogpeppe | fwereade_: even if it runs them all serially, the race detector will flag it | 15:18 |
| * fwereade_ scrubs that bad data out of his brain then | 15:19 | |
| rogpeppe | fwereade_: of course you can get false negatives if the code never actually accesses the memory in question | 15:19 |
| fwereade_ | rogpeppe, cool | 15:19 |
| rogpeppe | fwereade_: it's a pretty good tool | 15:19 |
| fwereade_ | rogpeppe, yeah, but that's not the case here | 15:19 |
| rogpeppe | fwereade_: i'm a big fan of race-detector-oriented tests | 15:19 |
| fwereade_ | rogpeppe, indeed, I have a deep and abiding love for the race detector | 15:20 |
| mup | Bug #1511822 changed: imports github.com/juju/juju/workload/api/internal/client: use of internal package not allowed <blocker> <ci> <regression> <wily> <juju-core 1.25:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1511822> | 15:20 |
| mup | Bug #1513096 changed: invalid agent version in environment configuration: "1.26-alpha1" <ci> <deploy> <juju-core:Triaged> <https://launchpad.net/bugs/1513096> | 15:20 |
| fwereade_ | rogpeppe, ok, so, some go-spam-every-method tests would be good in general | 15:20 |
| rogpeppe | fwereade_: so presumably your motivation for the initial question was wondering why the instance poller aggregator isn't seeing env config changes? | 15:26 |
| fwereade_ | rogpeppe, not so much, actually, I came across that later -- I was more thinking of running a separate EnvironObserver that *could* be shared by the various workers that use environs | 15:27 |
| rogpeppe | fwereade_: well, the current one can be in fact | 15:28 |
| rogpeppe | fwereade_: you could do the SetConfig locally in each worker as desired | 15:29 |
| fwereade_ | rogpeppe, don't think so? there's only one Environ in the observer | 15:29 |
| rogpeppe | fwereade_: each worker would have its own Environ | 15:29 |
| fwereade_ | rogpeppe, that's what I'm trying to get away from | 15:30 |
| rogpeppe | fwereade_: for reasons of efficiency? | 15:30 |
| fwereade_ | rogpeppe, more that the env-watching is unnecessary extra complexity in a bunch of different workers | 15:31 |
| fwereade_ | rogpeppe, and yeah, there's some efficiency improvement as well | 15:31 |
| fwereade_ | rogpeppe, and it opens the door to us being able to actually manager rate limits sanely, instead of having a herd of N environs stampeding to talk to the same endpoint from a single agent | 15:32 |
| rogpeppe | fwereade_: the difficulty is that it's all bound up with environ config and that smears a bunch of semi-related attributes together | 15:32 |
| rogpeppe | fwereade_: i'm toying with the thought that workers shouldn't ever look at the environ config directly at all | 15:34 |
| fwereade_ | rogpeppe, I do agree that env config is a mess; but AFAICS the potential for harm comes from people using the environ config -- ha, yeah | 15:34 |
| fwereade_ | rogpeppe, can you think of any legitimate uses for .Config() for a client? :) | 15:34 |
| rogpeppe | fwereade_: but instead have the parameters passed in and derived from the config | 15:34 |
| fwereade_ | rogpeppe, yeah, absolutely | 15:34 |
| rogpeppe | fwereade_: then you'd probably need to restart the worker when config relevant to it changed | 15:35 |
| fwereade_ | rogpeppe, we just want to pass in something that knows how to ask for instances, and which isn't all whiny and needy about being updated by the same client who wants instances | 15:35 |
| fwereade_ | rogpeppe, still not really understanding why not to SetConfig and be done with it? | 15:35 |
| fwereade_ | rogpeppe, in the observer, I mean | 15:36 |
| rogpeppe | fwereade_: SetConfig and use chan struct{} ? | 15:36 |
| fwereade_ | rogpeppe, no, I don't want the clients to have to care about environ config at all | 15:36 |
| rogpeppe | fwereade_: that's ok iff there's no overlap between the attrs used by the worker vs those used by the provider | 15:37 |
| rogpeppe | fwereade_: i wonder what it would take to split 'em | 15:38 |
| fwereade_ | rogpeppe, well, at least in the instancepoller case, it doesn't care about env config at all | 15:38 |
| rogpeppe | fwereade_: i'm more thinking of the provider case actually | 15:38 |
| fwereade_ | rogpeppe, in the provisioner case all I can think of is, uh, instance-reaping mode, whatever it's called | 15:38 |
| rogpeppe | sorry | 15:38 |
| rogpeppe | provisioner | 15:38 |
| rogpeppe | fwereade_: yeah | 15:38 |
| fwereade_ | rogpeppe, which the provisioner shouldn't really know is to do with the env config anyway, it shoudl just be watching/asking for reaping mode | 15:39 |
| rogpeppe | fwereade_: one way to be more sure that the workers aren't doing anything untoward might be to make the Environ with Config and SetConfig methods that return an error or panic | 15:43 |
| fwereade_ | rogpeppe, mm, yeah, I will poke around in that direction and see what happens | 15:52 |
| rogpeppe | fwereade_: that wouldn't be compatible with logic doing type inspection of the Environ, but i would hope that nothing is doing that anyway (and i've always considered it seriously misguided in the places we *are* doing it) | 15:53 |
| rogpeppe | s/hope that nothing/hope that nothing in the workers/ | 15:53 |
| fwereade_ | rogpeppe, yeah | 15:55 |
| natefinch | gc.ErrorMatches is horrible and bad, and anyone who uses it should feel bad. | 16:04 |
| fwereade_ | natefinch, gtg out, would still be interested to hear more on this -- I'd say that *overbroad* ErrorMatches~s are the usual problem? | 16:05 |
| natefinch | fwereade_: the only time the *text* of an error message matters, is if it is shown to a user... which 99% of the time it is not | 16:06 |
| natefinch | fwereade_: we use it as a shorthand for "I expect this specific error to be returned" | 16:06 |
| natefinch | fwereade_: which is not what is actually being tested | 16:07 |
| rogpeppe | natefinch: i disagree. i think it's really helpful to see what our errors look like | 17:11 |
| rogpeppe | natefinch: the alternative is often just asserting that the error is non-nil, which isn't very helpful (i have discovered lots of places where we generated a really stupid or malformed error which we never knew about because of that) | 17:13 |
| natefinch | rogpeppe: the problem is that asserting the error message asserts a ton of information you don't actually care about. Like how certain types serialize into strings, like how many levels of abstraction there are between you and the origin of the error | 17:15 |
| rogpeppe | natefinch: yes, i agree. that can be problematic too. but i think the upside of seeing what your error messages actually look like outweighs that. | 17:16 |
| rogpeppe | natefinch: i often finish an ErrorMatches string with .* | 17:16 |
| rogpeppe | natefinch: i've found the error string thing really helpful recently - i found one error that was mentioning the same URL 3 times in the same error message. | 17:17 |
| rogpeppe | natefinch: crafting decent error messages is important for the user experience | 17:18 |
| rogpeppe | natefinch: and the tests are usually the only place *we* will ever see them | 17:18 |
| rogpeppe | natefinch: if it hadn't been for ErrorMatches, we wouldn't have made the recent fix to the charm error messages ("charm or bundle not found" vs "entity not found") caught when ian was reviewing our juju-core changes in response to a charm dep update | 17:19 |
| natefinch | rogpeppe: sure, there are times when we show errors to users, and in those cases, error text matters.. but we use ErrorMatches *everywhere* in places we know the user will never see the message (logs don't really count). | 17:21 |
| rogpeppe | natefinch: logs definitely count | 17:22 |
| natefinch | rogpeppe: not down to the letter | 17:22 |
| rogpeppe | natefinch: so what would you do? just check that the error isn't nil? | 17:22 |
| natefinch | rogpeppe: no, check what you actually care about, that we detected a specific type of error and failed in an expected way. Use a custom error type or something. | 17:23 |
| rogpeppe | natefinch: another issue i found recently was where an API test wasn't actually testing what it thought it was - the error was for an entirely different reason. | 17:23 |
| rogpeppe | natefinch: i don't think we should need a custom error type or value for every kind of error we want to test for | 17:24 |
| natefinch | rogpeppe: the thing that brought this up for me was that a test started failing on master because I added a level of indirection, so the error message had an extra section of "while you were doing foo:" | 17:24 |
| rogpeppe | natefinch: yes, that's definitely the down side | 17:24 |
| rogpeppe | natefinch: it does make for more churm | 17:24 |
| rogpeppe | natefinch: but i still think it's worth it | 17:24 |
| rogpeppe | natefinch: (and i have thought about this quite a bit when making similar changes) | 17:25 |
| natefinch | rogpeppe: and the problem is that no one is actually thinking about what the error message says or means. For example, to fix that test, I just copied what the new text is from the error and pasted it into the regex. That's not really making our code or tests better. | 17:25 |
| natefinch | rogpeppe: imagine if we decided to change how tags print out, so now they print out as "tag: foo/0" ... we'd have thousands of broken tests. | 17:26 |
| rogpeppe | natefinch: when you did that, i hope you asked yourself the question "does this error accurately and reasonably represent the error that's being tested for?" | 17:26 |
| rogpeppe | natefinch: yes we would | 17:27 |
| rogpeppe | natefinch: but if we changed the representation of tag.String we'd have lots of other issues too | 17:27 |
| natefinch | rogpeppe: but there would be 1000 failing tests that are failing because they're testing something they don't actually care about. certainly there are places that care what tag's String() function outputs... but that's not the only tests that would fial. | 17:29 |
| rogpeppe | natefinch: yes, it's a tradeoff | 17:29 |
| rogpeppe | natefinch: but i don't see a better alternative | 17:30 |
| ericsnow | rogpeppe: checking for specific error types (a la os.IsNotExist and errors.IsNotFound) | 17:30 |
| rogpeppe | ericsnow: so every different error message should have its own error type? | 17:31 |
| natefinch | rogpeppe: no, but they shouldn't all be effectively bare strings either | 17:31 |
| ericsnow | rogpeppe: arguably one for each equivalence class of error | 17:31 |
| rogpeppe | ericsnow: how do you decide that? | 17:32 |
| ericsnow | rogpeppe: through bikeshedding <wink> | 17:32 |
| rogpeppe | ericsnow: and adding hundreds of different error types is a serious maintenance burden | 17:32 |
| ericsnow | rogpeppe: unlike hard-coding checks for error strings ;) | 17:33 |
| rogpeppe | ericsnow: at least that's only in the tests and easily changed | 17:33 |
| rogpeppe | ericsnow: the problem with having error types is that they're a burden on every developer and need to be maintained as part of the API | 17:33 |
| rogpeppe | ericsnow: but often a given error might only have meaning within the context of a given implementation | 17:34 |
| ericsnow | rogpeppe: I'd argue that the errors you get *are* part of the API | 17:34 |
| rogpeppe | ericsnow: i agree totally | 17:34 |
| rogpeppe | ericsnow: and i think that any API should think very hard about the set of error types it exposes | 17:34 |
| ericsnow | rogpeppe: definitely | 17:34 |
| rogpeppe | ericsnow: which doesn't mesh well with tests that want to test internal functionality | 17:35 |
| ericsnow | rogpeppe: agreed, though often having to test internal functionality is a code smell | 17:36 |
| ericsnow | rogpeppe: regardless, as you said there are tradeoffs | 17:37 |
| rogpeppe | ericsnow: if you're aiming for high coverage, you have to do that in practice | 17:37 |
| rogpeppe | ericsnow: (and i think aiming for high test coverage is worthwhile) | 17:37 |
| ericsnow | rogpeppe: I'll leave it to katco to expound the higher plane that is dependency injection :) | 17:37 |
| ericsnow | rogpeppe: and I couldn't agree more about the importance of high test coverage | 17:38 |
| katco | quick, look over there! | 17:38 |
| * rogpeppe looks at the pretty birdy | 17:38 | |
| natefinch | I'm with roger on internal tests. I think they greatly increase the confidence you can have in your tests. They make writing tests immensely faster, and they prevent you from mangling your exported API just to support testing. | 17:38 |
| katco | does anyone remember what the environmental var is for tabular status? | 17:39 |
| rogpeppe | katco: maybe JUJU_CLI_VERSION=2 ? | 17:41 |
| rogpeppe | katco: (haven't tried it, just scanned the code) | 17:42 |
| katco | that works | 17:42 |
| katco | rogpeppe: ty | 17:42 |
| rogpeppe | katco: np | 17:42 |
| === ericsnow is now known as ericsnow_afk | ||
| mup | Bug #1513165 opened: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165> | 18:08 |
| mup | Bug #1513165 changed: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165> | 18:17 |
| mgz_ | katco: got a sec? bug 1512399 | 18:19 |
| mup | Bug #1512399: ERROR environment destruction failed: destroying storage: listing volumes: Get https://x.x.x.x:8776/v2/<UUID>/volumes/detail: local error: record overflow <amulet> <bug-squad> <openstack> <uosci> <juju-core:Triaged> <https://launchpad.net/bugs/1512399> | 18:19 |
| mgz_ | why does the autogenerated cinder stuff have "https://cinder.example.com" in it at all? can't it just have the path? | 18:20 |
| mup | Bug #1513165 opened: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165> | 18:20 |
| mgz_ | issue is the calling code overrides the host, but not the scheme | 18:20 |
| mgz_ | so, it breaks if the endpoint is not https | 18:21 |
| mup | Bug #1513165 changed: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165> | 18:23 |
| mup | Bug #1513165 opened: Containers registered with MAAS use wrong name <juju-core:Triaged> <https://launchpad.net/bugs/1513165> | 18:26 |
| natefinch | katco: "Pull request successfully merged and closed. You’re all set—the natefinch:assign-worker branch can be safely deleted." | 18:32 |
| alexisb | mgz_, cherylj has been looking at lp 1512399 | 18:41 |
| mgz_ | alexisb: it's easy to fix, it's just katco's autogenration code needs changing to take an endpoint rather than do this weird overriding | 18:41 |
| mgz_ | wanted to check with her before hacking it | 18:42 |
| alexisb | mgz_, ack | 18:42 |
| alexisb | I will stay out of it, thanks | 18:42 |
| mgz_ | alexisb: no worries | 18:42 |
| katco | mgz_: natefinch: sorry was eating lunch | 18:46 |
| katco | natefinch: grats... feel like we should throw a party or something :p | 18:46 |
| natefinch | katco: right? :) | 18:46 |
| katco | mgz_: i believe axw has already modified the auto-generated code, so further modification is probably ok | 18:46 |
| mgz_ | ...that's more like not okay then, unless he pull requested back to your repo? | 18:47 |
| mgz_ | oh, or you mean he modified the generated file? | 18:47 |
| katco | mgz_: yes i think so | 18:48 |
| mgz_ | yeah, seems like that... mehp, that make updating more annoying | 18:48 |
| mgz_ | looks trivial | 18:50 |
| katco | mgz_: fwiw he asked first. we were both busy and i think the cinder project made some modifications that broke auto-generation w/o looking into it | 18:50 |
| perrito666 | beautiful, this is what mongorestore says when file not found: don't know what to do with file | 18:50 |
| katco | mgz_: but yes, because of the layering approach, it should be very trivial :) | 18:50 |
| mgz_ | katco: anyway, the code just needs to build urls in a sane way | 18:50 |
| katco | mgz_: should just have to modify protocol here: https://github.com/go-goose/goose/blob/v1/cinder/client.go#L25-L33 | 18:51 |
| mgz_ | an endpoint is not just a host, it's a scheme+host+path that you then append a path to | 18:51 |
| katco | mgz_: still, just need to modify that 1 function | 18:51 |
| katco | mgz_: and that's not even auto-generated code. that's goose | 18:52 |
| mgz_ | katco: just + req.URL.Scheme = endpoint.Scheme in SetEndpointFn works for the bug as reported, but that code is still wrong | 18:52 |
| katco | mgz_: modify the path in the same place | 18:52 |
| mgz_ | the auto gen code should append paths to the endpoint | 18:52 |
| mgz_ | and having hardcodes fake urls is ugly. | 18:53 |
| natefinch | katco, ericsnow_afk, wwitzel3: the tech debt bug to fix the tests: perrito666: nice error message | 19:07 |
| natefinch | lol wrong copy | 19:07 |
| natefinch | http://reviews.vapour.ws/r/3068/ | 19:07 |
| natefinch | wwitzel3: why does the package_test.go file need a +build go1.3? | 19:13 |
| wwitzel3 | the card said it did? | 19:13 |
| wwitzel3 | I foobar'd my go install trying to install 1.2 so I could test the build flags | 19:14 |
| wwitzel3 | so I'm playing with that right now, when I threw it at the bot through, it still didn't work, so I missed some | 19:15 |
| wwitzel3 | natefinch: feel free to give it a try if you have 1.2 | 19:15 |
| natefinch | wwitzel3: install go from source, it's easy and easy to switch versions | 19:15 |
| natefinch | (switching versions is just git checkout go1.2 and then make.bash) | 19:16 |
| * natefinch just switched from 1.4 to 1.2 in like 10 seconds) | 19:17 | |
| natefinch | wwitzel3: every file that imports github.com/lxc/lxd is going to have to be +build go1.3 ... and every file that imports anything those files | 19:21 |
| wwitzel3 | natefinch: so if the file that imports lxd is go1.3, all the files in the lxd package still have to have it? | 19:24 |
| natefinch | ahahahahahahahahahaha .... | 19:24 |
| natefinch | oh shit | 19:24 |
| natefinch | wwitzel3: go 1.2 doesn't have a "go1.3" build tag implemented | 19:25 |
| natefinch | waity wait... no, that should still work | 19:25 |
| natefinch | nevermind, sorry | 19:25 |
| === ericsnow_afk is now known as ericsnow | ||
| natefinch | screwing myself up | 19:25 |
| natefinch | wwitzel3: if you do go install ./... it'll independently try to build that package regardless of whether anything else imports it. | 19:26 |
| natefinch | wwitzel3: it's looking like probably all of the provider/lxd files will need // +build go1.3 | 19:32 |
| wwitzel3 | great | 19:32 |
| natefinch | wwitzel3: I have most of the changes on my local machine... haven't run tests which will also need it. | 19:33 |
| natefinch | > Directory: /home/nate/src/github.com/juju/juju/provider/lxd | 19:35 |
| natefinch | > Command: /home/nate/go/bin/go test ./... | 19:35 |
| natefinch | > Output: | 19:35 |
| natefinch | ? github.com/juju/juju/provider/lxd[no test files] | 19:35 |
| natefinch | > Elapsed: 0.131s | 19:35 |
| natefinch | > Result: Success | 19:35 |
| natefinch | Success! | 19:35 |
| ericsnow | cherylj: PTAL: http://reviews.vapour.ws/r/3067/ | 19:35 |
| natefinch | wwitzel3: running a full compile of test code now, but I think I got everything | 19:36 |
| natefinch | hmm..... | 19:37 |
| natefinch | I bet just having github.com/lxc/lxd in dependencies.tsv is going to be a non-starter | 19:37 |
| natefinch | katco: ^ | 19:37 |
| natefinch | wwitzel3: I'm getting some wacky compile errors in environs/bootstrap | 19:48 |
| natefinch | a bunch of these: | 19:48 |
| natefinch | ./bootstrap_test.go:79: cannot use env (type *bootstrapEnviron) as type environs.Environ in function argument: | 19:48 |
| natefinch | *bootstrapEnviron does not implement environs.Environ (wrong type for Bootstrap method) | 19:48 |
| natefinch | have Bootstrap(environs.BootstrapContext, environs.BootstrapParams) (string, string, environs.BootstrapFinalizer, error) | 19:48 |
| natefinch | want Bootstrap(environs.BootstrapContext, environs.BootstrapParams) (*environs.BootstrapResult, error) | 19:48 |
| cherylj | ericsnow: can you give me a quick explanation of what the bug was about? | 19:49 |
| ericsnow | cherylj: Go 1.5 disallows packages named "internal" from being used outside the package tree they are in | 19:49 |
| cherylj | oic | 19:50 |
| natefinch | it's a feature! ... just not one we intended to be using ;) | 19:50 |
| natefinch | wwitzel3: I pushed a bunch of my changes here : https://github.com/natefinch/juju/tree/lxd-provider-flags | 19:56 |
| perrito666 | ericsnow: I thought I should share the hapiness with you http://reports.vapour.ws/releases/3261 | 20:04 |
| ericsnow | perrito666: nice! :) | 20:04 |
| perrito666 | old restore is no more | 20:04 |
| perrito666 | and CI is now using the new one which is faster | 20:04 |
| ericsnow | yay | 20:05 |
| perrito666 | and, works flawlessly on HA | 20:05 |
| davecheney | can someone please review this to unblock me | 20:19 |
| davecheney | https://github.com/juju/utils/pull/170 | 20:19 |
| davecheney | it's fairly uncontraversial | 20:19 |
| mgz_ | davecheney: well, I disagree | 20:21 |
| mgz_ | but fine | 20:21 |
| mgz_ | the reason it's stalled is because this bullshit change-it-everywhere-or-nowhere problem | 20:22 |
| mgz_ | there's no reason that our deps shouldn't change apart from people want to keep lock-step on them | 20:22 |
| mgz_ | which is then... why are they even seperate github projects | 20:22 |
| mgz_ | and this is not going to be different when the big-bang v2 change has happened | 20:23 |
| mgz_ | people wanting to get a new fix in utils for a stable branch are going to cope | 20:24 |
| mgz_ | there's no utils 1.24 or 1.25 at present | 20:24 |
| davecheney | mgz_: yaml.v1/2 is only renferenced from one file in juju/utils | 20:27 |
| davecheney | called trivial.go | 20:27 |
| davecheney | which contains one function | 20:27 |
| davecheney | WriteYAML | 20:27 |
| davecheney | i'm going to move that function back into juju/juju where it is used | 20:27 |
| davecheney | and end this madness | 20:27 |
| davecheney | and yes, i agree taht this upgrade everything at once thing is bullshit | 20:27 |
| mgz_ | but the project is called utils! lets just stuff everything in there :) | 20:27 |
| davecheney | i hold that as prima facie evidence that putting version numbers in your import paths is a mistake | 20:28 |
| davecheney | i agree, creating a package called utils is bad enough | 20:28 |
| davecheney | then a repository called utils is asking for it | 20:28 |
| davecheney | at atlassian to try to counteract this we created a jar called 'bucket' | 20:28 |
| davecheney | so people would feel embaressed about using classes from it | 20:29 |
| davecheney | it didn't work, we ended up with bucket2 | 20:29 |
| natefinch | davecheney: the problem is not version numbers in your import paths, its that we don't care about backwards compatibility in those branches, and we use godeps in addition for some BS busywork on top of it just for kicks | 20:29 |
| davecheney | objection! | 20:30 |
| davecheney | this is an unrelated argument | 20:30 |
| davecheney | yaml.v1 and yaml.v2 _ARE_ different | 20:30 |
| davecheney | it says so right in their name | 20:30 |
| natefinch | davecheney: yes | 20:30 |
| davecheney | the problem is one we have created for oursleves where we _WANT_ to think of them as the same | 20:30 |
| davecheney | so there is no argument about backward compatability | 20:31 |
| davecheney | if you want them to be backwards compativle, they'd have the same major version number | 20:31 |
| davecheney | according to the rules of gopkg.in | 20:31 |
| natefinch | davecheney: sorry, I was thinking more of our own repos, charm.v5 etc | 20:31 |
| davecheney | don't even get me started on v6-unstable | 20:31 |
| natefinch | lol | 20:32 |
| natefinch | yes | 20:32 |
| davecheney | and yes, i have no idea why we use godeps _and_ gopkg.in versioned import paths | 20:33 |
| davecheney | the fact that we have to do both says that neither of those alone is a workable solutin | 20:33 |
| natefinch | davecheney: honestly, the problem s till seems to be godeps. that code doesn't expose yaml objects through its api, and I presume the yaml output is valid whether it's v1 or v2 of goyaml. | 20:34 |
| mgz_ | katco: I'm going to murder the autogen-ness of this cinder stuff. The current upstream wadl doesn't make working code, and if we're not syncing we're not gaining anything for the pain of using this. | 20:34 |
| katco | mgz_: that's fine | 20:34 |
| natefinch | davecheney: so why do we even care if some helper function uses yaml.v2 instead of v1? | 20:34 |
| davecheney | natefinch: beacuse we have tests in juju that look for a precise string match | 20:34 |
| mgz_ | katco: I pr'd some changes I needed to test, diff I get is http://paste.ubuntu.com/13105359 | 20:34 |
| davecheney | v2 changes the string form, and handling of empty keys | 20:35 |
| natefinch | davecheney: well I think I know where the problem lies :/ | 20:35 |
| davecheney | you get $0 for pointing out that our tests are fragile | 20:36 |
| natefinch | aww | 20:36 |
| * natefinch was ranting about gc.ErrorMatches earlier | 20:36 | |
| mgz_ | natefinch: the problem is not godeps, we have lots of code that depends on how json is handled, and it's part of our api stability contract | 20:36 |
| mgz_ | which we're already not good on. | 20:37 |
| natefinch | mgz_: ....and there were tests that were failing because we changed how we handled stuff in this function....? | 20:38 |
| davecheney | natefinch: in this case, how yaml is rendered to the client | 20:39 |
| mgz_ | not in dave's current case, that's just an error message change, but the charm stuff is scary | 20:39 |
| davecheney | there is also that yaml.v2 changes the handling of fields/map keys with empty values | 20:40 |
| davecheney | wow, worker/meterstatus/state.go: | 20:41 |
| davecheney | 47: return errors.Trace(utils.WriteYaml(f.path, st)) | 20:41 |
| davecheney | oh | 20:42 |
| davecheney | sorry | 20:42 |
| davecheney | that writeyaml doesn't return yaml | 20:42 |
| davecheney | it returns an error if it couldn't write | 20:42 |
| mgz_ | eheh | 20:42 |
| waigani | review please: http://reviews.vapour.ws/r/3061 | 20:42 |
| * perrito666 ponders buying a paper book after some time | 20:43 | |
| davecheney | thumper: wow, utils.WriteYaml has a huge concurrency failbomb | 20:43 |
| davecheney | prep := path + ".preparing" | 20:44 |
| davecheney | f, err := os.OpenFile(prep, os.O_WRONLY|os.O_CREATE|os.O_SYNC, 0644) | 20:44 |
| perrito666 | davecheney: did you actually read the DK book about go? is it good? | 20:44 |
| davecheney | perrito666: nope, both my physical and ebook copies are still on order | 20:45 |
| davecheney | but it has been reviewed by the whole go team | 20:45 |
| davecheney | so if you were looking for _the_ word on go | 20:45 |
| davecheney | you could not do better than that book | 20:45 |
| * perrito666 sends to sprint hotel | 20:45 | |
| natefinch | davecheney: yeah, that writeyaml function is pretty awful | 20:48 |
| natefinch | davecheney: we have an atomic writefile somewhere | 20:48 |
| natefinch | (probably in a utils package somewhere ;) | 20:52 |
| thumper | menn0, waigani: boring rename branch http://reviews.vapour.ws/r/3056/ | 21:01 |
| waigani | thumper: swap you: http://reviews.vapour.ws/r/3061/ | 21:02 |
| thumper | davecheney: I bet many of our tests have certain concurrency expectations | 21:02 |
| thumper | waigani: looking | 21:02 |
| waigani | thumper: woops, I reviewed that one yesterday, but didn't publish it | 21:02 |
| natefinch | wwitzel3: my branch now compiles (including tests) on go 1.2 | 21:14 |
| wwitzel3 | natefinch: nice, we should just use that then? | 21:15 |
| natefinch | wwitzel3: yeah. probably. I'll PR it | 21:15 |
| wwitzel3 | natefinch: make the PR and I'll review :) | 21:15 |
| natefinch | wwitzel3: http://reviews.vapour.ws/r/3070/ | 21:17 |
| natefinch | ericsnow, katco: super simple review to support go 1.2 in the lxd provider branch ^ | 21:19 |
| thumper | waigani: "controller environment" vs "controller", I do think that it is worthwhile talking about both. Mark wanted the initial environment / state server environment to be called the "controller environment". | 21:19 |
| thumper | I have tried to do that in the places we talked about the other | 21:19 |
| thumper | the controller itself encompasses the whole thing (in my mind at least) | 21:20 |
| thumper | meaning the environment, and the machines and bits in that env | 21:20 |
| thumper | waigani: but I do take your point, and we should perhaps think a bit more on our language | 21:21 |
| thumper | at least grepping for "controller environment" shouldn't be too hard | 21:21 |
| ericsnow | natefinch: if you rebase against my lxd-fix-local-remote branch, you don't need to touch the instance and container/factory packages | 21:22 |
| natefinch | ericsnow: is that branch landing soon? | 21:23 |
| ericsnow | natefinch: not before we get the 1.3+ support we need | 21:25 |
| natefinch | ericsnow: well, this PR is so we don't need 1.3+ support | 21:25 |
| natefinch | )ish) | 21:25 |
| ericsnow | natefinch: just to trick the merge bot? | 21:25 |
| ericsnow | natefinch: strike that :) | 21:26 |
| ericsnow | natefinch: regardless, feel free to strip all the LXD-as-a-container code now rather than waiting for any of my code to land | 21:27 |
| katco | natefinch: how is this different from wwitzel3 's pr? http://reviews.vapour.ws/r/3064/ | 21:28 |
| waigani | thumper: right. It's really about the concept we want to sell. "controller environment vs an environment in a controller" or just "controller vs environment". Either is fine, but we should consciously chose one and be consistent. | 21:28 |
| natefinch | katco: mine works ;) | 21:28 |
| wwitzel3 | yeah | 21:28 |
| wwitzel3 | lol | 21:28 |
| ericsnow | natefinch: also, I'm pretty sure we don't import github/lxc/lxd anywhere under provider/lxd so why is the build constraint needed there? | 21:28 |
| natefinch | ericsnow: transitive dependencies... since we're not building all the lxdclient code, the code that uses *that* code now won't compile | 21:29 |
| thumper | waigani: the tricky bit of this concept is that we have a controller that hosts environments, but also the controller environment that is the environment that contains the API server bits | 21:29 |
| waigani | yep | 21:29 |
| thumper | waigani: so I think I'm doing to defer changing these comments for now :) | 21:30 |
| waigani | okay, sure | 21:30 |
| ericsnow | natefinch: meh, I meant solve that a different way but that would be worse than sprinkling the build constraints all over :) | 21:30 |
| natefinch | ericsnow: you could make fake implementations of the lxdclient stuff for go1.2... but I think this actually might be ore clear and less real work. Really didn't take long, and it'll be trivial to undo (even if it does touch a lot of files... it's just one line per file). | 21:32 |
| ericsnow | natefinch: right; not worth it | 21:32 |
| waigani | thumper: But I do think it's worth thinking about. AFAICS, fact that a controller is an environ is implementation detail to support the API - as you say. It shouldn't be confusing the language we use to describe the overall design. | 21:36 |
| thumper | except it shows up whenever we talk about "all environments" | 21:36 |
| thumper | and environment commands work on the controller | 21:36 |
| thumper | I definitely agree that it is worth thinking about | 21:37 |
| waigani | thumper: I think it comes down to implementation details vs design. Are those details leaking into the design? If so, do we separate them (e.g. never speak of a "controller environment", rename env cmds on the controller to controller cmds) or do we update the design (e.g. always talk about "controller environment"). | 21:44 |
| natefinch | katco, ericsnow: I think we need to talk about dependency injection for the purpose of testing, re: http://reviews.vapour.ws/r/3021/#comment18995 | 21:45 |
| thumper | I don't think so... I think it depends a lot on context | 21:45 |
| thumper | you are either talking about the controller environment, and dealing with environment *things* | 21:45 |
| katco | natefinch: it's been queued for awhile. i have half an hour if everyone else does | 21:45 |
| thumper | or you are talking about the controller in a hosting capacity | 21:45 |
| thumper | the controller environment doesn't host environments | 21:45 |
| natefinch | katco: I have 15 minutes, which is probably not going to be enough. Tomorrow? | 21:46 |
| thumper | but talking about environment things on the controller doesn't make sense really either | 21:46 |
| katco | natefinch: tomorrow is meeting day for me =/ | 21:46 |
| natefinch | katco: I'm willing to sacrifice my 1:1 time to talk about this. I think it's worthy. | 21:46 |
| katco | natefinch: we can do that if everyone is available | 21:47 |
| waigani | thumper: ah okay. In a similar way you could talk about a controller machine? | 21:47 |
| thumper | I'm not sure you would... | 21:47 |
| thumper | you may talk about an API server machine | 21:48 |
| thumper | but a controller machine doesn't really make sense | 21:48 |
| waigani | so what do we call what we use to call the state server machine? | 21:48 |
| thumper | a machine in the controller environment is ok... | 21:48 |
| ericsnow | katco, natefinch, wwitzel3: I'm game | 21:48 |
| thumper | personally I tend to still call them state server machines | 21:49 |
| katco | ericsnow: natefinch: wwitzel3: invite in the mail | 21:49 |
| thumper | :) | 21:49 |
| waigani | haha | 21:49 |
| natefinch | thumper, waigani: FWIW, I think that "talking out loud" about the new names for things is a very good way to nail down gaps in the vocabulary, and exposes places where names may be misleading. | 21:49 |
| natefinch | like state server machine :) | 21:50 |
| thumper | agreed | 21:50 |
| thumper | definitely think it needs a new name :) | 21:50 |
| thumper | like: Bob | 21:50 |
| waigani | lol | 21:50 |
| natefinch | +1 ship it | 21:50 |
| thumper | I used to use Eric all the time, from Eric the Viking | 21:50 |
| thumper | but I feel I have to stop that now that we have ericsnow | 21:50 |
| natefinch | way to mess it up ericsnow | 21:51 |
| ericsnow | mwahaha | 21:51 |
| thumper | ericsnow: how about you change your name? | 21:51 |
| thumper | perhaps "snowman" | 21:51 |
| === ericsnow is now known as bobsnow | ||
| === bobsnow is now known as ericsnow | ||
| cherylj | ericsnow: for this branch: http://reviews.vapour.ws/r/3067/ Did you just do a rename for internal to private? | 21:51 |
| ericsnow | nah :) | 21:51 |
| ericsnow | cherylj: yep, that's it | 21:51 |
| natefinch | snowman sorta sounds like the codename for a mobster | 21:53 |
| cherylj | ericsnow: it's just showing up in a not-clear way in RB and github. Like it shows that you modified something in internal/client/unitfacade.go, but it doesn't show that you deleted any of the old files | 21:53 |
| thumper | natefinch: haha | 21:53 |
| ericsnow | cherylj: yeah, GH is confused and RB isn't helpful when it comes to renames | 21:54 |
| natefinch | I heard he snowed someone just for looking at him wrong. | 21:54 |
| cherylj | bleh. fun. | 21:54 |
| === natefinch is now known as natefinch-af | ||
| === natefinch-af is now known as natefinch-afk | ||
| ericsnow | cherylj: in case it helps, I rebased that PR so GH is showing the changes correctly now | 22:08 |
| cherylj | ah yeah, that helps | 22:10 |
| cherylj | ericsnow: there were just a couple things | 22:10 |
| ericsnow | cherylj: thanks | 22:10 |
| mup | Bug #1513236 opened: Cannot build trusty armhf with go1.2 on from master <armhf> <blocker> <go1.2> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1513236> | 22:12 |
| thumper | who loves shitty rename branches? http://reviews.vapour.ws/r/3072/diff/# | 22:25 |
| ericsnow | katco: FYI, I have the payloads-into-master patch up | 22:26 |
| * ericsnow raises hand | 22:29 | |
| katco | ericsnow: nice :) | 22:30 |
| katco | ericsnow: go ahead and merge your payloads branch into master | 22:48 |
| ericsnow | katco: k | 22:48 |
| ericsnow | katco: alas, master is blocked | 23:01 |
| katco | ericsnow: doh | 23:01 |
| davecheney | katco: ericsnow this may very well be an upstream bug | 23:10 |
| davecheney | looking at the ci dashboard | 23:10 |
| ericsnow | davecheney: k | 23:10 |
| davecheney | no builds for the crypto repo have run on arm for months | 23:10 |
| davecheney | and the go team turned off build faiure notifications a while back | 23:10 |
| davecheney | so yeah, there is that | 23:11 |
| davecheney | let me quickly check something | 23:11 |
| ericsnow | davecheney: thanks | 23:11 |
| davecheney | builds on go 1.5 | 23:12 |
| davecheney | we might have to chalk this one up to go 1.2 being unsupported | 23:12 |
| davecheney | katco: please unblock the build | 23:12 |
| davecheney | we cannot fix this | 23:12 |
| davecheney | it is blocked on other work which has been scheduled | 23:12 |
| davecheney | but has not reasonable ETA that can be used to unblock the build | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!