[18:26] <vila> cjwatson, wgrant: I'm curious about the following. I realize lp builders had a "bad hangover" to begin this year. And that many bets are off about the performance impact from many recent fixes. Yet, I seem to remember lp estimated times for builds to be accurate at the hour scale. For several days now, they are completely off though. Not progressing for hours, repeating the same (obviously wrong) estimation.Do you know why ?
[18:27] <wgrant> vila: The build start time estimation relies on the assumption that no new builds jump the queue in front of you. Do you have a particular build in mind?
[18:45] <vila> wgrant: https://code.launchpad.net/~vila/+recipe/byot-releases
[18:46] <vila> wgrant: just jumped from 17mins to 29mins
[18:47] <vila> wgrant: ha right, and there are way more jumpers these days. Makes sense.
[21:28]  * juliank is currently trying to add Valid-Until support to Launchpad because he thinks it's needed. Untested branch in https://code.launchpad.net/~juliank/launchpad/valid-until - diff so far in http://paste.ubuntu.com/26491591/
[21:28] <juliank> I'll try to actually get a test launchpad instance set up tomorrow or later this week and run the tests.
[21:29] <juliank> This mostly illustrates the idea :)
[21:30] <juliank> If that actually (or eventually) works and we decide to roll it out, I'd probably start with bionic-backports as a test stage, as nobody uses that yet, so we can check weekly regeneration without affecting much :D
[21:30] <juliank> or well, whatever is devel at that time :D
[21:42] <juliank> cjwatson: I must say that the code is quite easy to read
[21:42] <juliank> I mostly just grepped advertise_by_hash and replicated that into write_valid_until :D
[21:42] <cjwatson> I'd make the interval a configuration item (see lib/lp/services/config/schema-lazr.conf) and maybe also try to work out a way to make it configurable on a per-suite rather than per-series basis
[21:43] <cjwatson> "make it configurable" whether to do this at all, I mean
[21:43] <juliank> cjwatson: So a set of pockets would do that, right?
[21:43] <juliank> pockets_with_valid_until in distroseries, essentially
[21:43] <cjwatson> I guess two configuration items, one for the Valid-Until period and one for how long before its expiry we regenerate
[21:44] <cjwatson> Yes, I think something like that would be worthwhile for finer control
[21:44] <juliank> Right
[21:44] <cjwatson> juliank: Also initialize-distroseries needs to copy the configuration to new series
[21:44] <juliank> I guess we can just define valid_until_period instead of write_valid_until in days
[21:44] <juliank> it does now
[21:44] <cjwatson> And a bunch of other things I imagine we'll pick up :)
[21:45] <cjwatson> Ah yes, I was looking at an earlier diff
[21:45] <juliank> This is the first time I looked at LP code
[21:45] <juliank> So all you see happened within an hour of me first looking at it :D
[21:45] <cjwatson> archivepublisher is very probably the most accessible bit for an APT developer, and for almost nobody else :-)
[21:45] <juliank> It's super easy
[21:46] <juliank> or well it looks super easy
[21:46] <juliank> valid_until_expiry_threshold
[21:46] <juliank> valid_until_period
[21:46] <juliank> valid_until_pockets
[21:46] <cjwatson> The tests for this general area are a bit clunky by the standards of other LP code (they're very functional-testy, if you see what I mean, lots of "set up universe then run universe for a while" kinds of things), but should be manageable
[21:46] <juliank> I guess these are useful option names
[21:47] <juliank> Unless you want to configure period per pocket
[21:47] <cjwatson> I don't think that's necessary
[21:47] <juliank> valid_until_expiry_threshold and valid_until_period in days I guess
[21:48] <juliank> could make it seconds, though
[21:48] <cjwatson> We have configuration items with times in seconds, minutes, days
[21:48] <juliank> ah
[21:48] <cjwatson> Days should be OK I think
[21:48]  * juliank will take a look
[21:49] <juliank> yeah
[21:49] <cjwatson> Nice start, anyway - thanks for working on this
[21:50] <cjwatson> isReleaseFileOutdated might want to be careful of the case where there isn't a Release file for the suite yet
[21:50] <cjwatson> I have a sort of an itch about the way it parses the existing file rather than going off DB state, but it may be the most robust approach here
[21:50] <juliank> ack
[21:51] <juliank> cjwatson: I'm not sure date is in the db? It just generates the releasefile with datetime.now()
[21:51] <juliank> um, utcnow()
[21:51] <cjwatson> Yeah, it's not right now
[21:51] <cjwatson> What you have is probably fine, just thought I'd mention my initial itch :)
[21:52] <cjwatson> (Well - it's going to end up in the ArchiveFile table soon for InRelease-by-hash, but not in a form that's particularly useful for this)
[21:52] <juliank> cjwatson: InRelease-by-hash will be epic
[21:52] <cjwatson> Last stage of that is https://code.launchpad.net/~cjwatson/launchpad/inrelease-by-hash/+merge/336675
[21:52] <cjwatson> I think it will just about avoid conflicting with yours
[21:53] <juliank> yup seems ok
[21:56] <juliank> cjwatson: I guess I'll continue tomorrow, but these are all very helpful comments :)
[21:57] <juliank> cjwatson: The code in apt for checking that Date is not in the future is basically ready too, BTW. I hope it'll land for bionic :)
[21:57] <juliank> If both changes land in time for that, we end up with a strict 2 week validity period for Release files
[21:57] <juliank> which would be awesome, IMO
[21:58] <juliank> s/2 week/<n> day/
[22:13] <cjwatson> juliank: let me know when you've got near the point where you want to actually start running tests - I can help with setup, and you really don't want to be running the full suite if you don't have to, so I can offer advice on which segments to run
[22:14] <juliank> cjwatson: thanks :)
[22:14] <cjwatson> (full suite is 40min or so in buildbot, several hours on my laptop)
[22:15] <juliank> wow