cannot specify ControlPlane in envtest.Environment

[ixdy]

I think this issue is similar to #841.

We have some code using envtest.Environment that has used the ControlPlane field to specify arguments for the APIServer and Etcd components:

After sigs.k8s.io/testing_frameworks/integration was moved into pkg/internal/testing/integration in #714, we can no longer do this:

use of internal package sigs.k8s.io/controller-runtime/pkg/internal/testing/integration not allowed

Is there a better way to be achieving this? Or was this unintentional?

[rajathagasthya]

This just needs a release. It was fixed in #846.

cc @DirectXMan12

[ixdy]

@rajathagasthya no, this issue is different; #846 doesn't fix it.

We explicitly want to specify things like the apiserver host/port and etcd host/port.

We had been doing something like

env := &envtest.Environment {
  ControlPlane: &integration.ControlPlane{
    APIServer: &integration.APIServer{
      URL: apiserverURL,
      EtcdURL: etcdURL,
    },
    Etcd: &integration.Etcd{
      URL: etcdURL,
    },
  },
}

etc.

We can no longer do that, since integration.ControlPlane, integration.APIServer, and integration.Etcd are all in an internal package now.

[ixdy]

Or for another example, we can't do something like this anymore:

controller-runtime/pkg/internal/testing/integration/internal/integration_tests/integration_test.go

Lines 107 to 114 in 8975354

	myEtcd, myAPIServer :=
	&integration.Etcd{StartTimeout: 15 * time.Second},
	&integration.APIServer{StopTimeout: 16 * time.Second}
	controlPlane = &integration.ControlPlane{
	Etcd: myEtcd,
	APIServer: myAPIServer,
	}

[rajathagasthya]

Ah, sorry. I conflated this with the apiserver flags breakage. I don't think integration testing package should be in an internal package since many things there are customizable in an envtest environment. There are multiple breakages to envtest when testing framework was brought into controller-runtime and put into internal package.

[ixdy]

cc @hoegaarden

Was this intentionally put under pkg/internal in #749?

[DirectXMan12]

agreed here -- those types shouldn't be internal. Sorry about that. I think all the shuffling around got things lost in translation.

[DirectXMan12]

FWIW, I think the intention was that some of the internal helpers were supposed to be in internal, while the public types stayed exposed externally. The goal was to eventually unify our Environment with th e testing-frameworks config to avoid duplication, but we're not there yet, so re-exposing those types seems like a good idea.

[DirectXMan12]

/good-first-issue

should be an easy fix -- just re-export these types.

[k8s-ci-robot]

@DirectXMan12:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

/good-first-issue

should be an easy fix -- just re-export these types.

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.

[DirectXMan12]

/priority critical-urgent
/kind bug