Upgrade CAPO version to v0.12.2#152
Upgrade CAPO version to v0.12.2#152Dmitriy Rabotyagov (noonedeadpunk) wants to merge 10 commits into
Conversation
|
recheck |
|
|
|
So, in this CAPO version |
|
Yeah, ok, it's not capi version, but missing ORC which was split into separate project. doh. |
|
Dmitriy Rabotyagov (@noonedeadpunk) could we get away with bumping to latest 0.11.x which might have the fix? |
|
Mohammed Naser (@mnaser) this is the first I checked and unfortunately it's not there as of today. Probably could attempt backporting to 0.11, but I kinda not confident in stable policy in there :( |
|
Ah, the team is pretty flexible at backporting things especially if it's a crash. One moment. |
|
Oops, just realized I never added a fix, here it is: kubernetes-sigs/cluster-api-provider-openstack#2477 I'm also looking at what it would take to install ORC, as I'd guess sooner or later this needs to be done anyway. |
|
I pushed kubernetes-sigs/cluster-api-provider-openstack#2507 I'll ping folks for a review and hopefully we can get that landed, would still need a release :( |
I think the best way to go about this is to go over the install instructions on a normal Kind cluster and then see how to "replicate" this into the playbook. |
|
fwiw, regarding rocky failures in molecule here: we've spotted same failures caused by apparmor blocking PAM inside of the docker with EL, when host is running Ubuntu 24.04. And become/or SSH. With SSH workaround was to comment out UsePAM, but for become - we just dropped become from the role.... |
|
Ok, so I was able to spawn a healthy cluster with this PR in: Though it adds new required variable: Mohammed Naser (@mnaser) With that I was wondering - how CHANGELOG.md is managed? Manually or automated from some fragments? |
4cb46b0 to
489481c
Compare
|
The upgrade job seems validly broken :( https://zuul.atmosphere.vexxhost.dev/build/5d0e70976ea648d9ab3dd9d548995378 |
489481c to
084a728
Compare
|
Regarding |
084a728 to
3e1e1db
Compare
|
Dmitriy Rabotyagov (@noonedeadpunk) I have fixed the CI issue |
|
Would be really nice to get some reviews/progress on this one... |
|
Any updates? |
In CAPO version v0.11.2 there is a severe bug allowing to accomplish Denial of Service by any tenant. Manual removal of VM by tenant which is managed by CAPO results in a pod crash in a loop. This has been fixed with [1] and is part of the 0.12.2 release. Signed-off-by: Dmitriy Rabotyagov <noonedeadpunk@gmail.com>
More modern CAPO also requires corresponding CAPI , otherwise VM creation fails with: `no matches for kind \"Image\" in version \"openstack.k-orc.cloud/v1alpha1\` Signed-off-by: Dmitriy Rabotyagov <noonedeadpunk@gmail.com>
CAPO 0.12.0 has removed ORC [1] and now it needs to be installed additionally. [1] https://github.com/kubernetes-sigs/cluster-api-provider-openstack/releases/tag/v0.12.0 Signed-off-by: Dmitriy Rabotyagov <noonedeadpunk@gmail.com>
Signed-off-by: Dmitriy Rabotyagov <noonedeadpunk@gmail.com>
Signed-off-by: Dmitriy Rabotyagov <noonedeadpunk@gmail.com>
Signed-off-by: Dmitriy Rabotyagov <noonedeadpunk@gmail.com>
Signed-off-by: Dmitriy Rabotyagov <noonedeadpunk@gmail.com>
* feat: allow set capo instance creation timeoput Signed-off-by: Tadas Sutkaitis <tadasas@gmail.com> * fix: license and rename variable Signed-off-by: Tadas Sutkaitis <tadasas@gmail.com> * fix: patch using native kubernetes module Signed-off-by: Tadas Sutkaitis <tadas.sutkaitis@vexxhost.com> --------- Signed-off-by: Tadas Sutkaitis <tadasas@gmail.com> Signed-off-by: Tadas Sutkaitis <tadas.sutkaitis@vexxhost.com> Signed-off-by: Dmitriy Rabotyagov <noonedeadpunk@gmail.com>
Signed-off-by: Dong Ma <dong.ma@vexxhost.com> Signed-off-by: Dmitriy Rabotyagov <noonedeadpunk@gmail.com>
dddf49f to
49b81cd
Compare
|
omfg... Adding DCO seemed to pull in quite some unrelated things with rebase... I have no idea how to resolve that in github tbh at this point... |
|
recheck - Error: etcdserver: request timed out |
|
recheck |
|
In favor of #165 due to DCO mess-up |
In CAPO version v0.11.2 there is a severe bug allowing to accomplish
Denial of Service by any tenant.
Manual removal of VM by tenant which is managed by CAPO results
in a pod crash in a loop. This has been fixed with [1] and is part
of the 0.12.2 release.
[1] kubernetes-sigs/cluster-api-provider-openstack#2477