Support GCE PD testing

[kubernetes-sigs]

Support GCE PD testing

[mattcary]

Thanks Ben, I figured out in parallel exactly your point about the e2e test option vs the cluster config. Here's my stab at the right PR: kubernetes/kubernetes#111481.

Does that look like the right way to do things to you?

[BenTheElder]

Just a point of clarity for others reading this discussion: ENABLE_STORAGE_GCE_PD_DRIVER is only an option for the e2e tests, not cluster configuration.

For the e2e tests, they shouldn't be consuming many environment variables, we usually implement options in the e2e tests as flags to that binary upstream in Kubernetes, and then kubetest2 does allow passing through additional ginkgo flags. The upstream e2e framework has a lot of flags, and few environment variables.

I'm not sure why we used an environment variable for this e2e test option, but we can special case handling it in the ginkgo e2e tester or else revisit that decision upstream in Kubernetes.

---

For cluster environment based configuration ...

The "configure e2e clusters with inscrutably layered environment variables shell-expansion-interpolated-into-config" pattern we used previously with kubetest etc. is going to bite us badly when we have to move off cluster-up.sh to some other tool at some point. Possibly as GCE is removed from tree, so I'm not sure we want to go back on that now.

cluster-up.sh is barely maintained (I am one of the very few volunteer approvers), otherwise pretty much only begrudgingly patched on the go when PRing Kubernetes because it is used in presubmit today in-tree with in-tree GCE so you have to fix it before your PR merges. if it gets removed along with the in tree provider (I know people are pushing for it), those scripts are a nightmare and ~totally unstaffed. I would guess we will move to kops or cluster-API and those cluster-up.sh environment variables are going to be very tedious to interpret / track down / understand and port to some other form of config, whereas the kubetest2-gce flags we have today should mostly be a lot more easily ported.

---

Thank you for working on fixing this!

[BenTheElder]

That looks right to me! thanks 👍

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mattcary]

This was fixed by k/k/111481.