🐛 Fix namespace conditionality, upgrade test

[MikeSpreitzer]

Summary

This PR updates the namespace template in the Helm chart to properly handle a second helm upgrade, following an outline from @francostellari. This PR also makes the E2E test case for this executable and adds it to the set of test cases that actually run. This PR also fixes the waits and the display of Pods in that test case.

Related issue(s)

Fixes #453

[MikeSpreitzer]

This is the same wait as is done in step 6; no need to repeat it.

[MikeSpreitzer]

/cc @francostellari
/cc @pdettori

[MikeSpreitzer]

@Rupam-It
@RayyanSeliya
/cc @rxinui

[MikeSpreitzer]

@katara-Jayprakash

[francostellari]

Are you using a with/else/end statement?
I was not aware that it was supported
Something does not seem to make sense to me

[MikeSpreitzer]

Yes, that is one of the forms defined in https://pkg.go.dev/text/[email protected]#hdr-Actions .

The thing that that doc does not quite say clearly enough for my taste is that the value of an assignment is the value on the RHS of the assignment. But I do think that this is true, and is why the initial helm upgrade --install creates the namespace.

[MikeSpreitzer]

/cc @francostellari

[francostellari]

I tested these 4 configurations and they seem to work as expected:

1:

helm upgrade --install kubeflex-operator kubeflex-ks/chart/ \
--set domain=localtest.me \
--set externalPort=9443

2

kubectl create ns kubeflex-system

helm upgrade --install kubeflex-operator kubeflex-ks/chart/ \
--set domain=localtest.me \
--set externalPort=9443

3

kubectl create ns kubeflex-system

helm upgrade --install kubeflex-operator kubeflex-ks/chart/ \
--namespace kubeflex-system \
--set domain=localtest.me \
--set externalPort=9443

4

helm upgrade --install kubeflex-operator kubeflex-ks/chart/ \
--namespace kubeflex-system --create-namespace \
--set domain=localtest.me \
--set externalPort=9443

[francostellari]

however, for completeness, if an upgrade command specifies a different namespace of the previous helm command it will fail

helm upgrade --install kubeflex-operator kubeflex-ks/chart/ \
--namespace kubeflex-system --create-namespace \
--set domain=localtest.me \
--set externalPort=9443

then

helm upgrade --install kubeflex-operator kubeflex-ks/chart/ \
--set domain=localtest.me \
--set externalPort=9443

fails:

Error: Unable to continue with install: ServiceAccount "kubeflex-controller-manager" in namespace "kubeflex-system" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-namespace" must equal "default": current value is "kubeflex-system"

I'm not sure how this could be fixed at the moment and it's probably outside of this scope.

[francostellari]

/lgtm

[kubestellar-prow]

LGTM label has been added.

Details

Git tree hash: 370c9b0587a9956dcbf8f2b72e4513d5bf1269e7

[katara-Jayprakash]

however, for completeness, if an upgrade command specifies a different namespace of the previous helm command it will fail

helm upgrade --install kubeflex-operator kubeflex-ks/chart/ \
--namespace kubeflex-system --create-namespace \
--set domain=localtest.me \
--set externalPort=9443

then

helm upgrade --install kubeflex-operator kubeflex-ks/chart/ \
--set domain=localtest.me \
--set externalPort=9443

fails:

Error: Unable to continue with install: ServiceAccount "kubeflex-controller-manager" in namespace "kubeflex-system" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-namespace" must equal "default": current value is "kubeflex-system"

I'm not sure how this could be fixed at the moment and it's probably outside of this scope.

@MikeSpreitzer with these review I think we can move forward to the next steps

[MikeSpreitzer]

I think that #592 (comment) is outside the usage envelope that we intend to support.

[MikeSpreitzer]

/approve

[kubestellar-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: MikeSpreitzer

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [MikeSpreitzer]

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