This ensures that the same binary is used for kubetest2-kops commands as well as the kops commands invoked directly in the scenario script.
Periodic jobs will create a temp file that will be used to save the kops binary from the provided version marker.
non-periodic jobs (local invocation) will use the bazel build binary, preserving original behavior but using this same binary for kops commands rather than relying on PATH.
The api design for using existing instance profiles must have changed during its PR and I never removed the old field from the integration test.
grep shows that this field doesn't exist anywhere else in the codebase.
This will unblock the remaining periodic e2e jobs that havent been migrated yet.
They run a test with the kops version from "latest-ci.txt" as published by the "postsubmit-push-to-staging" postsubmit job,
and if the tests succeed then they get published to "latest-ci-updown-green.txt" which is what all of the other periodic jobs rely on.
example job that uses this functionality: 37b80c5e3b/config/jobs/kubernetes/kops/kops-pipeline.yaml (L46-L48)
This updates the upgrade scenario script to support building kops when ran locally, or using the version markers when ran in a periodic prow job.
hoping to fix the upgrade tests here: https://testgrid.k8s.io/kops-kubetest2#kops-aws-upgrade
When choosing a default value for the Cluster spec's
"cloudConfig.manageStorageClasses" field, first check whether a user
specified a concrete value for the related OpenStack
"blockStorage.createStorageClass" field. If so, use that value as the
effective default value for the former field as well, so as to avoid
an unnecessary conflict between the field values on the second
validation pass.
Previously we would incorrectly append create cluster arguments if they had already been specified and used --foo=bar notation.
This resulted in arguments being specified multiple times causing undesired behavior.
We now check for both `--foo bar` and `--foo=bar` when attempting to add a `--foo` argument.
As with the Cluster-level "spec.updatePolicy" field, add a similar
field at the InstanceGroup level, allowing overriding of the
cluster-level choice in each InstanceGroup.
Introduce a new value for the field ("automatic") as equivalent to the
default value applied when the field is absent. Honoring this new
value allows disabling automatic updates at the cluster level, but
then enabling them again for particular InstanceGroups. Without such a
positive affirmation, it's not possible to override a cluster-level
"external" policy at the InstanceGroup level, as there's no way to
specify positively that you want to recover the default
value. Instead, expressing the explicit "automatic" value is clear and
unambiguous.
Peter Rifel