-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Remove selfSignedCertSecretName property #15878
Conversation
✅ E2E Happy path tests succeed 🎉 See Details
Tested with Eclipse Che Multiuser User on K8S (minikube v1.1.1) |
E2E tests of Eclipse Che Multiuser on OCP has been successful:
|
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.
Good simplification! 👍
Can one of the admins verify this patch? |
Rebased |
✅ E2E Happy path tests succeed 🎉 See Details
Tested with Eclipse Che Multiuser User on K8S (minikube v1.1.1) |
E2E tests of Eclipse Che Multiuser on OCP has failed:
|
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.
Still LGTM after my commit ;)
❌ E2E Happy path tests failed ❗ See Details
Tested with Eclipse Che Multiuser User on K8S (minikube v1.1.1) ℹ️ |
E2E tests of Eclipse Che Multiuser on OCP has failed:
|
ci-build |
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 think the change on the condition for propagating the TLS secret is not correct.
optional: false | ||
{{- end }} | ||
|
||
# If workspaces are created in a separate precreated namespace | ||
# then configure Che Server to propagate TLS secret to workspaces' namespaces | ||
{{- if not (contains "<" .Values.global.cheWorkspacesNamespace) }} | ||
{{- if contains "<" .Values.global.cheWorkspacesNamespace }} |
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.
So originally, before we had placeholders in namespace names, this test was merely "if the namespace is different than the default one". With the introduction of placeholders, we changed the condition to "if this is a static, precreated, namespace". Reverting that condition as you suggest, would actually mean "if this is either a precreated namespace using a placeholder (e.g. <username>-che
) or a namespace we create (e.g. <workspaceid>-che
)".
So I don't think this change is actually valid. At the same time I agree the test is insufficient :) We need to capture the "precreatedness" of the namespaces here and I am afraid we cannot capture that by merely detecting the placeholders in the name.
Maybe just actually give up and introduce global.namespacePrecreated
?
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 wrote a lot of words and thought about the behavior we need here, but then just removed everything because I got to a conclusion that Che Server must be configured with TLS certs to propagate always if it's different than Che Server one...
We introduce placeholders and some conditions in helm chart and they are valid for ServiceAccounts, Roles, and RoleBindings... But what is the reason not to propagate TLS secret for WorkspaceIngresses?... At this stage, I believe that they must be propagated always if workspaces are not deployed in the same namespace as Che is because only in that case workspaces are not able to reuse Che Server's one...
Hope I described my thought quite clearly. Let me fix condition as I described and then we'll continue discussing it
I've just tested the latest changes and everything worked as supposed to. |
✅ E2E Happy path tests succeed 🎉 See Details
Tested with Eclipse Che Multiuser User on K8S (minikube v1.1.1) |
Signed-off-by: Mykola Morhun <[email protected]>
Signed-off-by: Sergii Leshchenko <[email protected]>
73bcaf8
to
378c28b
Compare
✅ E2E Happy path tests succeed 🎉 See Details
Tested with Eclipse Che Multiuser User on K8S (minikube v1.1.1) |
E2E tests of Eclipse Che Multiuser on OCP has failed:
|
Selenium tests execution on Eclipse Che Multiuser on OCP (https://ci.codenvycorp.com/job/che-pullrequests-test-ocp/3558//Selenium_20tests_20report/) doesn't show any regression against this Pull request. |
@mmorhun |
@tolusha no, we cannot, because this should be merged together with che-incubator/chectl#476, which is better to merge after the upcoming release. |
[ci-test] |
Signed-off-by: Mykola Morhun [email protected]
What does this PR do?
Reduces number of tls secrets in Che installation process.
Actually we may use the same certificate, but treat it differently depending on
self-signed
flag.What issues does this PR fix or reference?
#15810
Should be merged together with che-incubator/chectl#476