| wallyworld_ | sinzui: i'll have code using the new stream based tarball directories ready today - are you able upload tarballs to "juju/tools/released" so that sync-tools will work? no urgency, just letting you know | 00:15 |
|---|---|---|
| sinzui | wallyworld_, I cannot upload anything to Jerff | 00:15 |
| sinzui | wallyworld_, I control a script that can get assets from Lp | 00:15 |
| sinzui | We have limited powers, but we will be changing this because Lp wont be providing win-agents that we make. We need a new delivery mechanism to Jerff or a better pickup mechanism | 00:16 |
| wallyworld_ | ok, no worries. i can still commit the code - it will still find tools using the existing index files; i doubt people will care if sync-tools on trunk is broken for a few days | 00:17 |
| sinzui | wallyworld_, I misunderstood. we can NEVER replace an agent. We can remove if it is malign. That is why I keep hammer the point about controlling the archives. Alarms will sound and trees will be reverted if a checksum ever changes. | 00:21 |
| sinzui | wallyworld_, Until juju agent version can state their origin or build or packaging version, we will never be able to fix an agent | 00:22 |
| wallyworld_ | true. that's somewhat orthogonal to the current changes though isn't it? | 00:23 |
| sinzui | wallyworld_, it is. sync-tools cannot be fixed by steal, we require a release | 00:23 |
| sinzui | stealth | 00:23 |
| sinzui | nor ca we fix a broken ppc64el witha rebuild | 00:24 |
| wallyworld_ | sure. it's just that now sync-tools needs to be taught that it needs to look in a different place to find the tarballs | 00:24 |
| wallyworld_ | it currently looks in a "releases" dir | 00:24 |
| wallyworld_ | it needs to look in a dir named after the stream | 00:24 |
| sinzui | right | 00:24 |
| wallyworld_ | that's the change i'm making and which means sync-tools will be broken until tarballs are placed in "released" on streams.canonical.com | 00:25 |
| wallyworld_ | everything else about the changes i'm doing doesn | 00:25 |
| wallyworld_ | 't affect any thing | 00:25 |
| wallyworld_ | since it's just teaching generate-tools to write the correct metadata | 00:25 |
| thumper | wallyworld_: around? | 01:34 |
| wallyworld_ | thumper: hiya, just finished standup | 01:35 |
| thumper | wallyworld_: hangout chat? | 01:35 |
| wallyworld_ | sure, use our 1:1 | 01:35 |
| thumper | kk | 01:35 |
| niedbalski | wallyworld_, could you check https://github.com/juju/juju/pull/689? I think is not a definitive fix but at least address a potential issue (http://osdir.com/ml/general/2014-06/msg03723.html) | 02:01 |
| menn0 | thumper: I'm having second thoughts about the machine-id vs machineid thing | 02:08 |
| menn0 | thumper: there's lots of places where machineid is already in use | 02:08 |
| thumper | like where? | 02:09 |
| menn0 | networkinterfaces | 02:09 |
| thumper | ugh | 02:09 |
| menn0 | unit | 02:09 |
| thumper | ok, I'll suffer though with machineid | 02:09 |
| menn0 | :) | 02:10 |
| wallyworld_ | niedbalski: looking now, sorry just finished meeting | 02:35 |
| menn0 | thumper: the machines env uuid branch has merged \o/ | 02:40 |
| thumper | w00t | 02:40 |
| * thumper calls it an early day | 02:48 | |
| thumper | lots of extra hours Wed and Thu | 02:48 |
| thumper | have a good weekend everyone | 02:48 |
| thumper | it is a long weekend here in NZ, so see folks on Tuesday | 02:48 |
| thumper | davecheney: no standup monday | 02:48 |
| thumper | davecheney: or 1:1 as it is Labour day here | 02:48 |
| * thumper goes to delete items from the calendar | 02:49 | |
| davecheney | thumper: ack | 02:49 |
| davecheney | no problem | 02:49 |
| davecheney | nothing really to report anyhow | 02:49 |
| davecheney | enjoy your 8 hour work day celebration | 02:49 |
| thumper | \o/ | 02:51 |
| menn0 | davecheney: howdy. I wanted to chat to you about the state / apiserver dependency unpicking you're working on. hangout? | 02:58 |
| davecheney | menn0: sure | 03:02 |
| menn0 | davecheney: standup hangout? | 03:03 |
| davecheney | kk | 03:03 |
| menn0 | davecheney: i'm there now | 03:04 |
| davecheney | https://lists.ubuntu.com/archives/juju/2014-October/004434.html | 06:28 |
| mattyw | morning everyone | 07:50 |
| TheMue | axw: done | 07:55 |
| TheMue | mattyw: morning | 07:55 |
| mattyw | TheMue, good morning | 07:55 |
| axw | TheMue: thanks | 08:13 |
| TheMue | axw: yw | 08:17 |
| dimitern | morning all | 08:52 |
| fwereade | so, it turns out small boats can be quite stressful in 50 km/h winds | 08:53 |
| fwereade | dimitern, hey dude | 08:53 |
| Spads | swallows and amazons forever | 08:53 |
| TheMue | dimitern: morning | 08:53 |
| dimitern | fwereade, TheMue, hey guys | 08:56 |
| voidspace | dimitern: morning | 08:58 |
| voidspace | TheMue: morning | 08:58 |
| voidspace | fwereade: yow, you made it back safely though... | 08:58 |
| fwereade | voidspace, yeah, it was really a very short crossing | 08:58 |
| fwereade | voidspace, still a bit much tbh | 08:58 |
| voidspace | fwereade: are you away from home - or just taking perilous sea crossings in Malta? | 08:59 |
| dimitern | morning voidspace | 08:59 |
| fwereade | voidspace, it's laura's half term, we had a couple of days on comino | 09:00 |
| fwereade | voidspace, tiny island between malta and gozo | 09:00 |
| voidspace | fwereade: ah, but you've been working from there? | 09:00 |
| voidspace | At least you've been online... | 09:00 |
| fwereade | voidspace, yeah | 09:00 |
| dimitern | we had a great 14.10 release lunch yesterday, worthy of the 10y anniversary :) | 09:00 |
| fwereade | voidspace, nice to have a change of scene | 09:00 |
| fwereade | dimitern, nice :D | 09:00 |
| voidspace | fwereade: heh, cool - although you should have taken a proper break :-) | 09:00 |
| fwereade | voidspace, ehh, I've actualy been programming this week | 09:01 |
| voidspace | fwereade: looking it up on wikipedia, looks lovely | 09:01 |
| fwereade | voidspace, it's tremendously enjoyable and healing and all that :) | 09:01 |
| voidspace | fwereade: :-) | 09:01 |
| voidspace | dimitern: USEast region is now reporting a default vpc | 09:02 |
| voidspace | dimitern: did we request the change? | 09:02 |
| voidspace | anyway, it's good - makes testing this code less of a pain | 09:03 |
| dimitern | voidspace, which account is this? | 09:03 |
| voidspace | dimitern: "our" account | 09:03 |
| dimitern | voidspace, ah :) ok, I'm using my own actually | 09:03 |
| voidspace | ah | 09:03 |
| dimitern | voidspace, but it's good nonetheless | 09:03 |
| dimitern | voidspace, I probably should try to use "ours" as well :) | 09:04 |
| voidspace | yeah, although I was using APSoutheast2 before USEast is easier to type ;-) | 09:04 |
| voidspace | dimitern: yeah, saves making expense claims | 09:04 |
| voidspace | dimitern: balls, I was running the wrong file | 09:06 |
| voidspace | dimitern: the default-vpc is still for APSoutheast2 | 09:07 |
| dimitern | voidspace, ah, I've done that yeah | 09:08 |
| fwereade | wallyworld_, if you're around, do you have an opinion on https://github.com/juju/juju/pull/908/files ? | 09:26 |
| wallyworld_ | looking | 09:27 |
| fwereade | wallyworld_, I still don't think I'm happy -- strikes me as a scattergun fix-windows-paths-here-and-there approach | 09:27 |
| fwereade | wallyworld_, but much of it is simplestreams related, so maybe you can set my mind at rest? | 09:27 |
| wallyworld_ | fwereade: sure, give me a few minutes and i'll look | 09:28 |
| fwereade | wallyworld_, cheers | 09:28 |
| fwereade | wallyworld_, at your leisure | 09:28 |
| wallyworld_ | fwereade: so there are 2 issues. 1. the folks who created the simplestreams metadata files on streams.canonical.com chose to use ":" in the file names. juju provides a mechanism to generate metadata files (used to upload or import metadata) and also uses ":", 2. simplestreams uses file:// and http:// urls. the file:// urls are easy to create in linux but harder in windows due to drive letters. to solve issue #1, it is essentially a | 09:50 |
| wallyworld_ | change to the filename generation; the file name is arbitrary so use "-" instead of ":", doesn't matter. for issue #2, the various places where file:// urls are generated need to account for windows. most of the places are in tests. regardless, we should be deferring any windows conversion to the system boundaries, at the places where the urls are actually used. and this is only one place i think, in the actual Fetch() method | 09:50 |
| fwereade | wallyworld_, so I'm a bit concerned about having a Storage implementation that (1) doesn't allow : in paths and (2) doesn't produce sane urls | 09:52 |
| wallyworld_ | fwereade: blame windows | 09:52 |
| wallyworld_ | it's windows that doesn't allow ":" in urls | 09:52 |
| wallyworld_ | un paths | 09:52 |
| wallyworld_ | in | 09:52 |
| wallyworld_ | we only write out simplestreams metadata in one place | 09:53 |
| wallyworld_ | in the generation utility | 09:53 |
| fwereade | wallyworld_, so ISTM that it's simply that FileStorage is (1) failing to properly encode paths such that they can be stored on windows and (2) failing to generate urls that can be used on windows | 09:53 |
| wallyworld_ | we read simplestream metadata off disk in only one place - at bootstrap when the user can supply their own (and also in tests) | 09:54 |
| fwereade | wallyworld_, IMO simplestreams issues are completely secondary | 09:54 |
| fwereade | wallyworld_, we can make a point of generating simplestreams dirs that don't have :s in | 09:54 |
| fwereade | wallyworld_, but this is completely separate from the fact that FileStorage doesn't work on windows | 09:54 |
| fwereade | wallyworld_, and we need FileStorage to be able to be a Storage, so we can use it as a reasonablereplacement for the real simplestreams sources | 09:55 |
| fwereade | wallyworld_, but for now there are plenty of simplestreams sources that do include :s | 09:55 |
| wallyworld_ | fwereade: yes, that's what i was referring to when i talked about doing the conversion at system boundaries | 09:56 |
| fwereade | wallyworld_, yeah | 09:56 |
| wallyworld_ | fwereade: the sources that include ":" don't matter | 09:56 |
| wallyworld_ | these are urls | 09:56 |
| wallyworld_ | they are fine | 09:56 |
| fwereade | wallyworld_, yeah, exactly | 09:56 |
| fwereade | wallyworld_, the problem is the FileStorage is shite on windows | 09:56 |
| wallyworld_ | it is *only* the generation utility | 09:56 |
| fwereade | wallyworld_, and we need to fix that | 09:56 |
| wallyworld_ | and the tests | 09:57 |
| fwereade | wallyworld_, and then *separately* we can fix the metadata plugin | 09:57 |
| wallyworld_ | there are lots of tests that write out simplestreams files | 09:57 |
| wallyworld_ | and then substitute a file:// url for the real http:// url | 09:57 |
| fwereade | wallyworld_, but what we're seeing right now is a broken test framework, because FileStorage doesn't work on win | 09:57 |
| wallyworld_ | yes | 09:57 |
| fwereade | wallyworld_, so IMO the only reasonable thing to do is to fix the test framework | 09:57 |
| wallyworld_ | i'd look to file the FileStorage abstraction | 09:58 |
| fwereade | wallyworld_, ok, cool, I think we are aligned here | 09:58 |
| wallyworld_ | so that we deal with ":" etc internally | 09:58 |
| wallyworld_ | fwAH HANG ON A SEC | 09:59 |
| wallyworld_ | sorry capslock fail | 09:59 |
| wallyworld_ | fwereade: the issue is, that we use http.Get() | 09:59 |
| wallyworld_ | and file:// urls | 09:59 |
| wallyworld_ | so there's no real file storage abstraction as such. it is an abstraction based on getting froma url | 09:59 |
| wallyworld_ | trouble is, on windows, the file:// urls are broken | 10:00 |
| wallyworld_ | and so http.Get fails | 10:00 |
| wallyworld_ | so we would want to use a helper for the url getter | 10:00 |
| wallyworld_ | that converts the file:// urls on windows | 10:01 |
| wallyworld_ | the uniform use of http.Get makes the fetching of file content agnostic to file and http urls | 10:01 |
| fwereade | wallyworld_, if FileStorage can't generate URLs that work, it needs to start doing so | 10:04 |
| fwereade | wallyworld_, if that means running an http server, it should do that | 10:04 |
| fwereade | wallyworld_, and then we can drop the foul file://-handler haclk entirely | 10:04 |
| fwereade | wallyworld_, AIUI, it's only agnostic because we register a handler for file:// urls | 10:05 |
| fwereade | wallyworld_, so, yeah, hacking up the file:// handler in windows would be another way to do it | 10:06 |
| fwereade | wallyworld_, but AFAICS it's still all down to FileStorage | 10:06 |
| fwereade | wallyworld_, it doesn't Put properly | 10:06 |
| fwereade | wallyworld_, and it doesn't URL properly | 10:06 |
| fwereade | wallyworld_, and so it's not a Storage | 10:06 |
| fwereade | wallyworld_, and so it needs to be fixed | 10:07 |
| wallyworld_ | the Fetch mechanism uses http.Get, that's why file:// urls were introduced, so the simplestream.Fetch() could deal with a url based abstraction | 10:10 |
| wallyworld_ | file:// is a valid url schema | 10:10 |
| wallyworld_ | but yeah, what follows differs on wndows vs linux | 10:10 |
| fwereade | wallyworld_, sure -- but if we're not capable of generating file:// urls that work, we can't reasonably use them, can we? | 10:11 |
| wallyworld_ | we can use a helper - MakeFileURL(path) | 10:11 |
| wallyworld_ | different implementaion on windows vs linux | 10:11 |
| fwereade | wallyworld_, that's fine by me, because it stays inside FileStorage | 10:11 |
| wallyworld_ | instead of "file://" + path | 10:12 |
| wallyworld_ | which is used now | 10:12 |
| fwereade | wallyworld_, what I care about is that FileStorage keeps working like an actual Storage | 10:12 |
| fwereade | wallyworld_, although | 10:12 |
| fwereade | wallyworld_, honestly | 10:12 |
| fwereade | wallyworld_, simplestreams and Storage have an impedance mismatch *anyway* | 10:12 |
| wallyworld_ | the file storage part in tests is file, so long as the file names use "-" | 10:12 |
| fwereade | wallyworld_, there's no guarantee that Storage.URL() results have any relationship to the underlyingpaths | 10:13 |
| fwereade | wallyworld_, URLs that are just opaque hashes are perfectly valid | 10:13 |
| wallyworld_ | well, for disk based Storage() implementtions the URls do have that correspondence | 10:13 |
| fwereade | wallyworld_, right, but that's not part of the Storage interface | 10:14 |
| fwereade | wallyworld_, it's an invalid assumption made by the simplestreams machinery | 10:14 |
| wallyworld_ | sure, but i don't think we use Storage() for simplestreams | 10:14 |
| fwereade | wallyworld_, hmm, I thought the two were more than a little entangled | 10:15 |
| fwereade | wallyworld_, if we don't, why is that CL hitting both storage code and simplestreams code? | 10:15 |
| wallyworld_ | we use a simplestreams.DataSource abstraction | 10:15 |
| fwereade | gsamfira, conversation relevant to your interests for about the last 50 mins ^^ | 10:16 |
| wallyworld_ | and there are file based and http based implementations | 10:16 |
| wallyworld_ | fwereade: so, in effect, the comments still apply - what what we do internally, and convert the urls are the system boundaries | 10:17 |
| fwereade | wallyworld_, which I would say doesn't fit with Storage, but was welded on for convenience's sake, for understandable and defensible but ultimately unhelpful reasons | 10:17 |
| wallyworld_ | fwereade: simplestreams doesn't use storage | 10:17 |
| wallyworld_ | it uses a different abstraction | 10:18 |
| wallyworld_ | 99% of it is about streaming data from a url | 10:18 |
| wallyworld_ | the other 1% is a utility which can write data | 10:18 |
| fwereade | wallyworld_, that's frequently backed by Storage-based urls | 10:18 |
| wallyworld_ | no, mostly by htto urls | 10:18 |
| wallyworld_ | only storage based for tests | 10:18 |
| fwereade | wallyworld_, that don't necessarily have the properties required by simplestreams | 10:18 |
| fwereade | wallyworld_, well, when did that change? because for a long time we *were* uploading ss data to Storages, and depending on the properties of the URLs returned by storage | 10:19 |
| fwereade | wallyworld_, my understanding was that we were getting closer to breaking the link, but had not yet done so | 10:20 |
| fwereade | wallyworld_, I haven't seen the state-based catalogues of tools and images... | 10:20 |
| wallyworld_ | all we need to do is fix storageSimpleStreamsDataSource | 10:20 |
| wallyworld_ | they are there | 10:20 |
| wallyworld_ | tools are no longer store in the cloud storage | 10:20 |
| wallyworld_ | tools and image metadata go into catalogs in state | 10:21 |
| wallyworld_ | the other thing is that the simplestreams.DataSource interface is read only | 10:22 |
| wallyworld_ | it streams data from urls | 10:22 |
| wallyworld_ | but for tests, and the generation utility, we need to write data | 10:22 |
| wallyworld_ | write data to a location on disk that the DataSource can read back | 10:23 |
| wallyworld_ | the simlplestreams.Datasource interface uses urls | 10:23 |
| fwereade | wallyworld_, ok, I see, the apiserver/common.Tools stuff is just falling back to simplestreams sometimes? | 10:23 |
| wallyworld_ | fwereade: it does if the tools don't exist in the sate database | 10:24 |
| wallyworld_ | from memory | 10:24 |
| fwereade | wallyworld_, in that case... shoudl we not be using state-based tool/image catalogues across the board in the tests? | 10:25 |
| fwereade | wallyworld_, this'll leave some bootstrap tests broken, I imagine | 10:25 |
| fwereade | wallyworld_, and ofc the metadata plugin ones | 10:25 |
| wallyworld_ | yes, we should i guess. there are lots of tests to fix | 10:25 |
| fwereade | wallyworld_, but they feel like they're real problems that should require code changes | 10:26 |
| wallyworld_ | we still need to read and write metadata to/from disk | 10:26 |
| wallyworld_ | for the generate plugin and bootstrap | 10:26 |
| fwereade | wallyworld_, understood | 10:26 |
| wallyworld_ | bootstrap - read files off disk, store in state server | 10:26 |
| wallyworld_ | (if --metadata-source is specified) | 10:27 |
| fwereade | wallyworld_, but what I am fulminating over is that this Storage-based hackery is being proposed as a way to get all the other tests passing | 10:27 |
| wallyworld_ | generate - read files off disk, see what's there, merge new metadata, write back out | 10:27 |
| fwereade | wallyworld_, when it's not actually fixing anything | 10:27 |
| fwereade | wallyworld_, it's just torturing the test framework to the point where, yes, the tests kinda pass, but there's basically no connection between reality and the test fixture | 10:27 |
| wallyworld_ | in 1.21 yes, in 1.20 no | 10:28 |
| fwereade | wallyworld_, well, 1.21 is what we're currently working on... | 10:28 |
| wallyworld_ | yes, agreed | 10:28 |
| wallyworld_ | if we didn't want to fix all the tests in one go, we should be able to tweak the urls in the storage data source before they are used i think | 10:30 |
| wallyworld_ | and generate filenames with "-", not ":" | 10:30 |
| wallyworld_ | the last bit is trivial | 10:30 |
| fwereade | wallyworld_, is it even about fixing all the tests in one go, though? | 10:31 |
| fwereade | wallyworld_, can this not be done piecemeal? | 10:31 |
| wallyworld_ | um, don't think so, could be wrong. there are a lot of tests though that fail on windows aren't there? | 10:31 |
| fwereade | wallyworld_, AIUI, yes, there are loads | 10:32 |
| fwereade | wallyworld_, and many of them are failing because FileStorage doesn't work on windows | 10:32 |
| wallyworld_ | yes, so we tweak the helper method which writes the files | 10:32 |
| wallyworld_ | to fix the storage path on windows | 10:32 |
| fwereade | wallyworld_, but any that aren't bootstrapping, or aren't using the metadata plugin, shouldn't need it anyway, because we now have tool/image catalogues in state anyway | 10:32 |
| wallyworld_ | yes, but there are still tests that exercise the simplestreams fetch/filer code | 10:33 |
| wallyworld_ | using file based metadata | 10:33 |
| fwereade | wallyworld_, understood -- but aren;t they going to be an absoluteminority? | 10:33 |
| wallyworld_ | we still need those tests | 10:33 |
| fwereade | wallyworld_, sure | 10:33 |
| fwereade | wallyworld_, and they're exercising functionality that is currently broken | 10:33 |
| fwereade | wallyworld_, I'm saying that it is moreimportant that we get the tests for working functionality to themselves start working | 10:34 |
| wallyworld_ | there are several of them. and bootstrap tests also need the url based data sources | 10:34 |
| wallyworld_ | and there are lots of those | 10:34 |
| wallyworld_ | so there are 3 types of test 1. simplestreams infrastructre, 2. bootstrap, 3. general juju | 10:35 |
| wallyworld_ | the first 2 still need al lthe crap we have now | 10:35 |
| fwereade | wallyworld_, gsamfira: my understanding is that less than 50% of the test suite is passing on windows -- I don't believe that 50% of the test suite needs to depend on bootstrapping or simplestreams | 10:35 |
| wallyworld_ | agree (waves arms in air) | 10:36 |
| fwereade | wallyworld_, gsamfira: I want to get the bits that don't depend on those two peiecs working reliably | 10:36 |
| wallyworld_ | 50% seems way low | 10:36 |
| wallyworld_ | i thought it was only several | 10:36 |
| wallyworld_ | maybe a package or two plus some other misc tests | 10:36 |
| fwereade | wallyworld_: gsamfira should be able to confirm, but I thought that was what he said the other day | 10:36 |
| fwereade | wallyworld_, I hadn't realised it was that bad myself | 10:36 |
| wallyworld_ | doesn't seem right | 10:37 |
| fwereade | wallyworld_, this is a large part of why I am freaking out somewhat indiscriminately | 10:37 |
| wallyworld_ | i am surprised myself | 10:37 |
| wallyworld_ | i honesty thought a MakeFileURL() or similar at the system boundary would work | 10:37 |
| fwereade | wallyworld_, correct me if I'm wrong | 10:38 |
| fwereade | wallyworld_, actually, no, this is just a pure question | 10:38 |
| fwereade | wallyworld_, in simplestreams, when adding a compenent to a path, does it always pass through the underlying storage's URL() method again? | 10:38 |
| fwereade | wallyworld_, if it doesn't, I don't think there's any expectation that it will work | 10:39 |
| wallyworld_ | fwereade: not sure ottomh. i know we use path.Join() to glue together the bits | 10:39 |
| fwereade | wallyworld_, because relative paths in storage are not guaranteed to map to relative storage urls in the first place | 10:39 |
| wallyworld_ | there's always a base url | 10:40 |
| wallyworld_ | and simplstreams works off relatives paths under that | 10:40 |
| fwereade | wallyworld_, so if there's a path component including a : that gets tacked on | 10:40 |
| fwereade | wallyworld_, that will *never* work as a file url on windows | 10:40 |
| wallyworld_ | yes | 10:40 |
| fwereade | wallyworld_, whereas if the path had a : tacked on | 10:40 |
| wallyworld_ | that's the issue | 10:40 |
| fwereade | wallyworld_, and that passed through the URL method | 10:40 |
| fwereade | wallyworld_, we'd get a new URL that should work everywhere | 10:41 |
| wallyworld_ | but we don't need the ":" | 10:41 |
| wallyworld_ | and we also need to strip drive letters | 10:41 |
| wallyworld_ | but regardless, we can store internally what we want, and only when it is used, which is via the URL()_ method, do we convert it | 10:42 |
| fwereade | wallyworld_, I am still deeply reluctant to use different filenames in the tests on windows, when we're writing code that needs to work against filenames with :s on remote systems | 10:42 |
| fwereade | wallyworld_, especially when this apparently hits so much of the test suite | 10:43 |
| wallyworld_ | fwereade: but on remote systems they are not filenames | 10:43 |
| wallyworld_ | they are http urls | 10:43 |
| wallyworld_ | and that bit works fine on windows | 10:43 |
| fwereade | wallyworld_, then can we have FileStorage run an http server, and return http urls? for the purpose of the tests, at least, allowing us to isolate the bits that need work in the real code? | 10:44 |
| wallyworld_ | http://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:aws.json | 10:44 |
| wallyworld_ | that wil work fine on windows | 10:44 |
| fwereade | wallyworld_, agreed | 10:45 |
| fwereade | wallyworld_, but I would like our test data to reflect that reality, and not just sub out certain characters because they're inconvenient | 10:45 |
| wallyworld_ | we could run an http server, or, we could just 1. not use ":", use "-" instea | 10:45 |
| wallyworld_ | the ":" are *totally* arbitrary | 10:45 |
| wallyworld_ | the filenames don't matter | 10:46 |
| fwereade | wallyworld_, agreed, but they're also in the live data | 10:46 |
| wallyworld_ | we just used ":" because the streams folks did | 10:46 |
| wallyworld_ | the image metadata folks have their own utilities for generate image json | 10:47 |
| fwereade | wallyworld_, I agree that we can do that in the metadata plugin, and I think that's fine and great | 10:47 |
| wallyworld_ | our QA folks generate the tools metadata, and if we switch to "-", that won't affect anything | 10:47 |
| fwereade | wallyworld_, my concern is all about the unrelated tests, that should be working against data that maps as closely as possible to the stuff in the wild | 10:47 |
| fwereade | wallyworld_, we can generate other data for local usage, and that's all fine | 10:48 |
| wallyworld_ | the data *content* is important, not the filenaes | 10:48 |
| wallyworld_ | the filenames just don;t matter one iota | 10:48 |
| wallyworld_ | there is only one file accessed directly - the index file | 10:48 |
| wallyworld_ | the index file contains paths to the product files | 10:48 |
| wallyworld_ | we can make those whatever we want | 10:49 |
| wallyworld_ | to me that's easier than setting up a http server for storage | 10:49 |
| fwereade | wallyworld_, I see this in the code: | 10:49 |
| fwereade | ProductMetadataPath = "streams/v1/com.ubuntu.cloud:released:imagemetadata.json" | 10:49 |
| fwereade | wallyworld_, is it unused? | 10:50 |
| fwereade | wallyworld_, or ill changing it suddenly cause us to stop working against the live data? | 10:50 |
| wallyworld_ | fwereade: that is *only* for the generate utility | 10:50 |
| wallyworld_ | not live data | 10:50 |
| wallyworld_ | live data reads the index file, looks in there, and follows the path therein | 10:51 |
| wallyworld_ | our generate plugin makes index files also | 10:51 |
| wallyworld_ | and uses what you reference about for the product file path | 10:51 |
| wallyworld_ | but we can totally chaneg that | 10:51 |
| wallyworld_ | fwereade: look inside this http://cloud-images.ubuntu.com/releases/streams/v1/index.json | 10:52 |
| wallyworld_ | that is live data | 10:52 |
| wallyworld_ | and the paths are what they are, we don't care | 10:52 |
| wallyworld_ | we just make a url from them | 10:52 |
| wallyworld_ | all that has nothing to do with the above const | 10:52 |
| fwereade | wallyworld_, I understand that | 10:53 |
| fwereade | wallyworld_, I am still not convinced that it's sane to arbitrarily change the format of our test data to be different to the live data -- *even if it's just a convention they use* -- for the convenience of the tests on windows | 10:53 |
| fwereade | wallyworld_, am I making sense? | 10:54 |
| wallyworld_ | i guess that's where we differ - i see it as an arbitary internal implemenation detail | 10:54 |
| wallyworld_ | so long as the external behaviour is correct | 10:55 |
| wallyworld_ | ie Fetch works, the datasources work | 10:55 |
| wallyworld_ | who cares what the files are called under the covers | 10:55 |
| fwereade | wallyworld_, I don't care what the files on disk are called, but I do care that the urls we create map to the ones used live | 10:55 |
| fwereade | wallyworld_, and using file:// urls causes that correspondence to be important | 10:56 |
| wallyworld_ | i disagree :-) | 10:56 |
| wallyworld_ | the url content is also totally arbitrary | 10:56 |
| wallyworld_ | so long as we can 1. load an index file, 2. parse the data, 3. file and load the correct product file, | 10:57 |
| wallyworld_ | it doesn;t matter what the urls are | 10:57 |
| wallyworld_ | simplestreams doesn't care | 10:57 |
| wallyworld_ | simplestreams doesn;t even parse the urls | 10:57 |
| wallyworld_ | it just hands them off to http.Get | 10:57 |
| fwereade | wallyworld_, I think it does matter, because it guards against inappropriate messing around with :s or drive letters in places where we shouldn't have to worry about them | 10:58 |
| wallyworld_ | we get rid of ":", problem solved there | 10:58 |
| fwereade | wallyworld_, every time we tweak our test data to be less like the real data, we go another step away from a real test | 10:59 |
| fwereade | wallyworld_, and that's great for the plugin/bootstrap cases | 10:59 |
| wallyworld_ | we use a helper MakeFileURL(path) function instead of "file://" + path, problem solved there | 10:59 |
| fwereade | wallyworld_, except that simplestreams will try to create a url by tacking on a filename with a : in it | 10:59 |
| wallyworld_ | fwereade: disagree about another step away from real test | 10:59 |
| fwereade | wallyworld_, and that won't work everywhere | 11:00 |
| wallyworld_ | you mean for the streams.canonical.com case? | 11:00 |
| wallyworld_ | those aren't filenames | 11:00 |
| wallyworld_ | they are url paths | 11:00 |
| fwereade | wallyworld_, I know -- but we're apparently using FileStorage all over the shop as our mock for streams.c.c | 11:00 |
| wallyworld_ | sure, but simplestreams doesn't know thar | 11:01 |
| wallyworld_ | so long as we give it a url which http.Get can use, job done | 11:01 |
| wallyworld_ | it doesn't care what the url is | 11:02 |
| fwereade | wallyworld_, so we have simplestreams code that mucks about with :s, and streams.c.c data that contains :s, and we're explicitly avoiding triggering the : cases | 11:02 |
| wallyworld_ | it won't muck around with ":" is we use "-" in our file names for the generate plugin | 11:03 |
| wallyworld_ | if | 11:03 |
| wallyworld_ | the streams.c.c data contains ":" but we don't cares, it's just urls we are dealing with | 11:04 |
| fwereade | wallyworld_, agreed, AFAICS the generate plugin is easy to fix, but IMO it needs to be fixed *after* we get the working code reliably tested | 11:04 |
| wallyworld_ | the troube there is the tests and generate plugin use shared code to write out metadata | 11:05 |
| wallyworld_ | so it still comes down to those 2 issues. 1. use windows compatible file names "-" instead of ":" | 11:07 |
| wallyworld_ | and 2. the way we generate file:// urls | 11:08 |
| fwereade | wallyworld_, ok, circling back, and leaving aside the question of how much work it is: | 11:08 |
| fwereade | wallyworld_, would you agree that it's generally more appropriate to use state-based tool/image catalogues for all tests that are not about bootstrapping and/or the metadata plugin? | 11:09 |
| wallyworld_ | yes | 11:09 |
| wallyworld_ | but those are in the minority (hand waves) | 11:09 |
| fwereade | wallyworld_, I find that hard to believe (waves hands vigorously and intimidatingly) | 11:10 |
| fwereade | wallyworld_, I guess we'll need input from someone who's actually got a windows to run the tests against here :) | 11:10 |
| * fwereade waves hands at gsamfira | 11:10 | |
| wallyworld_ | fwereade: under environs/tools environs/simplestreams, environs/imagemetadata there are mainly pure simplestreams tests | 11:11 |
| wallyworld_ | then there are tests in cmd/juju/bootstrap (lots) | 11:11 |
| wallyworld_ | then there are the plugins tests | 11:11 |
| fwereade | wallyworld_, anyway, even if they are in the minority, I contend that it's important to fix those first, because they're potentially obscuring other real failures | 11:11 |
| wallyworld_ | sure | 11:12 |
| fwereade | wallyworld_, or alternatively eroding confidence in bits that really do work | 11:12 |
| wallyworld_ | no issue fixing tests which should be using tools from state but which aren't | 11:12 |
| wallyworld_ | but i have my doubts how many there are | 11:12 |
| fwereade | wallyworld_, not to mention obscuring regressions in the bits that should work, that might get introduced by tangentially-related work | 11:12 |
| fwereade | wallyworld_, just a mo | 11:14 |
| fwereade | wallyworld_, WriteMetadata uses the Storage interface anyway | 11:14 |
| fwereade | wallyworld_, it ought to be working with paths not URLs anyway, right? | 11:14 |
| wallyworld_ | let me check | 11:14 |
| fwereade | wallyworld_, yeah, stor.Put(filePath, ...) | 11:15 |
| * fwereade brb | 11:15 | |
| wallyworld_ | fwereade: that Storage is a file system stor, not an provider cloud stor | 11:16 |
| wallyworld_ | it was done to allow metadata to be written to cloud storage as well as file system | 11:16 |
| wallyworld_ | but of course, cloud storage not needed anymore | 11:16 |
| fwereade | wallyworld_, well, it's the Storage interface ;p | 11:19 |
| wallyworld_ | true, but doesn't need to be now | 11:20 |
| wallyworld_ | but yes, WriteMetadata works with paths | 11:21 |
| wallyworld_ | not urls | 11:21 |
| bogdanteleaga | fwereade, wallyworld_: have you reached some agreement? I disconnected right after I've seen you've started to discuss my pr :) | 11:24 |
| fwereade | bogdanteleaga, well, I remain adamant that we need to get the non-simplestreams and non-bootstrap tests working against state catalogues -- so we can have faith in the parts of the system that do work -- before we start changing up the bits that don't work | 11:25 |
| fwereade | bogdanteleaga, can you estimate the proportions in play? | 11:25 |
| wallyworld_ | i agree with that | 11:25 |
| fwereade | bogdanteleaga, my understanding is that there are a *lot* of tests failing, and I find it hard to believe that they're all about simplestreams and botstrap | 11:26 |
| fwereade | bogdanteleaga, do you know what the failing proportion is offhand? | 11:26 |
| bogdanteleaga | well right now we're looking at about 100 tests I think | 11:26 |
| bogdanteleaga | without counting worker | 11:26 |
| fwereade | bogdanteleaga, hmm, most of juju is in worker, isn't it? | 11:27 |
| bogdanteleaga | the problem with getting non-simplestreams and non-bootstrap things up | 11:27 |
| bogdanteleaga | is that some of the stuff depends on it | 11:27 |
| bogdanteleaga | there's not really much else going on | 11:28 |
| fwereade | bogdanteleaga, btw, can you send me the test output on windows? | 11:28 |
| bogdanteleaga | there's some separate package derps | 11:28 |
| bogdanteleaga | and some ssh/charms problems | 11:28 |
| bogdanteleaga | sure | 11:29 |
| marcoceppi | what is metrics.yaml | 12:33 |
| mgz | marcoceppi: it's for metering, charms can define what kind of ticks they care about | 12:43 |
| mgz | mattyw/cmars talked a bit about it at the sprint | 12:44 |
| TheMue | mgz: ping | 13:07 |
| voidspace | so, to assign a new private IP address to a network (amazon ec2), *and* know what ip address is, we have to make 3 calls | 13:48 |
| voidspace | fetch all ips for that network, add a new ip address (which doesn't tell you the new one), fetch the ips for the network again and work out which is the new one | 13:48 |
| voidspace | at least as far as I can tell | 13:48 |
| mgz | voidspace: ick | 13:49 |
| voidspace | mgz: yeah, I'm just spelunking the api docs to see if it's really that bad | 13:49 |
| mgz | I guess what you actually care about is if there's any as-yet-unused private ip? | 13:50 |
| voidspace | mgz: this is specifically for adding a new ip address for a new container in an instance | 13:50 |
| voidspace | mgz: so really we do want "the one we just created" | 13:51 |
| mgz | so it's really while True: ip = get_free_addr_from_pool() if addr: break; allocate_new_private_ip() | 13:51 |
| voidspace | mgz: hmmm.... | 13:51 |
| mgz | which wpuld be maybe one call, but generally the three you mentioned :) | 13:52 |
| mgz | also, ip==addr, go variable naming | 13:52 |
| voidspace | mgz: there's an api call in goamz AssignPrivateIPAddresses | 13:52 |
| voidspace | mgz: I'm not following you | 13:53 |
| voidspace | mgz: we're not maintaining a pool here, and the abstraction you suggest doesn't really map to what we're doing | 13:54 |
| voidspace | as far as I can tell :-) | 13:54 |
| mgz | voidspace: well, I guess my assumption about just having any private ip is wrong, so rest makes no sense | 13:54 |
| voidspace | mgz: hehe | 13:54 |
| voidspace | mgz: yeah, we get ec2 to allocate the address for us | 13:54 |
| voidspace | mgz: but when they allocate it, they don't tell you what they allocated... | 13:55 |
| mgz | but you don't have to get ec2 to assign it, you can also supply one | 13:56 |
| voidspace | mgz: that's possibly true, and then we'd need to maintain the pool (or similar) | 13:57 |
| mgz | which is back to what I was assuming - not sure which is actually better in practice | 13:57 |
| voidspace | at least for ec2 | 13:57 |
| voidspace | for maas I think we really do want maas to allocate it | 13:57 |
| voidspace | but we don't have to use the same approach for both - so long as we have a consistent abstraction for getting the address | 13:58 |
| TheMue | mgz: could you please drop the actions sync calendar entry? I'll add a new one I've got to change when daylight saving times are over | 13:59 |
| mgz | drop? | 14:00 |
| TheMue | mgz: remove, delete | 14:01 |
| TheMue | mgz: just took the first word that came into my mind. ;) | 14:01 |
| mgz | I can just make you all have edit rights? | 14:02 |
| TheMue | mgz: that's ok too | 14:02 |
| mgz | done | 14:02 |
| TheMue | thanks | 14:03 |
| TheMue | we're changing this weekend, the US next weekend | 14:03 |
| marcoceppi | so, where are the windows charms? | 14:28 |
| * fwereade has evidently done something dumb with git, anyone free to tell me what I did exactly and how to undo it? can be seen in reviews.vapour.ws/r/258/diff/ and https://github.com/juju/juju/pull/961 which claims to contain changes I already merged in the previous branch | 15:21 | |
| jcw4 | fwereade: did you update your fork's master branch before making the PR? | 15:22 |
| jcw4 | fwereade: dunno if it still applies, but rbt previously required your master branch on your fork to be up to date | 15:23 |
| TheMue | fwereade: had it once too. switch to the false changed branch, do an rbt post -u, then switch back to the correct changed branch and do an rbt post -u there too (afair, will take a look again) | 15:23 |
| natefinch | fwereade: that can happen if you create a new branch from your old branch, without switching back to master first. I did that yesterday. The way I fixed it was to just make a new branch off master and cherry-pick the commit. There's probably a better way to fix the current branch, but I don't know it offhand. | 15:26 |
| fwereade | cheers guys, I'll hack at it a bit and see if it gets better :) | 15:27 |
| fwereade | ah, looks happier now after merging master (again) and pushing (again) | 15:28 |
| voidspace | fwereade: Jonathan is looking for work and we have an open position... | 16:32 |
| voidspace | fwereade: I've emailed him... | 16:32 |
| fwereade | voidspace, awesome, the collection grows... | 16:44 |
| voidspace | fwereade: hopefully | 16:45 |
| voidspace | fwereade: although I suspect it's a juju-gui position from the description | 16:45 |
| voidspace | right, have a happy weekend everyone | 17:08 |
| voidspace | g'night all | 17:08 |
| jcw4 | happy weekend voidspace | 17:08 |
| voidspace | o/ | 17:08 |
| === urulama is now known as urulama___ | ||
| === tvansteenburgh is now known as tvan|lunch | ||
| jog | mgz, or natefinch, could I get a quick review here: https://github.com/juju/juju/pull/963 | 17:51 |
| natefinch | sure | 17:51 |
| mgz | jog: lgtm | 17:53 |
| natefinch | laziness pays off again | 17:53 |
| jcw4 | :) | 17:57 |
| === tvan|lunch is now known as tvansteenburgh | ||
| === tdc_ is now known as tdc | ||
| jcw4 | fwereade: do you happen to be online at 9:30 pm on a Friday evening? | 19:34 |
| fwereade | jcw4, kinda, for a bit :) | 19:36 |
| fwereade | jcw4, what can I do for you? | 19:37 |
| jcw4 | I'm feeling like the watcher mechanism for handling actions is creaking at the seams | 19:37 |
| jcw4 | fwereade: per niemeyer 's comments I think it's a fairly sizeable refactor to enforce ordering of action execution | 19:38 |
| jcw4 | fwereade: right now the watcher uses set.Strings to collect the id's in the watcher, which is a set without any ordering mechanism (afaik) | 19:40 |
| fwereade | jcw4, so, that was not the idea, they were meant to produce ordered events | 19:40 |
| fwereade | jcw4, but that's not that hard to enforce, is it? | 19:40 |
| jcw4 | fwereade: I think you're right | 19:41 |
| fwereade | jcw4, worst case I can see is that two people sending actions at *almost* the same time might not get them in the db in quite the order they sent them | 19:41 |
| jcw4 | fwereade: I just get nervous relying on the watcher for ordering; but I suppose it's as good a queuing mechanism as any | 19:42 |
| jcw4 | fwereade: also, when the watcher is first created it gets a list of the id's already enqueued in the actions collection | 19:42 |
| jcw4 | fwereade: and in that query we're depending on the order that mongo gives them back to us in | 19:43 |
| fwereade | jcw4, hmm, I thought we were sorting them | 19:44 |
| jcw4 | fwereade: I guess I'm beginning to prevaricate about the sequence id's -- they may not be a guarantee of ordering between two different clients, but I can't imagine them not being ordered for one client | 19:44 |
| fwereade | jcw4, that was one of the reasons to have the sequence number in the id | 19:44 |
| jcw4 | fwereade: yeah - I can make sure we sort | 19:44 |
| jcw4 | fwereade: but niemeyer 's point was that the sequence mechanism isn't reliable for two different clients | 19:45 |
| jcw4 | fwereade: although if we allow that ordering between two clients is undetermined then the only issue left is if action-3 from client 1 runs before action-2 from client 2 | 19:46 |
| niemeyer | jcw4: That wans't the point, actually | 19:46 |
| jcw4 | I misunderstood then... :( | 19:46 |
| niemeyer | jcw4: If two people send actions concurrently, there's no pre-defined order between them by definition | 19:47 |
| jcw4 | niemeyer: yes, that makes sense | 19:47 |
| fwereade | niemeyer, o/ | 19:47 |
| niemeyer | jcw4: My point is that you should not allow that to be observable as order 103 goes before 102 if it comes from different clients | 19:48 |
| niemeyer | fwereade: Yo | 19:48 |
| jcw4 | niemeyer: I thought that the problem was advertising sequence number that may not reflect reality | 19:48 |
| niemeyer | jcw4: Isn't that what I just said? | 19:48 |
| jcw4 | niemeyer: yes exactly | 19:48 |
| jcw4 | I was just still typing | 19:48 |
| niemeyer | jcw4: Okay | 19:48 |
| niemeyer | jcw4: and my other point is that if one client sends two actions, the order should be respected | 19:49 |
| jcw4 | niemeyer: okay - which we can do using the sequence numbers right? | 19:49 |
| niemeyer | jcw4: Can you? I don't know | 19:49 |
| niemeyer | jcw4: You implied that sequence numbers were being generated out of the transaction | 19:49 |
| jcw4 | niemeyer: ah, I tried to clarify that it was in a separate transaction before the action was created | 19:50 |
| jcw4 | niemeyer: but you indicated that was even worse | 19:50 |
| jcw4 | :) | 19:50 |
| niemeyer | jcw4: No, I just said it was a proof that you cannot trust the numbers alone if you are using a queue | 19:51 |
| niemeyer | jcw4: Because client 1 might get action 103 committed before client 2 gets action 102 committed | 19:51 |
| niemeyer | jcw4: and that's confusing | 19:51 |
| jcw4 | niemeyer: okay so far everything is consistent with my understanding from the emails | 19:51 |
| fwereade | niemeyer, IIRC it's the sequence() thing we've had in state since forever -- downside is very rare out-of-order effects, upside is less unnecessary overlap in the txns | 19:52 |
| niemeyer | fwereade: I don't see how that's relevant in this case | 19:52 |
| niemeyer | fwereade: It doesn't matter how it's been used before, does it? | 19:52 |
| niemeyer | fwereade: Actions are queued.. having a queue with out-of-order sequence numbers feels obviously bogus | 19:53 |
| fwereade | niemeyer, yeah, wouldn't be hard to tweak -- the tradeoff in play is having lots of subtly-different code paths for doing almost identical things | 19:53 |
| jcw4 | niemeyer: is there a better queueing mechanism? I don't know how to order actions other than by some generated sequence | 19:54 |
| niemeyer | fwereade: I don't quite understand why this is not a trivial problem, with zero code duplication | 19:54 |
| niemeyer | fwereade: If the sequence numbers are not sequential, use anything else, such as a random id | 19:54 |
| jcw4 | niemeyer: that implies to me that we can't use mongo collections as the queue because we have no way of sorting the items in the collection without a sequence? | 19:55 |
| niemeyer | jcw4: a timestamp, a list field, a sequence number that is not exposed to the user, etc | 19:55 |
| jcw4 | niemeyer: okay - so timestamp is fine with me | 19:56 |
| niemeyer | jcw4: That's a surreal statement :) | 19:56 |
| jcw4 | niemeyer: :) | 19:56 |
| niemeyer | jcw4: You can order any data at all.. even a pair of random bytes | 19:57 |
| jcw4 | niemeyer: in my surreal statement a timestamp is a suitable sequence so I'm happy | 19:57 |
| jcw4 | niemeyer: sure - it's finding meaningful sorting that seems to be the trick here | 19:57 |
| niemeyer | jcw4: Not even that.. the only thing I pointed out is that you should not have bogus sequence numbers exposed to the user | 19:58 |
| jcw4 | niemeyer: I keep coming back to the fundamental point that this is just an issue of representation to the end user right? | 19:58 |
| jcw4 | niemeyer: what you just said | 19:58 |
| niemeyer | jcw4: The ordering was not the problem | 19:58 |
| niemeyer | jcw4: Unless, of course, you use the actions completely unsorted, as you suggested in the email thread | 19:59 |
| jcw4 | niemeyer: so internally I'll fix the bug and sort actions by timestamp | 19:59 |
| jcw4 | niemeyer: and externally we'll represent action id's without implied ordering | 19:59 |
| niemeyer | jcw4: Watch out for timestamp issues | 19:59 |
| niemeyer | (clocks changing, machines in a cluster with unmatching clocks, etc) | 20:00 |
| jcw4 | fwereade: and sorting by timestamp, I think, introduces pulling the entire document instead of just the _id | 20:00 |
| jcw4 | niemeyer: is that mitigated by having the queuing done on the state server (i.e. only one machine) | 20:00 |
| jcw4 | niemeyer: esp. if we use UTC rather than some local representation of time | 20:01 |
| niemeyer | jcw4: In principle the id with a sequence was fine for ordering | 20:01 |
| jcw4 | niemeyer: just not representing to the user? | 20:01 |
| niemeyer | jcw4: As long as you're not exposing it to the user as means for defining the order in which events took place | 20:01 |
| fwereade | jcw4, I'd be more inclined to pull the sequence generation into the txn if you want to expose the internal sequence | 20:01 |
| niemeyer | fwereade: Hah, yep.. the txn-revno has a sequence | 20:02 |
| niemeyer | Either way, I need to step out | 20:02 |
| niemeyer | Back later | 20:02 |
| jcw4 | thanks niemeyer | 20:02 |
| jcw4 | fwereade: so use txn-revno instead of sequence() ? | 20:02 |
| jcw4 | fwereade: right now state.sequence() encapsulates its own transaction. | 20:03 |
| fwereade | jcw4, hmm, that would work for ordering, and we have it available in the watcher | 20:04 |
| jcw4 | yeah | 20:04 |
| jcw4 | fwereade: does txn-revno guarantee uniqueness though? | 20:05 |
| fwereade | jcw4, so long as we guarantee a single write to the doc inquestion, yes, I think so | 20:05 |
| jcw4 | fwereade: i.e. will dozens of new actions across different clients produce a steadily increasing txn-revno? Yeah only one write. | 20:06 |
| fwereade | well, so long as there's some document touched by all those transaction, yes | 20:06 |
| fwereade | jcw4, so in practice, without changes, actually... no | 20:06 |
| fwereade | jcw4, so | 20:06 |
| jcw4 | fwereade: so include a write to a master doc? | 20:07 |
| fwereade | jcw4, well | 20:07 |
| fwereade | jcw4, just putting the sequence-getting inside the txn might be the easiest way? | 20:07 |
| jcw4 | fwereade: duplicating the existing sequence() code? | 20:07 |
| jcw4 | fwereade: or factoring lines 19-24 of state/sequence.go into a re-usable block? | 20:09 |
| fwereade | jcw4, I would need to look at it, but I would favour the latter on general principles | 20:09 |
| jcw4 | fwereade: +1 | 20:09 |
| fwereade | jcw4, would you take an hour or so to figure out the actual impact of pulling all sequence-generation into txns? | 20:09 |
| jcw4 | fwereade: sure... you mean every use of sequence() not just actions right? | 20:10 |
| fwereade | jcw4, yeah, please figure out the larger picture | 20:11 |
| jcw4 | fwereade: +1 | 20:11 |
| fwereade | jcw<3 | 20:11 |
| jcw4 | haha | 20:11 |
| fwereade | wwitzel3, are you still working? | 22:14 |
| fwereade | or katco maybe? | 22:14 |
| jcw4 | fwereade: 0 for 2 | 22:16 |
| fwereade | jcw4, seems that way | 22:17 |
| jcw4 | fwereade: gotta look for us west coast dudes | 22:17 |
| jcw4 | :) | 22:17 |
| fwereade | jcw4, don't suppose I can induce you to review http://reviews.vapour.ws/r/258/ can I? | 22:17 |
| jcw4 | or whatever the gender neutral version of dude is | 22:17 |
| jcw4 | sure sure | 22:17 |
| fwereade | jcw4, be harsh | 22:17 |
| jcw4 | hehe | 22:17 |
| fwereade | jcw4, but bear in mind that I think it's a *bit* less bad than the current state | 22:17 |
| * jcw4 rubs his hands evilly | 22:17 | |
| fwereade | don'tforget to twirl your mustachios | 22:18 |
| fwereade | jcw4, http://www.themarysue.com/ibm-black-team/ | 22:19 |
| jcw4 | amost exactly what I pictured when you said mustacios | 22:19 |
| wwitzel3 | fwereade: yep | 22:33 |
| fwereade | wwitzel3, so, I landed most of that stuff that'll mess with you, I'm afraid | 22:33 |
| wwitzel3 | fwereade: ok, great | 22:33 |
| fwereade | wwitzel3, jcw4 is currently looking at the next one that'll hurt | 22:34 |
| fwereade | wwitzel3, but the more reviews I get on that one the better | 22:34 |
| fwereade | wwitzel3, http://reviews.vapour.ws/r/258/ | 22:34 |
| jcw4 | wwitzel3, fwereade hehehe | 22:34 |
| wwitzel3 | fwereade: ok, I will take a pass of it in a bit? or you trying to land it before the weekend? | 22:34 |
| wwitzel3 | fwereade: I'm right in the middle of a completely different thought :) | 22:35 |
| fwereade | wwitzel3, I'd *love* to land it | 22:35 |
| fwereade | wwitzel3, but just put it on the stack | 22:35 |
| fwereade | wwitzel3, I am going to either finish the next refactoring or pass out | 22:35 |
| fwereade | wwitzel3, which is to say "finish" | 22:35 |
| wwitzel3 | right :) | 22:35 |
| fwereade | wwitzel3, in that it'll need a sober pass before I even try to propose it | 22:35 |
| fwereade | wwitzel3, but I don't have the courage to start it unfortified | 22:36 |
| fwereade | wwitzel3, and hey it's friday, I'm already fortified, and everyone else is asleep | 22:36 |
| wwitzel3 | fwereade: no one should be subjected to starting a refactor sober | 22:37 |
| jcw4 | *thats* my problem | 22:37 |
| wwitzel3 | fwereade: how else will you get the courage to start? | 22:37 |
| fwereade | wwitzel3, I've been putting this one off for almost two years now :/ | 22:37 |
| * jcw4 yells "honey: where's my petit syrah!?" | 22:37 | |
| wwitzel3 | fwereade: I'm glad it is happening :) .. I am sure it is doubtful, but it any of it can be worked on async, let me know. | 22:39 |
| wwitzel3 | fwereade: refactoring is always one of those things where I wish there was five of me with the same overall vision at the same time | 22:39 |
| wwitzel3 | under most conditions five of me would be a horrible thing | 22:39 |
| fwereade | wwitzel3, yeah, I worry that I'd just argue with myself even more than usual | 22:40 |
| * fwereade wishes he hadn't started by renaming a package, it's really not helping | 22:43 | |
| wwitzel3 | :) | 22:44 |
| fwereade | nah, actually, that's *nothing* compared to the errors I'm suddenly seeing in totally unrelated packages :/ | 22:45 |
| * fwereade runs godeps and hopes | 22:45 | |
| * fwereade feels unjustifiably smug | 22:45 | |
| wwitzel3 | fwereade: I played a game of Dominion where I won doing nothing but stacking my buys and getting as many actions, coppers, and vineyards (+1 VP per 3 action points) | 22:47 |
| wwitzel3 | fwereade: I thought of you | 22:47 |
| fwereade | wwitzel3, lol, nice :) | 22:48 |
| fwereade | wwitzel3, don't think I've ever played with vineyards | 22:48 |
| fwereade | wwitzel3, is that cornucopia? | 22:48 |
| wwitzel3 | http://wiki.dominionstrategy.com/index.php/Vineyard | 22:48 |
| wwitzel3 | Alchemy | 22:48 |
| fwereade | wwitzel3, very nice | 22:49 |
| fwereade | fuck, knew I should have done that other step first :/ | 22:55 |
| fwereade | ...and didn't even realise that *other* step I should also have done first | 22:57 |
| fwereade | bah | 22:57 |
| jcw4 | I thought you said you were fortified fwereade | 22:58 |
| fwereade | jcw4, I didn't say I'm not pressing on, did I :) | 22:59 |
| jcw4 | hehe | 22:59 |
| fwereade | jcw4, just means I've got to split it up more before I can land it ;p | 22:59 |
| jcw4 | fwereade: LGTM, plus minor comments | 23:05 |
| * fwereade cheers heartily at jcw4 | 23:06 | |
| jcw4 | :) | 23:06 |
| * fwereade wishes jc<tab> autocompleted | 23:06 | |
| jcw4 | well three tabs means you might as well just type it out | 23:07 |
| jcw4 | I need a longer nick to justify the multiple tabs | 23:07 |
| === jcw4 is now known as jw4 | ||
| jw4 | fwereade: there... jw<tab> ? | 23:18 |
| fwereade | jw4, man, now I need to rewire my muscle memory ;p | 23:18 |
| jw4 | haha | 23:18 |
| fwereade | jw4, but it *is* nice all the same | 23:19 |
| fwereade | jw4, you wouldn't think that "jc" would be such a common prefix | 23:19 |
| fwereade | omfg uniter tests passing | 23:19 |
| jw4 | haha | 23:19 |
| fwereade | this might have actually worked | 23:20 |
| * fwereade is coder, hear me roar | 23:23 | |
| wwitzel3 | it either worked, or we have no coverage for what you just changed .. but really, they might as well be the same thing ;) | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!