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

Helm chart deploy registries #13890

Merged
merged 10 commits into from
Jul 23, 2019
Merged

Helm chart deploy registries #13890

merged 10 commits into from
Jul 23, 2019

Conversation

sparkoo
Copy link
Member

@sparkoo sparkoo commented Jul 18, 2019

What does this PR do?

Helm chart to deploy devfile and plugin registries with Che by default.

What issues does this PR fix or reference?

#13633 which is subtask of #13557

Release Notes

n/a

Docs PR

n/a

@che-bot
Copy link
Contributor

che-bot commented Jul 18, 2019

Can one of the admins verify this patch?

1 similar comment
@che-bot
Copy link
Contributor

che-bot commented Jul 18, 2019

Can one of the admins verify this patch?

@skabashnyuk skabashnyuk requested a review from monaka July 18, 2019 06:57
Signed-off-by: Michal Vala <mvala@redhat.com>
@sparkoo
Copy link
Member Author

sparkoo commented Jul 18, 2019

I've added new bool variables for each registry deploy cheDevfileRegistry.deploy and chePluginRegistry.deploy. This might be replaced by just url variables with logic "When url is set, don't deploy. When url is empty, deploy registry.". However, this would break scenario when user wants to set the url and deploy registry at the same time. I'm not sure that this scenario is valid though.
Thoughts?

{{- if .Values.cheDevfileRegistry.url }}
CHE_WORKSPACE_DEVFILE__REGISTRY__URL: {{ .Values.cheDevfileRegistry.url | quote }}
{{- else if .Values.cheDevfileRegistry.deploy }}
CHE_WORKSPACE_DEVFILE__REGISTRY__URL: http://{{ printf .Values.global.cheDevfileRegistryUrlFormat .Release.Namespace .Values.global.ingressDomain }}
Copy link
Contributor

Choose a reason for hiding this comment

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

how it will work if che would be configured to work over https?

Copy link
Member Author

Choose a reason for hiding this comment

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

hmm, good question. It probably will not work. I guess we would need to have registries also on https then. I'll look at that.

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed af3eaeb
I'd like to avoid duplication of print, but I don't know how to do it to keep readability.

{{- if .Values.chePluginRegistry.url }}
CHE_WORKSPACE_PLUGIN__REGISTRY__URL: {{ .Values.chePluginRegistry.url | quote }}
{{- else if .Values.chePluginRegistry.deploy }}
CHE_WORKSPACE_PLUGIN__REGISTRY__URL: http://{{ printf .Values.global.chePluginRegistryUrlFormat .Release.Namespace .Values.global.ingressDomain }}/v3
Copy link
Contributor

Choose a reason for hiding this comment

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

same question about https?

@skabashnyuk
Copy link
Contributor

skabashnyuk commented Jul 18, 2019

Does this pr compatible with che-incubator/chectl#189 these changes?

@musienko-maxim
Copy link
Contributor

Can one of the admins verify this PR?

@sparkoo
Copy link
Member Author

sparkoo commented Jul 18, 2019

@skabashnyuk no, because I've changed the che.workspace.devfileRegistryUrl variable to cheDevfileRegistry.url. It's passed here in chectl https://github.com/che-incubator/chectl/blob/master/src/installers/helm.ts#L184, so it's an easy fix. However, as I'm thinking about it, I would rather revert my change here, as it is Che configuration and not Registry configuration.

Signed-off-by: Michal Vala <mvala@redhat.com>
@sparkoo
Copy link
Member Author

sparkoo commented Jul 18, 2019

@skabashnyuk ok, I've reverted the variable rename and it is still not compatible as chectl have it's defaults to openshift.io registries and is always sending the parameter, overriding anything what was set before. I guess patch chectl to NOT have default registries urls is way to go here. Agree?

@skabashnyuk
Copy link
Contributor

I guess patch chectl to NOT have default registries urls is way to go here. Agree?

I believe that makes sense.
CC @l0rd

@davidfestal
Copy link
Contributor

I've added new bool variables for each registry deploy cheDevfileRegistry.deploy and chePluginRegistry.deploy

@l0rd When discussing about the implementation of this issue on the operator side, we had agreed on using the externalDevfileRegistry field in the Custom resource, with a default value to false, instead of having a deployDevfileRegistry with default to true. This seemed more consistent with how it is managed for Keycloak (at least in the operator) and how defaults are managed in Go K8s CRDs.

Maybe this should be the same in the helm charts and chectl options ?
cheDevfileRegistry.external for exemple here ?

# devfileRegistryUrl: "https://che-devfile-registry.openshift.io/"
# pluginRegistryUrl: "https://che-plugin-registry.openshift.io/v3"

cheDevfileRegistry:
deploy: true
Copy link
Contributor

Choose a reason for hiding this comment

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

Couldn't we change this to external: false, to be consistent with what was decided for the operator (and what is already in place for the Keycloak case )?
cc @l0rd

Copy link
Member Author

Choose a reason for hiding this comment

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

If this is the way how we're doing that in operator, I agree. Do you know how to do NOT in requirements.yaml condition: ? https://github.com/sparkoo/che/blob/helm-chart-deploy-registries/deploy/kubernetes/helm/che/requirements.yaml#L14 I can't find anything how to achieve that and all my experiments are failing so far :/

Copy link
Contributor

Choose a reason for hiding this comment

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

If this is the way how we're doing that in operator, I agree

it is

Do you know how to do NOT in requirements.yaml condition ?

TBH I don't know. Not a Helm expert, but what if you use an else as mentioned here: https://github.com/helm/helm/blob/master/docs/chart_template_guide/control_structures.md#ifelse

Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry, I didn't read the question correctly: if/else has nothing to do with your question it seems. So no, I don't know. Maybe using a calculated value that could be defined as the opposite of external ?

Copy link
Member Author

Choose a reason for hiding this comment

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

as far as I know, requirements.yaml is just clean yaml, no interpolation. And I believe all values there must be taken from values.yaml, which is the again just clean yaml. For keycloak we're doing check for true here https://github.com/eclipse/che/blob/master/deploy/kubernetes/helm/che/requirements.yaml#L18 global.cheDedicatedKeycloak. So we might go with deploy=true way, just for technology conventions sake here.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, it seems that you will have to do the same as for Keycloak.

I assume that CheCtl should do the same as the operator though, to maintain some sort of consistency.
@l0rd do you confirm ?

Copy link
Contributor

Choose a reason for hiding this comment

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

You mean that there will be some inconsistency amongst helm and operator in the semantic of the parameter right? Yes it doesn't seam like a big deal and we can let chectl manage it

Signed-off-by: Michal Vala <mvala@redhat.com>
Signed-off-by: Michal Vala <mvala@redhat.com>
@sparkoo
Copy link
Member Author

sparkoo commented Jul 19, 2019

chectl PR to don't send registries defaults che-incubator/chectl#228
@skabashnyuk @davidfestal @l0rd

@sparkoo
Copy link
Member Author

sparkoo commented Jul 19, 2019

All comments were fixed. Can you please re-review the changes and approve/comment the PR? Same for chectl PR here che-incubator/chectl#228
@skabashnyuk @l0rd @davidfestal @sleshchenko (anyone else?)

app: che-plugin-registry
strategy:
type: RollingUpdate
rollingParams:
Copy link
Contributor

Choose a reason for hiding this comment

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

I get unknown field "rollingParams" in io.k8s.api.extensions.v1beta1.DeploymentStrategy

It doesn't look like rollingParams is in a DeploymentStrategy (c.f. k8s api reference). That's curious. Have you tested on OpenShift?

Anyway chaging to

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

worked

Copy link
Member Author

Choose a reason for hiding this comment

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

no, I've tested on minikube. Looks like values were ignored, but I didn't get any error. Fixed

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

#

chePluginRegistry:
image: quay.io/openshiftio/che-plugin-registry
Copy link
Contributor

Choose a reason for hiding this comment

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

We are moving to the new quay.io/eclipse organisation. Please use quay.io/eclipse/che-plugin-registry:nightly here.

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed

#

cheDevfileRegistry:
image: quay.io/openshiftio/che-devfile-registry
Copy link
Contributor

Choose a reason for hiding this comment

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

We are moving to the new quay.io/eclipse organisation. Please use quay.io/eclipse/che-devfile-registry:nightly here.

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed

Signed-off-by: Michal Vala <mvala@redhat.com>
Signed-off-by: Michal Vala <mvala@redhat.com>
kind: Deployment
metadata:
labels:
app: che-devfile-registry
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, fixed

Signed-off-by: Michal Vala <mvala@redhat.com>
Signed-off-by: Michal Vala <mvala@redhat.com>
@sparkoo
Copy link
Member Author

sparkoo commented Jul 22, 2019

I see no more unfixed comments. Could you please re-review/approve/comment? @l0rd @davidfestal @benoitf

Signed-off-by: Michal Vala <mvala@redhat.com>
- containerPort: 8080
livenessProbe:
httpGet:
path: /plugins/
Copy link
Contributor

Choose a reason for hiding this comment

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

AFAIK /plugins is deprecated so should we wait for another path like v3/plugins ?

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, fixed

Copy link
Member Author

Choose a reason for hiding this comment

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

PR for plugin-registry eclipse-che/che-plugin-registry#189

Signed-off-by: Michal Vala <mvala@redhat.com>
@sleshchenko
Copy link
Member

ci-build

@davidfestal
Copy link
Contributor

@sparkoo what was the reason to do changes in commit bb0af81 ?

This introduces inconsistency with the already-merged implementation of the registry deployment on the Che operator side (https://github.com/eclipse/che-operator/pull/51/files#diff-d9445e614f0d728fd140771b0fd29c50R381)

@sparkoo
Copy link
Member Author

sparkoo commented Jul 22, 2019

@davidfestal hmm, I've followed other components pattern here #13890 (comment)

@sparkoo
Copy link
Member Author

sparkoo commented Jul 22, 2019

@davidfestal @benoitf che-devfile-registry or devfile-registry ? I like the latter more. However, operator uses the former.

@davidfestal
Copy link
Contributor

@davidfestal @benoitf che-devfile-registry or devfile-registry ? I like the latter more. However, operator uses the former.

@sparkoo @benoitf if you are OK about app=che && component=devfile-registry being the way to go, I'll create a PR on the operator repo.

However in CheCtl code, in the server stop command, I see this code:

      {
        title: 'Wait until Keycloak pod is deleted',
        enabled: (ctx: any) => !ctx.isAlreadyStopped && !ctx.isNotReadyYet && ctx.foundKeycloakDeployment,
        task: async (_ctx: any, task: any) => {
          await kh.waitUntilPodIsDeleted('app=keycloak', flags.chenamespace)
          task.title = `${task.title}...done.`
        }
      },

That doesn't seem very consistent to me. @l0rd any idea ?

1 similar comment
@davidfestal
Copy link
Contributor

@davidfestal @benoitf che-devfile-registry or devfile-registry ? I like the latter more. However, operator uses the former.

@sparkoo @benoitf if you are OK about app=che && component=devfile-registry being the way to go, I'll create a PR on the operator repo.

However in CheCtl code, in the server stop command, I see this code:

      {
        title: 'Wait until Keycloak pod is deleted',
        enabled: (ctx: any) => !ctx.isAlreadyStopped && !ctx.isNotReadyYet && ctx.foundKeycloakDeployment,
        task: async (_ctx: any, task: any) => {
          await kh.waitUntilPodIsDeleted('app=keycloak', flags.chenamespace)
          task.title = `${task.title}...done.`
        }
      },

That doesn't seem very consistent to me. @l0rd any idea ?

@benoitf
Copy link
Contributor

benoitf commented Jul 22, 2019

@davidfestal probably a missing code refactoring when selector methods were introduced
https://github.com/che-incubator/chectl/blob/3f36ffa2378df2444f9588855bdcdecdaa42c251/src/commands/server/start.ts#L326-L335

@benoitf
Copy link
Contributor

benoitf commented Jul 22, 2019

@davidfestal

@sparkoo @benoitf if you are OK about app=che && component=devfile-registry being the way to go, I'll create a PR on the operator repo.

I like it as well

BTW I was late commenting as github was kind of not working :-)

@benoitf
Copy link
Contributor

benoitf commented Jul 22, 2019

@davidfestal server:stop looks like a bug

@sparkoo
Copy link
Member Author

sparkoo commented Jul 23, 2019

stop.ts is hot candidate for refactoring. Lot duplicate code in this scale/wait pattern https://github.com/che-incubator/chectl/blob/master/src/commands/server/stop.ts#L154. This selector https://github.com/che-incubator/chectl/blob/master/src/commands/server/stop.ts#L221 also won't work with this deployment https://github.com/eclipse/che/blob/master/deploy/kubernetes/helm/che/custom-charts/che-postgres/templates/deployment.yaml#L16.
But I'd like to close this one. If we agree on app=che,component=devfile-registry, and update operator to same convention, can we merge this PR? Chectl counterpart is here che-incubator/chectl#228 and is working with this PR.

@skabashnyuk
Copy link
Contributor

@benoitf wdyt can we merge this pr? Or should we do some changes in chectl first?

@davidfestal
Copy link
Contributor

Seems to me that we should merge this and further work on chectl afterwards. There are already pending PRs on chectl that we are waiting for.

@benoitf
Copy link
Contributor

benoitf commented Jul 23, 2019

@skabashnyuk can merge here

@skabashnyuk skabashnyuk merged commit ec50704 into eclipse-che:master Jul 23, 2019
@sparkoo sparkoo deleted the helm-chart-deploy-registries branch July 23, 2019 08:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants