Return meta information about the cluster

[krisnova]

Right now the call to context.Create only returns a possible error

// Create provisions and starts a kubernetes-in-docker cluster
func (c *Context) Create(cfg *config.Config, retain bool, wait time.Duration) error {
     // ...
}

If you drill down in to the logic contained in the method you find that we eventually reach provisionControlPlane

// provisionControlPlane provisions the control plane node
// and the cluster kubeadm config
func (cc *createContext) provisionControlPlane(
	nodeName string,
) (kubeadmConfigPath string, err error) {
     // ...
}

In the provisionControlPlane method there is valuable information being lost such as the ephemeral port that the container has listening for the API server.

If using KIND to write a unit test, being able to define the port to test on is critical.

Can I please PR a feature that allows for this valuable information to be captured from a calling piece of code?

I think we can do it by adding a new return type to context.Create or caching the information at the package level and pulling from the cache.

Would like to use something like this for TGIK on Friday.

Thanks for the great project!

[BenTheElder]

Can I please PR a feature that allows for this valuable information to be captured from a calling piece of code?

Definitely! The library use-case is not the most well supported right now, but it's certainly something we want to enable. 😅

Returning a new type in context.Create SGTM.

We'll probably need to rework this a bit when something like #164 merges but we can figure that out then.

Would like to use something like this for TGIK on Friday.

Thanks for the great project!

😄
/kind feature
/priority important-soon
/assign @kris-nova
/assign

[krisnova]

Okay! I opened up #187

It doesn't break any of the method signatures just ends up adding some exported values to both the Context and the createContext

[krisnova]

Which sig is responsible for this project? I am trying to find the best slack channel in case anything else comes up.

[alejandrox1]

I believe kind is a subproject of sig-testing but it has its own channel in slack - "kind"

[BenTheElder]

Yes, this is a #sig-testing project, but there is a #kind channel now on the Kubernetes slack.

Will take a look at the PR :-)

[BenTheElder]

Also: I like the approach but we're free to break the signatures etc. for now, all of the APIs / types are "alpha" grade 🙃

Aiming to stop breaking compatibility anywhere roughly by the end of the Kubernetes 1.14 release cycle xref: kind 1.0 milestone

The config format in particular is getting overhauled before then, #147