A recent commit changed name validation from DNS Subdomain to DNS Label.
The assumption was that a subdomain-named SS could never work and the
only reasonable thing to do would be to delete it. But if there is a
finalizer, the delete is not possible because we would reject the update
because the old name (subdomain) did not pass the new validation.
This commit does not re-validate the ObjectMeta on update. Probably
every resource should follow this pattern, but mostly it's a non-issue
becauase the above change (name validation) is not something we do -
this case was excpetional.
Any StatefuleSet which took advantage of this (by having dots in the
name) can't have worked because we set `pod.spec.hostname` from it,
which is validated as a DNS label.
So while this is strictly a breaking change, it doesn't break anything
that was not already broken.
This `DeploymentSpec` struct is used internally; the ones used for
serialization do have a pointer and this text was most likely copied
from there and not corrected.
Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
- Run hack/update-codegen.sh
- Run hack/update-generated-device-plugin.sh
- Run hack/update-generated-protobuf.sh
- Run hack/update-generated-runtime.sh
- Run hack/update-generated-swagger-docs.sh
- Run hack/update-openapi-spec.sh
- Run hack/update-gofmt.sh
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
* restructure tests
restructure TestValidateStatefulSet and TestValidateStatefulSetUpdate to be an array and accept list of expected errors. in this commits, no tests were changed and expected errors are not filled yet
* add expected errors
adding expected errors and making the tests pass, without making any changes to the tests
* clean up TestValidateStatefulSet error cases
* clean up TestValidateStatefulSetUpdate cases
* validate new statefulset as part of update validation
* address PR comments
* De-share the Handler struct in core API
An upcoming PR adds a handler that only applies on one of these paths.
Having fields that don't work seems bad.
This never should have been shared. Lifecycle hooks are like a "write"
while probes are more like a "read". HTTPGet and TCPSocket don't really
make sense as lifecycle hooks (but I can't take that back). When we add
gRPC, it is EXPLICITLY a health check (defined by gRPC) not an arbitrary
RPC - so a probe makes sense but a hook does not.
In the future I can also see adding lifecycle hooks that don't make
sense as probes. E.g. 'sleep' is a common lifecycle request. The only
option is `exec`, which requires having a sleep binary in your image.
* Run update scripts
