[01:47] <jtv> bigjools: we can just make maas-test import from the daily images and ignore the releases repo, right?
[01:47] <bigjools> jtv: hmm good question
[01:47] <bigjools> I would say both, but default to release
[01:49] <jtv> Maybe we can have a chat about this?
[02:24] <mwhudson> hm
[02:24] <mwhudson> how do you configure maas-dns?
[02:37] <jtv> mwhudson: maas generates the dns config using a template (in /etc/maas/templates IIRC)
[02:37] <jtv> So you edit the template.
[02:37] <mwhudson> hm
[02:38] <mwhudson> what i want to do is tell it where to forward most requests to
[02:38] <mwhudson> like e.g. "python.org"
[02:38] <jtv> Ah, that's already a thing.
[02:38] <jtv> For some quantity of thing.  Let me look.
[02:38] <mwhudson> i don't know much about configuring dns
[02:40] <jtv> So what you want to set is the “upstream” DNS, for all requests for hostnames not managed by the MAAS, right?
[02:41] <mwhudson> yes
[02:41] <jtv> There's a UI setting for that.  Look for "upstream DNS."
[02:41] <mwhudson> oh UI
[02:42] <mwhudson> i wonder why the UI isn't responding
[02:42] <jtv> At all..?
[02:42] <mwhudson> just hanging
[02:42] <mwhudson> bet it turns out to be a firewall
[02:42] <jtv> Then why did it work before though?  Maybe a big ongoing upgrade?
[02:43] <mwhudson> hm?
[02:43] <mwhudson> it's never worked for me
[02:43] <mwhudson> on this install
[02:43] <mwhudson> which is a day old
[02:45] <bigjools> you can set it via the API too, it's just a config item
[02:51] <mwhudson> ah ok i think the api not working was a stale ip address
[02:53] <mwhudson> shouldn't maas createadmin prompt for a password?
[02:53] <bigjools> here we go again :)
[02:53] <bigjools> createsuperuser does
[02:53] <mwhudson> or maybe the docs should be fixed, if it's that sigh-worthy :)
[02:53] <bigjools> people keep asking for one and then the other
[02:54] <bigjools> one is django's command, one is our wrapper
[02:54] <mwhudson> bigjools: http://maas.ubuntu.com/docs/install.html#create-a-superuser-account seems to be just wrong (for trusty anyway i guess?)
[02:54] <bigjools> yeah the docs will be updated when 1.5 is released
[02:55] <bigjools> and we'll have docs for each supported release, at last
[02:55] <bigjools> separate docs I mena
[02:55] <bigjools> mean
[02:55] <mwhudson> i don't see a setting for dns in the ui :/
[02:55] <mwhudson> oh that will be nice
[02:55] <bigjools> it's on the config page somewhere
[02:56] <mwhudson> this maas install seems less fresh than i thought it was :/
[02:57] <bigjools> heh
[02:57] <bigjools> 2230 is latest trusty
[03:01] <mwhudson> is it possible that this maas doesn't think it's managing dns?
[03:01] <mwhudson> 1.4+bzr1693+dfsg-0ubuntu2.2
[03:01] <mwhudson> ok that's ancient?
[03:01] <bigjools> mwhudson: ancient!
[03:01] <mwhudson> ffs
[03:01] <bigjools> that's cloud-tools or saucy's version
[03:02] <bigjools> only about 500 revision behind
[03:02] <mwhudson> oh
[03:02] <mwhudson> this vm is saucy
[03:02] <mwhudson> ffs
[03:19] <mwhudson> anti-progress: the dns server i want to forward to does not, in fact, appear to be listening to me
[03:22] <bigjools> winning
[04:11] <bigjools> jtv: is there anything else in your branch that needs attention?
[04:11] <bigjools> I will approve it
[04:14] <jtv> I hit a different problem in Q/A; part that worked before.  May just be my experimental change.
[04:49] <jtv> I always knew the uploading of the file would be the hard and risky part, but why did it work when Raphaël tried it?
[05:02] <bigjools> jtv: what goes wrong?
[05:04] <jtv> Oh, I see it now.  The scp command.
[05:10] <bigjools> jtv: let me guess, quoting?
[05:10] <jtv> No, just a missing username/host prefix.
[05:11] <jtv> I guess Raphaël fixed that up in his experiment.
[05:17] <bigjools> ahah
[05:19] <jtv> Yup, that seems to work.
[05:19] <jtv> I'll try another Q/A run.
[05:43] <jtv> Hmm... images are imported just fine now (and according to spec), but Raphaël's new poll-until-images-are-imported code hits a timeout.
[05:44] <jtv> So report_boot_images is not working in some way.
[05:45] <jtv> Or maybe it's just genuinely taking too long.
[05:49] <jtv> Ah, wouldn't surprise me — he switched over from running the import script to triggering a run from the API.
[05:49] <jtv> The script doesn't return until the import is done, and from there all we need to wait for is for report_boot_images to run.
[05:49] <jtv> But when we call the API for importing images, it returns immediately — and so what we're waiting for is completion of the import itself.
[05:50] <jtv> (No longer report_boot_images, because the API-triggered task runs that right after the import).
[05:50] <jtv> The timeout is 10 minutes, IIRC, which is fine for the report_boot_images cycle — but maybe not for the import.
[05:50] <bigjools> jtv: so, is it working or not? :)
[05:50] <jtv> Not yet, not yet!
[05:51] <jtv> Can't wait to have some hardware for this stuff...
[05:54] <jtv> No, no, the change that triggers the API version of the imports doesn't seem to have landed yet...
[06:14] <jtv> Ahhh, found the cause: chmod.
[06:14] <jtv> Another easy fix.
[06:32] <jtv> My branch just passed the enlist-a-node test.
[06:36] <jtv> \o/  Test successful.  Landing.
[07:09] <jtv> bigjools, is this what you had in mind?  https://code.launchpad.net/~jtv/maas-test/daily-option/+merge/215088
[07:10] <bigjools> jtv: boolean params always pique my interest
[07:11] <bigjools> they are nearly always better replaced with some sort of enumerated value
[07:11] <jtv> Very true, but it's the UI choice that matters here.
[07:11] <bigjools> --image-type=
[07:11] <jtv> What happens under the bonnet can be changed easily.
[07:11] <bigjools> ?
[07:11] <bigjools> and default to "release"
[07:11] <jtv> ?
[07:12] <bigjools> then it stays a little looser
[07:12] <jtv> I have similar misgivings about calling things types of things.  There are usually different aspects that you could call types.
[07:12] <bigjools> ok
[07:13] <jtv> This option is just a shortcut for an alternate config...  easier to improve once a real pattern forms.
[07:13] <bigjools> it was a rough suggestion, I'm open to options
[07:13] <bigjools> you *could* just take a whole simplestreams path
[07:14] <jtv> Yeah, but it's a lot more work for the user.  I figured that could be a next step in making it more flexible — if we need it.
[07:14] <bigjools> but remember that this API needs to stick after bootresources is gone
[07:15] <jtv> I see that as a reason to keep the UI as simple as possible: keeps it easy to change the whole implementation, even if we may later have to build a more flexible, more complicated way of doing the same thing.
[07:15] <jtv> Not hard to say "you can't specify --daily-images and a custom path" later, if/when we add an option for the latter.
[07:15] <bigjools> the mass-test UI would have to change if a new "type" was introduced
[07:15] <bigjools> it would not have to change in maas
[07:15] <bigjools> see my point?
[07:16] <jtv> Wait... what's the connection to maas?
[07:16] <jtv> I mean, maas would never know about any of this anyway.
[07:17] <bigjools> maas itself just cares about the url to the index
[07:17] <bigjools> "path" in the config
[07:17] <jtv> Yes, that's what I mean.
[07:17] <bigjools> it knows nothing about dailies/release
[07:17] <bigjools> I think maas-test should be the same
[07:17] <jtv> And that's the way I like it.
[07:17] <bigjools> me too
[07:17] <jtv> We can do that, but getting the right URL has been a bit of a pain in the past.
[07:18] <jtv> You know: "I have a URL to an index listing here, but how many path components do I need to strip off to get the URL that simplestreams wants?"
[07:19] <bigjools> my suggestion is to default the whole URL and allow knowledgeable users to override as they want
[07:19] <bigjools> dailies won't get used much after release, everyone will want to know if trusty works on their hardware
[07:19] <jtv> Okay.  It's an easy change — I just figured it was hard on the users.
[07:20] <bigjools> I would normally agree but I think the frequency of using this option will be limited to power users
[07:20] <jtv> What should I call the option then?  --image-stream?
[07:20] <bigjools> --image-stream-url
[07:20] <bigjools> ?
[07:20] <jtv> OK
[07:20] <bigjools> cool, thanks
[08:50] <jtv> rvba: if you want to use the API for starting the import job, that'll work now — but don't forget that the timeout for the BootImage records to appear will then have to cover the import time, not the report_boot_images interval.
[08:50] <rvba> jtv: not sure it's worth doing right now tbh.  It's a cleanup that can be done later.
[08:51] <jtv> OK, just a thing to keep in mind.
[08:51] <rvba> Yeah.
[08:51] <jtv> Because 10 minutes is a long, long time for the report_boot_images schedule... but not a lot of time to import images!
[08:51] <rvba> A very useful cleanup would be to avoid downloading the i386 images when it's not necessary.
[08:51] <rvba> Maybe I'll fix that.
[08:52] <jtv> That'd be great — look for "mipf" in the function name, in utils.py IIRC.
[08:52] <rvba> allenap: bigjools: jtv: gmb: just a reminder (in case I forget): just before the release we want to change the label of the Trusty images from 'daily' to 'release'.
[08:52] <jtv> That's what says "oh you asked for armhf?  I'll give you armhf/generic and throw in i386/generic as well."
[08:52] <rvba> I know.
[08:53] <jtv> Change the label?  Of already imported images you mean!?
[08:53] <rvba> No, the label for Trusty in /etc/maas/bootresources.yaml.
[08:53] <jtv> So Scott is going to throw the switch?
[08:55] <rvba> We probably need to get confirmation from him that the 'release' images for Trusty have been published.
[08:56] <jtv> Since AFAIR _all_ the images in the daily stream were labelled "daily," shouldn't we just use label "*"?  Saves us worrying about synchronicity.
[08:57] <rvba> Doesn't make a great difference.  We would still have to change the 'path.'
[08:58] <jtv> Is he going to change that as well!?
[08:59] <jtv> ISTM we can just put trusty under the "releases" source.
[08:59] <jtv> And just leave the label as *.
[08:59] <jtv> ISTM we can do that before the upstream data changes, with no ill effects.
[09:00] <bigjools> rvba: we need to change that ASAP well before the FF.  If there's a problem with images then we just ask someone to put images in release.
[09:00] <bigjools> did that make sense?
[09:00] <rvba> bigjools: I just checked and it seems the 'release' images for Trusty are already there.
[09:00] <bigjools> \o/
[09:00] <bigjools> JFDI then
[09:01]  * gmb -> getting breakfast; bbiab
[09:01] <rvba> Yep.
[09:01] <rvba> JFDoingI
[09:01] <bigjools> o/
[09:03] <allenap> rvba, jtv: https://code.launchpad.net/~allenap/maas/dhcp-leases-parsing/+merge/215112 is my work-in-progress for speeding up lease parsing.
[09:04] <allenap> It uses a regex to identify records, then it select only the latest ones, then it uses the full parser to break those apart.
[09:04] <allenap> It saves a lot of work when the leases file is large.
[09:04] <rvba> bigjools: btw, the upcoming (still waiting for the RT ticket to go through —hint, hint) api doc page has a toc: compare http://people.canonical.com/~rvb/maas-docs/api.html with http://maas.ubuntu.com/docs/api.html
[09:05] <jtv> allenap: that's very little code indeed...  not sure what it does yet.
[09:05] <bigjools> rvba: can you go and pester them again for the RT please
[09:07] <bigjools> rvba: and the toc is a nice improvement, thanks
[09:07] <rvba> bigjools: we got a response on the RT, just no estimation of when it will be done.  I'll ask them about that.
[09:07] <bigjools> rvba: ok, thanks
[09:08] <rvba> Done.
[10:12] <jtv> rvba: did you want to make the change to how/where we import trusty?
[10:13] <jtv> If not, I can propose a quick branch.
[10:23] <rvba> jtv: I have a branch already.  I'm testing a package built from it right now.
[10:24] <rvba> jtv: https://code.launchpad.net/~rvb/maas/use-release-trusty-resources/+merge/215114 WIP until I get confirmation that it's working as expected.
[10:26] <jtv> Why not just move the "trusty" selection under the other source?
[10:26] <jtv> I'm currently setting up for an import with that config btw.
[10:28] <rvba> jtv: yes, that would be even a bit simpler.  Fixing the branch now.
[10:31] <jtv> Oh dear.  Import fails while trying to write the meta file: snapshot directory does not exist!
[10:32] <jtv> I have a horrible feeling we haven't been getting any new dailies for a while, and so failed to notice some problem or other...
[10:34] <rvba> uh-oh
[10:36] <jtv> Just filed it as bug 1305758
[10:46] <jtv> Oh, another possibility I guess would be that there is simply nothing to download, and that this gets handled particularly badly in some cases.
[10:46] <rvba> jtv: the import doesn't seem to work now.  I only got the precise image.
[10:47] <jtv> Any tracebacks?
[10:47] <rvba> No, no traceback.
[10:47] <jtv> Spooky.
[10:48] <rvba> Like you said, maybe there is nothing to download.  Although the images seem to be there.
[10:49] <jtv> Probably identical to versions we already had...
[10:49] <jtv> And I don't see anything that would create that snapshot directory if there was nothing to download.
[10:49] <jtv> The code would try to write that maas.meta file, but the directory wouldn't exist.
[10:49] <jtv> I seem to remember that this was always a weakness in the code, actually.
[10:50] <rvba> jtv: the images seem to be there but clearly, the index file doesn't contain an entry for Trusty/release.
[10:50] <jtv> Maybe because the same file was already in there as Trusty/daily?
[10:50] <rvba> jtv: I guess I'll wait for smoser to come online and ask him about that.
[10:51] <jtv> Wow.  Latest images I have in cache are from March 31.
[10:53] <jtv> Uh-oh.  Deleting everything from /var/lib/boot-resources doesn't fix the problem either.
[10:53] <jtv> And it fails suspiciously quickly — within a second.
[10:53] <jtv> Maybe because it's hitting the caching proxy.
[10:54] <rvba> pdb time :)
[10:56] <jtv> When I put the daily trusty import back in (in addition to the release trusty) it seems to get going again.
[10:57] <jtv> But of course maybe it's just slower to fail because I made it download stuff.
[10:57] <jtv> I'm expecting to be called out soon.  May not have time to say so.
[11:13] <rvba> jtv: when importing (with the updated config) from a freshly installed package, I don't get a traceback.
[11:13] <jtv> !?
[11:13] <rvba> Only precise gets imported.  but no traceback.
[11:13] <jtv> Then I guess it may be getting confused because the same images are in different streams with different metadata...
[11:14] <jtv> Although then why did it keep failing for me when I deleted my cache & snapshots..?
[11:14] <rvba> I doubt that's the problem; like I said, there is no reference to Trusty/release in the index.
[11:15] <jtv> Oh, there still isn't?
[11:15] <jtv> Ah yes, see that.
[11:15] <rvba> No.  Again: the images seem to be there but there is no reference to them in the index.
[11:16] <jtv> So then the import procedure wouldn't find them...  I think.
[11:16] <rvba> That's the behavior I see.
[11:16] <rvba> Doesn't explain the bug you're seeing though.
[11:20] <jtv> But the behaviour you're getting sounds completely correct under the circumstances, so maybe it's just something weird in my setup.
[11:20] <jtv> After the ongoing import I'll try re-running it, and if that doesn't reproduce the problem, I'll try re-running but without the daily trusty source.
[11:20] <rvba> k
[11:21] <rvba> But like you said, this part of the code seems a bit fragile.  I'd be relieved if we could get to the bottom of this.
[11:23] <jtv> That's exactly why I'm trying to reproduce the problem.
[11:23] <jtv> Can't promise that it'll work.  :(
[11:46] <jtv> Ahhh, I've reproduced the traceback.
[11:46] <jtv> By commenting out the "daily" source.
[11:47] <jtv> Ah!  Maybe I understand why!
[11:47] <jtv> The snapshot directory gets created, "en passant" as it were, when <something> is downloaded from the simplestreams repo.  Not sure what exactly, but no downloads means no snapshot directory.
[11:47] <jtv> But then.
[11:48] <jtv> (Good thing I recently refactored this code — otherwise I wouldn't have understood it)
[11:48] <jtv> Then, the import code generates a yaml dump for the metadata it has downloaded from the repo, _in memory_, and compares it to what's in /var/lib/maas/boot-resources/current/maas.meta
[11:49] <jtv> If the two do not match, then something has changed, and so the import code decides that the new snapshot directory is worth keeping.
[11:49] <jtv> It writes a new maas.meta file in that snapshot directory.
[11:49] <jtv> Which, oops, does not exist because all that happened is that things disappeared.
[11:50] <jtv> I think the sensible thing to do is to create the snapshot directory.  Assuming the rest of the code behaves sensibly.
[12:00] <jtv> Oh dear.  The story just got weirder.
[12:00] <jtv> The metadata dict is empty.
[12:01] <jtv> That means that no matching products were found.
[12:35] <jtv> Bother.  All this time wasted on what is probably a syntax error.  I don't like yaml.
[13:17] <rvba> smoser: around?
[13:20] <rvba> jtv: gmb: allenap: is one of you taking care of https://code.launchpad.net/~andreserl/maas/third_party_drivers/+merge/215065 ?
[13:21] <jtv> Not me, sorry!
[13:44] <allenap> rvba: Yeah, I was looking at it, but I’m not going to be able to review it until at least 1900 UTC.
[13:44] <rvba> allenap: I've written the tests.
[13:44] <allenap> roaksoax: ^ is that going to be too late.
[13:44] <allenap> rvba: \o/
[13:44] <rvba> allenap: I'm taking care of it unless gmb wants to review it :)
[13:44] <allenap> rvba: If gmb’s not around I think a selfie might be in order.
[13:45] <rvba> allenap: that's the plan
[13:54] <roaksoax> allenap: nope, we have until EOD today
[13:55] <roaksoax> allenap: i'll be pushing the release team toapprove this too while jhobbs finishes up some changes
[13:55] <roaksoax> allenap: all the hardcodede stuff (where the pPA is and stuff needs to go on a config file)
[13:56] <rvba> roaksoax: btw, we'd like to land https://code.launchpad.net/~rvb/maas/use-release-trusty-resources/+merge/215114
[13:56] <rvba> But it seems the images for Trusty/release are not included in the index file yet.
[13:56] <rvba> The simplestreams index that is.
[13:56] <roaksoax> rvba: so it would fail?
[13:56] <roaksoax> rvba: maas-improt-pxe-files would fail?
[13:57] <rvba> roaksoax: it would not fail for it would only import precise's images.
[13:57] <rvba> s/for/but/
[13:57] <roaksoax> rvba: so there's something weird
[13:58] <roaksoax> rvba: http://paste.ubuntu.com/7230893/
[13:58] <roaksoax> rvba: and it that diff I see: arches: ["i386", "amd64"]
[13:58] <rvba> roaksoax: what's weird?
[13:59] <rvba> roaksoax: the config file gets rewritten… but it's semantically the same.
[13:59] <roaksoax> rvba: ok
[14:01] <roaksoax> rvba: so, i'm thikning that sicne there no release for trusty yet
[14:01] <roaksoax> rvba: we could sru this, or tryu to get it post today?
[14:01] <rvba> roaksoax: SRU works for me.  It's a bit of a chicken and egg problem.
[14:01] <roaksoax> yeah
[14:01] <rvba> bigjools: see ;) ^
[14:03] <roaksoax> rvba: https://code.launchpad.net/~andreserl/maas/third_party_drivers_1.5/+merge/215185
[14:04] <rvba> roaksoax: approved (you can usually self-review simple backports)
[14:07] <roaksoax> rvba: thanks :)
[14:08] <roaksoax> rvba: it does nee dot be manually uploaed right?
[14:49] <rvba> smoser: when are the Trusty/release images going to be available in the simplestreams index on http://maas.ubuntu.com/images/ephemeral-v2/releases/ ?  i.e. should we land https://code.launchpad.net/~rvb/maas/use-release-trusty-resources/+merge/215114 as an SRU?
[14:58] <roaksoax> rvba: don't lanmd anything to 1.5 please
[15:01] <rvba> roaksoax: well, I'm not landing this unless the images are there, that's for sure.
[15:01] <roaksoax> rvba: thganks
[15:12] <fader> Hey folks, is there any documentation anywhere on authenticating against the REST API?
[15:12] <fader> I can use it properly from a web browser if I have logged into MAAS interactively already, but if I haven't logged in or try from a script I get something like "Unrecognised signature: GET list"
[15:12] <fader> Seems to be similar to: http://askubuntu.com/questions/402691/handling-ubuntu-maas-restful-api-login (and not covered that I see in the API docs)
[15:17] <rvba> fader: Hi, I just posted a reply to that question on askubuntu.com.  Although we know the documentation is a bit poor in this area, the example Python code should be you started.
[15:17] <rvba> fader: note that, if you're using Python, you can use the client library directly.
[15:19] <fader> rvba: Thanks, I'll take a look!  (Don't shoot me but I was planning to do it from PHP via its built-in URL grabbing as a prototype)
[15:20] <fader> I'm just trying to build a page that shows the status of multiple MAAS clusters as a proof-of-concept, nothing that will really be in production
[15:24] <tych0> hi smoser, roaksoax, it looks like maas defaults to syncing the daily ephemerals as well as the release versions
[15:24] <tych0> is that the way we are going to release it?
[15:25] <rvba> tych0: That was my question to smoser :).  We've got https://code.launchpad.net/~rvb/maas/use-release-trusty-resources/+merge/215114 ready to land.  But we're waiting on simplestreams having the right data.
[15:25] <tych0> oh, i see
[15:25] <tych0> rvba: yeah, cool
[15:27] <smoser> rvba, ?
[15:27] <tych0> rvba: so one thing i don't understand about that diff, can we not specify two releases in the same keyring path?
[15:28] <smoser> oh. i see.
[15:28] <smoser> i'd land it.
[15:28] <rvba> tych0: that's exactly what that branch does. The diff is a bit messed up.
[15:28] <tych0> or maybe a question better for smoser
[15:28] <smoser> well you're not going to have something labeled release until ... after release.
[15:28] <tych0> rvba: ah, ok
[15:28] <tych0> rvba: i am not that good at reading diffs :-)
[15:28] <smoser> so that would put you in the realm of SRU
[15:28] <rvba> smoser: okay, so I guess we will SRU this
[15:29] <rvba> tych0: this diff is particularly nasty
[15:29] <tych0> :-)
[15:29] <smoser> suck.
[15:29] <smoser> alright. so lets figure something out here.
[15:29] <smoser> i'll try to get something itnto daily today.
[15:29] <rvba> tych0: here is the file http://paste.ubuntu.com/7231245/
[15:30] <smoser> and we can test that, and then i think i'm willing to call somethinng release in this single case.
[15:30] <smoser> but we could also possibly call it "rc" or something
[15:30] <rvba> smoser: it's a bit of a chicken and egg problem.
[15:30] <smoser> and you allwo the label "rc"
[15:30] <smoser> label rc|release
[15:31] <rvba> smoser: that would work
[15:31] <tych0> rvba: cool, that's what i was thinking
[15:31] <smoser> i dont think its terrible either. and actually, since you have (poorly) only 'trusty' in that list, then its safe in the future.
[15:31] <smoser> i really dont like that you've only extended the number of places with hard coded release names though.
[15:32] <rvba> Not sure what you're talking about.
[15:32] <smoser> 'trusty'
[15:32] <smoser> you'll never see 'urban' (of 'urban unicorn')
[15:33] <smoser> when it would be better if you started pulling those things in (or at least allowed for that) when said unicorn was 'release' or 'rc'
[15:33] <smoser> maas should not have a database of ubuntu names.
[15:33] <smoser> thats what i'm complaining about.
[15:33] <rvba> I see.  This is a long-standing bug.
[15:33] <smoser> yes. and this config file extended the number of places where naems are typed.
[15:34] <smoser> i will work today
[15:34] <smoser> and try to get daily updated.
[15:34] <rvba> This file replaces two other files with these names in it.  So technically, it's one step into the right direction.
[15:34] <smoser> rvba, thats good.
[15:34] <smoser> *and* its user editable config
[15:34] <smoser> rather than source code
[15:34] <smoser> :)
[15:35] <smoser> i'll get daily updated today. and we'll get that tested and then will promote a trusty to 'rc'
[15:35] <smoser> and then you can land that patch tomorrow
[15:35] <rvba> See, there is your silver lining.
[15:36] <rvba> smoser: okay, please send an email to a maas ML when it's done.  Julian will probably be able to test and land the change to bootresources.yaml