- Remove `info` field from `Version` struct
- Modify `WithInfo` and `Info` methods to be deprecated
- Update version information retrieval to use base version info
- Simplify version information generation in compatibility tests
- Remove unnecessary version info passing in build and test scenarios
- Add new version fields to version.Info struct:
* EmulationMajor and EmulationMinor to track emulated version
* MinCompatibilityMajor and MinCompatibilityMinor for compatibility tracking
- Update related code to populate and use these new fields
- Improve version information documentation and OpenAPI generation
- Modify version routes and documentation to reflect new version information structure
We don't build these tests for Windows, let's remove this skip.
We should have never added that skip, we should have skipped the entire
suite on Windows.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
this is handled centrally by make test which is called by make test-integration which this script calls
only make test's implementation actually calls gotestsum, and it also handles installing if needed
- stop setting ARTIFACTS from WORKSPACE, CI handles setting ARTIFACTS and WORKSPACE isn't used anymore (bazel?)
- stop cd-ing GOPATH, CI sets the working dir already and local users won't necessarily have GOPATH
- sop clobbering PATH with hardcoded assumptions, source install-etcd.sh instead (which updates PATH)
- don't redundantly set KUBE_COVER to the default
- pass logging env inline so the command can be pasted locally
- set -x so the command is visible
- add TODO about needing a wrapper script just to call install-etcd
.spec.serviceName field is injected into pod.spec.subDomain which
requires values to be valid DNS1123 label, but statefulset validation
never validates the field, if specifired. This can cause the controller
to fail creating pods.
Signed-off-by: Maciej Szulik <soltysh@gmail.com>
This is needed to make declaratve validation clean. Past me thought
this was clever (pointer versioned, non-pointer internal) but it is just
confusing.
We plan to add more formats in upcoming releases.
This tracks which formats are introduced at a version.
Unrecognized formats remain ignored. That is,
if a format is not supported at the emulated version,
the format is not enforced. This differs from typical
field handling, where unsupported field values are
forbidden. This is pre-existing behavior and is
in compliance with JSON Schema's format handling.
Ratcheting of custom resources helps with the introduction
of new formats. When a cluster is upgraded to a version
of Kubernetes that supports a format already set (but not enforced)
in a custom resource definition, the format will start
being enforced against custom resources. Ratcheting will
tolerate unchanged values of custom resources, even
if the value is not valid according to the format.
