Closed kingdonb closed 3 years ago
There was still a controller change that was needed to correct:
Error: Unknown Error (503): {"detail":"(scale): ('failed to scale Deployment \"example-php-web\" in Namespace \"example-php\": 400 Bad Request Scale in version \"v1\" cannot be handled as a Scale: no kind \"Scale\" is registered for version \"apps/v1\" in scheme \"k8s.io/kubernetes/pkg/api/legacyscheme/scheme.go:30\"', 'Deployment', 'example-php-web', 'example-php')"}
This fixed it (bb05432)
I think this is now good to merge and re-publish for next Workflow release! Extensive testing shows this actually scales (not just pretend scales or exits zero without effect), so I made some notes in the commit messages about why it works.
I finally wound up using this strategy from a bash shell exec'ed inside of my controller to be able to see what I was doing:
https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#without-using-a-proxy
eg. curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/apis/apps/v1/namespaces/example-php/deployments/exmple-php-web/scale
showed that even though our request is in apps/v1
HTTP group, the body is expected to have autoscaling/v1
for the apiVersion
:
{
"kind": "Scale",
"apiVersion": "autoscaling/v1",
"metadata": {
"name": "example-php-web",
"namespace": "example-php",
"selfLink": "/apis/apps/v1/namespaces/example-php/deployments/example-php-web/scale",
"uid": "f3680a2e-85c4-49e9-8d14-0db9fbaa66b1",
"resourceVersion": "9886",
"creationTimestamp": "2020-10-04T20:16:19Z"
},
"spec": {
"replicas": 1
},
"status": {
"replicas": 1,
"selector": "app=example-php,heritage=deis,type=web"
}
So that's a major mystery solved, and I almost feel like I know enough Python now to make me dangerous!
Very nice find and fix @kingdonb! I have added the hacktoberfest-accepted
label so do check if the PR is approved in the Hacktoberfest 2020 challenge.
~Affects charts only~. Fixes this error:
Quite unhelpfully, the error messaging says "cannot update" here when it evidently means to warn you that it "cannot PATCH" in the HTTP verb parlance. I wonder if this "cannot update" language is our string, or if it came from upstream libraries?