-
Notifications
You must be signed in to change notification settings - Fork 0
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
Initial provider implementation #2
Conversation
7b58254
to
f7ef913
Compare
46e270b
to
266f44e
Compare
CSR checks for a `NodeInternalDNS` address in the Machine object that matches the future Node object name.
Also compacts the rendered userData json.
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.
Didn't fully check, but it feels like the flavour/flavor spelling isn't 100% identical across the code base, error messages and comments.
Overall looks good to me, the one thing that needs to be fixed is the flipped CPU/memory extraction from the cloudscale flavor string when annotating the machineset (cf. inline comments).
Note that I didn't review all the tests in detail.
Co-authored-by: Simon Gerber <gesimu@gmail.com>
This PR contains the initial implementation of the provider for Cloudscale.
The provider has been observed to work until the
Provisioned
state on a local non-OCP test cluster, and to theRunning
state with node linking on our internal OCP lab, without any manual intervention. The steps for this are in the readme underTesting on a...
. The CSRs for the new nodes are approved automatically, and a deployment for the upstream node-linker can be created withhack/deploy-nodelink-controller.sh
.The critical code is in
pkg/machine/actuator.go
.controllers/machineset_controller.go
adds some annotations to theMachineSet
to tell autoscaler vCPUs and memory of a new node.Checklist
bug
,enhancement
,documentation
,change
,breaking
,dependency
as they show up in the changelog