Closed MarcelMue closed 6 years ago
I would appreciate some feedback if I am going in the right direction here. My thoughts were that the endpoint is reconciled but doesn't have any properties, so the desired state is always generated by querying the k8s api for annotations. Is this a decent direction or are there better ideas?
The current state is therefor always just a list of all endpoints.
Let me try to get this straight.
GetCurrentState
. Any idea of how to improve this design wise in operatorkit is welcome, but this is a different story.GetCurrentState
has to decide if the current pod is of interest or not. This decision is made by inspecting its annotations. The annotation should point to a service/endpoint. The current state is then a pair of endpoint and IP. I would create a spec.go
and put some structure reflecting this state pair. This is then the state we dispatch and work on. WDYT?
This makes sense to me. I will try to implement it the way you described and hopefully everything will clear up from there. I hope to have some decent looking attempt tomorrow and then @calvix and I can look how the progress is going.
Thanks for your input ❤️
Ok cool. Maybe lets get the filtering in this PR done and go ahead with other steps in separate PRs.
My goal here is to split the endpoint similarly to our other operators and implement the CurrentState and some tests.