-
Notifications
You must be signed in to change notification settings - Fork 496
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
feat (jkube-kit/helm) : HelmService exposes helm install functionality #3142
feat (jkube-kit/helm) : HelmService exposes helm install functionality #3142
Conversation
Eclipse JKube CI ReportStarted new GH workflow run for #3142 (2024-07-12T12:52:51Z) ⚙️ JKube E2E Tests (9907992305)
|
9a6ca43
to
491426d
Compare
491426d
to
347af49
Compare
7136585
to
f37a0cf
Compare
f37a0cf
to
d8af701
Compare
protected static final String PROPERTY_HELM_RELEASE_NAME = "jkube.helm.release.name"; | ||
protected static final String PROPERTY_HELM_INSTALL_DEPENDENCY_UPDATE = "jkube.helm.install.dependencyUpdate"; | ||
protected static final String PROPERTY_HELM_INSTALL_WAIT_READY = "jkube.helm.install.waitReady"; | ||
protected static final String PROPERTY_HELM_INSTALL_DISABLE_OPENAPI_VALIDATION = "jkube.helm.disableOpenAPIValidation"; |
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 doesn't follow the pattern of other settings.
Is it a generic setting (i.e. it applies to more than one helm goal -install, uninstall, upgrade-)?
Or is it a setting specific to install?
I'd say it's the former, so in this case maybe the field name is not ok.
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 saw in manusa/helm-java#133 that this field is applicable for install and update, that's why I kept the name as global one.
I'll rename the field name.
private Path createTemporaryKubeConfigForInstall() { | ||
if (kubernetesClient == null) { | ||
kubernetesClient = new ClusterAccess(ClusterConfiguration.from( | ||
System.getProperties(), jKubeConfiguration.getProject().getProperties()).build()).createDefaultClient(); |
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 is done to avoid other Helm goals requiring cluster access. When I was trying to initialize KubernetesClient in HelmService construction in JKubeServiceHub, it caused other Helm actions to start throwing exceptions in offline mode
d8af701
to
fbca00a
Compare
this(jKubeConfiguration, resourceServiceConfig, logger, null); | ||
} | ||
|
||
HelmService(JKubeConfiguration jKubeConfiguration, ResourceServiceConfig resourceServiceConfig, KitLogger logger, KubernetesClient kubernetesClient) { |
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'm reviewing and thinking about this PR since yesterday.
The fact that we're adding extra fields to this constructor doesn't feel right (especially one that's not a configuration but a heavy KubernetesClient instance).
We should probably be able to infer the configuration using ClusterConfiguration.from(access, System.getProperties(), project.getProperties()).build();
just like we do here:
Lines 128 to 137 in ad4233e
private ClusterAccess initClusterAccessIfNecessary() { | |
if (offline) { | |
throw new IllegalArgumentException("Connection to Cluster required. Please check if offline mode is set to false"); | |
} | |
if (clusterAccess != null) { | |
return clusterAccess; | |
} | |
return new ClusterAccess(ClusterConfiguration.from( | |
System.getProperties(), configuration.getProject().getProperties()).build()); | |
} |
And then use the ClusterAccess#getConfig to initialize the temporary .kube/config
Maybe we can discuss this later, to see if there are better alternatives.
But storing an KubernetesClient instance here, doesn't seem right at all.
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 had added this mainly for testing. Exposing KubernetesClient field from constructor was causing other helm features to depend on K8s. It's only package private constructor, this KubernetesClient field would not be exposed via public constructor (it's passed as null
)
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.
It doesn't matter, it's still not right to do so.
The helm module has no beef with the Kubernetes Client, it only has the dependency because the kubernetes-client dependency is high up in the hierarchy.
Let's say we want to split this in the future to allow for a helm-maven-plugin, the only dependency we'd probably want at that point would be the helm-java one, nothing else.
6640e57
to
e150f1c
Compare
bc06601
to
09762e3
Compare
ed551d0
to
e9887d1
Compare
Signed-off-by: Rohan Kumar <rohaan@redhat.com>
e9887d1
to
84a7a7d
Compare
Quality Gate passedIssues Measures |
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, thx!
Description
Related to #2663
prepareMockWebServerExpectationsForAggregatedDiscoveryEndpoints
in KubernetesMockServerUtil for adding manual expectations for Kubernetes Aggregated Discovery endpointsinstall
method in HelmService that would perform installation of a helm chart onto Kubernetes cluster using Helm java libraryreleaseName
installDependencyUpdate
installWaitReady
disableOpenAPIValidation
Type of change
test, version modification, documentation, etc.)
Checklist