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

Add conditionals for Rhel9 in common role #3802

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

AswathySK
Copy link
Contributor

The common role for Unix playbook doesnt include conditionals for rhel9 causing playbook failures.

Failures caused due to current condition:

  • EPEL release not enabled for rhel9
  • packags included in Installing additional build tools if NOT RHEL 8 task is applicable for rhel9 as well. For example NTP is replaced by chronyd.
  • Additional build tools for rhel 8 is also required by rhel 9
Checklist
  • commit message has one of the standard prefixes
  • faq.md updated if appropriate
  • other documentation is changed or added (if applicable)
  • playbook changes run through VPC or QPC (if you have access)
  • VPC/QPC not applicable for this PR
  • for inventory.yml changes, bastillion/nagios/jenkins updated accordingly

Sorry, something went wrong.

Copy link
Contributor

@AdamBrousseau AdamBrousseau left a comment

Choose a reason for hiding this comment

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

@AswathySK can we make these conditions smarter so we don't have to keep updating them every time a new OS is released? Or do we prefer to leave it like this so we can test the new major OS releases?

@AswathySK
Copy link
Contributor Author

@AdamBrousseau instead of changing conditional to do it for everything greater than or equal to rhel 8 instead?
There could be change in package dependencies for the future releases.
So how to make the change right now is up to the community I suppose.

@AdamBrousseau
Copy link
Contributor

Sure. We can get other opinions. If we change it to be something like >=, and it stops working, the PBs will presumably fail and someone can investigate at that point. That would have to happen either way, but at least this way, you don't have to monitor and update it when it works.

@AdamBrousseau
Copy link
Contributor

@sxa do you have an opinion on the above?

@AswathySK AswathySK force-pushed the rhel9-conditionals branch 2 times, most recently from d831534 to e9ee426 Compare November 12, 2024 06:16
@AswathySK
Copy link
Contributor Author

@AdamBrousseau , I have made the change as per your suggestion.

package: "name={{ item }} state=latest"
with_items: "{{ Java_RHEL8 }}"
when: (ansible_distribution_major_version == "8")
when: (ansible_distribution_major_version | int >= 8)
Copy link
Contributor

Choose a reason for hiding this comment

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

Are these 3 cases still what we want?
From

Java_RHEL8:
  - java-1.8.0-openjdk-devel

Java_NOT_RHEL6_PPC64:             # Not RHEL8 either
  - java-1.7.0-openjdk-devel
  - java-1.8.0-openjdk-devel

Java_RHEL6_PPC64:
  - java-1.7.0-ibm-devel
  - java-1.8.0-ibm-devel

What is java 7 and 8 used for?

Copy link
Contributor Author

@AswathySK AswathySK Nov 12, 2024

Choose a reason for hiding this comment

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

@AdamBrousseau @sxa , I am not sure. Should we bump it to 17 or 21?

Copy link
Contributor

Choose a reason for hiding this comment

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

As far as I can tell it's been there since the beginning. Java is needed for 2 purposes that I know of.

  • Connecting agents to jenkins.
  • Bootjdk for compiling java.

Since Jenkins now requires jdk17 to run agents, and jdk11 was required 2 years ago, I don't think leaving this at java8 for jenkins connections is necessary.
For bootjdk requirement, the build scripts will pull the needed jdk during the build process so having a permanent install of 8 is not necessary in my opinion.

I would want an opinion from Adopt/@sxa before we remove it completely though.

Copy link
Member

Choose a reason for hiding this comment

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

As far as the boot JDK is concerned I don't want the builds pulling it down dynamically in most cases - that's mostly just a fallback mechanism. Other than pulling down the source, the builds should be able to run without network access.

I suspect those java-1.8.0* packages are no longer required, at least by Temurin, so it would likely be safe to remove them.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@AdamBrousseau , @sxa ,
Since stewart is of opinion not to pull down the bootjdks by the jobs.And java8 is not required, Should we remove the installing and setting up default java part in this role or should we maybe bump it to jdk17 or 21?

Copy link
Member

Choose a reason for hiding this comment

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

Yes I think that should be safe. It will hopefully be obvious if some part of the process requires it, in which case it's easy to back it out again :-)

Can the 1.7 version be installed from the RHEL9 repositories?

Copy link
Contributor

Choose a reason for hiding this comment

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

@sxa is there another part of the PB installing java for use by the jenkins agent that Adopt is running?
We have an internal Semeru role that installs 21 for this.

Copy link
Member

Choose a reason for hiding this comment

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

Yep. The adoptopenjdk_install role: .

- role: adoptopenjdk_install # JDK21 Build Bootstrap

It's extracting as a tarball and doesn't set any default on the system to point to it, so the Jenkins agent is pointed directly to it under /usr/lub/jvm when it's started

@karianna karianna requested a review from sxa November 25, 2024 21:33
Signed-off-by: Aswathy S Kumar <aswathyskumar144@gmail.com>
Signed-off-by: Aswathy S Kumar <aswathyskumar144@gmail.com>
@karianna
Copy link
Contributor

karianna commented Dec 5, 2024

@AswathySK Linter failures as well

Copy link
Member

@sxa sxa left a comment

Choose a reason for hiding this comment

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

A few comments/suggestions in addition to the Java7 on RHEL9 comments above.
Should any of these changes be made in the CentOS files too?

package: "name={{ item }} state=latest"
with_items: "{{ Additional_Build_Tools_NOT_RHEL8 }}"
with_items: "{{ Additional_Build_Tools_NOT_RHEL8Plus }}"
Copy link
Member

Choose a reason for hiding this comment

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

We probably need to go through and sanitise some of these names. This one should probably be Additional_Build_Tools_RHEL6_RHEL7 now but that doesn't need to be changed in this PR

@@ -92,17 +92,6 @@ Additional_Build_Tools_RHEL7_s390x:
- libstdc++.s390 # a dependency required for executing a 32-bit C binary
- yum-utils # yumdownloader required for devkit creation

Java_RHEL8:
Copy link
Member

@sxa sxa Dec 5, 2024

Choose a reason for hiding this comment

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

Since we still have the reference to Java_RHEL8 above I believe this should not be removed

@karianna karianna requested a review from sxa January 15, 2025 01:35
@sxa
Copy link
Member

sxa commented Jan 15, 2025

New VPC run at https://ci.adoptium.net/view/Tooling/job/VagrantPlaybookCheck/2038/ (Expect at least CentOS6 to fail - unrelated to this PR)

@karianna
Copy link
Contributor

@AswathySK merge conflicts.

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

A block has been put on this Pull Request as this repository is temporarily under a code freeze due to an ongoing release cycle.

If this pull request needs to be merged during the release cycle then please comment /merge and a PMC member will be able to remove the block.

If the code freeze is over you can remove this block by commenting /thaw.

@AswathySK
Copy link
Contributor Author

@karianna @sxa ,
should this merge wait until code freeze is over?

@karianna
Copy link
Contributor

Yes and I'd love to see the CEntOS6 and Solaris GH actions start passing again, but I suspect that's a separate issue

@AswathySK
Copy link
Contributor Author

@karianna ,
when will the code freeze be over?

@karianna
Copy link
Contributor

Not sure, should be by end of this week at the latest though

@sxa
Copy link
Member

sxa commented Feb 4, 2025

Looks like it was done during my time away at FOSDEM :-)
adoptium/.github#193
Currently catching up with notifications ...

@AswathySK
Copy link
Contributor Author

@sxa @karianna ,
Can this be merged then as the code freeze is over?

@karianna
Copy link
Contributor

karianna commented Feb 5, 2025

/merge

@karianna
Copy link
Contributor

karianna commented Feb 5, 2025

Hmm, I think it actually wants the two failing GH Actions to pass (although I realize they're not related)

@sxa
Copy link
Member

sxa commented Feb 5, 2025

@AswathySK Have you confirmed that a system installed with these playbooks is capable of building and testing openjdk? When I tried to run a temurin build in a CentOS Stream 9 (Should be equivalent to RHEL9) containers configured with these changes it was still missing some things like diffutils.

[EDIT: diffutils and procps-ng are not included with the default containers for Stream 9 and later, so I've created an issue to get those added]

@sxa
Copy link
Member

sxa commented Feb 5, 2025

Hmm, I think it actually wants the two failing GH Actions to pass (although I realize they're not related)

I'd be happy to dismiss the bots review for the purposes of getting this through when we agree it's ready.

@sxa
Copy link
Member

sxa commented Feb 5, 2025

Side note: It looks like the playbooks are not happy running under the version of ansible that ships with CentOS Stream 10 (and presumably true for the upcoming RHEL10 release), but that's for the future.

@sxa
Copy link
Member

sxa commented Feb 6, 2025

/thaw

@github-actions github-actions bot dismissed their stale review February 6, 2025 11:12

Pull Request unblocked - code freeze is over.

Copy link
Member

@sxa sxa left a comment

Choose a reason for hiding this comment

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

From the limited testing I can do just now this looks good I think. Needs a second reviewer then we can get it in.

@sxa sxa requested review from Haroon-Khel, karianna and AdamBrousseau and removed request for AdamBrousseau February 6, 2025 11:43
@sxa
Copy link
Member

sxa commented Feb 6, 2025

@AswathySK Did you manage to get this working on RHEL9 given that the curl installation that the playbooks do would confict with curl-minimal which is there by default?

[EDIT: I've included a change in https://github.com//pull/3870/commits/9ce073d93fcbca837b57d66117c70790f08d068f to compensate for this]

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

Successfully merging this pull request may close these issues.

None yet

4 participants