Refactor tracker to an abstract implementation #850
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
Tracker is used to link kubernetes resources and haproxy entities each other, allowing to list, remove and rebuild all objects related with a configuration change. This is the base of the partial parsing implementation. The codebase used in v0.11 (starting implementation) up to v0.13 is a lot bigger than necessary, coupled with k8s and haproxy types , and also tricky to extend and test. This update changes the code base to an abstract implementation that can be expanded without the need to write more code, but instead just declaring a new type to every new k8s or haproxy type that need to be tracked. Both old and new code base are compatible, they only change in the interface declaration, and the new one doesn't have a special behavior when the target doesn't exist - being missing or not, a resource creation or update will trigger the list+remove+recreate in the same way.
Resource tracking uses arrays of resource namespaces/names as input parameter. The resource array to string array conversion and classification is being moved to cache, which already need to iterate all the resource types. This simplifies the partial ingress converter and also simplifies the future partial gateway implementation.
The old tracking component had a limited number of Kubernetes resources and haproxy types that could be combined, leading to a number of resource types using hostname as an anchor. New implementation allows any<->any link, and this update starts some sanitization in the ingress converter.
Kubernetes Services and Endpoints share the same resource name and behavior from the controller point of view - no matter who changed, controller will behaves in the same way. Since the first tracking version Services and Endpoints are managed in the same scope. This update creates a new scope to the Endpoints resource. This fixes event logging and also allows to track Services and Endpoints individually.
Hostname and TCPService from the HAProxy types were being tracked together due to the missing of distinct tracking types in the old implementation. This update adds TCPService as a new resource type and decouple the implementations.
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.
Tracker is used to link kubernetes resources and haproxy entities each other, allowing to list, remove and rebuild all objects related with a configuration change. This is the base of the partial parsing implementation.
The codebase used in v0.11 (starting implementation) up to v0.13 is a lot bigger than necessary, coupled with k8s and haproxy types , and also tricky to extend and test. This update changes the code base to an abstract implementation that can be expanded without the need to write more code, but instead just declaring a new type to every new k8s or haproxy type that need to be tracked.
Both old and new code base are compatible, they only change in the interface declaration, and the new one doesn't have a special behavior when the target doesn't exist - being missing or not, a resource creation or update will trigger the list+remove+recreate in the same way.
Backlog: