[00:27] thumper: http://reviews.vapour.ws/r/177/ [01:44] davecheney: could u please review http://reviews.vapour.ws/r/235/ - it'd b gr8 to land it :-) [01:44] anastasiamac: sure [01:45] davecheney: thnx! [01:46] anastasiamac: not lgtm [01:46] sorry [01:46] config.AgentMetadataURLKey: " [01:46] i don't think this payus for itself [01:46] 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:47] the reason I say this is [01:47] all the test fixtures still assert it's a constant [01:47] davecheney: u mean using variables instead of string? [01:47] yup [01:47] thumper: https://github.com/mjs/juju/commit/b7f48aa500f6aba285320c6a4aa184736d287b1a [01:47] anastasiamac: all the fixtures still encode the string directly [01:47] so does the documentation and the examples [01:47] i don't feel this pays for itself [01:48] 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] thumper: it's actually mostly done, except for some unit test changes [01:48] ok, it doesn't look TOO long [01:48] davecheney: m not big fan of retyping the same string. if a string is used more thn once, it should b a variable... [01:49] thumper: it's a bit horrible but the horribleness is fairly localised [01:49] anastasiamac: but you ended up typing a slightly longer variable ... [01:50] thumper: instead of storing and using a DB version, the code checks for evidence of the upgrade being in place [01:50] thumper: this is safer IMHO [01:51] thumper: because otherwise you end up with points in time where the DB has been changed but the version hasn't [01:51] thumper: i will be late for the team meeting [01:51] have 1:1 with robbiew [01:51] kk [01:54] ericsnow: reviews.ws has gone back to reporting it's ec2 url again [01:54] just got another email from the wrong address [01:56] davecheney: :-) what length would u consider k for a variable? also should the name be descriptive? eg. here would AgentURL be k? [01:56] davecheney: (╯°□°)╯︵ ┻━┻ [01:57] thumper: does this approach look ok to you? [01:58] * thumper looks in detail [01:58] anastasiamac: I like descriptive names [01:58] please don't be sucked in to thinking shorter is better [01:58] * thumper is opinionated on this [01:59] thumper: i agree. shorter is not always practical.. [01:59] thumper: by the same token, metadata is 8 chars... ;-( [01:59] anastasiamac: i'm not arguging about the length [02:00] its the fact that this change doesn't pay for itself [02:00] you can't turn all the test fixtures into variables as well [02:00] or the examples [02:00] or the documentation [02:00] or the yaml keys [02:00] etc [02:02] menn0: mostly looks ok [02:02] not gone through in exceptional detail yet [02:36] seriously, i missed the meeting ? [02:49] davecheney: yeah... [02:49] davecheney: we were done in 15 minutes [02:51] davecheney: it seems that rb doesn't pick up juju/cmd [02:51] https://github.com/juju/cmd/pull/8 [02:53] wallyworld_: or you maybe? ^^^ [02:53] or axw... [02:53] wot [02:53] simple change [02:53] ok [02:53] juju/cmd update [02:56] thumper: are other sub command affected besides juju user? [02:57] wallyworld_: it only impacted nested subcommands [02:57] and only if you didn't say anything else [02:57] ok [02:57] so 'juju user' would miss out the 'juju' prefix in the help output [02:57] juju user --help was fine [02:57] juju user help add was fine [02:57] juju user add --help was fine [02:58] juju user was not [02:58] ack [02:58] sadly you still need to hit the merge button manually for this sub repo i think [02:58] will do [02:59] wallyworld_: I also noticed that all the licences were wrong [02:59] wallyworld_: I'll submit another quick one to fix that [02:59] for cmd/juju? [02:59] i thought robbie had audited everything [03:00] it still shows AGPL [03:00] instead of LGPL with exception [03:03] OH FFS [03:03] should the file be LICENCE or LICENSE? [03:04] we have a mix [03:04] LICENSE [03:04] according to the world [03:05] thumper: one is noun, on is verb.. [03:07] WTF?... [03:07] thumper: ~ce (from French/Latin), ~se (from Mid English)... [03:07] * thumper found a weird file... [03:10] wallyworld_: https://github.com/juju/cmd/pull/9 [03:11] ceis noun [03:11] se is verb [03:11] like practice and practise [03:11] and advise and advice [03:11] I always get that shit wrong [03:11] wallyworld_: so in that PR, you'll notice I also remove names.go [03:11] easy to remember - ice is a noun' [03:11] which should never have been there in the first place [03:12] ok [03:12] why are we changing LICEENCE to be incorrectly spelt? [03:12] oh the irony. LICENCE [03:13] because this is what the world has [03:13] oh it also appears to be an americanism [03:14] yes :-( [03:14] americans cannot spell for shit [03:14] http://oss-watch.ac.uk/resources/opensourceyourcode#applying-the-licence [03:14] says to have LICENSE [03:14] we are an englidh company [03:14] not LICENCE [03:14] english [03:14] that is a .uk site [03:14] but the farking url says licence [03:15] notice the header: Applying The Licence [03:15] sigh [03:15] GNU LESSER GENERAL PUBLIC LICENSE [03:15] notice the SE [03:15] but but but [03:15] sigh [03:15] don't shoot me [03:15] I'm just trying to be consistent [03:15] they know it's wrong or else why have licence in their url [03:15] sigh [03:16] thumper: be original and say it in german [03:16] :P [03:16] "es" [03:16] or "der" or "sie" depending on gender [03:16] did I pass? [03:18] thumper: it's spelt COPYING [03:19] ha [03:30] thumper: PTAL http://reviews.vapour.ws/r/175/ [03:30] menn0: kk, need to look at waigani's first [03:31] thumper: np [03:46] 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:47] wallyworld_: and the backups command test checks for a wrong usage :-) [03:59] \o/ === urulama_eod is now known as urulama === TheRealMue is now known as TheMue [07:14] 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:22] 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:23] wallyworld_, I'll see what Ican do, thanks [07:23] you rock [07:55] morning everyone [08:34] mattyw, updated http://reviews.vapour.ws/r/234/diff/ [08:34] mattyw, fwiw, it's almost all just moves [08:35] 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:43] fwereade_, ok great, I'll take a look this afternoon [09:04] dimitern: ping [09:08] voidspace, pong, give me 20m please, doing a test now [09:11] sure [09:40] does anyone know why we use an abstract socket for the jujuc server, but a filepath socket for the juju-run listener? [09:41] wallyworld_, when you return, ^^ -- on the basis that you're sort of near thumper and might know why he did it [10:26] gsamfira, does juju-run work on windows? [10:27] gsamfira, the tests have linux stuff hardcoded, I don't see how they can run [10:28] 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] gsamfira, if the tests don't pass, I don't really consider it working ;p [10:28] those tests have yet to be fixed on windows [10:28] gsamfira, what's the progress there? [10:29] yeah, a little more then half the tests pass on windows [10:29] gsamfira, because, you know, code without tests *is* fundamentally broken [10:29] fwereade_: my colleagues are working on the tests [10:29] gsamfira, in the same way that data without offsite backups only happens to exist by coincidence [10:29] gsamfira, I know, and I'm glad that they are, I'm just stressing about it a bit [10:30] gsamfira, do you have an ETA? [10:30] 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] so com.ubuntu.juju:series:foo [10:30] gsamfira, tedious -- which files are those? [10:30] cannot be written on windows [10:31] gsamfira, where would they come up? simplestreams? [10:31] for those files some normalization needs to happen (the juju-metadata plugin fails for the same reasons) [10:31] yep [10:31] simplestreams [10:31] and a ton of tests rely on those [10:32] let me ping bogdanteleaga to get the status of that [10:32] gsamfira, I strongly recommend you talk to wallyworld about that [10:33] gsamfira, gut feeling says there should be a simple way around that, and we shouldn't depend on those FS paths [10:33] I think bogdan has been in touch with wallyworld [10:33] gsamfira, ok, fantastic [10:34] most likely after the Paris ODS, I'll be joining in to work on the tests. [10:35] fwereade_: right now we are in crunch mode for the summit in openstack [10:36] 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] fwereade_: understood [10:37] 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] fwereade_: I would suggest we disable all tests that fail on windows ATM, and enable them as they get fixed [10:38] fwereade_: so yes. it is worth doing :) [10:39] gsamfira, mgz: ok, I'd be fine with a SkipWindows() func we jam into the failing tests, or something [10:39] gsamfira: fwereade_ : there's a bug nate is aware of to change the file paths to be windows compatible [10:39] gsamfira, mgz: can I leave you guys to coordinate getting that done somehow? [10:39] wallyworld_, so we're reading dirs with tools in that format? [10:39] fwereade_: thanks for helping with the relation stuff - i was not across those older bugs in previous versions [10:40] wallyworld_, ok, good to know [10:40] wallyworld_, yw :) [10:40] fwereade_: we're reading dirs with file names containing : [10:40] which is fine for linux [10:40] wallyworld_, yeah [10:41] wallyworld_, gsamfira: I guess I'm a bit surprised that the :s are problematic for a large proportion of the tests, though [10:41] wallyworld_, I can understand how they'd mess up the metadata ones [10:41] fwereade_: so skimming the back scroll in #juju, their issues were caused by bugs in 1.16.5? [10:42] wallyworld_, I *think* so, yeah [10:42] wallyworld_, the units were coming up and believing they weren't in the relations they actually were [10:42] fwereade_: gsamfira: many tests set up fake metadata, writing files with :, hence they fail [10:42] 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] fwereade_, wallyworld_ : bogdanteleaga proposed a fix for the : files [10:42] https://github.com/juju/juju/pull/908 [10:43] wallyworld_, oh ok -- can we get around that by not writing the metadata to the filesystem? [10:43] wallyworld_, or just fixing the FS storage to map : paths to something else? [10:43] wallyworld_, hell just urlencide all paths? [10:43] 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:44] fwereade_: we originally used : because that's what the simplestreams folks did onthe public web server [10:44] fwereade_, wallyworld_ : https://github.com/juju/juju/pull/908 <-- I think this should do [10:44] easy enough just to change the : to - [10:45] gsamfira: ok, will look soon, gotta have dinner after coming hie from soccer [10:45] home [10:45] 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] gsamfira, wallyworld_: that CL scares the life out of me tbh [10:46] gsamfira, wallyworld_: way too many arbitrary-lookin changes in arbitrary-looking places [10:46] gsamfira, wallyworld_: why wouldn't just encoding internal paths work? [10:46] gsamfira, wallyworld_: the metadata fixes would be different but they feel like they really *are* different [10:46] or just notusing filenames with : in them [10:47] gsamfira, wallyworld_: they're about parsing a particular FS structure [10:47] the metadata is fine on either os - it's the filenames that need changing unless i am missing something [10:47] gsamfira, wallyworld_: why wouldn't we just make :s work in Storage paths? [10:47] gsamfira, wallyworld_: the solution to a leaky abstraction is to fix the leak [10:47] fwereade_: the json files are written to disk [10:47] gsamfira, wallyworld_: not to add duct tape in 10 other files [10:48] fwereade_: i've had no input to the CL, not seen it yet [10:48] nor [10:48] wallyworld_, and? the Storage names can have :s just fine, we just need to encode them differently for the FS, surely? [10:48] sure, but why do that? the file names are totally arbitrary [10:49] just make file names compatible with all os's [10:50] wallyworld_, yes [10:50] wallyworld_, that shoudl be completely hidden behind the Storage interface [10:50] yep [10:50] but don't forget [10:50] wallyworld_, not splattered across the codebase everywhere we *happen* to have noticed a problem today [10:50] we generate files on disk also [10:51] we just need to change *1* method [10:51] wallyworld_, I understand that the metadata plugin is a separate issue [10:51] 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] gsamfira, that is true as well [10:52] fwereade_: the metadata plugin uses the same filenames/constants. if we fix the metadata plugin, we fix most tests [10:52] 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] changing this const should work [10:52] ProductMetadataPath = "streams/v1/com.ubuntu.cloud:released:imagemetadata.json [10:53] fwereade_: agreed, i'm not sure of the current mix of tests which use storage vs fs metadata [10:53] but regardless, changing a const should fix everything [10:53] sorry guys, my lunch is getting cold [10:53] wallyworld_, it wil *not* [10:53] wallyworld_, it will fix *one symptom* of the underlying problem [10:53] wallyworld_, which is that our FS storage abstraction is leaky and fails on windows [10:53] ok, we can talk after your lunch [10:54] wallyworld_, cheers :) [10:55] wallyworld_, there is also this: https://github.com/juju/juju/blob/master/environs/tools/marshal.go#L21 [10:55] and the one immediately bellow that [10:55] gsamfira: yes, i knew that was there but didn;t find the method in time to type it in [10:55] there's a couple of places where we generate the filename [10:57] wallyworld_: if we can create a constant with those names, that would be great [10:57] bogdanteleaga: can you try changing the filenames and see if that works on both windows and linux ? [10:58] gsamfira: the content id doesn't need to change [10:58] just the file name [10:58] there's quite a lot of places where there are :'s, mostly are sptrintf'd [10:58] and we have some tests where they are hardcoded [10:58] it's only the file names isn't it? [10:58] but it's pretty doable [10:58] yes [10:58] the content ids should be fine [10:58] content ids are fine, yes [10:59] so there should be a small number of places where filenames are generated, these just need to have the : replaced [10:59] only paths inside index.json (and of course the names on disk) need to change [11:00] and what about files online? [11:00] there's no difference between the offline and offline paths, they're generated from the same string [11:00] bogdanteleaga: those can be replaced. the index.json is the only one of consequence, and we don't touch that [11:01] so the path to the file containing information about tools in in the index.json file [11:01] the online ones are url paths [11:01] http://paste.ubuntu.com/8639101/ [11:01] it's just windows fs that is broken :-( [11:02] the "path" inside this file tells you where to find the tools information. [11:03] wallyworld_: yeah...unfortunately...windows uses ":" for drive letters.... [11:03] stupid windows, stupid drive letters [11:04] wallyworld_: ....amen [11:06] wallyworld_: its funny because windows also has UNC paths, which would be nicer to use in general... [11:08] yeah, go figure [11:49] morning [11:52] perrito666: morning [12:42] natefinch: https://github.com/juju/juju/pull/928 care to take a second look? [12:44] fwereade: question about timestamps in action docs [12:44] fwereade: creation time and completion time are straightforward [12:45] fwereade: capturing start time (i.e. when the action is picked up and started) is a little tricky. [12:46] fwereade: we chose to only write actionDoc once when enqueing it, and then writing a new actionResultDoc when done [12:47] fwereade: so that the watchers can be efficient about detecting new actions, and not fire when we *update* the actionDoc [12:47] 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:49] jcw4, can we plausibly write the beginnings of the actionResultDoc when we start? [12:49] fwereade: that's the only thing that makes sense to me [12:49] 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] bodie_, was there any progress there? [12:50] 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:52] 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] at least this way it'd be clear from the actionResultDoc that a unit tried to start working on it [12:53] jcw4, yeah, I think that would be handy [12:53] jcw4, the uniter has responsibilities if it goes down mid-action [12:53] 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] jcw4, the uniter responsibilities are one of my major concerns, though [12:53] bodie_, ^^ [12:54] fwereade: do we already have mechanisms in place for uniter cleanup ? [12:54] before the big hammer of state-server-side cleanup [12:54] jcw4, we're *meant* to [12:55] jcw4, everything the uniter does can pick itself up and recover if it's kill -9'd at any time [12:55] jcw4, *except* actions [12:55] ooh [12:55] jcw4, to be fair, it's pretty easy [12:55] jcw4, it just needs to detect and handle it in ModeContinue [12:56] 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] jcw4, I'm inclined to make it local, actually [12:56] hmm; interesting [12:56] jcw4, we do already record that fact locally [12:56] i see [12:56] jcw4, just got factored out into uniter/operation package [12:57] fwereade: I saw your emails about that refactor, but haven't looked at the diff [12:57] fwereade: I'll check it out too [12:57] jcw4, the reason we no longer run actions in error states is because the current implementation smashes op-error state [12:57] jcw4, this does need to be fixed :) [12:58] fwereade: the current implementation of action handling in uniter you mean? [12:58] jcw4, yeah, it's just writing out hook state [12:58] jcw4, which smashes pre-existing hook-pending state [12:59] fwereade: ah; I see. [12:59] jcw4, which is how the uniter can tell it was interrupted running one, and hence should be in error mode [13:00] 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:02] fwereade: +1 [13:02] 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] jcw4, that sounds good to me [13:02] jcw4, take a look at the metrics stuff [13:03] jcw4, I can't remember how they do that [13:03] jcw4, if it's good, do the same [13:03] fwereade: okay - I did see some code there [13:03] jcw4, if it's not, please fix both ;p [13:03] jcw4, and maybe sling thumper a mail? I suspect he is, or soon will be, doing something like that re user stuff [13:04] 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] It seems like a TimeProvider interface or something would be good [13:04] jcw4, +1 to that [13:04] axw, ping [13:11] dimitern, are you able to do a trivial review? http://reviews.vapour.ws/r/248/ [13:12] mattyw, sure, looking [13:28] mgz, sinzui any idea why CI keeps failing on Does not match ['fixes-1384175'] ? [13:29] that bug doesn't show up in the critical bugs on lp [13:29] 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] or [13:29] 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:30] mgz, sinzui bug 1384175 shows as fixed in LP [13:30] Bug #1384175: Utopic test failures due to addition of vivid series

[13:31] jcw4: it's only fix committed atm [13:31] it requires fix released [13:32] which I will mark now, as the utopic unit tests are blue [13:32] jcw4: go wild [13:32] mgz: I see; I need to update my bookmark for checking blockers :) [13:32] woo hoo [13:34] 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:35] sinzui: ta (mgz beat you to marking the bug as fix released though) === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: None [13:46] natefinch, is anyone working on a backport of the vivid and ppc64el test fixes to 1.20? [13:48] sinzui: yeah, me or someone to whom I delegate [13:48] * perrito666 ducks [13:48] natefinch, :) I never assume it is you when I ask, I just hope you know the answer [13:49] sinzui: probably a good assumption ;) [14:06] natefinch, perrito666: standup? [14:06] ericsnow: natefinch just moved it [14:06] you should have a new invite [14:07] ericsnow: sorry... there's a tosca meeting today that always conflicts, I should have moved today's meeting like 2 months ago [14:07] 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:08] natefinch: forgot to refresh my calendar [14:08] 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:09] gsamfira, ah, so file:// urls won't work right on windows? [14:09] file:// works fine on windows actually [14:09] they do work, but not the way juju uses them [14:09] heh [14:09] gsamfira, I'd be entirely happy to have FileStorage run an http server and just happen to use an FS backend [14:10] fwereade: on linux we register '/' as the root for file:// [14:10] gsamfira, I think we already have an HTTPStorage like that anyway? [14:10] 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] for that bit, it would be ok to use a small http server for tests only [14:10] BUT, there comes the need to generate simpolestreams files using the client [14:11] fwereade: for example, the juju-metadata plugin [14:11] gsamfira, sure, understood [14:11] that plugin uses file:// iirc [14:11] gsamfira, my position there is that we have a *huge* number of tests not passing thanks to FileStorage [14:11] gsamfira, which equates to a huge proportion of juju not working, or at best working by coincidence [14:11] huge is right :) [14:12] gsamfira, so fixing filestorage is the important thing [14:12] gsamfira, because we believe that's just a test problem [14:12] fwereade : *local* file storage [14:12] gsamfira, metadata doesn't work anyway [14:12] gsamfira, and IMO it strictly comes behind fixing the tests that we believe are spurious failures [14:13] gsamfira, certainty on the bits that do work comes first [14:14] 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] and simply does a os.Stat() [14:14] if the file is local, just serve it [14:14] instead of doing filepath.Join(rootDir, filename) [14:14] and then serving it [14:15] then we would be able to have file://C:/my awesome/file [14:15] can i get a quick lgtm on a 2-line change? http://reviews.vapour.ws/r/236/diff/# [14:15] kind of the same way every other browser on the planed does it [14:15] :) [14:15] 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:16] we can, but then we need to strip the drive letteer every time. Juju generates full paths most times [14:16]