@nabuskey FYI - this would let us use finch as the kind provider, but our "RunsOnRightPort" hard depends on the docker CLI outside of our use of kind so it breaks on first run.

@nabuskey FYI - this would let us use finch as the kind provider, but our "RunsOnRightPort" hard depends on the docker CLI outside of our use of kind so it breaks on first run.

You're correct that the RunsOnRightPortfunctionality relies on the Docker API (used via the imported docker client package), but it works fine on "first use"; e.g. if you don't have an existing cluster created by idpbuilder.

Only if you try to run create again with an existing/running KinD cluster do you hit the problem of no Docker API available. With this PR I can at least test and validate the full idpbuilder create flow as long as I manually delete any pre-existing KinD clusters created with idpbuilder using kind delete cluster --name=....

You're correct that the RunsOnRightPortfunctionality relies on the Docker API (used via the imported docker client package), but it works fine on "first use"; e.g. if you don't have an existing cluster created by idpbuilder.

Only if you try to run create again with an existing/running KinD cluster do you hit the problem of no Docker API available. With this PR I can at least test and validate the full idpbuilder create flow as long as I manually delete any pre-existing KinD clusters created with idpbuilder using kind delete cluster --name=....

I don't think we should merge this then. When I am developing patterns and examples of using idpbuilder, I have to be able to run the create command multiple times against the same cluster. Being forced to re-create the cluster is a blocker for me.

If RunsOnRightPort is the problem, we should get rid of it or put it behind an interface.

nvm I misunderstood. These apply when you are using non-docker provider. So you are not affected if you use docker. We don't say we support non-docker providers anywhere yet so I think we are good.

We should reconsider RunsOnRightPort though.

@estesp I am catching up here. Thanks for this PR!

I am assuming there are mechanisms in Finch that would allow us to check whether the kind control plane container already serves idpBuilder on an existing port. correct?

if so, we should be able to use @greghaynes PR @183 to fix this and include Finch as a fully supported runtime.

Thanks @nimakaviani

I am assuming there are mechanisms in Finch that would allow us to check whether the kind control plane container already serves idpBuilder on an existing port. correct?

Yes, generally, but there is no programmatic API for Finch (or nerdctl) as they are just client/command line tools, not API servers. So, even #183 still imports the Docker client API pkg and makes calls (via the container object(s)) that require a Docker HTTP API server, which will mean that nerdctl and finch will not work in that model.

If pkg/docker was abstracted to pkg/runtimeprovider (not a great name, but as an example), and runtimeprovider could be implemented as it is today for "Docker", but finch, nerdctl, and any other runtimes could provide their own method to return a list of containers/ports for a container, then that would be the best solution.

If that's a bit too adventurous, another option is to "dumb down" pkg/docker into exec of Docker commands (docker ps, docker info) and then parse the JSON responses for the port info. Nowhere near as elegant as calling APIs, but would allow finch and nerdctl to work if aliased to "docker" at the command line, or if you could specify what binary is the "docker executable" in an idpbuilder config option/command line flag.