driver: make buildkitd "config" and "flags" names consistent

[crazy-max]

I found it confusing to have config as driver opt instead of buildkitd-config so we are consistent with buildkitd-flags. Same for variables not aligned across our code base.

This is also relevant for #2270

[crazy-max]

ci failure for docs-upstream workflow is not related: #2269

[dvdksn]

General: should it be --buildkitd-x or --buildkit-x ?

I don't think we would expect buildx to refer to buildkit as anything other than a daemon. So maybe the d can be removed. I think it would make it easier to remember.

[crazy-max]

General: should it be --buildkitd-x or --buildkit-x ?

I don't think we would expect buildx to refer to buildkit as anything other than a daemon. So maybe the d can be removed. I think it would make it easier to remember.

Hum I think buildkitd is the correct assumption as we are passing them to the daemon. Would also avoid deprecating buildkitd-flags but I agree for casual users buildkit is well-known. On the other hand, someone setting these flags knows what he's doing.

[thaJeztah]

Should we keep the old flags as hidden / deprecated for 1 .. 2 releases so that we can print a meaningful error if someone is using these? (didn't fully read through the diff, so perhaps we have something for that).

[crazy-max]

Should we keep the old flags as hidden / deprecated for 1 .. 2 releases so that we can print a meaningful error if someone is using these? (didn't fully read through the diff, so perhaps we have something for that).

@thaJeztah Yes we keep config as hidden: https://github.com/docker/buildx/pull/2268/files#diff-e163527133bf99ae0eee4eacce5a81fd349ab589b9e85c205cba4618c5562305R113-R116

This is similar to https://github.com/docker/cli/blob/1443014cbd604b460548a7729ec8ec510a5dbc5d/cli/command/container/opts.go#L247-L250

[thaJeztah]

Ah, thanks! Are we planning to officially deprecate the old one? (in that case, we could consider printing a deprecation warning when used, which can be "non-fatal" for now, but made "fatal" in a future release).

[crazy-max]

Ah, thanks! Are we planning to officially deprecate the old one? (in that case, we could consider printing a deprecation warning when used, which can be "non-fatal" for now, but made "fatal" in a future release).

Fine to keep it imo and I don't think the cli prints such warning atm for docker run --net-alias ... for example?

[dvdksn]

LGTM

[crazy-max]

Needs follow-up on https://github.com/crazy-max/docker-setup-buildx-action