Hi David, On 18/03/2020 18:21, David Spitzer-Dulagan wrote: > > Hi, > > If this isn't the right place please let me know - after reading the > "contributing" page that was linked in the readme of > kubernetes-ingress I thought that this mailing list might be my best > bet to ask for your input. > Thanks for you interest in the project.
This ML is the right place to contribute to the HAProxy software, but for the ingress controller better do this by creating an issue in the github project. It isn't your fault anyway, we have updated the contribute/discussion sections of the README in order to put clear information. > I wanted to know if the following feature would be something you'd be > interested in seeing in the official kubernetes-ingress controller: > The ability to add an annotation to a pod that would translate into a > weight in the backend wherever that pod is used. > We'd be interested to know more about the use case. In a standard use case, pods are ephemeral and they are not expected to carry specific information. Thus they can be easily replaceable, scalable, etc So typical questions: - What kind of pods are these? static pods or created via Service ? - How they are configured (annotation part in this case)? So don't hesitate to give us more context about this in the github issue. > Our company currently has the need for setting weights for specific > pods and there is no way that I could find to achieve that with the > current kubernetes-ingress controller. > > The implementation would be as follows: > > * Cache all Pod objects and subscribe to changes on all namespaces > similar to the other observed k8s objects in the controller > * Extend EndpointIP in types.go to include the targetRef property of > the k8s object > * handleEndpointIP in controller.go would be extended to look up the > pod from the cache via the targetRef property and set the weight > if found > * Changes to the weight in the Pod would trigger a reload as well > > I've started working on a patch for kubernetes-ingress to implement > that. I'd love your thoughts on this. > > David > > The general idea makes sense, here are some notes: - Caching pods objects, tracking them and syncing the corresponding configuration is an important amount of work which for now seems to be only useful for an edge case. That's why we would probably prefer having CLI arg to activate this. - No need for reload since we can set server weight via the Runtime API (for example we do this already to change a server address via c.NativeAPI.Runtime.SetServerAddr) My coworkers will probable have other thoughts to add once the github issue is created. -- Moemen MHEDHBI
