Add possibility to copy ConfigFile to host

[afbjorklund]

• Refactor PortForward guest/host processing
• Add possibility to copy ConfigFile to host

Issue #1300

[jandubois]

Except for the file permissions this seems to be ready for merging, I think, so maybe remove the Draft status?

[jandubois]

Thanks, LGTM.

@AkihiroSuda Please merge if you have no objections!

[AkihiroSuda]

I still think "conf" ("config") is a confusing name

[AkihiroSuda]

Also please consider squashing commits

[afbjorklund]

I still think "conf" ("config") is a confusing name'

I don't have a much better name, for a directory for $KUBECONFIG files.

It was supposed to be an internal concept, similar to the "sock" directory

Could call it "yaml", based on file type ?

Or maybe even "kube", to specialize it.

Also please consider squashing commits

I can squash them when the new names are finalized, I am deliberately trying to scope it down from the last time...

Now it looks like a more generic functionality, but the requirement was only to do a mkdir -p and ssh a sudo cat.

So that the wrapper could do something simple, similar to the tunneled sockets:

KUBECONFIG=$(limactl list "$LIMA_INSTANCE" --format '{{.Dir}}/conf/kubeconfig.yaml')

[jandubois]

I still think "conf" ("config") is a confusing name'

I don't have a much better name, for a directory for $KUBECONFIG files.

The use for $KUBECONFIG files is your immediate use case, but the feature is more general, and called copyToHost. I think @AkihiroSuda wants to quite literally call it $INSTANCE_DIR/copied-from-guest, which is pretty descriptive.

I admit that personally I find it too long, but I can see the value for users not yet familiar with the concept.

I too don't have a better suggestion.

It was supposed to be an internal concept, similar to the "sock" directory

Anything documented in the default.yaml is not an internal concept, but a supported API.

That said, I thought conf was fine, but I see now that the concept is bigger than that. However, I'm not sure what else you would want to exfiltrate from the guest after provisioning, but config files.

Could call it "yaml", based on file type ?

No, that doesn't work for me. Do you actually means to create different directories, based on the file extension of the copied file? What about files without an extension?

Or maybe even "kube", to specialize it.

I think the idea is to generalize the name beyond this specific use case, not to specialize it even further.

Note that this is also just the default location for relative host names, so mostly useful for shared templates. For local instances I would probably use absolute host names to point to a convenient location instead.

[afbjorklund]

"yaml" was extrapolating from "sock" (i.e. based on file suffix)

"kube" was based on the default location, $HOME/.kube/config

If I understand the code correctly, using relative paths would also work.

portForwards:
- guestSocket: "/var/run/docker.sock"
  hostSocket: "docker.sock"

copyToHost:
- guest: "/etc/kubernetes/admin.conf"
  host: "kubeconfig.yaml"

It wouldn't help for printing out the location, though (probably opposite)

At least not without more variables, for the subdirectories of {{.Dir}}

Something like "client" perhaps, but it wouldn't make sense without "config"

---

Can go with copied-from-guest

Maybe OK, with the new wrapper.

I don't really see the difference, I guess the sockets would be forwarded-from-guest

And think it looks rather long and ugly, but now I sort of warmed into the kubectl.lima

[jandubois]

"yaml" was extrapolating from "sock" (i.e. based on file suffix)

But "sock" was not based on file suffix (except they accidentally match). It is based on the fact the the only thing you can forward are sockets. And the name was shortened to sock to make it more likely to stay under the maximum socket name length of 103 characters on macOS.

Can go with copied-from-guest

Yeah, I can go with that if @AkihiroSuda feels strongly about not using conf.

I don't really see the difference, I guess the sockets would be forwarded-from-guest

No, as explained above, there can only be sockets inside sock, but there can be any kind if files in copied-from-guest. And the name of the socket directory needs to be short. There is no such limitation on the "copied from guest" directory name.

And think it looks rather long and ugly

I agree, but I can see the point of it being more self-explanatory.

Alternatively, maybe this could be solved by more extensive explanation in the default.yaml comments?

[AkihiroSuda]

"conf" (config) is confusing because the yaml is also called "config".
And yet we also have a bunch of other "configs" too.

Same applies to the "sock" though, but there is a compromise because of the limit of the sock path length.

[afbjorklund]

I removed the global constants, so now it is up to each example to name the local files to whatever suits best...

The default.yaml shows the suggested {{.Dir}}/copied-from-guest/myconfig location, as an example host path.

[AkihiroSuda]

Thanks, but the commit does not seem updated

[jandubois]

Thanks, but the commit does not seem updated

Seems updated to me. The current state of the PR now requires an absolute path for both the guest and the host filename, and no longer provides a default location.

It is not clear to me what you are requesting: should the default location be restored and set to .../copied-from-guest?

[AkihiroSuda]

Thanks, LGTM but with a single nit

[afbjorklund]

This also opens for choosing a more suitable name for each example, matching the files that are copied.

Like {{.Dir}}/kube/config.yaml

[jandubois]

This also opens for choosing a more suitable name for each example, matching the files that are copied.

Like {{.Dir}}/kube/config.yaml

This is actually a reason why I preferred to have a default location because this now opens the instance directory up to users creating arbitrarily named directories, which could conflict with files or directories Lima wan't to create in the future.

This was the reason we specified sock/ as the default location for forwarded sockets instead of creating them directly in the instance dir.

[afbjorklund]

Actually they can copy them anywhere on the host, since we require it to be an absolute path and not just a filename...

[jandubois]

Actually they can copy them anywhere on the host, since we require it to be an absolute path and not just a filename...

Yes, but users copy from the provided examples, and if our examples create random directories inside the instance directories, then that means that we implicitly endorse doing so.

[AkihiroSuda]

Any idea to move this forward? (for v0.16 ?)

[jandubois]

Any idea to move this forward? (for v0.16 ?)

Does this need anything more than the single line comment change you requested above, and that @afbjorklund gave the 👍 for, but hasn't pushed yet?

[afbjorklund]

Missed to update this, didn't know if the names were settled.

Need to update kubectl.lima to use "copied-from-guest", sigh.

• Add kubectl kubernetes client wrapper #1302

Hopefully that means that nobody has to use the file path.

[jandubois]

Thanks, LGTM