Support CAPI in-place version updates#1332
Conversation
apedriza
changed the title
apedriza
force-pushed
the
inplace-upgrades
branch
16 times, most recently
from
79562f1 to
69fc056
Compare
apedriza
force-pushed
the
inplace-upgrades
branch
2 times, most recently
from
fbd9464 to
fdcbd9c
Compare
apedriza
force-pushed
the
inplace-upgrades
branch
2 times, most recently
from
ddab6e4 to
5719058
Compare
apedriza
changed the title
| // TODO: use DownloadURL from K0sControllerConfig/K0sWorkerConfig when available | ||
| amd64DownloadURL := `https://get.k0sproject.io/` + desiredMachine.Spec.Version + `/k0s-` + desiredMachine.Spec.Version + `-amd64` | ||
| arm64DownloadURL := `https://get.k0sproject.io/` + desiredMachine.Spec.Version + `/k0s-` + desiredMachine.Spec.Version + `-arm64` | ||
| armDownloadURL := `https://get.k0sproject.io/` + desiredMachine.Spec.Version + `/k0s-` + desiredMachine.Spec.Version + `-arm` |
There was a problem hiding this comment.
we should add and respect downloadURL as we do for control planes now
There was a problem hiding this comment.
added the downloadurl from the config associated to the machine
| } | ||
| } | ||
|
|
||
| func DoCanUpdateMachine(ctx context.Context, req *runtimehooksv1.CanUpdateMachineRequest, resp *runtimehooksv1.CanUpdateMachineResponse) { |
There was a problem hiding this comment.
should we somehow check that workers can be updated only after controllers?
There was a problem hiding this comment.
mm I guess that is the general assumption for cluster updates in k8s
| "` + target + `": { | ||
| "discovery": { | ||
| "static": { | ||
| "nodes": ["` + desiredMachine.Name + `"] |
There was a problem hiding this comment.
I don't really like the idea that we're creating a Plan per machine, but looks like this is how that Extension works. In future we might think and detect a higher object (like Cluster) changes and update the whole cluster at once
There was a problem hiding this comment.
agree, we should try to combine k0s plan declaring multiple nodes with this upgrade extension. We can think about it in the future but I dont know how from capi controllers POV this case can be done..mm
internal/controller/controlplane/k0s_controlplane_controller.go
Outdated
Show resolved
Hide resolved
e2e/config/aws.yaml
Outdated
| type: RuntimeExtensionProvider | ||
| versions: | ||
| - name: v1.10.99 # next; use manifest from source files | ||
| value: ../../extension/config/default |
There was a problem hiding this comment.
Ive removed aws configuration, we have docker infra atm
|
|
||
| func isCAPIVersionSuitableForInplaceUpdate(ctx context.Context, c client.Client) (bool, error) { | ||
| var capiProvider clusterctlv1.Provider | ||
| err := c.Get(ctx, client.ObjectKey{Name: clusterctlconfig.ClusterAPIProviderName, Namespace: "capi-system"}, &capiProvider) |
There was a problem hiding this comment.
We need to check, there is a chance that k0rdent installs everything including CAPI providers and objects in kcm-system namespace, not standard capi-system
There was a problem hiding this comment.
changed logic to list core providers in the cluster instead retrieve it from capi-system
apedriza
force-pushed
the
inplace-upgrades
branch
from
5719058 to
56e8c9a
Compare
Signed-off-by: apedriza <adripedriza@gmail.com>
Signed-off-by: apedriza <adripedriza@gmail.com>
apedriza
force-pushed
the
inplace-upgrades
branch
from
56e8c9a to
1eed10c
Compare
2 participants
fix #1307