Closed SpComb closed 5 years ago
Note that "retry" here covers the entire "GET" + "PUT" pair... the conventional approach for these kinds of modify operations would look something like:
kube.api('extensions/v1beta1').resources('Deployment', namespace: 'kube-system').modify('kube-dns') do |resource|
resource.spec.replicas = ...
...
end
Performing a GET
+ yield
to modify + PUT
.
The current kube_session.resource(...).update
is a bit odd, because it does a GET
+ merge + PUT
using the partial resource data given... it could be rewritten to just use PATCH
instead to avoid the need for retries, if the changes do not depend on the current state of the resource?
it could be rewritten to just use PATCH instead to avoid the need for retries, if the changes do not depend on the current state of the resource?
Patch acted a bit weird on some cases.
I think we can close this. There's now retry baked in to phases and addons, plus there's fixes in k8s-client too
Other kube operators might be modifying the resources at any time, causing our
GET
=>PUT
operations to fail with conflicts... that is normal and to be expected, and the modification should be retried. Alternatively, just re-run the entirepharos-cluster up
, but that's pretty heavyweight...