Flag based client configuration failed with err: fetch cert: Get "http://127.0.0.1:42114/cert": dial tcp 127.0.0.1:42114: connect: connection refused. Trying with env var legacy method

[djpbessems]

When running tink by defining a function that performs docker-compose exec tink-cli tink $@; every invocation of the function shows this error (but still performs the commands as expected): Flag based client configuration failed with err: fetch cert: Get "http://127.0.0.1:42114/cert": dial tcp 127.0.0.1:42114: connect: connection refused. Trying with env var legacy method

For reference, the function:

function tink() {
  pushd <path to docker-compose.yml> >/dev/null
  docker-compose exec tink-cli tink "$@"
  popd > /dev/null
}

Expected Behaviour

No error is shown

Current Behaviour

Error is shown; command is executed without issues

Possible Solution

Steps to Reproduce (for bugs)

1. Create function (in shell script)
2. Run tink through function

Context

Your Environment

• Operating System and version (e.g. Linux, Windows, MacOS):

• How are you running Tinkerbell? Using Vagrant & VirtualBox, Vagrant & Libvirt, on Packet using Terraform, or give details:

• Link to your project or a code example to reproduce issue:

[tstromberg]

I believe this is warning message from https://github.com/tinkerbell/tink/pull/442

Admittedly, the message isn't very helpful, as it doesn't give the user a clue what flag to provide.

@mmlb - any clue what should be provided to avoid this error message?

[djpbessems]

Does it have anything to do with these errors?

> curl http://10.0.0.1:42113
curl: (52) Empty reply from server

> curl -k https://10.0.0.1:42113/cert
curl: (92 HTTP/2 stream 0 was not closed cleanly: INTERNAL ERROR (err 2)

[tstromberg]

I spoke to @mmlb during our community triage meeting and he mentioned that this noisy warning should be silenced.

I understand that this warning should only happen when tink is configured via environment variables.

[rgl]

The correct way to call tink now seems to be:

function tink {
  docker exec -i compose_tink-cli_1 \
    tink \
    --tinkerbell-grpc-authority $TINKERBELL_HOST_IP:42113 \
    --tinkerbell-cert-url http://$TINKERBELL_HOST_IP:42114/cert \
    "$@"
}

Why this is better than an environment variable?

[tstromberg]

@rgl - Personally, I don't think that flags are universally better than environment variables. I would rather see the flags override the environment variable.

[rgl]

Oh, after all, the workaround is not good, because --tinkerbell-grpc-authority and --tinkerbell-cert-url is not universally supported by all the tink commands :-(

For example:

# docker exec -i compose_tink-cli_1 tink --tinkerbell-grpc-authority 10.3.0.2:42113 --tinkerbell-cert-url http://10.3.0.2:42114/cert template create
Error: unknown flag: --tinkerbell-grpc-authority
Usage:
  tink template create [flags]

Flags:
      --file string   path to the template file (default "./template.yaml")
  -h, --help          help for create

Global Flags:
  -f, --facility string   used to build grpc and http urls

unknown flag: --tinkerbell-grpc-authority

Can this be fixed?

[jacobweinstock]

This definitely needs some love. Looks like there might be only 2 places that need to be updated? search query https://github.com/tinkerbell/tink/blob/b18b238e1807b1159a3a2455986c636fb552da71/cmd/tink-cli/cmd/get/get.go#L79 https://github.com/tinkerbell/tink/blob/5923ca980280867d7c52c80b2336feafdba7db7b/cmd/tink-cli/cmd/delete/delete.go#L88

[chrisdoherty4]

The Tink CLI has been deprecated and removed.

[djpbessems]

I haven't been following the development of Tinkerbell since I've changed teams. But I am curious about what replaced tink-cli's workflow then, because I know our setup relies on it.

[chrisdoherty4]

Hi @djpbessems, sorry I didn't put more detail.

Tinkerbell has transitioned to a Kube backend and kubectl can be used to perform the actions Tink CLI used to do.

[djpbessems]

So would it now be easier to just install/configure Tinkerbell on a k3s node instead of using docker-compose?

[chrisdoherty4]

Thats correct. The maintainers generally use K3D and deploy with our new Helm chart. There is some twiddling of variables required but its all documented in the README.md.