Bug 1793128: enable s390x bootimage support #2933

crawford · 2020-01-16T03:51:14Z

This is a backport of #2885 along with two other commits that enable and add s390x images. The latter two weren't included in master because there are no 4.4 builds for s390x.

Don't allow people to point to e.g. an RHT-internal endpoint. See: #2462

Not everyone has python3 installed into /usr/bin/.

openshift-ci-robot · 2020-01-16T03:51:16Z

@crawford: No Bugzilla bug is referenced in the title of this pull request.
To reference a bug, add 'Bug XXX:' to the title of this pull request and request another bug refresh with /bugzilla refresh.

In response to this:

*: enable s390x bootimage support

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

crawford · 2020-01-16T04:06:41Z

/hold

Waiting to know that this is the correct version for s390x.

wking · 2020-01-16T04:28:54Z

$ git --no-pager grep buildid origin/pr/2933 -- data/data
origin/pr/2933:data/data/rhcos-amd64.json:    "buildid": "42.80.20191002.0",
origin/pr/2933:data/data/rhcos-s390x.json:    "buildid": "42s390x.81.20191224.0",
origin/pr/2933:data/data/rhcos.json:    "buildid": "42.80.20191002.0",

We're ok with this divergence? Should we be bumping AWS to a December build at the same time? Or are our AMIs frozen out? Do we have a summary of what chanced between October and December?

miabbott · 2020-01-16T14:00:28Z

Should we be bumping AWS to a December build at the same time? Or are our AMIs frozen out?

We haven't made new AMIs for 4.2 since the GA release.

Do we have a summary of what chanced between October and December?

The biggest change is a bump from RHEL 8.0 to RHEL 8.1 content. Using the x86_64 metadata as a guide (the differ script doesn't support multi-arch, yet):

https://gist.github.com/miabbott/1e790139031706c4b47eec10f2870e40

andymcc · 2020-01-16T14:46:32Z

The latest build for s390x is here:
https://releases-rhcos-art.cloud.privileged.psi.redhat.com/?stream=releases/rhcos-4.2-s390x&release=42s390x.81.20200115.0#42s390x.81.20200115.0

That said no changes have gone in to redhat-coreos or coreos-assembler for the 4.2-multiarch branch since 2019/12/19 so I don't think there would be any benefit to changing that version to the latest from the 2019/12/24 build.

crawford · 2020-01-16T21:36:53Z

/retest

wking · 2020-01-16T21:43:27Z

You'll need a bug to get the bugzilla/valid-bug label.

sdodson · 2020-01-16T21:45:30Z

/approve

openshift-ci-robot · 2020-01-16T21:45:58Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: sdodson

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [sdodson]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

wking · 2020-01-16T22:34:29Z

Comparing with the master-ward PR:

45de9b9 is from hack/update-rhcos-bootimage: Require ART endpoint #2463 (also landed in master).
efaeb0c is a clean cherry-pick of 8428471.

I dunno if we care about fixing this shift:

diff -U3 <(git show b1726d2c5) <(git show 9895178ce) | tail -n15
  args = parser.parse_args()
  
-+metadata_dir = os.path.join(os.path.dirname(sys.argv[0]), "../data/data")
-+
  if not args.meta.startswith(RHCOS_RELEASES_APP):
      raise SystemExit("URL must start with: " + RHCOS_RELEASES_APP)
  
++metadata_dir = os.path.join(os.path.dirname(sys.argv[0]), "../data/data")
++
+ with urllib.request.urlopen(args.meta) as f:
+     string_f = codecs.getreader('utf-8')(f)  # support for Python < 3.6
+     meta = json.load(string_f)
 @@ -32,5 +33,14 @@ newmeta['amis'] = {
      for entry in meta['amis']
  }

Otherwise b1726d2 -> 9895178 only differs in the choice of bootimage, which is fine.

2583ba4 -> 13a0e55 has a lot of context noise, but is a clean cherrypick.
d7f0664 and 1362d78 are new (because the masterward PR wasn't adding s390x, as discussed earlier in this PR).

wking · 2020-01-16T22:35:44Z

Oh, hanging a bug on this will need a 4.3 backport of #2885 as well. Which I guess will not include these s390x commits?

wking · 2020-01-16T22:42:44Z

Two nits: the metadata_dir position and the reactive-bump-logic suggestion. I'm fine with this landing without either of those being addressed though.

This splits the RHCOS build metadata into architecture-specific files. This will allow the metadata to contain information about bootimages of multiple architectures. In order to preserve backward compatibility (there are a few users, including certain CI jobs, that pull rhcos.json from GitHub directly), I've opted to use separate files for each architecture. Normally, we could have just symlinked the legacy metadata file, but when hosted on raw.githubcontent.com, the symlinks aren't followed. When updating the RHCOS bootimages, this script will need to be run once for each architecture that is being updated. The build metadata was resynced with the following: ./hack/update-rhcos-bootimage.py https://releases-art-rhcos.svc.ci.openshift.org/art/storage/releases/rhcos-4.2/42.80.20191002.0/meta.json amd64

This adds an architecture parameter to the RHCOS image lookup process and a corresponding field to MachinePool. This is a backward-compatible change, defaulting the architecture to AMD64 if none has been specified. This also enforces that the control plane and compute nodes share an architecture, since we don't support heterogeneous clusters today.

These images differ in version from the AMD64 variants because the s390x variants don't exist. Support for s390x was added after 4.2 was released. The version used here has been the one tested in CI. This was generated with the following: ./hack/update-rhcos-bootimage.py https://releases-art-rhcos.svc.ci.openshift.org/art/storage/releases/rhcos-4.2-s390x/42s390x.81.20191224.0/meta.json s390x

crawford · 2020-01-16T22:48:39Z

@wking Good catches. I've updated the commits to address both.

openshift-ci-robot · 2020-01-20T18:05:55Z

@crawford: This pull request references Bugzilla bug 1793128, which is invalid:

expected Bugzilla bug 1793128 to depend on a bug in one of the following states: VERIFIED, RELEASE_PENDING, CLOSED (ERRATA), but no dependents were found

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

Bug 1793128: enable s390x bootimage support

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

crawford · 2020-01-20T18:06:54Z

We've come to an agreement that this is the desired image.

/hold cancel

crawford · 2020-01-20T18:08:12Z

I'm manually changing the BZ validity label because this change cannot (at this time) be verified in the 4.3 branch. Once Z ships, we will then start on forward-porting these changes to the release-4.3 branch. A little backward, I know.

patrickdillon · 2020-01-20T20:07:40Z

/lgtm

openshift-bot · 2020-01-20T20:19:49Z

/retest