Initial loadbalancer implementation #5
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The default API timeout was ignored. It is now also set to 15s instead of 5s, as the latter proofed too short for some loadbalancer calls.
This is a first commit that implements the necessary logic and adds basic unit tests. There are some missing features and there are no integration tests yet.
href
changed the title
alakae
reviewed
Oct 11, 2023
This reverts commit 10281fe.
href
force-pushed
the
denis/lbs
branch
2 times, most recently
from
b1b7dee to
481bceb
Compare
Some commands seem to time out occiasionally, even though nothing is wrong. Waiting a little longer seems okay, but this should be the limit. If the timeout fails, the operation will be retried, which might be preferrable.
This allows for cleaner instantiation via cloud.go
Those need to be reusable for integration tests.
The kubernetes project states the following: > Kubernetes reserves all labels and annotations in > the kubernetes.io and k8s.io namespaces. Therefore, using a namespace "owned" by cloudscale is the most logical step. The following format is used from now on: k8s.cloudscale.ch/<type>-<key> For example: k8s.cloudscale.ch/loadbalancer-uuid
All options should now be configurable via annotations and cause the right actions to be taken. In most cases, the change is rendered immediately.
With this change, a forward-compatible addition has been added that future listeners without associated pools will also be managed by the CCM, and not be left lingering.
Loadbalancers should usually be fully built after 120s, but it can be a bit slower and that leaves too little time for additional actions taken by the CCM. Since it's not the job of the CCM integration tests to enforce speedy loadbalancer creation, some slack can be added.
This ensures that the log does not include a warning/error that would otherwise be invisible.
Otherwise a single load balancer creation process (which blocks the worker for quite a while), prevents other services from being updated. Of course, there's still a limit, but the default of a single worker is too low.
The error can still happen, as there is currently no way of knowing if a delete has been applied already. To properly solve this, a method to check if a delete has been successful is needed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See internal ticket for details.