Ticket #123 (closed task: fixed)

Opened 4 years ago

Last modified 4 years ago

New test: check upgrade paths (etc) between releases

Reported by: wwoods Owned by: vaschenb
Priority: major Milestone: Package Update Acceptance Test Plan
Component: tests Keywords:
Cc: till, robatino Blocked By:
Blocking:

Description

(As pointed out by spot on the devel list: http://lists.fedoraproject.org/pipermail/devel/2010-March/131746.html)

We should be emitting warning/error messages if the new package(s) have a higher ENVR than the currently-released package(s) in any newer release.

For example, right now a new F11 package should be checked against the corresponding package(s) in the current F12, branched F13, and rawhide repos.

This involves a lot of extra repos and metadata, though. It's not a trivial thing to add.

Attachments

upgrade-path.py (3.0 KB) - added by jlaska 4 years ago.
upgrade-path.py

Change History

comment:1 Changed 4 years ago by kparal

I agree, this a very important test. But I don't think it should be the task of rpmguard, the rpmguard just prints differences between two packages. I think it would be best to create a separate test just for upgrade path testing.

I can volunteer to do that, it can be interesting. I just want to stress I believe it should be a new test.

comment:2 Changed 4 years ago by wwoods

  • Keywords rpmguard removed
  • Summary changed from rpmguard: check upgrade paths between releases to New test: check upgrade paths (etc) between releases

Yeah, that sounds reasonable. Removing rpmguard keywords.

comment:3 Changed 4 years ago by jlaska

  • Milestone set to Package update tests

Re-assigning to 'package update tests' milestone

comment:4 Changed 4 years ago by jlaska

skvidal drafted a script to compare packages in F12 and F13 and hilight the F13 packages that are older than F12 packages.

http://skvidal.fedorapeople.org/misc/newer_pkgs_in_old_repos.py

comment:5 follow-up: ↓ 6 Changed 4 years ago by skvidal

This is not a good script to build from but the idea is easy enough if you're doing it for comparing sets of repos.

However, if you're just doing to compare 1 pkg then you'd want to do:

  1. return a list of all the pkgs matching name of the pkg in question.
  2. sort the list by EVR (which is just sort for yum pkg objects)
  3. take the highest one and compare it to your pkg. If it is not less than or equal to your pkg, then you have an issue to flag.

If y'all can tell me where the 'other' pkgs are and how I can query them I can probably put this together for you.

comment:6 in reply to: ↑ 5 Changed 4 years ago by jlaska

Replying to skvidal:

This is not a good script to build from but the idea is easy enough if you're doing it for comparing sets of repos.

However, if you're just doing to compare 1 pkg then you'd want to do:

  1. return a list of all the pkgs matching name of the pkg in question.
  2. sort the list by EVR (which is just sort for yum pkg objects)
  3. take the highest one and compare it to your pkg. If it is not less than or equal to your pkg, then you have an issue to flag.

If y'all can tell me where the 'other' pkgs are and how I can query them I can probably put this together for you.

Apologies for delay. I *think* what you might use is autoqa.koji_utils (see http://git.fedorahosted.org/git/?p=autoqa.git;a=blob;f=lib/python/koji_utils.py;h=c9fad5da584631b734679520376e4d023b80e521;hb=HEAD).

Perhaps something like ...

import autoqa.koji_utils
koji = autoqa.koji_utils.SimpleKojiClientSession()
envr="lftp-4.0.5-2.fc13"
name="lftp"

print "Proposed update - %s" % envr
print "Available in N-1 - %s" % (koji.list_previous_release(name, "dist-f12-updates-candidate")['nvr'],)
print "Available in N-2 - %s" % (koji.list_previous_release(name, "dist-f11-updates-candidate")['nvr'],)

What's missing ...

  • using autoqa.koji_utils.compareNVR() to determine if a previously released verion is newer.
  • something build-into autoqa.koji_utils that understands which tags to use when looking for older packages?

Just some thoughts. Is this what you were looking for?

comment:7 Changed 4 years ago by jlaska

Attached is a sample script I played with to get something working. I'm not 100% sure I'm using the correct method to determine the previous Fedora releases for the provided update. But in my testing, this seems to work well enough. It returns '1' upon failure.

Some sample calls included below.

  • Checking if ypbind-1.31-3.fc13 has a sane upgrade path if it were to be released in dist-f14-updates-candidate
    # python upgrade-path.py -n ypbind-1.31-3.fc13 -t dist-f14-updates-candidate
    Checking proposed update for ypbind-1.31-3.fc13 tagged in dist-f14-updates-candidate
    Available in dist-f14-updates-candidate - ypbind-1.31-4.fc14 (FAIL)
    Available in dist-f13-updates-candidate - ypbind-1.31-2.fc13 (OK)
    Available in dist-f12-updates-candidate - ypbind-1.20.4-23.fc12 (OK)
    
  • Checking if ypbind-1.31-3.fc13 has a sane upgrade path if it were to be released in dist-f13-updates-candidate
    # python upgrade-path.py -n ypbind-1.31-3.fc13 -t dist-f13-updates-candidate
    Checking proposed update for ypbind-1.31-3.fc13 tagged in dist-f13-updates-candidate
    Available in dist-f13-updates-candidate - ypbind-1.31-2.fc13 (OK)
    Available in dist-f12-updates-candidate - ypbind-1.20.4-23.fc12 (OK)
    Available in dist-f11-updates-candidate - ypbind-1.20.4-19.fc11 (OK)
    
  • Checking if ypbind-1.31-3.fc13 has a sane upgrade path (autodetect current release)
    # python upgrade-path.py -n ypbind-1.31-3.fc13 
    Checking proposed update for ypbind-1.31-3.fc13 tagged in dist-f13-updates-candidate
    Available in dist-f13-updates-candidate - ypbind-1.31-2.fc13 (OK)
    Available in dist-f12-updates-candidate - ypbind-1.20.4-23.fc12 (OK)
    Available in dist-f11-updates-candidate - ypbind-1.20.4-19.fc11 (OK)
    

I'm sure it can be improved, suggestions welcome.

Changed 4 years ago by jlaska

upgrade-path.py

comment:8 follow-up: ↓ 9 Changed 4 years ago by till

  • Cc till added

According to the examples, there is only a backward check but no forward check happening. E.g. if ypbind-1.31-3.fc13 should be added to dist-f13-updates-candidate, it needs to be checked, whether all new releases have a higher NEVR, i.e. dist-f14-updates-candidate needs to be checked. The other way round is afaics not that important, because if you guarantee that a package all packages in F(N+1) have a higher NEVR than the new package in F(N), then no do not need to check F(N-1), assuming that EVR will always increase.

comment:9 in reply to: ↑ 8 ; follow-up: ↓ 10 Changed 4 years ago by jlaska

Replying to till:

According to the examples, there is only a backward check but no forward check happening. E.g. if ypbind-1.31-3.fc13 should be added to dist-f13-updates-candidate, it needs to be checked, whether all new releases have a higher NEVR, i.e. dist-f14-updates-candidate needs to be checked. The other way round is afaics not that important, because if you guarantee that a package all packages in F(N+1) have a higher NEVR than the new package in F(N), then no do not need to check F(N-1), assuming that EVR will always increase.

Good suggestion. Certainly worth exploring that option, and a fairly trivial code change with the example posted so far.

You suggestion brings up a good point. With either approach, are there any undocumented package update order requirements being implicitly enforced by this test?

With the approach you suggest, packages must be released starting with the newest Fedora release, and then for each applicable older release. For example:

  1. devel (rawhide)
  2. Fedora + 1 (branched) -- if desired
  3. Fedora (current) -- if desired
  4. Fedora - 1 (previous) -- if desired
  5. Fedora - 2 (previous+1) -- if desired

With the other approach, packages must be released starting with the oldest desired Fedora release. For example:

  1. Fedora - 2 (previous+1) -- if desired
  2. Fedora - 1 (previous) -- if desired
  3. Fedora (current) -- if desired
  4. Fedora + 1 (branched) -- if desired
  5. devel (rawhide)

comment:10 in reply to: ↑ 9 Changed 4 years ago by till

Replying to jlaska:

You suggestion brings up a good point. With either approach, are there any undocumented package update order requirements being implicitly enforced by this test?

Afaik the upgrade path is only about having the newer NEVR first in the newer Fedora releases. The afaik unanswered question is still from which package collection to which package collection this needs to be ensured. E.g. is it enough to have it from FN stable to FN+1 updates-candidate? Iirc from the FESCo ticket, there is no decision about what is desired here, but only a goal to check out what is (currently?) technically possible to ensure and then use this.

comment:11 Changed 4 years ago by robatino

  • Cc robatino added

comment:12 Changed 4 years ago by kparal

  • Owner set to vaschenb

Vojta is currently working on this test.

comment:13 Changed 4 years ago by jlaska

I believe this is now in master. Vojta, can you confirm? If so, feel free to close this ticket. Thanks!

comment:14 Changed 4 years ago by kparal

  • Status changed from new to closed
  • Resolution set to fixed

Yes, this is now in master.

Note: See TracTickets for help on using tickets.