Jakob Schrettenbrunner

^ That was me. The bot took a while, so I thought I was missing permissions and deleted the original message.

We've built a small custom controller that interfaces with Infoblox which is available [here](https://github.com/telekom/das-schiff/tree/ipam/ipam). I've also started working on a proposal for a proper ipam integration contract that different providers...

> Sorry for all thsoe questions but I'm really interested in your approach. Our current approach is similar to the spectrocloud one, it just directly talks to Infoblox instead of...

> [this spectrocloud implementation I refered to earlier](https://github.com/spectrocloud/cluster-api-provider-vsphere-static-ip) is going to be merged with upstream CAPV No, it's not. They were referring to spectrocloud/cluster-api-provider-vsphere-static-ip#26, which adds support for v1alpha4 to...

I think this would still be valuable. /reopen /remove-lifecycle rotten

> But we only import it in _test.go files and in the printer package, so this shouldn't matter for consumers, right? I just tested with the cluster-api project, manually replacing...

Ok. This is now using the `ginkgo` cli, which allows to remove the ginkgo helper to create unit test reports. The apidiff is failing because of that. I've adapted the...

> @schrej the tests paniced but still passed: https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_controller-runtime/1977/pull-controller-runtime-test-master/1559847725640454144 Yeah. ~~Apparently `ginkgo` detects and reports panics even when they are intentional ("injected panic").~~ ``` •••E0817 10:24:49.659771 23457 runtime.go:77] Observed a...

> Why? Shouldn't we only depend on ginkgo in _test.go files? If anyhow possible, we shouldn't force users to use either version Probably because we're currently importing ginkgo v1 in...

Yes, but importing both at the same time causes issues with flag parsing as mentioned in the PR description. I'm almost done removing the ginkgo cli again. It solves the...