-
Notifications
You must be signed in to change notification settings - Fork 42
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
✨ CAPI 1.5 support #674
✨ CAPI 1.5 support #674
Conversation
Current status is that while things compile just fine, creating a cluster results in nothing happening. The reconciler never seems to submit the API requests to create a device on Equinix Metal. Attempting to debug this with metal go's debug options results in a SIGSEGV nil pointer error. |
/hold |
@displague What would your thoughts be about removing the support for older packet-ccm cloud provider entirely with this PR and only supporting equinixmetal. The method of introspection we used to figure out which cloud provider folks had installed:
|
While testing the new cluster API 1.5 changes in kubernetes-sigs/cluster-api-provider-packet#674 We discovered the API was returning down,down for the bgpsessionstatus after enabling BGP on a device. This didn't match any of the values in the enum and would return an error. @ctreatma recommends we remove this enum and go back to just a string. --------- Signed-off-by: Chris Privitere <23177737+cprivitere@users.noreply.github.com> Co-authored-by: Charles Treatman <ctreatman@equinix.com>
/unhold |
Signed-off-by: Chris Privitere <23177737+cprivitere@users.noreply.github.com>
/hold issues with e2e tests still |
That's the only qualifier that I think we need to consider. If we were to remove support for that, I would recommend doing it in a separate PR. CAPI 1.5 upgrade PRs tend to be lighter. Removing packet-ccm support would make review harder. opened #681 for that concern |
After looking over the changes, I'm fine with including #681 in this PR. The changes are almost entirely line removal. |
a7ce993
to
2d761fe
Compare
- remove support for packet-ccm - reduce tag length (capp instead of cluster-api-provider-packet) - use quay.io repo by default - fix lint errors - bump to capi 1.5.4 - upgrade metal-go to v0.29.0 - bump go version of Dockerfile to 1.20.11 - fix return types for new CR version - add new logging calls more like upstream has - update rbac for packet-controller - better logging of unimplemented webhooks - add new clusterproxy methods to wrappedclusterproxy in e2e testing - bump e2e config capi versions - Update e2e yaml files to only test v1beta1 - revert e2e ci config to standard version numbers - remove e2e clusterctl upgrade test as we dropped v1alpha3 support Signed-off-by: Chris Privitere <23177737+cprivitere@users.noreply.github.com>
/unhold |
machineUIDTag = "cluster-api-provider-packet:machine-uid" | ||
clusterIDTag = "cluster-api-provider-packet:cluster-id" | ||
namespaceTag = "cluster-api-provider-packet:namespace" | ||
machineUIDTag = "capp:machine-uid" |
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.
This change is a breaking change that will need to be called out in release notes with upgrade steps (along with the ramifications).
Presumably, changing the tags that are used in determining what to manage will cause the service to disown existing resources (without cleanup) and provision new resources. Is this for EIPs and servers? Control plane nodes too/
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 recognize that this was needed to fit more restrictive tag lengths in EM API resources.
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.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cprivitere, displague The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What this PR does / why we need it:
This PR is for upgrading CAPP to 1.5.X CAPI support.
This shall include dependency bumps as well as any new feature support we want/need to add.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #611