Bug 1255420 - getArches() doesn't return all arches for release minor
getArches() doesn't return all arches for release minor
Status: CLOSED CURRENTRELEASE
Product: Beaker
Classification: Community
Component: command line (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified (vote)
: 21.2
: ---
Assigned To: Dan Callaghan
tools-bugs
: NeedsTestCase, Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-20 10:23 EDT by Jan Stancek
Modified: 2015-11-22 22:52 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-22 22:52:42 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Stancek 2015-08-20 10:23:41 EDT
Description of problem:
Problem seems to be that if family is passed as parameter, then beaker gets confused, because we seem to have multiple family majors with same family name, but each minor has different set of arches:
RedHatEnterpriseLinux7 	0 	x86_64 ppc64 s390x
RedHatEnterpriseLinux7 	1 	x86_64 ppc64 s390x ppc64le
RedHatEnterpriseLinux7 	2 	x86_64 ppc64 s390x aarch64 ppc64le

    def getArches(self, *args, **kwargs):
        """ Get all arches that apply to either this distro or family/osmajor """

        distro   = kwargs.get("distro", None)
        family   = kwargs.get("family", None)

        if not hasattr(self,'hub'):
            self.set_hub(**kwargs)

        if family:
            return self.hub.distros.get_arch(dict(osmajor=family))
        if distro:
            return self.hub.distros.get_arch(dict(distro=distro))

1. if I provide both, which is what we have always did in workflow_kernel
  --family=RedHatEnterpriseLinux7 --distro=RHEL-7.2-20150806.1
getArches returns: ['x86_64', 'ppc64', 's390x']

2. if I provide family and distro tag
  --family=RedHatEnterpriseLinux7 --tag=RTT_ACCEPTED
getArches returns: ['x86_64', 'ppc64', 's390x']

Version-Release number of selected component (if applicable):
beaker-client-20.2-1.el7sed.noarch

How reproducible:
100%

Steps to Reproduce:
run getArches() with both family and distro
run getArches() with family and distro tag

Actual results:
some arches are missing

Expected results:
all arches from selected minor release are returned

Additional info:
Comment 1 Dan Callaghan 2015-10-21 03:22:50 EDT
I have this weird feeling that we had an old bug and/or patch from Bill about this same issue. But I can't find anything now.
Comment 2 Dan Callaghan 2015-10-21 03:27:39 EDT
I guess on the client side we actually want to just pass through all the distro-selection options that we were given, and then let the server apply the usual distro selection logic and then decide the arches from that.
Comment 3 Dan Callaghan 2015-10-21 03:35:38 EDT
Also I wonder if we shouldn't just be returning all the actual tree arches that exist for the distro we picked -- rather than looking at the OS minor, which is kind of a roundabout way of doing it.
Comment 4 Dan Callaghan 2015-10-21 04:22:53 EDT
Well ideally the client would just build its desired <distroRequires/> XML and on the server side we would apply that filter and then just return all arches that matched. But unfortunately the workflow commands aren't structured that way, they are expecting to call getArches() before building all their job templates and adding distroRequires etc.

So probably the best we can do for now is:

* flip the condition so that if a specific distro is named, we just use that and nothing else

* also pass tag along, in case the tag filters it down to some older OS version than the latest

* on the server side, find the newest matching distro and use its OS version arch list
Comment 5 Dan Callaghan 2015-10-21 04:30:26 EDT
http://gerrit.beaker-project.org/4450

I guess this can go onto a maintenance release, although it won't always give the right answer until both the client and server have the patch.
Comment 9 matt jia 2015-11-22 22:52:42 EST
Beaker 21.2 has been released.

Note You need to log in before you can comment on or make changes to this bug.