Changes for supporting ppc64le #19689
Conversation
…already installed in base image
Update .travis.yml Update .travis.yml Update .travis.yml Update .travis.yml Update .travis.yml Update before_install.sh Update before_install.sh Update setup_ruby_env.sh
| dist: bionic | ||
| arch: | ||
| - amd64 | ||
| - ppc64le |
There was a problem hiding this comment.
This is a change that we should make in all the repos before merging this in here.
There was a problem hiding this comment.
@carbonin thank you and acknowledged, I have had to touch mostly the container-ruby and manageiq-pods repo only besides this, would you be able to point to the other repositories that need to have Travis support enabled or I guess I can look up each one under the ManageIQ umbrella? also as mentioned I am working directly with the Travis team to get the PostgreSQL sorted out on Power, so we post an update here once that is done and I can get the job to pass.
| @@ -1,3 +1,4 @@ | |||
| ./tools/ci/setup_ruby_environment.rb | |||
| bundle config --local build.sassc --disable-march-tune-native | |||
There was a problem hiding this comment.
What is going on here? Why is this needed?
There was a problem hiding this comment.
There is more context around why this was needed here #19520
Essentially the build fails while installing (or building) this gem if the --disable-march-tune-native flag is not set for ppc64le
| @@ -1,4 +1,7 @@ | |||
| dist: xenial | |||
| dist: bionic | |||
There was a problem hiding this comment.
I assume we're updating the distribution because xenial doesn't support ppc64le?
There was a problem hiding this comment.
xenial supports ppc64le but has the older (9.x) version of PostgreSQL, where we need 10.x
|
IIUC this is now just a change to update the CI suite to test against the new arch, correct? @seth-priya no changes are needed to the Dockerfile in this repo? |
|
@carbonin that is correct, no changes in the Dockerfile, however the Travis build is failing, the original issue with respect to the PostgreSQL service not starting up correctly on ppc64le has been resolved by the Travis team, however there are test failures in the vmdb test suite. There are lot of errors related to git config in the job logs, but I am yet to have a closer look. |
|
Hm looks like everything that is failing has to do with rugged which is the libgit wrapper for ruby. |
|
thanks for the pointer, will check on that |
|
@carbonin, just a quick update - I setup the build and test environment locally on a Power (ppc64le) VM and do not see the test failures that are seen on Travis i.e. as long as the git "user.name" and "user.email" values are set correctly. By unsetting them, I was able to replicate the issue. I further configured a test Travis job to print the git config --list and confirmed that while these values are set by default on the base Travis/Intel image as follows user.name=Travis CI User BUT, they are not set for other architectures (ppc64le/s390x etc.), so I have reached out to the Travis team to help correct this and I expect the job will just pass post that. I will keep you posted on the developments! |
|
👍 Great find @seth-priya |
|
@carbonin the Travis base image issue for ppc64le is resolved now and the build is passing now! I will check the indentation issue reported above, though |
|
Checked commits seth-priya/manageiq@9aad0f2~...b6fc82c with ruby 2.5.7, rubocop 0.69.0, haml-lint 0.28.0, and yamllint |
|
So while it's good to know our tests pass in both architectures this adds a ton of time to the suite. @Fryguy is this something we really want to add to every PR? I'm not sure our tests really have that much exposure to arch differences ...
|
|
@carbonin understand your concerns, I will investigate more about the additional time being taken for Power, as well - specifically if it something on Travis side or consistent across all environments |
|
Yeah, I'm very concerned about the time needed. Let's hold this open while @seth-priya looks why this is so slow, and we'll decide based on that. |
|
@carbonin @Fryguy - thanks for your patience and support on this while we investigated the issue on our side, working in close co-ordination with the Travis team. So, here is an update - further investigation and some adjustments and tuning of certain parameters on the Travis side have confirmed that the issues were environment specific and with recent changes (on the Travis side), we are seeing better execution times which are now quite close to and comparable with Intel https://travis-ci.com/github/Siddhesh-Ghadi/manageiq-/builds/161012931. Please note though, that some recent changes upstream (in manageiq-providers-azure_stack and manageiq-pods) have broken a couple of things on Power and I am working on fixing them, will shortly create separate issues to track those. |
Installation of unf_ext gem < v0.0.7.4 fails on power More info: ManageIQ/manageiq-pods#460 (comment)
Changes for ext_unf gem installation
seth-priya
requested review from
agrare,
bdunne,
jrafanie and
kbrock
as code owners
|
@seth-priya this diff looks wrong. Maybe a bad rebase/merge? |
|
yeah, sorry @carbonin I think I'll drop this one and let @Siddhesh-Ghadi create a new PR for Travis enablement |
This is in reference to
#19676
Please note that the Travis job for Power is still failing and the cause for that is that the PostgreSQL-10 service is not starting correctly on Power, I am planning to raise it to the Travis team today.
The last logs for reference
https://travis-ci.org/seth-priya/manageiq