Streamline Gslb Status

[ytsarev]

Currently we have Gslb Status content as shown in example below:

  status:
    healthyRecords:
      app3.cloud.example.com:
      - 172.17.0.4
      - 172.17.0.5
      - 172.17.0.6
    managedHosts:
    - app1.cloud.example.com
    - app2.cloud.example.com
    - app3.cloud.example.com
    serviceHealth:
      app1.cloud.example.com: NotFound
      app2.cloud.example.com: Unhealthy
      app3.cloud.example.com: Healthy

It is easily visible that we have duplication between the managedHosts and serviceHealth
It happened historically during development of the project. Initially serviceHealth looked like

    serviceHealth:
      unhealthyServiceName: NotFound
      backend: Unhealthy
      frontend: Healthy

so basically referenced serviceName that is referenced in associated gslb ingress.
Later on it was changed to ingressHost:Status as it became apparent that it is practical to have them in a single data structure.

So some questions to discuss:

1. Do we need serviceName exposed somewhere in Status ?
2. If yes - should we extend serviceHealth or place it somewhere else ?
3. Easiest scenario - we just remove managedHosts

[kuritka]

Hi true is that managedHosts looks a little redundant.

Perhaps this ?

  status:
    serviceHealth:
      app1.cloud.example.com: NotFound
      app2.cloud.example.com: Unhealthy
      app3.cloud.example.com: Healthy

    healthyRecords:
      app3.cloud.example.com:
      - 172.17.0.4
      - 172.17.0.5
      - 172.17.0.6

[ytsarev]

Yeah, so it is 3)

[ytsarev]

will implement it removal. We can always amend more data whenever we need anything else to be exposed in Status

[ytsarev]

Another issues with the Status. Whenever workload on the specific cluster is down it does not populate HealthyRecords with external cluster records even if it is alive. Meanwhile in reality it populates response with external cluster entries.