[00:06] thumper: why does var b []byte != var b = []byte{} ? [00:06] one is nil, one is not [00:07] right, but was that the question ? [00:07] I think that either they should be equal, or be visually different [00:07] no [00:07] the question is why they have the same representation [00:07] a nil string slice is output as []string(nil), but a nil byte slice is shown as []byte{} [00:08] empty string slice is []string{}, empty byte slice is []byte{} [00:08] nil slice != empty slice [00:08] so they shouldn't have the same representation [00:08] made debugging very confusing [00:08] probably just how fmt decides to print them [00:08] thumper: if you're looking for someoone to blame [00:08] blame gocheck [00:09] davecheney: see the play things above [00:09] they don't use gocheck [00:09] if anything, I'll blame the "fmt" library [00:09] hence, go bug? [00:10] certainly an inconsistency [00:11] id' still like to blame gocheck for this [00:11] because the chance of chaning it in the go runtime are approximatly 0 [00:12] you can't just blame a different library because core won't change [00:12] that's dumb [00:12] yup, i'm dumb [00:12] surely it could be filed as a bug [00:12] absolutely [00:12] and fixed during the next *we'll break things* type release [00:13] to make things more consistent [00:34] lunch time... [00:49] axw: ping [01:26] https://bugs.launchpad.net/juju-core/+bug/1218329 [01:26] <_mup_> Bug #1218329: Update default environment.yaml for Azure to use Precise for default-series [01:27] do we need to hold off 1.13.3 for this bug ? [01:27] davecheney: i think we should, but that's IMHO [01:28] wallyworld: ack [01:29] davecheney: it's a trivial patch, so we can do it today once confirmation of the stream is done [01:32] davecheney: would you prefer if I hold off merging manual provisioning? [01:34] axw: what are the changes it'll bugger up azure [01:34] if it's > 5%, then yes [01:35] davecheney: I would say 0%, but my thinking may be biased [01:36] :) [01:36] your call [01:37] https://canonical.leankit.com/Boards/View/103148069 [01:37] i;m worried about all the stuff in review [01:37] davecheney: worried why? [01:38] worred that we need them in for 1.14? [01:38] three cards there that I wanted to see land [01:38] MP, azure stuff, and the bug fix for version formatting [01:38] there is nearly as much stuff in review as has landed [01:39] davecheney: I can and will get MP in right now. I'm confident it's not going break anything else [01:39] axw: sgtm [01:39] dunno anything about the others I'm afraid [01:50] axw: for manually provisioning, this requires a working environment [01:50] ie, you cannot manually provision a bootstrap node [01:50] davecheney: correct [01:51] axw: if my bootstrap node is in amazon, can I manually provision a machine in my local lan ? [01:51] davecheney: yes, if it can route to the bootstrap node [01:51] hmm [01:51] this sounds icky [01:51] i'd like to not mention this in the release notes [01:51] or we'll get bollocked by jorge again [01:51] davecheney: fair enough, it is a bit raw [01:52] alternatively, if you want to write war and peace [01:52] go for it [01:52] nah leave it out for now [01:52] but I vote for putting a card in leankit to properly document it [01:52] and leaving it for 1.15.0 [01:52] agreed [01:59] axw: https://bugs.launchpad.net/juju-core/+bug/1218329 [01:59] <_mup_> Bug #1218329: Update default environment.yaml for Azure to use Precise for default-series [01:59] do you have an environemnt to test this change >? [02:00] davecheney: yep I'll give it a whirl [02:00] ta [02:01] azure called me up yesterday morning about the account I created ... that was slightly weird [02:02] axw: yeah, they'll call you a few times [02:03] i told the guy i was only using it for a test and had no interest in paying for their service [02:03] he soundded confused [02:03] and was still confused when he called me a week later and asked the same thing [02:03] lol [02:12] davecheney: so far, not so good... looks like the SSH keys aren't setup properly [02:12] also - I couldn't use released, had to use daily [02:12] axw: ok, play with it a bit more, otherwise move the ticket to 1.15.0 [02:13] ok [02:13] once we have a 1.14 series we can backport fixes [02:13] but waiting on a working precise image could take longer than we have [02:13] so screw it [02:13] we can do a point release into 1.14 [02:31] * davecheney waves to robbiew [02:31] davecheney: hang out with us! [02:31] jcastro: but it's my special time with ubu hulk [02:31] oh dang [02:31] davecheney: on my way...got distracted with other work stuff [02:31] ok, after? [02:32] jcastro: sure thing [02:32] we're just hanging out [02:32] jcastro: shiiit, what is this, a party ? [02:32] didn't know it was Thor <-> Hulk bonding time [02:33] davecheney: nah, did a live juju upgrade on discourse so we had to do it post-work and late [02:33] jcastro: DC characters need love too [02:33] and we had some feedback, but whatever, nothing that can't wait [02:33] from now on you are SOLMON GRUNDY [02:34] jcastro: wtf you doing up? [02:34] robbiew: upgrading services with less than a minute downtime? :) [02:34] nice [02:34] next time we're doing cascading upgrades .... [02:34] not to brag or anything [02:35] * jcastro brags because he's backed by marcoceppi. [03:16] damnit! [03:16] This party is over... [03:16] But you can start a new one. [03:17] some party [03:24] davecheney: let's party tomorrow? [04:04] axw: ping [04:04] wallyworld: hoy [04:04] i just saw your mp for genersting tools metadata and have a question or two [04:05] 1. i'd like the functionality to generate the json separated out into a separate method, as i need to use it in another context [04:05] i want to pass a list of ToolsMetdata and get back the index and product json [04:05] i need this for tests [04:05] ok- I can move it to environs/tools? [04:06] also, the Boilerplate() method can be updated to use this also [04:06] instead of go templates [04:06] ok [04:06] i think environs/tools sounds ok [04:06] 2. i'm not sure why you are writing to a storage and not just to disk [04:07] we don't need to generate the metadata into a public bucket [04:07] oops [04:07] :) [04:07] we need to read tools from somewhere (currently all we have is the public bucket), but the metadata needs to go either to disk locally or uploaded somewhere [04:08] would people not want to host it in their private swift storage or whatever? [04:08] so for now, just have the command take a dest dir (default to .juju like for imagte metadata) [04:08] yes, private storage perhaps, but not public [04:09] so you could use a storage abstraction as yuo have done [04:09] yeah I was thinking "public" as in shared within a private org [04:09] not the official public one [04:09] ah ok [04:09] but anyway [04:09] it can go to disk and they can do that [04:09] manually [04:09] well, the storage abstraction used works [04:10] but use the env.Storage() [04:10] not env.PublicStorage() to write to [04:10] okey dokey [04:11] it would be great to land this today if we could as i have stuff queued up behind it - i have tests where i need to generate tools metadata and then read it back [04:11] will get onto it now [04:12] thanks :-) it doesn't have to be perfect straight up cause we won't advertise it, it will mainly be for us internally [04:13] axw: with the metadata generation, if the new method could be such that i get the json back as a string for index and product, that would be good. then there would be another new method to write those strings to files [04:14] or a reader or whatever [04:14] wallyworld: nps, easy enough [04:14] i just need to hold the data in memory for a http proxy class to use [04:14] thanks [04:51] wallyworld: I think I just found a problem... paths should be relative to the base URL right? i.e. "juju-1.12.0-precise-amd64.tgz", and not "tools/juju-1.12.0-precise-amd64.tgz"? [04:51] since the base URL includes /tools/ [04:52] yes, paths should be relative to the base url [04:52] i envisiage tarballs will be in releases/ [04:52] ie http://juju.canonical.com/tools/releases [04:52] ok [04:53] and metadata in http://juju.canonical.com/tools/streams/v1 [05:03] * wallyworld has to go do school pickup [05:03] wallyworld: updated. I haven't yet added tests to environs/tools. Haven't yet updated boilerplate. It's still using storage, I will change that now. [05:03] axw: ok, thanks, bbiab [05:03] cya [05:23] * thumper slogs through fixing shit [05:38] morning fwereade [05:38] fwereade: around 7:30am? [05:38] thumper, heyhey [05:38] thumper, yeah [05:39] got time for a quick chat before I EOD? [05:39] and EOW [05:39] sure [05:39] and EOM [05:40] fwereade: https://plus.google.com/hangouts/_/ebc7ddf59bb207399b6ce7ab7ccd391a4fd9fede?hl=en [06:02] night all [06:34] mornin' all [06:41] axw: hi, i made some more comments. i hope they make sense === tasdomas_afk is now known as tasdomas [06:45] wallyworld: thanks, I'll have a look in a sec [06:45] axw: np. i have to take the dog for a quick walk before he bites me, i'll check back in soon [06:45] hehe [06:45] no worries [07:17] wallyworld: `There's little point using an env to read the tools - the tools are readily [07:17] accessible directly from "https://juju-dist.s3.amazonaws.com/" (see synctools)` [07:18] environs/sync does use the env's storage? [07:26] axw, it's done in sync-tools -- there's a storage interface that talks to juju-dist directly over http [07:26] ah [07:26] fwereade: thanks [07:26] axw, and also allows for reading in from a dir, which I think wallyworld mentioned, but I barely skimmed that CL I'm afraid [07:50] axw: sync uses the env storage to write to the private bucket, so the tools are available for that env [07:55] wallyworld: yeah I just missed the whole bit about newFileStorageReader/ec2.NewHTTPStorageReader [07:56] axw: is anything unclear with my (brief) comments? [07:56] wallyworld: nope, makes sense [07:56] just updating and testing now [07:56] cool, thanks [07:57] the main business logic is to (somehow) get a list of tools and generate metadata [07:57] yup [07:57] this will be used by sync tools and tests, plus the generate command for devs/prototyping [07:57] I've moved the fileStorageReader to environs/filestorage [07:57] will use that and the ec2 thing inside toolsmetadata [07:58] and update sync accordingly [07:58] ok. i'm wondering is we want a "wget" reader also, one that takes a http url if you know what i mean [07:59] maybe not [07:59] let's wait till we need it [08:00] i'm hoping medium term when we have the proper tools repository that we won't need the reader abstraction [08:00] since we can access the official tools and metadata directly using wget [08:00] and not via a s3 bucket [08:00] yeah, no need to list then [08:01] wallyworld: you want me to move ItemCollection.UnmarshalJSON to json.go? so, I should move all the structures there? [08:01] so when we do that, we should be able to have an abstraction that takes a url, either file:// or http:// to get the tools etc [08:01] in environs/simplestreams [08:01] axw: i 'd like all the json related stuff out separate [08:02] ok [08:02] so as not to obscure the core simplestreams lofic [08:02] we did something similar in goose [08:02] see goose.nova package [08:50] fwereade: ping [08:50] rogpeppe, pong [08:51] fwereade: i've been looking at the config stuff, and wondering about firewallmode==default [08:51] fwereade: the idea is that a given environment can choose its own default, right? [08:51] rogpeppe, I *think* so, yes [08:51] fwereade: i can't see how that can happen currently [08:51] rogpeppe, doesn't surprise me at all [08:52] fwereade: the code *looks* as if it's trying to go in that direction [08:52] fwereade: but swerves at the last moment [08:52] rogpeppe, haha [08:52] rogpeppe, if that's not what it's for, your guess is as good as mine [08:52] fwereade: in particular, in config.New: [08:52] // Default firewall mode is instance. [08:52] if c.FirewallMode() == FwDefault { [08:52] c.m["firewall-mode"] = string(FwInstance) [08:52] } [08:52] ha [08:52] rogpeppe, I think TheMue may have been involved there [08:53] fwereade: so AFAICS no provider will ever see FwDefault [08:53] rogpeppe, he might remember [08:53] rogpeppe, I think you're right [08:53] fwereade: i'm sorely tempted to lose the whole idea [08:54] fwereade: and just let a given provider ignore the firewall mode if it can't deal with it [08:54] * fwereade shrugs, and doubts that's any worse than what we currently have [08:55] rogpeppe, the whole firewalling story is madness anyway IMO [08:55] fwereade: BTW i'm testing a branch which cleans up the config prior to moving forward with environment attr storage, which changes config.New to this: http://paste.ubuntu.com/6043287/ [08:56] rogpeppe, it's probably not too many steps from sanity, but plotting those steps makes me confused [08:56] fwereade: i'm hoping/assuming you will wholeheartedly approve [08:57] wallyworld: there's a bunch of tests I'm not going to be able to complete today. if you wanted this stuff landed to unblock you, I can do so and follow up with tests on Monday [08:57] axw: it's ok, i can wait. i'm currently modifying another upstream branch [08:57] wallyworld: okey dokey [08:57] rogpeppe, that looks pretty sexy to me :) [08:57] we can get the next release out first anyway [08:58] fwereade: the next step is to pass a config.Defaulting flag to EnvironProvider.Prepare and EnvironProvider.Open [08:58] axw: maybe push what you have and i'll take a look over the w/e [08:58] fwereade: to enable providers to be similarly strict about env vars [08:58] rogpeppe, nice [08:59] wallyworld: done [08:59] thanks :-) [08:59] will look a bit later [08:59] wallyworld: just missing tests on environs/filestorage (never were any explicit ones), and the new marshalling stuff in environs/tools [08:59] thanks [09:00] wallyworld, btw, I'm having some persistent difficulty mapping simplestreams cloud info <-> juju concepts -- would you be free for a chat about it after the standup? [09:00] we are also blocked on IS getting the tools repository set up [09:01] wallyworld: I generated metadata for all the tools in S3 earlier, if you want the JSON files for anything... [09:01] fwereade: sure. i'll be up to my 5th drink by then, should be fun :-) [09:02] axw: sure, send them my way, thanks :-) [09:03] wallyworld, it'll probably help ;p [09:03] fo :-) [09:54] everyone should try the go coverage tool to check test coverage - it's awesome! [09:55] for example, see this output: http://paste.ubuntu.com/6043486/ (save the text as html and open it in your browser) [09:56] wallyworld, btw, when you're around, I was wondering if you knew what "crsn" was meant to stand for :) [09:56] fwereade: cloud region short name [10:01] rogpeppe, nice and shiny, indeed [10:02] rogpeppe, I have seen far worse coverage output ;p [10:02] fwereade: BTW, speaking of test coverage, do you know what happened to the tests for RelationUnitsWatcher ? [10:02] fwereade: there appear to be none at all [10:04] rogpeppe, I'm not that surprised, it's basically an implementation detail of RelationScopeWatcher [10:04] fwereade: it is used directly by the uniter though [10:06] fwereade: and none of its code is covered by the state tests (verified with the shiny new coverage tool) [10:08] fwereade: i suspect the test coverage loss was an inadvertent consequence of https://code.launchpad.net/~fwereade/juju-core/state-relationunit-move/+merge/144747 [10:44] rogpeppe, sorry, meeting pushed that conversation out of my mind [10:44] fwereade: np [10:49] rogpeppe, looks like you're right, and I suck [10:49] fwereade: happens to all of us :-) [10:49] rogpeppe, indeed, but thanks for catching it [10:50] rogpeppe, I suspect I zoned briefly out of the distinction between Watch and WatchScope and, boom, splat [10:51] fwereade: i'm wondering if we could do something with the coverage tool to automatically detect loss of test coverage [10:51] fwereade: something to keep in mind anyway [10:52] rogpeppe, that would be very nice, yeah [10:52] rogpeppe, tech-debt bug? [10:52] fwereade: https://bugs.launchpad.net/bugs/1218362 [10:52] <_mup_> Bug #1218362: state.RelationUnitWatcher is not tested

[10:53] rogpeppe, ah, I meant for the coverage tool [10:53] fwereade: oh, i see [10:53] fwereade: yeah, i'll do that [10:56] fwereade: https://bugs.launchpad.net/juju-core/+bug/1218834 [10:56] <_mup_> Bug #1218834: There's no way to easily detect loss of test coverage

[11:33] rogpeppe, standup [11:34] fwereade: "There is a problem with connecting to this video call. Try again in a few minutes" [12:27] evilnickveitch: it occurs to me that your document says to sync docs with the reality of 1.12 ... does that mean we shouldn't document stuff that is later than 1.12? For example, windows support is not in 1.12 [12:27] natefinch: if we release 1.14, presumabley we'd update that to read '1.14' [12:28] natefinch, i think in this case we can document it and work out what notes and info we need to provide later. at some point in the future we will have different versions of the docs which will make this easier [12:28] having a doc 'feature' branch for dev stuff that will be in next stable seems sane [12:28] then we just merge that to doc trunk when we do the release [12:28] mgz, indeed [12:29] we need a good base to start from - i think we need to be at a point where we are not adding loads of stuff to the stable docs before we start doing that [12:48] mgz, fwereade, rogpeppe: just had a thought - should we refrain from creating a "local" environment section in environment.yaml on Windows, since it can't possibly work there? Or maybe create it commented out, with a comment that it doesn't work on Windows. [12:50] TheMue: ^^^ since you're writing docs on the local provider - might be good to mention it doesn't work on Windows :) [12:54] natefinch: oh, yes, good hint, and it won't work on a mac [12:54] TheMue: yep [12:55] natefinch: only in a vmware image running linux ;) [13:39] natefinch, good idea, thank you [13:43] hmm, my smoothie has fermented [13:50] fwereade_: iirks [13:57] How often does the store update personal branches? [13:58] nvm, gui cache issue [14:29] fwereade_, mgz, natefinch, jam, TheMue: trivial CL, enabling some tests that were not hooked in: https://codereview.appspot.com/13428043/ [14:30] rogpeppe, I'll do that if you'll do https://codereview.appspot.com/13401045 :) [14:31] rogpeppe, LGTM [14:31] fwereade_: likewise [14:32] : [14:32] rogpeppe, cheers [14:32] nice backscratching :) [14:33] rogpeppe: LGTM from my side too [14:33] mgz: always good when you have an itch === tasdomas is now known as tasdomas_afk [15:01] fwereade_: you around? [15:02] mramm, yeah, what can i do for you? [15:02] I am wondering if we can setup a "what does 2.0 mean" meeting for the beginning of next week [15:03] mramm, sure, that sounds good [15:03] mramm, a bit after standup on monday perhaps? [15:03] I'm thinking about timelines, and thinking that we may want to manage the scope of a 2.0 release a bit more [15:04] yea, that works for me [15:04] mramm, that was put with admirable delicacy btw [15:05] I will want to include Gary in that conversation [15:08] fwereade_, ping [15:12] hazmat, pong [15:15] fwereade_, trying to debug the slowness that's been reported on the list [15:16] do you have a minute to discuss on g+? [15:16] hazmat, thank you kindly :) [15:16] hazmat, in a moment I think [15:20] hazmat: a fair bit of it can just go from status, when it doesn't need to do anything other than query state (over the api) [15:21] mgz, right, i could make a fast status impl right now just using the allwatcher, not quite the same data. one of the issues in their status output is the amount of garbage they've got in terms of machines [15:21] that are missing, pending, etc. [15:21] and helping them garbage collect [15:22] right, there's always an issue inside the reported issue :) [15:22] mgz, status in the api is all nesc for correctness for deployer [15:22] since watch api is eventually consistent [15:22] i took a look at the sprint unfortunately the status code has several embedded panics [15:24] s/all/also [15:57] hmm.. bootstrapping on ec2 takes a very long time [15:57] for the command to complete === TheRealMue is now known as TheMue [16:42] bbl [18:01] is juju trunk supposed to build? [18:01] provider/ec2/ec2.go:131: inst.Instance.IPAddress undefined (type *ec2.Instance has no field or method IPAddress) [18:09] hazmat: i think you need to do go get -u launchpad.net/goamz/ec2 [18:10] rogpeppe, thanks [18:11] fwereade_, natefinch, TheMue, anyone else: , here's a large but trivial CL, just moving test code around: https://codereview.appspot.com/13348049/ [18:22] hazmat: for the record, there's no a file in the juju-core root (dependencies.tsv) that declares the revision numbers of dependencies [18:27] s/no a/now a/ [18:30] hmm ec2 Storage().RemovaAll() takes 50s of 1m3s for destroy-environment [18:37] hazmat: hmm, how many tools were uploaded? [18:38] rogpeppe, 1 [18:39] hazmat: that's really odd [18:39] rogpeppe, it was an empty environment, nothing deployed [18:39] hazmat: i mean, i know s3 is slow, but... [18:41] rogpeppe, do we even need to remove them? [18:41] rogpeppe, i mean minus provider-state, its basically just cache [18:41] hazmat: it tries to remove all trace of an environment when it's destroyed [18:41] except security groups [18:42] hazmat: unfotunately that's not possible [18:42] hazmat: (i tried) [18:42] rogpeppe, right.. but its not clear that we're adding significant value destroying the bucket vs the time it takes [18:42] hazmat: i've never seen it take anywhere near that long [18:43] hazmat: does this happen every time for you? [18:44] rogpeppe, atm yes, i'm still instrumenting, but about to switch out for a meeting [18:46] rogpeppe, bootstrap also takes quite a while [18:46] hazmat: with --upload-tools ? [18:46] rogpeppe, no [18:48] hazmat: hmm, it's not bad for me if i'm not uploading tools [18:48] rogpeppe, 2m9s for me [18:48] rogpeppe, define not bad? [18:50] hazmat: 26s for me [18:50] rogpeppe, which provider? [18:50] hazmat: ec2 [18:51] rogpeppe, hmm.. region? [18:51] hazmat: us-east, i think [18:51] hazmat: yeah [18:52] i'm working against us-west-2 (us-east is literally my backyard) [18:54] hazmat: part of the slowness is timeouts for eventual consistency. it looks like if you haven't uploaded any tools, we time out, because the bucket doesn't exist and we poll just in case it was only created a moment ago [18:54] hazmat: that's 5s of my time [18:54] hazmat: there's another 10s gap where i'm not sure what it's doing [18:54] gotta run for a meeting.. [18:54] hazmat: k [18:55] rogpeppe, it does look like the destroy time was an abberation, i'm getting closer to 30s averages now. [18:55] hazmat: ok. but that's still a bit rubbish [18:56] hazmat: i'd like to add trace messages that print all traffic to and from servers [18:56] hazmat: so we can see just what's going on [18:56] rogpeppe, here's my instrumentation on destroy fwiw http://pastebin.ubuntu.com/6045232/ [18:57] hazmat: looks like there might be 15s worth of eventual-consistency waiting in there [18:58] hazmat: or maybe 20s [18:58] rogpeppe, should destroy-env care about eventual consistency? [18:59] hazmat: the difficulty is writing live tests that pass consistently [18:59] hazmat: if we've just created some storage, then try to delete it, the operation often fails [18:59] hazmat: unless we try for a while [18:59] hazmat: i frickin' hate it [18:59]