| waigani | thumper: http://reviews.vapour.ws/r/177/ | 00:27 |
|---|---|---|
| anastasiamac | davecheney: could u please review http://reviews.vapour.ws/r/235/ - it'd b gr8 to land it :-) | 01:44 |
| davecheney | anastasiamac: sure | 01:44 |
| anastasiamac | davecheney: thnx! | 01:45 |
| davecheney | anastasiamac: not lgtm | 01:46 |
| davecheney | sorry | 01:46 |
| davecheney | config.AgentMetadataURLKey: " | 01:46 |
| davecheney | i don't think this payus for itself | 01:46 |
| davecheney | are we really going to be changing the definition of this so frequently that we need to move it's definition to a shared location ? | 01:46 |
| davecheney | the reason I say this is | 01:47 |
| davecheney | all the test fixtures still assert it's a constant | 01:47 |
| anastasiamac | davecheney: u mean using variables instead of string? | 01:47 |
| davecheney | yup | 01:47 |
| menn0 | thumper: https://github.com/mjs/juju/commit/b7f48aa500f6aba285320c6a4aa184736d287b1a | 01:47 |
| davecheney | anastasiamac: all the fixtures still encode the string directly | 01:47 |
| davecheney | so does the documentation and the examples | 01:47 |
| davecheney | i don't feel this pays for itself | 01:47 |
| menn0 | thumper: this is the commit that adds various hacks to allow the machine agent to start so that it can run the machine env UUID upgrades | 01:48 |
| * thumper wonders how horrible it is | 01:48 | |
| menn0 | thumper: it's actually mostly done, except for some unit test changes | 01:48 |
| thumper | ok, it doesn't look TOO long | 01:48 |
| anastasiamac | davecheney: m not big fan of retyping the same string. if a string is used more thn once, it should b a variable... | 01:48 |
| menn0 | thumper: it's a bit horrible but the horribleness is fairly localised | 01:49 |
| davecheney | anastasiamac: but you ended up typing a slightly longer variable ... | 01:49 |
| menn0 | thumper: instead of storing and using a DB version, the code checks for evidence of the upgrade being in place | 01:50 |
| menn0 | thumper: this is safer IMHO | 01:50 |
| menn0 | thumper: because otherwise you end up with points in time where the DB has been changed but the version hasn't | 01:51 |
| davecheney | thumper: i will be late for the team meeting | 01:51 |
| davecheney | have 1:1 with robbiew | 01:51 |
| thumper | kk | 01:51 |
| davecheney | ericsnow: reviews.ws has gone back to reporting it's ec2 url again | 01:54 |
| davecheney | just got another email from the wrong address | 01:54 |
| anastasiamac | davecheney: :-) what length would u consider k for a variable? also should the name be descriptive? eg. here would AgentURL be k? | 01:56 |
| ericsnow | davecheney: (╯°□°)╯︵ ┻━┻ | 01:56 |
| menn0 | thumper: does this approach look ok to you? | 01:57 |
| * thumper looks in detail | 01:58 | |
| thumper | anastasiamac: I like descriptive names | 01:58 |
| thumper | please don't be sucked in to thinking shorter is better | 01:58 |
| * thumper is opinionated on this | 01:58 | |
| anastasiamac | thumper: i agree. shorter is not always practical.. | 01:59 |
| anastasiamac | thumper: by the same token, metadata is 8 chars... ;-( | 01:59 |
| davecheney | anastasiamac: i'm not arguging about the length | 01:59 |
| davecheney | its the fact that this change doesn't pay for itself | 02:00 |
| davecheney | you can't turn all the test fixtures into variables as well | 02:00 |
| davecheney | or the examples | 02:00 |
| davecheney | or the documentation | 02:00 |
| davecheney | or the yaml keys | 02:00 |
| davecheney | etc | 02:00 |
| thumper | menn0: mostly looks ok | 02:02 |
| thumper | not gone through in exceptional detail yet | 02:02 |
| davecheney | seriously, i missed the meeting ? | 02:36 |
| thumper | davecheney: yeah... | 02:49 |
| thumper | davecheney: we were done in 15 minutes | 02:49 |
| thumper | davecheney: it seems that rb doesn't pick up juju/cmd | 02:51 |
| thumper | https://github.com/juju/cmd/pull/8 | 02:51 |
| thumper | wallyworld_: or you maybe? ^^^ | 02:53 |
| thumper | or axw... | 02:53 |
| wallyworld_ | wot | 02:53 |
| thumper | simple change | 02:53 |
| wallyworld_ | ok | 02:53 |
| thumper | juju/cmd update | 02:53 |
| wallyworld_ | thumper: are other sub command affected besides juju user? | 02:56 |
| thumper | wallyworld_: it only impacted nested subcommands | 02:57 |
| thumper | and only if you didn't say anything else | 02:57 |
| wallyworld_ | ok | 02:57 |
| thumper | so 'juju user' would miss out the 'juju' prefix in the help output | 02:57 |
| thumper | juju user --help was fine | 02:57 |
| thumper | juju user help add was fine | 02:57 |
| thumper | juju user add --help was fine | 02:57 |
| thumper | juju user was not | 02:58 |
| wallyworld_ | ack | 02:58 |
| wallyworld_ | sadly you still need to hit the merge button manually for this sub repo i think | 02:58 |
| thumper | will do | 02:58 |
| thumper | wallyworld_: I also noticed that all the licences were wrong | 02:59 |
| thumper | wallyworld_: I'll submit another quick one to fix that | 02:59 |
| wallyworld_ | for cmd/juju? | 02:59 |
| wallyworld_ | i thought robbie had audited everything | 02:59 |
| thumper | it still shows AGPL | 03:00 |
| thumper | instead of LGPL with exception | 03:00 |
| thumper | OH FFS | 03:03 |
| thumper | should the file be LICENCE or LICENSE? | 03:03 |
| thumper | we have a mix | 03:04 |
| thumper | LICENSE | 03:04 |
| thumper | according to the world | 03:04 |
| anastasiamac | thumper: one is noun, on is verb.. | 03:05 |
| thumper | WTF?... | 03:07 |
| anastasiamac | thumper: ~ce (from French/Latin), ~se (from Mid English)... | 03:07 |
| * thumper found a weird file... | 03:07 | |
| thumper | wallyworld_: https://github.com/juju/cmd/pull/9 | 03:10 |
| wallyworld_ | ceis noun | 03:11 |
| wallyworld_ | se is verb | 03:11 |
| wallyworld_ | like practice and practise | 03:11 |
| wallyworld_ | and advise and advice | 03:11 |
| thumper | I always get that shit wrong | 03:11 |
| thumper | wallyworld_: so in that PR, you'll notice I also remove names.go | 03:11 |
| wallyworld_ | easy to remember - ice is a noun' | 03:11 |
| thumper | which should never have been there in the first place | 03:11 |
| wallyworld_ | ok | 03:12 |
| wallyworld_ | why are we changing LICEENCE to be incorrectly spelt? | 03:12 |
| wallyworld_ | oh the irony. LICENCE | 03:12 |
| thumper | because this is what the world has | 03:13 |
| thumper | oh it also appears to be an americanism | 03:13 |
| wallyworld_ | yes :-( | 03:14 |
| wallyworld_ | americans cannot spell for shit | 03:14 |
| thumper | http://oss-watch.ac.uk/resources/opensourceyourcode#applying-the-licence | 03:14 |
| thumper | says to have LICENSE | 03:14 |
| wallyworld_ | we are an englidh company | 03:14 |
| thumper | not LICENCE | 03:14 |
| wallyworld_ | english | 03:14 |
| thumper | that is a .uk site | 03:14 |
| wallyworld_ | but the farking url says licence | 03:14 |
| thumper | notice the header: Applying The Licence | 03:15 |
| wallyworld_ | sigh | 03:15 |
| thumper | GNU LESSER GENERAL PUBLIC LICENSE | 03:15 |
| thumper | notice the SE | 03:15 |
| wallyworld_ | but but but | 03:15 |
| wallyworld_ | sigh | 03:15 |
| thumper | don't shoot me | 03:15 |
| thumper | I'm just trying to be consistent | 03:15 |
| wallyworld_ | they know it's wrong or else why have licence in their url | 03:15 |
| wallyworld_ | sigh | 03:15 |
| anastasiamac | thumper: be original and say it in german | 03:16 |
| thumper | :P | 03:16 |
| wallyworld_ | "es" | 03:16 |
| wallyworld_ | or "der" or "sie" depending on gender | 03:16 |
| wallyworld_ | did I pass? | 03:16 |
| davecheney | thumper: it's spelt COPYING | 03:18 |
| thumper | ha | 03:19 |
| menn0 | thumper: PTAL http://reviews.vapour.ws/r/175/ | 03:30 |
| thumper | menn0: kk, need to look at waigani's first | 03:30 |
| menn0 | thumper: np | 03:31 |
| thumper | wallyworld_: wouldn't ya know it, juju was depending on that names package in juju/cmd | 03:46 |
| * thumper will fix with the branch that increments the dependency | 03:46 | |
| thumper | wallyworld_: and the backups command test checks for a wrong usage :-) | 03:47 |
| wallyworld_ | \o/ | 03:59 |
| === urulama_eod is now known as urulama | ||
| === TheRealMue is now known as TheMue | ||
| anastasiamac | ericsnow: rbt problem.. probably related to the issue of creating my request yesterday... update did not occur automatically either. I had to manually update it... | 07:14 |
| wallyworld_ | fwereade_: i have to go to soccer - do you have a little time to pop into #juju on canonical and offer some insight into some relation departed issues they are having in oil? some relations are behaving, others aren't, and i'm a little unclear on what to tell them | 07:22 |
| fwereade_ | wallyworld_, I'll see what Ican do, thanks | 07:23 |
| wallyworld_ | you rock | 07:23 |
| mattyw | morning everyone | 07:55 |
| fwereade_ | mattyw, updated http://reviews.vapour.ws/r/234/diff/ | 08:34 |
| fwereade_ | mattyw, fwiw, it's almost all just moves | 08:34 |
| fwereade_ | mattyw, the only things that should really be worth paying attention to are the code that's moved from uniter into context.factory; and the proxy junk that I deleted from uniter (which kinda comes under the same heading anyway) | 08:35 |
| mattyw | fwereade_, ok great, I'll take a look this afternoon | 08:43 |
| voidspace | dimitern: ping | 09:04 |
| dimitern | voidspace, pong, give me 20m please, doing a test now | 09:08 |
| voidspace | sure | 09:11 |
| fwereade_ | does anyone know why we use an abstract socket for the jujuc server, but a filepath socket for the juju-run listener? | 09:40 |
| fwereade_ | wallyworld_, when you return, ^^ -- on the basis that you're sort of near thumper and might know why he did it | 09:41 |
| fwereade_ | gsamfira, does juju-run work on windows? | 10:26 |
| fwereade_ | gsamfira, the tests have linux stuff hardcoded, I don't see how they can run | 10:27 |
| gsamfira | fwereade_: juju-run should work on windows, unless someone changed that code :). Instead of a unix socket, juju-run uses named pipes on windows | 10:28 |
| fwereade_ | gsamfira, if the tests don't pass, I don't really consider it working ;p | 10:28 |
| gsamfira | those tests have yet to be fixed on windows | 10:28 |
| fwereade_ | gsamfira, what's the progress there? | 10:28 |
| gsamfira | yeah, a little more then half the tests pass on windows | 10:29 |
| fwereade_ | gsamfira, because, you know, code without tests *is* fundamentally broken | 10:29 |
| gsamfira | fwereade_: my colleagues are working on the tests | 10:29 |
| fwereade_ | gsamfira, in the same way that data without offsite backups only happens to exist by coincidence | 10:29 |
| fwereade_ | gsamfira, I know, and I'm glad that they are, I'm just stressing about it a bit | 10:29 |
| fwereade_ | gsamfira, do you have an ETA? | 10:30 |
| gsamfira | fwereade_: understood. There are some issues that are giving us a bit of a headache. For example, colon delimited files are not possible on windows | 10:30 |
| gsamfira | so com.ubuntu.juju:series:foo | 10:30 |
| fwereade_ | gsamfira, tedious -- which files are those? | 10:30 |
| gsamfira | cannot be written on windows | 10:30 |
| fwereade_ | gsamfira, where would they come up? simplestreams? | 10:31 |
| gsamfira | for those files some normalization needs to happen (the juju-metadata plugin fails for the same reasons) | 10:31 |
| gsamfira | yep | 10:31 |
| gsamfira | simplestreams | 10:31 |
| gsamfira | and a ton of tests rely on those | 10:31 |
| gsamfira | let me ping bogdanteleaga to get the status of that | 10:32 |
| fwereade_ | gsamfira, I strongly recommend you talk to wallyworld about that | 10:32 |
| fwereade_ | gsamfira, gut feeling says there should be a simple way around that, and we shouldn't depend on those FS paths | 10:33 |
| gsamfira | I think bogdan has been in touch with wallyworld | 10:33 |
| fwereade_ | gsamfira, ok, fantastic | 10:33 |
| gsamfira | most likely after the Paris ODS, I'll be joining in to work on the tests. | 10:34 |
| gsamfira | fwereade_: right now we are in crunch mode for the summit in openstack | 10:35 |
| fwereade_ | gsamfira, fantastic -- just bear in mind that it's hard to legitimately claim windows support while the unit tests are still far from green | 10:36 |
| gsamfira | fwereade_: understood | 10:36 |
| fwereade_ | gsamfira, would it be worth syncing up with (say) mgz to get proto-CI in place for windows? that way at least we can catch regressions in tests that had been passing | 10:37 |
| gsamfira | fwereade_: I would suggest we disable all tests that fail on windows ATM, and enable them as they get fixed | 10:37 |
| gsamfira | fwereade_: so yes. it is worth doing :) | 10:38 |
| fwereade_ | gsamfira, mgz: ok, I'd be fine with a SkipWindows() func we jam into the failing tests, or something | 10:39 |
| wallyworld_ | gsamfira: fwereade_ : there's a bug nate is aware of to change the file paths to be windows compatible | 10:39 |
| fwereade_ | gsamfira, mgz: can I leave you guys to coordinate getting that done somehow? | 10:39 |
| fwereade_ | wallyworld_, so we're reading dirs with tools in that format? | 10:39 |
| wallyworld_ | fwereade_: thanks for helping with the relation stuff - i was not across those older bugs in previous versions | 10:39 |
| fwereade_ | wallyworld_, ok, good to know | 10:40 |
| fwereade_ | wallyworld_, yw :) | 10:40 |
| wallyworld_ | fwereade_: we're reading dirs with file names containing : | 10:40 |
| wallyworld_ | which is fine for linux | 10:40 |
| fwereade_ | wallyworld_, yeah | 10:40 |
| fwereade_ | wallyworld_, gsamfira: I guess I'm a bit surprised that the :s are problematic for a large proportion of the tests, though | 10:41 |
| fwereade_ | wallyworld_, I can understand how they'd mess up the metadata ones | 10:41 |
| wallyworld_ | fwereade_: so skimming the back scroll in #juju, their issues were caused by bugs in 1.16.5? | 10:41 |
| fwereade_ | wallyworld_, I *think* so, yeah | 10:42 |
| fwereade_ | wallyworld_, the units were coming up and believing they weren't in the relations they actually were | 10:42 |
| wallyworld_ | fwereade_: gsamfira: many tests set up fake metadata, writing files with :, hence they fail | 10:42 |
| fwereade_ | wallyworld_, which could happen pre 1.18.1, because we weren't recording what relations we'd joined locally until we saw a remote unit in them | 10:42 |
| gsamfira | fwereade_, wallyworld_ : bogdanteleaga proposed a fix for the : files | 10:42 |
| gsamfira | https://github.com/juju/juju/pull/908 | 10:42 |
| fwereade_ | wallyworld_, oh ok -- can we get around that by not writing the metadata to the filesystem? | 10:43 |
| fwereade_ | wallyworld_, or just fixing the FS storage to map : paths to something else? | 10:43 |
| fwereade_ | wallyworld_, hell just urlencide all paths? | 10:43 |
| wallyworld_ | fwereade_: yes i think so, but there's a lot of tests to fix, and we need to change the file names anyway for the generate metadata plugin | 10:43 |
| wallyworld_ | fwereade_: we originally used : because that's what the simplestreams folks did onthe public web server | 10:44 |
| gsamfira | fwereade_, wallyworld_ : https://github.com/juju/juju/pull/908 <-- I think this should do | 10:44 |
| wallyworld_ | easy enough just to change the : to - | 10:44 |
| wallyworld_ | gsamfira: ok, will look soon, gotta have dinner after coming hie from soccer | 10:45 |
| wallyworld_ | home | 10:45 |
| gsamfira | wallyworld_: cool. If those 2 patches are fine, we can fix a large portion of the tests that try to write simplestreams files | 10:45 |
| fwereade_ | gsamfira, wallyworld_: that CL scares the life out of me tbh | 10:45 |
| fwereade_ | gsamfira, wallyworld_: way too many arbitrary-lookin changes in arbitrary-looking places | 10:46 |
| fwereade_ | gsamfira, wallyworld_: why wouldn't just encoding internal paths work? | 10:46 |
| fwereade_ | gsamfira, wallyworld_: the metadata fixes would be different but they feel like they really *are* different | 10:46 |
| wallyworld_ | or just notusing filenames with : in them | 10:46 |
| fwereade_ | gsamfira, wallyworld_: they're about parsing a particular FS structure | 10:47 |
| wallyworld_ | the metadata is fine on either os - it's the filenames that need changing unless i am missing something | 10:47 |
| fwereade_ | gsamfira, wallyworld_: why wouldn't we just make :s work in Storage paths? | 10:47 |
| fwereade_ | gsamfira, wallyworld_: the solution to a leaky abstraction is to fix the leak | 10:47 |
| wallyworld_ | fwereade_: the json files are written to disk | 10:47 |
| fwereade_ | gsamfira, wallyworld_: not to add duct tape in 10 other files | 10:47 |
| wallyworld_ | fwereade_: i've had no input to the CL, not seen it yet | 10:48 |
| wallyworld_ | nor | 10:48 |
| fwereade_ | wallyworld_, and? the Storage names can have :s just fine, we just need to encode them differently for the FS, surely? | 10:48 |
| wallyworld_ | sure, but why do that? the file names are totally arbitrary | 10:48 |
| wallyworld_ | just make file names compatible with all os's | 10:49 |
| fwereade_ | wallyworld_, yes | 10:50 |
| fwereade_ | wallyworld_, that shoudl be completely hidden behind the Storage interface | 10:50 |
| wallyworld_ | yep | 10:50 |
| wallyworld_ | but don't forget | 10:50 |
| fwereade_ | wallyworld_, not splattered across the codebase everywhere we *happen* to have noticed a problem today | 10:50 |
| wallyworld_ | we generate files on disk also | 10:50 |
| wallyworld_ | we just need to change *1* method | 10:51 |
| fwereade_ | wallyworld_, I understand that the metadata plugin is a separate issue | 10:51 |
| gsamfira | aside from index.json, i *think* the rest can be named whatever we want. As long as we use the same path inside index.json | 10:51 |
| fwereade_ | gsamfira, that is true as well | 10:51 |
| gsamfira | fwereade_: the metadata plugin uses the same filenames/constants. if we fix the metadata plugin, we fix most tests | 10:52 |
| fwereade_ | gsamfira, wallyworld_: but the proportion of tests in which we depend on FS simplestreams data (as opposed to Storage-based simplestreams data) should be minimalk | 10:52 |
| wallyworld_ | changing this const should work | 10:52 |
| wallyworld_ | ProductMetadataPath = "streams/v1/com.ubuntu.cloud:released:imagemetadata.json | 10:52 |
| wallyworld_ | fwereade_: agreed, i'm not sure of the current mix of tests which use storage vs fs metadata | 10:53 |
| wallyworld_ | but regardless, changing a const should fix everything | 10:53 |
| fwereade_ | sorry guys, my lunch is getting cold | 10:53 |
| fwereade_ | wallyworld_, it wil *not* | 10:53 |
| fwereade_ | wallyworld_, it will fix *one symptom* of the underlying problem | 10:53 |
| fwereade_ | wallyworld_, which is that our FS storage abstraction is leaky and fails on windows | 10:53 |
| wallyworld_ | ok, we can talk after your lunch | 10:53 |
| fwereade_ | wallyworld_, cheers :) | 10:54 |
| gsamfira | wallyworld_, there is also this: https://github.com/juju/juju/blob/master/environs/tools/marshal.go#L21 | 10:55 |
| gsamfira | and the one immediately bellow that | 10:55 |
| wallyworld_ | gsamfira: yes, i knew that was there but didn;t find the method in time to type it in | 10:55 |
| wallyworld_ | there's a couple of places where we generate the filename | 10:55 |
| gsamfira | wallyworld_: if we can create a constant with those names, that would be great | 10:57 |
| gsamfira | bogdanteleaga: can you try changing the filenames and see if that works on both windows and linux ? | 10:57 |
| wallyworld_ | gsamfira: the content id doesn't need to change | 10:58 |
| wallyworld_ | just the file name | 10:58 |
| bogdanteleaga | there's quite a lot of places where there are :'s, mostly are sptrintf'd | 10:58 |
| bogdanteleaga | and we have some tests where they are hardcoded | 10:58 |
| wallyworld_ | it's only the file names isn't it? | 10:58 |
| bogdanteleaga | but it's pretty doable | 10:58 |
| bogdanteleaga | yes | 10:58 |
| wallyworld_ | the content ids should be fine | 10:58 |
| gsamfira | content ids are fine, yes | 10:58 |
| wallyworld_ | so there should be a small number of places where filenames are generated, these just need to have the : replaced | 10:59 |
| gsamfira | only paths inside index.json (and of course the names on disk) need to change | 10:59 |
| bogdanteleaga | and what about files online? | 11:00 |
| bogdanteleaga | there's no difference between the offline and offline paths, they're generated from the same string | 11:00 |
| gsamfira | bogdanteleaga: those can be replaced. the index.json is the only one of consequence, and we don't touch that | 11:00 |
| gsamfira | so the path to the file containing information about tools in in the index.json file | 11:01 |
| wallyworld_ | the online ones are url paths | 11:01 |
| gsamfira | http://paste.ubuntu.com/8639101/ | 11:01 |
| wallyworld_ | it's just windows fs that is broken :-( | 11:01 |
| gsamfira | the "path" inside this file tells you where to find the tools information. | 11:02 |
| gsamfira | wallyworld_: yeah...unfortunately...windows uses ":" for drive letters.... | 11:03 |
| wallyworld_ | stupid windows, stupid drive letters | 11:03 |
| gsamfira | wallyworld_: ....amen | 11:04 |
| gsamfira | wallyworld_: its funny because windows also has UNC paths, which would be nicer to use in general... | 11:06 |
| wallyworld_ | yeah, go figure | 11:08 |
| perrito666 | morning | 11:49 |
| TheMue | perrito666: morning | 11:52 |
| perrito666 | natefinch: https://github.com/juju/juju/pull/928 care to take a second look? | 12:42 |
| jcw4 | fwereade: question about timestamps in action docs | 12:44 |
| jcw4 | fwereade: creation time and completion time are straightforward | 12:44 |
| jcw4 | fwereade: capturing start time (i.e. when the action is picked up and started) is a little tricky. | 12:45 |
| jcw4 | fwereade: we chose to only write actionDoc once when enqueing it, and then writing a new actionResultDoc when done | 12:46 |
| jcw4 | fwereade: so that the watchers can be efficient about detecting new actions, and not fire when we *update* the actionDoc | 12:47 |
| jcw4 | fwereade: I'm just bringing this up 'cause you'd mentioned capturing start time, and I'm looking for your preference on how to capture that | 12:47 |
| fwereade | jcw4, can we plausibly write the beginnings of the actionResultDoc when we start? | 12:49 |
| jcw4 | fwereade: that's the only thing that makes sense to me | 12:49 |
| fwereade | jcw4, the big trouble is that we still don't seem to have proper handling for units that die halfway through an action | 12:49 |
| fwereade | bodie_, was there any progress there? | 12:49 |
| jcw4 | fwereade: I think we'd have to rework how we write actionResultDoc though, since I think the code expects it only to be written once too, on completion. | 12:50 |
| jcw4 | it actually might be cleaner, if we begin actionResult right away and remove actionDoc as soon as it's picked up, but we'd have to decide what happens when units die halfway through. | 12:52 |
| jcw4 | at least this way it'd be clear from the actionResultDoc that a unit tried to start working on it | 12:52 |
| fwereade | jcw4, yeah, I think that would be handy | 12:53 |
| fwereade | jcw4, the uniter has responsibilities if it goes down mid-action | 12:53 |
| fwereade | jcw4, but if it goes down forever, we should also have the state-server-side cleanup for a dead unit explicitly mark all those actions failed | 12:53 |
| fwereade | jcw4, the uniter responsibilities are one of my major concerns, though | 12:53 |
| fwereade | bodie_, ^^ | 12:53 |
| jcw4 | fwereade: do we already have mechanisms in place for uniter cleanup ? | 12:54 |
| jcw4 | before the big hammer of state-server-side cleanup | 12:54 |
| fwereade | jcw4, we're *meant* to | 12:54 |
| fwereade | jcw4, everything the uniter does can pick itself up and recover if it's kill -9'd at any time | 12:55 |
| fwereade | jcw4, *except* actions | 12:55 |
| jcw4 | ooh | 12:55 |
| fwereade | jcw4, to be fair, it's pretty easy | 12:55 |
| fwereade | jcw4, it just needs to detect and handle it in ModeContinue | 12:55 |
| jcw4 | fwereade: that's partially because we don't have a way right now to know that actions have been started... which an initial record of actionResult may help. | 12:56 |
| fwereade | jcw4, I'm inclined to make it local, actually | 12:56 |
| jcw4 | hmm; interesting | 12:56 |
| fwereade | jcw4, we do already record that fact locally | 12:56 |
| jcw4 | i see | 12:56 |
| fwereade | jcw4, just got factored out into uniter/operation package | 12:56 |
| jcw4 | fwereade: I saw your emails about that refactor, but haven't looked at the diff | 12:57 |
| jcw4 | fwereade: I'll check it out too | 12:57 |
| fwereade | jcw4, the reason we no longer run actions in error states is because the current implementation smashes op-error state | 12:57 |
| fwereade | jcw4, this does need to be fixed :) | 12:57 |
| jcw4 | fwereade: the current implementation of action handling in uniter you mean? | 12:58 |
| fwereade | jcw4, yeah, it's just writing out hook state | 12:58 |
| fwereade | jcw4, which smashes pre-existing hook-pending state | 12:58 |
| jcw4 | fwereade: ah; I see. | 12:59 |
| fwereade | jcw4, which is how the uniter can tell it was interrupted running one, and hence should be in error mode | 12:59 |
| fwereade | jcw4, I did agree that it's not *top* priority -- "can't run actions in error state" is a bug, but it's not unreasonable in the first cut, while "running actions in error state messes everything up" is unreasonable at any time | 13:00 |
| jcw4 | fwereade: +1 | 13:02 |
| jcw4 | fwereade: also; slight side topic: I'm *really* uncomfortable embedding time.Now() in the bowels of any state code.. I'd want to inject the concept of current time somehow to make chronology more predictable, and more testable. | 13:02 |
| fwereade | jcw4, that sounds good to me | 13:02 |
| fwereade | jcw4, take a look at the metrics stuff | 13:02 |
| fwereade | jcw4, I can't remember how they do that | 13:03 |
| fwereade | jcw4, if it's good, do the same | 13:03 |
| jcw4 | fwereade: okay - I did see some code there | 13:03 |
| fwereade | jcw4, if it's not, please fix both ;p | 13:03 |
| fwereade | jcw4, and maybe sling thumper a mail? I suspect he is, or soon will be, doing something like that re user stuff | 13:03 |
| jcw4 | fwereade: what I saw there looked like 1/2 a solution of at least capturing current time in a function that could be monkey patched | 13:04 |
| jcw4 | It seems like a TimeProvider interface or something would be good | 13:04 |
| fwereade | jcw4, +1 to that | 13:04 |
| fwereade | axw, ping | 13:04 |
| mattyw | dimitern, are you able to do a trivial review? http://reviews.vapour.ws/r/248/ | 13:11 |
| dimitern | mattyw, sure, looking | 13:12 |
| jcw4 | mgz, sinzui any idea why CI keeps failing on Does not match ['fixes-1384175'] ? | 13:28 |
| jcw4 | that bug doesn't show up in the critical bugs on lp | 13:29 |
| jcw4 | https://bugs.launchpad.net/juju-core/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.importance%3Alist=CRITICAL&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_sub | 13:29 |
| jcw4 | or | 13:29 |
| jcw4 | https://api.launchpad.net/devel/juju-core?ws.op=searchTasks&status%3Alist=Triaged&status%3Alist=In+Progress&importance%3Alist=Critical&tags%3Alist=regression&tags%3Alist=ci&tags_combinator=All | 13:29 |
| jcw4 | mgz, sinzui bug 1384175 shows as fixed in LP | 13:30 |
| mup | Bug #1384175: Utopic test failures due to addition of vivid series <ci> <regression> <test-failure> <vivid> <juju-core:Fix Committed by thumper> <juju-core 1.20:Triaged by anastasia-macmood> <https://launchpad.net/bugs/1384175> | 13:30 |
| mgz | jcw4: it's only fix committed atm | 13:31 |
| mgz | it requires fix released | 13:31 |
| mgz | which I will mark now, as the utopic unit tests are blue | 13:32 |
| mgz | jcw4: go wild | 13:32 |
| jcw4 | mgz: I see; I need to update my bookmark for checking blockers :) | 13:32 |
| jcw4 | woo hoo | 13:32 |
| sinzui | mgz, jcw4 : We are finishing of the test run and we can see the test will be declared a pass. I will mark the bug as fix released | 13:34 |
| jcw4 | sinzui: ta (mgz beat you to marking the bug as fix released though) | 13:35 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: None | ||
| sinzui | natefinch, is anyone working on a backport of the vivid and ppc64el test fixes to 1.20? | 13:46 |
| natefinch | sinzui: yeah, me or someone to whom I delegate | 13:48 |
| * perrito666 ducks | 13:48 | |
| sinzui | natefinch, :) I never assume it is you when I ask, I just hope you know the answer | 13:48 |
| natefinch | sinzui: probably a good assumption ;) | 13:49 |
| ericsnow | natefinch, perrito666: standup? | 14:06 |
| perrito666 | ericsnow: natefinch just moved it | 14:06 |
| perrito666 | you should have a new invite | 14:06 |
| natefinch | ericsnow: sorry... there's a tosca meeting today that always conflicts, I should have moved today's meeting like 2 months ago | 14:07 |
| gsamfira | fwereade, bodganteleaga: so there are essentially 2 major aspects that need to get fixed to have all tests that require to generate/upload tools to work (and also fix the metadata plugin). First one is the obvious problem of having colons in filenames written to disk. The other is the file:// handler the http module uses to fetch local files. | 14:07 |
| ericsnow | natefinch: forgot to refresh my calendar | 14:08 |
| gsamfira | fwereade, bodganteleaga: changing the filename that gets written to disk should not impact functionality. We can do this for bith windows and linux. What is a bit wonky is the file:// handler | 14:08 |
| fwereade | gsamfira, ah, so file:// urls won't work right on windows? | 14:09 |
| natefinch | file:// works fine on windows actually | 14:09 |
| gsamfira | they do work, but not the way juju uses them | 14:09 |
| natefinch | heh | 14:09 |
| fwereade | gsamfira, I'd be entirely happy to have FileStorage run an http server and just happen to use an FS backend | 14:09 |
| gsamfira | fwereade: on linux we register '/' as the root for file:// | 14:10 |
| fwereade | gsamfira, I think we already have an HTTPStorage like that anyway? | 14:10 |
| natefinch | fwereade: do we really want to change the whole way filestorage works just to avoid using colons? I think getting this done sooner rather than later is more important than making it perfect. | 14:10 |
| gsamfira | for that bit, it would be ok to use a small http server for tests only | 14:10 |
| gsamfira | BUT, there comes the need to generate simpolestreams files using the client | 14:10 |
| gsamfira | fwereade: for example, the juju-metadata plugin | 14:11 |
| fwereade | gsamfira, sure, understood | 14:11 |
| gsamfira | that plugin uses file:// iirc | 14:11 |
| fwereade | gsamfira, my position there is that we have a *huge* number of tests not passing thanks to FileStorage | 14:11 |
| fwereade | gsamfira, which equates to a huge proportion of juju not working, or at best working by coincidence | 14:11 |
| gsamfira | huge is right :) | 14:11 |
| fwereade | gsamfira, so fixing filestorage is the important thing | 14:12 |
| fwereade | gsamfira, because we believe that's just a test problem | 14:12 |
| gsamfira | fwereade : *local* file storage | 14:12 |
| fwereade | gsamfira, metadata doesn't work anyway | 14:12 |
| fwereade | gsamfira, and IMO it strictly comes behind fixing the tests that we believe are spurious failures | 14:12 |
| fwereade | gsamfira, certainty on the bits that do work comes first | 14:13 |
| gsamfira | fwereade: there is another option. The way file:// is mapped now, assumes that we have a root folder. On linux using "/" is fine, because any volume is mounted under that. On windows we have drive letters (unfortunately). So A possible solution would be to implement a version of http.NewFilesystemHandler() that does not chroot all requests inside a folder | 14:14 |
| gsamfira | and simply does a os.Stat() | 14:14 |
| gsamfira | if the file is local, just serve it | 14:14 |
| gsamfira | instead of doing filepath.Join(rootDir, filename) | 14:14 |
| gsamfira | and then serving it | 14:14 |
| gsamfira | then we would be able to have file://C:/my awesome/file | 14:15 |
| katco | can i get a quick lgtm on a 2-line change? http://reviews.vapour.ws/r/236/diff/# | 14:15 |
| gsamfira | kind of the same way every other browser on the planed does it | 14:15 |
| gsamfira | :) | 14:15 |
| fwereade | gsamfira, bogdanteleaga: do we need the full path there anyway? since we register the handler anyway, can we not just have file:// defined as relative to rootDir? | 14:15 |
| gsamfira | we can, but then we need to strip the drive letteer every time. Juju generates full paths most times | 14:16 |
| gsamfira | so juju will most times pass: "C:/path/to/file" | 14:16 |
| gsamfira | fwereade: so paths would become file://C:/path/to/file | 14:17 |
| fwereade | gsamfira, why would we need to strip the drive letter other than inside FileStorage? | 14:17 |
| gsamfira | if we chroot NewFilesystemHandler to C:/ | 14:17 |
| gsamfira | and pass in C:/path | 14:18 |
| gsamfira | file would look for C:/C:/path | 14:18 |
| fwereade | gsamfira, why would we be passing in C:/anything? | 14:18 |
| gsamfira | fwereade: because that's how juju generates all paths :) | 14:18 |
| fwereade | gsamfira, all I care about is that URL() returns something that's a valid url, that we can write a handler for that goes back to the right place | 14:18 |
| fwereade | gsamfira, er, what? | 14:18 |
| fwereade | gsamfira, the Storage interface has complete control | 14:19 |
| fwereade | gsamfira, the fullPath thing looks like the problem here | 14:19 |
| fwereade | gsamfira, that's how FileStorage works now | 14:19 |
| fwereade | gsamfira, but it evidently doesn't work right on windows | 14:19 |
| fwereade | gsamfira, so lng as we end up with (1) FileStorage working on windows and (2) none of the client code having to dick around with windows-isms to use FileStorage, I'm happy | 14:20 |
| gsamfira | cool | 14:20 |
| fwereade | gsamfira, in fact, (2) beats out (1) | 14:23 |
| fwereade | gsamfira, if we can't eliminate the windows-isms, I'd be perfectly happyto see HTTPStorage used instead | 14:24 |
| fwereade | gsamfira, tedious that it'd need cleanup | 14:24 |
| fwereade | gsamfira, but really, whatever minimal-friction Storage interface we can get is what we need | 14:24 |
| gsamfira | fwereade: so then what needs to happen now is: 1) have fullPath return a correct path on windows 2) chroot in C:/ on windows (for now) 3) filenames need to contain valid characters on both OS | 14:24 |
| fwereade | gsamfira, I think I'm suggesting that we should drop the notion of fullPath entirely | 14:25 |
| bogdanteleaga | fwereade: are you talking about the URL functions in environs on (2)? | 14:25 |
| fwereade | gsamfira, register the stupidTestFile:// handler if we have to | 14:25 |
| fwereade | gsamfira, nobody should be using file:// urls in anything other than a test context anyway afaics | 14:25 |
| fwereade | gsamfira, except for wget in that special cloudinit case, which I don';t think is underconsideration here | 14:26 |
| fwereade | gsamfira, is it? | 14:26 |
| gsamfira | nope | 14:26 |
| katco | jam: hey i see you're ocr, do you have time to give a quick look at a 2-line change? http://reviews.vapour.ws/r/236/diff/# | 14:26 |
| fwereade | katco, not 100% sure about that -- I think we want to prioritise speed in the local provider, and for thumper to finish his local provider plugin that will give us better handling of image updates | 14:38 |
| fwereade | katco, am I misunderstanding? | 14:39 |
| katco | fwereade: i am definitely getting mixed messages on this | 14:39 |
| katco | fwereade: originally that was what we were going for | 14:39 |
| sinzui | natefinch, https://bugs.launchpad.net/juju-core/+bug/1370149 | 14:39 |
| mup | Bug #1370149: No defined 'state-servers' on environment file after bootstrap, works after run 'juju status' <bootstrap> <cloud-installer> <cts-cloud-review> <juju-core:Triaged> <https://launchpad.net/bugs/1370149> | 14:39 |
| katco | fwereade: but wallyworld_ asked me to make this change, and i think there are a few others who would like to see this behavior | 14:39 |
| fwereade | katco, dammit | 14:40 |
| fwereade | katco, do you know where the requirement came from upstream of wallyworld_? | 14:40 |
| katco | fwereade: it can sit there a bit longer until there's some consensus. i'm only trying to finish it on wallyworld_'s behest before the eow | 14:40 |
| katco | fwereade: let me do some digging rq | 14:41 |
| fwereade | katco, cool, thanks | 14:41 |
| fwereade | katco, the code looks fine fwiw | 14:41 |
| wwitzel3 | fwereade: ping, and I good to start on the juju-run side of things? | 14:47 |
| wwitzel3 | s/and/am | 14:47 |
| fwereade | wwitzel3, I've been hoping for a review of http://reviews.vapour.ws/r/234/ | 14:55 |
| fwereade | wwitzel3, if I can hassle you for a review of that, and maybe 1 followup, you should be good to go | 14:58 |
| fwereade | wwitzel3, they're both a lot simpler than they look, they're really just moves... | 14:58 |
| voidspace | TheMue: so you point out in your review that the test doesn't use the constant for "none" | 15:04 |
| voidspace | TheMue: this is because the constant is not available in the test namespace | 15:04 |
| voidspace | TheMue: but it isn't a potential source of error | 15:04 |
| voidspace | TheMue: if the string literal is wrong then the test will fail | 15:04 |
| voidspace | TheMue: the same applies for the "default-vpc" | 15:04 |
| voidspace | TheMue: so I don't think there's much value in defining constants just for those test uses | 15:05 |
| voidspace | TheMue: as they provide no actual value | 15:05 |
| voidspace | (s/namespace/package/) | 15:05 |
| TheMue | voidspace: ok, can live with it. only always get a bit scary of typos when seeing repeating strings | 15:06 |
| voidspace | TheMue: I understand | 15:06 |
| voidspace | TheMue: but for a single use string literal (the test "none") the const is just as likely to have the typo... and it's now non-locally to the test | 15:06 |
| voidspace | TheMue: so you're even less likely to see it! | 15:06 |
| voidspace | TheMue: more importantly though, for these literals, a typo will cause an actual failure | 15:07 |
| voidspace | so I don't think there's a danger in *these* cases | 15:07 |
| TheMue | voidspace: yep, in your case it's ok. | 15:07 |
| voidspace | TheMue: thanks, can I have a "ShipIt"? | 15:07 |
| TheMue | voidspace: didn't I already gave you one? | 15:09 |
| * TheMue -> looking | 15:09 | |
| voidspace | TheMue: I didn't think so | 15:09 |
| voidspace | I may just have not seen it :-) | 15:09 |
| TheMue | voidspace: it has been a fix it, then ship it. now it's only a ship it. :) | 15:10 |
| voidspace | Haha, ok thanks | 15:10 |
| * fwereade has frightened wwitzel3 away :( | 15:22 | |
| voidspace | that's an achievement | 15:22 |
| voidspace | he's pretty hard to frighten | 15:22 |
| fwereade | ok, cath will be justifiably upset with me if I don't go and see the blue lagoon before the sun sets | 15:23 |
| fwereade | I hope I will make it back on tonight | 15:24 |
| fwereade | but then I meant to do that yesterday, and ended up sleeping 12 hours or something | 15:24 |
| voidspace | fwereade: o/ night | 15:26 |
| voidspace | fwereade: enjoy the lagoon :-) | 15:26 |
| fwereade | voidspace, cheers | 15:27 |
| voidspace | PANIC: machine_test.go:70: MachineSuite.TestSetRebootFlagDeadMachineRace | 15:27 |
| fwereade | natefinch, I appoint you answerer of questions while I'm out ;p | 15:27 |
| voidspace | ... value *errors.Err = &errors.Err{message:"", cause:(*net.OpError)(0xc210362380), previous:(*errors.Err)(0xc21041f690), file:"github.com/juju/juju/state/open.go", line:68} ("cannot create log collection: local error: bad record MAC: local error: bad record MAC") | 15:27 |
| voidspace | ^^^ familiar anyone? | 15:27 |
| natefinch | voidspace: wacky... | 15:32 |
| voidspace | natefinch: that was a buildbot failure for my merge | 15:32 |
| voidspace | didn't fail locally | 15:32 |
| voidspace | will retry | 15:33 |
| natefinch | voidspace: that's a tls error... almost certainly not a code problem | 15:34 |
| perrito666 | voidspace: saw it then when I tried to reproduce it it was gone | 15:34 |
| voidspace | natefinch: perrito666: thanks | 15:35 |
| mgz | gsamfira: do you have a mo, I'm trying to understand some kardianos/service dep weirdness | 16:06 |
| gsamfira | mgz: sure. I will gladly help if I can | 16:07 |
| natefinch | mgz: doh, is it causing a problem? I just changed the deps yesterday so godeps -t ./... would produce the right output | 16:07 |
| mgz | natefinch: maybe? I didn't see your change *doing* anything to the windows deps though | 16:08 |
| mgz | it just seems like kardianos/service/service_windows.go needs code.google.com/p/winsvc - which we don't have as a dep | 16:08 |
| mgz | but this *did* build before, and I can't see what has changed | 16:09 |
| mgz | gsamfira: so, do we need to build that file, and is it actually a dep? | 16:10 |
| gsamfira | mgz: the kardianos/service is actually a wrapper for winsvc (on windows) | 16:11 |
| gsamfira | so yeah | 16:11 |
| natefinch | weird that godeps isn't picking that up | 16:12 |
| natefinch | ahh... I see, it's only included in an _windows.go file | 16:13 |
| natefinch | I'm surprised it built before if we weren't including that package. Do we build the windows code differently? | 16:16 |
| mgz | natefinch: not deliberately, but perhaps | 16:18 |
| mgz | so, I'll just file a bug, and we add the dep now I guess | 16:18 |
| natefinch | yeah | 16:18 |
| * natefinch grumbles about not using go get | 16:18 | |
| mgz | it does, but we try and make our tarball make sense, mostly for ubuntu's benefit (they have to document all the licences of all the deps and such like) | 16:20 |
| mgz | so, this is a bit of an edge case in that they don't really need to care about windows-only dependencies, but life is still somewhat easier if we actually know what our code needs to build | 16:20 |
| jamespage | dimitern, hey - just noticed that juju 1.21 started accessing the bootstrap node via its IPv6 address ;-) | 16:34 |
| dimitern | jamespage, hey, yeah - esp. if you set prefer-ipv6: true in env.yaml :) | 16:37 |
| jamespage | dimitern, ooooooo | 16:37 |
| dimitern | but apart from that, prefer-ipv6 does not do much | 16:38 |
| dimitern | (yet) | 16:38 |
| mgz | gsamfira: filed bug 1384818 | 16:49 |
| mup | Bug #1384818: Windows service dependency missing <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1384818> | 16:49 |
| mgz | we probably also want to change the 1.20 branch | 16:49 |
| sinzui | natefinch, mgz, do either of you have a minute to review https://github.com/juju/juju/pull/955 | 17:35 |
| natefinch | sinzui: LGTMd | 17:44 |
| sinzui | thank you natefinch | 17:44 |
| voidspace | g'night all | 18:10 |
| natefinch | this is why I never write bash scripts.... because stuff that looks like it should absolutely work, just doesn't | 18:38 |
| natefinch | wtf is wrong with this: #!/bin/bash | 18:39 |
| natefinch | export GOPATH=$HOME | 18:39 |
| natefinch | go get gopkg.in/yaml.v1 | 18:39 |
| natefinch | ^^^ says GOPATH is not set | 18:39 |
| natefinch | how is that possible? | 18:39 |
| perrito666 | natefinch: its most likely your fault :p | 18:58 |
| perrito666 | natefinch: pastebin the whole thing | 18:59 |
| natefinch | http://pastebin.ubuntu.com/8644139/ | 19:00 |
| natefinch | it's an install hook where I tried to do the "right thing" by using go run. But seriously... this is why I never write bash scripts | 19:00 |
| perrito666 | natefinch: I noticed | 19:00 |
| perrito666 | natefinch: you can ditch the export | 19:00 |
| natefinch | ok | 19:00 |
| natefinch | is that what's screwing me? | 19:00 |
| perrito666 | nope | 19:01 |
| natefinch | lol | 19:01 |
| perrito666 | although you are assuming that $HOME actually has something | 19:01 |
| perrito666 | since its bash you can safely use ~ | 19:01 |
| natefinch | yeah, I thought of that | 19:01 |
| perrito666 | mm, re thinking keep the export I am not sure what go get does inside | 19:02 |
| thumper | morning folks | 19:06 |
| perrito666 | morning t | 19:06 |
| perrito666 | meh, too many t people | 19:06 |
| TheMue | thumper: morning | 19:06 |
| thumper | hmm... | 19:40 |
| thumper | both the on call reviewers for Friday still think it is Thursday | 19:41 |
| thumper | :-( | 19:41 |
| thumper | that wasn't well planned | 19:41 |
| perrito666 | thumper: well I also think there is some thursdayness in the day | 19:42 |
| perrito666 | the fun part is that both thursday reviewers think its friay | 19:43 |
| perrito666 | friday* | 19:43 |
| thumper | anyone? http://reviews.vapour.ws/r/254/diff/ | 19:45 |
| ashipika | http://reviews.vapour.ws/r/247/ | 19:45 |
| perrito666 | thumper: done | 19:49 |
| thumper | perrito666: ta | 19:49 |
| menn0 | thumper: I've just responded to your review comments for 175 | 20:51 |
| menn0 | thumper: one thing though, can you explain why it's preferable to use a non-LTS series for machines in tests? | 20:51 |
| thumper | menn0: histerical raisins | 20:52 |
| thumper | I'm sure there was a rational reason at some stage | 20:52 |
| thumper | but I don't recall what it was | 20:52 |
| menn0 | thumper: ok np | 20:52 |
| menn0 | thumper: gah! I've just noticed that envUserDoc uses "envuuid" instead of "env-uuid" | 20:54 |
| thumper | :-( | 20:54 |
| menn0 | thumper: we've been using env-uuid for the migrated collections | 20:54 |
| thumper | which is good | 20:54 |
| menn0 | thumper: should we fix now while it's new? | 20:55 |
| thumper | I think the dashes make it more readable | 20:55 |
| menn0 | thumper: I noticed because I was thinking about machineid vs machine-id | 20:55 |
| menn0 | thumper: I think we should settle on machine-id and make the pre-existing fields consistent | 20:56 |
| thumper | +1 | 20:56 |
| menn0 | thumper: what about envUserDoc? that's just been released hasn't it? | 20:58 |
| thumper | we should migrate it, not just assume | 20:58 |
| menn0 | thumper: ok | 20:58 |
| menn0 | thumper: I'll do that as a separate branch | 20:59 |
| menn0 | thumper: onyx standup hangout? | 21:01 |
| thumper | sure, there in 2 m | 21:01 |
| === arosales_ is now known as arosales | ||
| wallyworld_ | thumper: hey | 22:33 |
| thumper | o/ | 22:33 |
| wallyworld_ | a question when you were offline | 22:33 |
| wallyworld_ | <fwereade_> does anyone know why we use an abstract socket for the jujuc server, but a filepath socket for the juju-run listener? | 22:33 |
| wallyworld_ | answer? | 22:33 |
| thumper | if there was a reason, I don't recall it now | 22:34 |
| wallyworld_ | ok :-) | 22:34 |
| thumper | I do think there may have been a reason | 22:34 |
| thumper | actually I think I do know | 22:34 |
| wallyworld_ | next time you "see" william, maybe touch base with him about it | 22:34 |
| thumper | jujuc used to use a filepath one too | 22:34 |
| thumper | perhpas this was changed for the windows work | 22:35 |
| wallyworld_ | ah ok | 22:35 |
| thumper | without them realisign about the juju-run one | 22:35 |
| wallyworld_ | makes sense | 22:35 |
| thumper | menn0: have you updated the rb diff with the latest stuff? | 22:58 |
| thumper | menn0: although I have noticed that when you push to github, it gets the diff updated | 22:58 |
| thumper | menn0: I'm still seeing "machineid" and I thought you were changing | 22:59 |
| menn0 | thumper: nope. just finishing off the bit to move the upgrade steps to 1.21alpha3 | 22:59 |
| thumper | ok... | 22:59 |
| thumper | I'll go to exercise before reviewing then | 22:59 |
| thumper | wallyworld_: can we chat this afternoon about the local charmstore integration? | 22:59 |
| menn0 | thumper: the tests in the upgrades package were lacking so I'm fixing them too | 22:59 |
| menn0 | thumper: give me 10 mins | 22:59 |
| thumper | np | 22:59 |
| thumper | menn0: take an hour :) | 23:00 |
| menn0 | thumper: I have to take my son swimming soon so it'll be much less than that | 23:00 |
| menn0 | thumper: done | 23:07 |
| wallyworld_ | thumper: sure, just ping when you want to talk | 23:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!