bookingcom / shipper

Kubernetes native multi-cluster canary or blue-green rollouts using Helm
Apache License 2.0
734 stars 39 forks source link

Surface CapacityTarget issues in the release #287

Closed juliogreff closed 4 years ago

juliogreff commented 4 years ago

This looks like it doesn't change anything in the Release, but that's mostly because the Release was just reading the CapacityTarget conditions anyway :)

Before this, the capacity controller would only put a list of unready clusters in the CapacityTarget's Ready condition when it would set it to False. This requires users to go digging into each cluster condition, and most likely they would only be directed to SadPods, where they could finally get some useful information.

Now, that information is summarized in a very brief format, in the hopes that users will have to do less jumping around when investigating why their CapacityTarget is not progressing.

For instance, if the CapacityTarget is stuck because one container can't pull its image, we'll now have the following in the CapacityTarget's .stauts.conditions:

[
  {
    "lastTransitionTime": "2020-02-12T13:16:44Z",
    "status": "True",
    "type": "Operational"
  },
  {
    "lastTransitionTime": "2020-02-12T13:16:44Z",
    "message": "docker-desktop: PodsNotReady 3/3: 3x\"test-nginx\" containers with [ImagePullBackOff]",
    "reason": "ClustersNotReady",
    "status": "False",
    "type": "Ready"
  }
]

As a bonus, this is also shown on a kubectl get ct:

% kubectl get ct  snowflake-db84be2b-0
NAME                   OPERATIONAL   READY   REASON                                                                                AGE
snowflake-db84be2b-0   True          False   docker-desktop: PodsNotReady 3/3: 3x"test-nginx" containers with [ImagePullBackOff]   8d

This addresses the CT part of both #139 and #79.