! In D358#6488, @adamwill wrote: The $fedup_url in upgrade_run_minimal.pm is not really sufficiently sophisticated, unfortunately: this test will probably not run as of right now, because the $BUILD for Final TC1 will be 22_Final_TC1, but the directory on the mirrors is 22_TC1. (Another case of us - well, me - and releng not using exactly the same versioning philosophy, by which I mean I'm right and they're idiots. :>) fedfind copes with this, but the fedfind CLI at present doesn't give a convenient way to display just the base mirror path for a given release; I could add that capability, that might be the 'best' way to do this...in fact I might make it possible to output this specific directory (/foo/bar/'generic'_product/arch/os) for any given fedfind 'release', that seems useful in possibly more than one way. That should also make it much more robust for tests that aren't of TCs/RCs (like nightlies). To get the value from fedup I guess we can redirect the command's output to a file and then incorporate the contents of the file into the fedup command (type_string "fedup --network ".$to_version." --instrepo $(cat /tmp/fedfind.output) or whatever). I might try and play with this later today.
$fedup_url
upgrade_run_minimal.pm
$BUILD
22_Final_TC1
22_TC1
/foo/bar/'generic'_product/arch/os
type_string "fedup --network ".$to_version." --instrepo $(cat /tmp/fedfind.output)
Change upgrade tests to use fedfind to provide $fedup_url instead of taking it from $BUILD. I am not sure right now how to manage that - it seems that it requires to install fedfind into Fedora image that is used for upgrade. See comments in D358 to see how to use fedind for that.
This ticket had assigned some Differential requests: D471 D470 D358
"it seems that it requires to install fedfind into Fedora image that is used for upgrade"
the other option is to have the dispatcher work it out and pass it in as a variable. You can pass in arbitrary variables when doing the 'isos post'.
Ok, I've discussed it with jskladan and we have agreed that the best way would be to install fedfind on guest machine along with fedup and use it to obtain url to os directory of specified BUILD.
os
adamwill, is it possible to add this functionality (return url to /foo/bar/product/arch/os for specified release/milestone/compose) to fedfind?
/foo/bar/product/arch/os
I already did it: fedfind images -g
fedfind images -g
It doesn't do the arch/os bit because that didn't quite seem to fit (you'd have to pass in an arch and then it would pass it right back out to you...). Consumers should tack on the subdirectory they want to the result.
arch/os
It does handle the product/flavor problem; what it does is give you the tree that would be considered the 'generic' one for the given release. So for nightlies it gives you the nightly tree, for F21 and later releases it gives you the Server tree; if we ever get a Fedora tree again, it'll return that when appropriate. This is certainly what's needed for the upgrade case.
Great. The problem is, I am not really sure where to get values I have to pass to fedfind (release, milestone, compose). I could parse them from BUILD variable, but I am not really sure whether it's reliable solution.
Edit: I could parse it from BUILD by using /(.*)_(.*)_(.*)/ regex, but I couldn't use it deterministically - $1 is often release version, but sometimes it's Rawhide, $2 is milestone, but sometimes it isn't defined.
/(.*)_(.*)_(.*)/
$1
Rawhide
$2
BUILD is explicitly designed such that if you do BUILD.split('_') in python (or, of course, an equivalent split in any other way) it will give you release, milestone, compose values for fedfind or wikitcms that will produce the expected result. If one of the values is not specified simply leave it out. It's actually produced from fedfind values in the first place (see jobs_from_fedfind()). I can give you far more boring details if you like, but that's the short version :)
BUILD.split('_')
jobs_from_fedfind()
you may note that openqa_trigger/report_job_results.py already uses it this way.
Ok, so I have tested it and it doesn't work with BUILD that is currently set for Rawhide in Boston - for example, for current build, BUILD is set to Rawhide__20150714, that gives us release Rawhide, no milestone and compose 20150714, but calling fedfind images -g -r Rawhide -c 20150704 reults in:
Rawhide__20150714
20150714
fedfind images -g -r Rawhide -c 20150704
fedfind images: error: argument -r/--release: invalid int value: 'Rawhide'
Another thing, could you please add something like -q for quiet to fedfind, so we could use something like:
-q
fedup --network $to_version --instrepo `fedfind images -g -r 22 -m Beta`
because currently, running fedfind images -g outputs more verbose output.
Ah, sorry, I loosened up the restrictions on the CLI a while back but didn't adjust the release parameter sufficiently...I'll fix it tomorrow. You're still going to need to append the appropriate subdir to the output for fedup, though.
actually I just pushed this to fedfind git master now. It's midnight and I've had half a bottle of wine, though, so test carefully. :P
I've just posted two diffs which implement this from the other end (the trigger script figures out the URL and passes it in as an openQA variable for the test to use): D470, D471.
! In #478#6755, @adamwill wrote: I've just posted two diffs which implement this from the other end <... snip />
Although the patches most probably work, I'd much rather have it implemented as we discussed above. This code makes us another bit more dependent on the trigger for running jobs, and I'd strongly prefer having the URL discovery inside the upgrade test - installing one more package (fedup) during the upgrade process does have no impact on the test itself, and is much more user friendly than adding another CLI argument.
AFAIK, @jsedlak even already has the code for the aforementioned solution, and is just waiting for the changes to get into fedup.
I think you mean 'fedfind' everywhere you wrote 'fedup', right?
I don't know, it doesn't feel better to me at all, having the client run commands just to find out how to do the test seems like a mess to me, but I guess it depends on how you look at it. I never kick off tests by hand.
This is apparently all going to be academic anyway since wwoods wants to deprecate fedup...
I've cut a 1.2 release of fedfind and sent updates for all Fedora/EPEL releases. It has the fix allowing --release Rawhide, and output is now arranged such that you can do something like this:
--release Rawhide
fedup --network $to_version --instrepo `fedfind images -g -r 22 -m Beta`/$arch/os
after setting $arch, of course. wwoods is still deprecating fedup, though. sigh.
I've read on Phoronix that wwoods is ditching fedup in place of PackageKit and systemd's offline updates, but I couldn't find it anywhere else. Is there any page with details?
https://fedorahosted.org/fesco/ticket/1463 https://fedoraproject.org/wiki/Changes/DNF_System_Upgrades (note: only created today) https://bugzilla.redhat.com/show_bug.cgi?id=1245838
Well, if fedup is going to be ditched, we can abandon the revisions alltogether. Although it seems like there is currently no way to upgrade, so maybe fedup is not really dead yet :D
This is now obsolete.
Login to comment on this ticket.