First of all, agree we should provide hooks/events. See #2804 and #3692.

By "client", do you mean a client of the Kubernetes API, or a client of the service provided by the pods created by the replication controller -- that is, something connecting directly to the pods?

In most cases, we recommend that application clients connect through services rather than directly to the underlying pod IPs.

If Stratos itself needs to track the changes in pod IPs in a group, the Endpoints API provides that for groups for which you've created services. Our endpoint controller watches the services' label selectors and keeps the Endpoints lists up to date.

Hi @bgrant0607,

Thanks for your quick response! I went through #2804 and #3692, yes they are much similar to this requirement. By "client" what I meant is a client of the Kubernetes API, in this use-case client would be Stratos Cloud Controller.

The exact requirement we have here is to avoid overlapping of pod healing functionality in Stratos and Kubernetes. Stratos Autoscaler component has this functionality which would work on top of any Infrastructure as a Service (IaaS) platform. When using Kubernetes, we would like to let Kubernetes handle it as it would be much efficient to do it in Kubernetes layer.

If Kubernetes can generate an event or invoke a callback (I think an event would be much appropriate) with the details of the healed Pod and newly created Pod ID, Stratos could update its topology data structure accordingly.

I understand that Kubernetes already has an initiative to implement events and hooks in Replication Controller. If there is any opportunity we would like to contribute to this area.

Thanks

Let's move the discussion to #2804. We're not planning to do any work on that in the near future, so if you'd like that functionality, contributions would be welcome.