Bug 1255420
| Summary: | getArches() doesn't return all arches for release minor | ||
|---|---|---|---|
| Product: | [Retired] Beaker | Reporter: | Jan Stancek <jstancek> |
| Component: | command line | Assignee: | Dan Callaghan <dcallagh> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | tools-bugs <tools-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | asavkov, bpeck, dcallagh, dowang, jburke, mjia, pbunyan, rjoost |
| Target Milestone: | 21.2 | Keywords: | NeedsTestCase, Patch |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-11-23 03:52:42 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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. 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. 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 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. Beaker 21.2 has been released. |
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: