-
Notifications
You must be signed in to change notification settings - Fork 44
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
(Tests pending) TOOL-11960 Install ca-certifcates to delphix-platform such that openjdk11 can install #317
Conversation
Happy to say testing is no longer pending. @basil's suggestion to install
appliance-build-orchestrator-pre-push job: http://ops.jenkins.delphix.com/job/devops-gate/job/master/job/appliance-build-orchestrator-pre-push/1078/console |
debian/rules
Outdated
@@ -93,7 +93,7 @@ DEPENDS += pam-challenge-response, \ | |||
# Platform-specific dependencies | |||
DEPENDS.aws = nvme-cli, | |||
DEPENDS.azure = walinuxagent, | |||
DEPENDS.esx = open-vm-tools, | |||
DEPENDS.esx = open-vm-tools, ca-certificates-java, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this package specific to ESX? IMO, we should try to minimize the differences between the various cloud platforms, so I'd like to install this package in all cases, rather than specific to ESX, if possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This package is only consumed by a variant that is only used by ESX. As discussed in this Slack thread in #dcol-dev, this package is only consumed by the internal-dcenter
variant, whose only consumer is ESX. To keep package installations as minimal as possible I decided to only install it on ESX. In addition, as part of TOOL-11962 I plan to deprecate the ability to build the internal-dcenter
variant for any platform aside from ESX. Doing so will decrease the number of appliance-build-stage1 jobs from 42 (6 variants * 7 platforms) to 36 (5 variants * 7 platforms), a 14% decrease (which saves time and resources on wasted builds for variant-platform combos that aren't useful)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To keep package installations as minimal as possible I decided to only install it on ESX.
Please correct me if I'm mistaken, but I interpret this to mean that we could install this package on all platforms without adverse effects. Thus, my preference would be to do that. IMO, I value consistency of the product across the cloud platforms, even when that isn't strictly necessary, than intentional inconsistency to avoid installing packages on platforms that may not need the package.
With that said, I'm not sure what our "official" stance is w.r.t. cloud platform consistency, so others may disagree.
In addition, as part of TOOL-11962 I plan to deprecate the ability to build the internal-dcenter variant for any platform aside from ESX.
Sure, that's fine, but tangential to this specific issue/PR. For example, this new package will not be installed on non-dcenter variants, so I just want to make sure this change is "correct" for the non-dcenter cases as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd tend to agree with Prakash on that. Unless ca-certificates-java
causes some unwanted side-effects on other platforms or takes an excessive amount of space I'd say it's preferable to install it on all platforms. Moreover, given that most of our automated testing is run on AWS, if that package does cause some side effects we'd be more likely to catch it this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you both for your feedback. I'll install the package on all platforms and re-build with all testing (I am unable to run tests on internal-dcenter variant as show in this attempted job)
bb80018
to
783084c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, pending testing. Please get a successful git-ab-pre-push
run with this change, in addition to any dcenter specific testing.
Thanks for the review. Here's the appliance-build-orchestrator job: http://ops.jenkins.delphix.com/job/devops-gate/job/master/job/appliance-build-orchestrator-pre-push/1089/console, it's still running. As mentioned in my edited reply here above I cannot run the dx-integration-tests with the |
I'm requesting a clean run of |
@prakashsurya thanks for double checking my test and it makes sense, here's the job kicked off from There were no arguments except |
(copied from this JIRA comment for TOOL-11960) This causes a regression. Java 11 is a dependency of The new approach is to install |
Background:
As part of TOOL-11707, we are trying to install Java 11 on the DCoL hosts because the Jenkins project is planning on deprecating Java 8 support in the near future. DCoL is used as a Jenkins agent.
Problem:
When testing TOOL-11707, I tried to install
openjdk11
but I kept receiving this error:As @basil mentions in this GitHub PR comment, adding
ca-certificates-java
to the delphix-platform package list should resolve this.The current workaround is to install
adoptopenjdk-java11-jdk
but this install is Linux distribution dependent (we plan on upgrading as part of TOOL-7726) and also requires setting apt keys and repository, a bit of a maintenance burden.Solution:
Add the package. Test the change for this in conjunction with the change for TOOL-11707, which is being reviewed in this appliance-build PR (ID 576).
Testing:
appliance-build-orchestrator-pre-push job: http://ops.jenkins.delphix.com/job/devops-gate/job/master/job/appliance-build-orchestrator-pre-push/1078/console
See next comment: #317 (comment)
Related tickets:
internal-dcenter
appliance-buildca-certificates-java
is only being added to ESX andinternal-dcenter
will require this package, it makes sense to only build theinternal-dcenter
variant for ESX. This will also moderately decrease the number of appliance-build-stage1 post-push jobs from 42 (6 variants * 7 platforms) to 36 (5 variants * 7 platforms + 1internal-dcenter
for ESX)