[stable/jenkins] Make chart compatible with Helm 3

[helfper]

Signed-off-by: Helder Pereira helfper@gmail.com

What this PR does / why we need it:

Trying to install Jenkins chart with route enabled using Helm 3 fails because of openshift/origin#24060:

$ helm install jenkins . --set master.route.enabled=true
Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(Route.spec): missing required field "host" in com.github.openshift.api.route.v1.RouteSpec, ValidationError(Route): missing required field "status" in com.github.openshift.api.route.v1.Route]

This PR adds the missing fields required by the Route v1 spec. Additionally, it also fixes the confusing binding from a value called master.route.path to the Route's host field.

Checklist

• DCO signed
• Chart Version bumped
• Variables are documented in the README.md
• Title of the PR starts with chart name (e.g. [stable/mychartname])

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: helfper
To complete the pull request process, please assign viglesiasce
You can assign the PR to them by writing /assign @viglesiasce in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• stable/jenkins/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Hi @helfper. Thanks for your PR.

I'm waiting for a helm member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[torstenwalter]

We should not include a status in the generated manifests.

[helfper]

Adding status is needed to solve the problem that this PR is trying to address, that is being able to create this route using Helm 3. You can see that in the error I pasted and in the issue linked in the PR description.

[torstenwalter]

My feeling is that we would fix it at the wrong location. For me it's rather an upstream issue that those fields are marked as required. Introducing a fix here would also mean to remove it later.

[helfper]

While I completely agree that the status should have been made optional in the spec. As it stands, I'd argue that this chart is wrong by creating a resource that doesn't follow its specification.

[torstenwalter]

Why do we need a different value host can't we re-use the already existing hostName?

[helfper]

I feel it would be rather confusing to use master.ingress.hostName as the route's host, when we are not using anything else from master.ingress.* in the route definition. Unless it was changed to master.hostName.

[torstenwalter]

Agree that it's not ideal. The issue I see is that the hostname is also used to determine the Jenkins URL which is configured in the config map. Here is the template code:

{{/*
Returns the Jenkins URL
*/}}
{{- define "jenkins.url" -}}
{{- if .Values.master.jenkinsUrl }}
  {{- .Values.master.jenkinsUrl }}
{{- else }}
  {{- if .Values.master.ingress.hostName }}
    {{- if .Values.master.ingress.tls }}
      {{- default "https" .Values.master.jenkinsUrlProtocol }}://{{ .Values.master.ingress.hostName }}{{ default "" .Values.master.jenkinsUriPrefix }}
    {{- else }}
      {{- default "http" .Values.master.jenkinsUrlProtocol }}://{{ .Values.master.ingress.hostName }}{{ default "" .Values.master.jenkinsUriPrefix }}
    {{- end }}
  {{- else }}
      {{- default "http" .Values.master.jenkinsUrlProtocol }}://{{ template "jenkins.fullname" . }}:{{.Values.master.servicePort}}{{ default "" .Values.master.jenkinsUriPrefix }}
  {{- end}}
{{- end}}
{{- end -}}

https://github.com/helm/charts/blob/master/stable/jenkins/templates/_helpers.tpl#L51-L68

So it won't be as easy as introducing a new flag...

[helfper]

1. It's seems the same due diligence was not done during the code review when this route was added initially. I don't think that, by any measure, this PR makes that situation worse than it is currently. Notice that the route's host can already be modified by setting master.route.path, which is not taken into account whatsoever in the jenkins.url definition.

2. Even ignoring the route for a second, that logic for jenkins.url doesn't seem right. If I don't set the master.jenkinsUrl value and set master.ingress.enabled to false, the jenkins.url template might still use the value master.ingress.hostName.

3. The logic for jenkins.url can easily be changed to take into account the route values:

{{- define "jenkins.url" -}}
{{- if .Values.master.jenkinsUrl }}
  {{- .Values.master.jenkinsUrl }}
{{- else if and .Values.master.ingress.enabled .Values.master.ingress.hostName }}
  {{- if .Values.master.ingress.tls }}
    {{- default "https" .Values.master.jenkinsUrlProtocol }}://{{ .Values.master.ingress.hostName }}{{ default "" .Values.master.jenkinsUriPrefix }}
  {{- else }}
    {{- default "http" .Values.master.jenkinsUrlProtocol }}://{{ .Values.master.ingress.hostName }}{{ default "" .Values.master.jenkinsUriPrefix }}
  {{- end }}
{{- else if and .Values.master.route.enabled .Values.master.route.host }}
  {{- default "http" .Values.master.jenkinsUrlProtocol }}://{{ .Values.master.route.host }}{{ default "" .Values.master.jenkinsUriPrefix }}
{{- else }}
  {{- default "http" .Values.master.jenkinsUrlProtocol }}://{{ template "jenkins.fullname" . }}:{{.Values.master.servicePort}}{{ default "" .Values.master.jenkinsUriPrefix }}
{{- end}}
{{- end -}}

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

[stale]

This issue is being automatically closed due to inactivity.