Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ARM image build support #7607

Merged

Conversation

agaffney
Copy link
Contributor

SUMMARY

This commit adds support for building AWX docker images on ARM/64

  • upgrade chromedriver for ARM support
  • upgrade pynacl to fix libsodium build issue on ARM
  • remove unnecessary i686-specific libstdc++.so.6 package
  • install kubectl and tini from upstream binaries for ARM support
  • use upstream postgres and alpine docker images for postgresql helm chart

Fixes #7051

ISSUE TYPE
  • Feature Pull Request
COMPONENT NAME
  • Installer
AWX VERSION

N/A

ADDITIONAL INFORMATION

N/A

@softwarefactory-project-zuul
Copy link
Contributor

Build failed.

@softwarefactory-project-zuul
Copy link
Contributor

Build failed.

@softwarefactory-project-zuul
Copy link
Contributor

Build failed.

@softwarefactory-project-zuul
Copy link
Contributor

Build failed.

@softwarefactory-project-zuul
Copy link
Contributor

Build failed.

@agaffney agaffney closed this Jul 27, 2020
@agaffney agaffney reopened this Jul 27, 2020
@softwarefactory-project-zuul
Copy link
Contributor

Build succeeded.

@shanemcd
Copy link
Member

Ping @jakemcdermott. JFYI, this bumps the version of chromedriver.

Copy link
Member

@shanemcd shanemcd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will let this sit for another day or so for more feedback to trickle in, but I'm +1 on this.

@ryanpetrello
Copy link
Contributor

I think my biggest concern about this is not the work in this PR, but in how we add CI so we avoid breaking it long term (every time we add some dependency, we'll have to make sure we don't break ARM support?)

dnf -y install centos-release-stream && dnf -y install "rsyslog >= 8.1911.0" && dnf -y remove centos-release-stream && \
dnf -y clean all

# Install kubectl
RUN curl -L -o /usr/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/v1.17.8/bin/linux/{{ kubectl_architecture | default('amd64') }}/kubectl && \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to do this in a way that doesnt require pinning the version of kubectl?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The k8s docs[1] show using a command like the following, but I personally don't like that for various reasons.

curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"

[1] https://kubernetes.io/docs/tasks/tools/install-kubectl/

@shanemcd
Copy link
Member

@ryanpetrello I think saying this is only "community supported" is fine... we have plenty of other install paths that aren't tested by either upstream or downstream tests.

@jakemcdermott
Copy link
Contributor

chromedriver bump should be fine as long as unit tests still work and are passing. That appears to be the case so LGTM.

@softwarefactory-project-zuul
Copy link
Contributor

Build failed (gate pipeline). For information on how to proceed, see
http://docs.openstack.org/infra/manual/developers.html#automated-testing

@agaffney
Copy link
Contributor Author

Why do the SSL connections randomly get closed when running these tests? There seems to be some trouble with the test infra, because I really doubt that storage.googleapis.com is that flaky

@ryanpetrello
Copy link
Contributor

regate

@softwarefactory-project-zuul
Copy link
Contributor

Build failed (gate pipeline). For information on how to proceed, see
http://docs.openstack.org/infra/manual/developers.html#automated-testing

* upgrade `chromedriver` for ARM support
* upgrade `pynacl` to fix `libsodium` build issue on ARM
* remove unnecessary i686-specific `libstdc++.so.6` package
* install `kubectl` and `tini` from upstream binaries for ARM support
* use upstream `postgres` and `alpine` docker images for `postgresql` helm chart

Fixes ansible#7051
@softwarefactory-project-zuul
Copy link
Contributor

Build succeeded.

@ryanpetrello
Copy link
Contributor

ryanpetrello commented Jul 31, 2020

Why do the SSL connections randomly get closed when running these tests? There seems to be some trouble with the test infra, because I really doubt that storage.googleapis.com is that flaky

Yea, I'm not totally sure what's going on here. It seems specific to this URL, though:

https://storage.googleapis.com/kubernetes-release/release/v1.17.8/bin/linux/amd64/kubectl

@shanemcd, you have any ideas?

@softwarefactory-project-zuul
Copy link
Contributor

Build failed (gate pipeline). For information on how to proceed, see
http://docs.openstack.org/infra/manual/developers.html#automated-testing

@shanemcd
Copy link
Member

regate

@softwarefactory-project-zuul
Copy link
Contributor

Build failed (gate pipeline). For information on how to proceed, see
http://docs.openstack.org/infra/manual/developers.html#automated-testing

@ryanpetrello
Copy link
Contributor

regate

@softwarefactory-project-zuul
Copy link
Contributor

Build succeeded (gate pipeline).

@softwarefactory-project-zuul softwarefactory-project-zuul bot merged commit 5d208cc into ansible:devel Aug 19, 2020
ryanpetrello added a commit to ryanpetrello/awx that referenced this pull request Aug 25, 2020
chrismeyersfsu pushed a commit to chrismeyersfsu/awx that referenced this pull request Aug 27, 2020
mabashian pushed a commit to mabashian/awx that referenced this pull request Aug 31, 2020
elyezer pushed a commit to ryanpetrello/awx that referenced this pull request Sep 1, 2020
AlanCoding pushed a commit to AlanCoding/awx that referenced this pull request Sep 10, 2020
@JRobinson333
Copy link

I've just run into the standard_init_linux.go:228: exec user process caused: exec format error and realised there was architecture incompatibility. In the first instance it'd be really good to get some pointers about getting this running on aarch64 but adding CI for aarch64 would be great too!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ARM64/Aarch64 Support (Raspberry Pi4)
6 participants