virtctl port-forward/ssh/scp syntax

[Felix Matouschek]

Hi all,

I'd like to discuss possible changes to virtctl port-forward/ssh/scp
with you.

The syntax of virtctl works like this right now: $KIND/$NAME.$NAMESPACE

To me this is a bit unusual, especially if you look at kubectl port-
forward, which uses $KIND/$NAME and '-n' for specifying a namespace.

My assumption is that this syntax was added to satisfy the use case in
[1]. However, this syntax is a bit problematic, as seen in [2].

My suggestion would be to change virtctl port-forward/scp/ssh to use
the same syntax as kubectl ($KIND/$NAME and '-n' for the namespace).

This would mean that SSH configs as in [1] would now require to have
the '-n' flag if you want to specify a specific namespace and that a
single catch-all config for all namespaces would no longer be possible.
With the new syntax we could make multiple configs for different
namespaces work by accepting any kind of prefix before the first slash.
(right now only vm/ and vmi/ are accepted).

This also presents a chance to unify the commands to only use the VMI
subresource endpoint, as right now it is possible to switch between the
VM and VMI port-forward subresource endpoints, which both ultimately
connect to a VMI.

All in all, this would allow the virtctl code to become less brittle,
easier to maintain and the UX would be closer to kubectl.

Going forward with 1.5 I would like to deprecate the old syntax while
still keeping support it. In 1.6 I'd like to drop the old syntax
entirely.

Any comments on that? Do you think this is acceptable?

Thanks,
Felix

[1]
https://kubevirt.io/user-guide/user_workloads/accessing_virtual_machines/#using-virtctl-as-proxy
[2] https://github.com/kubevirt/kubevirt/issues/13679

[Fabian Deutsch]

Hey Felix,

+1 from my side on the alignment.

As you noted, the workaround is to adjust the SSH config.

 

Thanks,
Felix

[1]
https://kubevirt.io/user-guide/user_workloads/accessing_virtual_machines/#using-virtctl-as-proxy
[2] https://github.com/kubevirt/kubevirt/issues/13679

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/797e0838702cca2e3755c3482e79121125f98f25.camel%40redhat.com.

[Roman Mohr]

I wonder on 2, I thought we had the same limitation like pods, that dots are not allwoed in names to be able to accomodate DNS.

Is that not the case? What do we do with headless services if the VMs have a dot in  the name then?

Best regards,

Roman
 

Thanks,
Felix

[1]
https://kubevirt.io/user-guide/user_workloads/accessing_virtual_machines/#using-virtctl-as-proxy
[2] https://github.com/kubevirt/kubevirt/issues/13679

[Felix Matouschek]

According to the Kubernetes docs, it should be fine to use dots in
object names. [1]

I tried creating a VM with dots in its name (fedora.amd64) and that is
working fine.

[1]
https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names

> Is that not the case? What do we do with headless services if the VMs
> have a dot in  the name then?

I can verify dots in the name of a VM also work with a headless
service. The EndpointSlice of the service is created as expected.

See:

kind: EndpointSlice
apiVersion: discovery.k8s.io/v1
endpoints:
- addresses:
- 10.244.0.21
conditions:
ready: true
serving: true
terminating: false
nodeName: kind-control-plane
targetRef:
kind: Pod
name: virt-launcher-fedora.amd64-vs6f5
namespace: default
uid: 7aec8c6c-52b6-430b-ab3a-e5e40245b241

Thanks,
Felix

[Roman Mohr]

Great! Thanks for checking Felix. Obviously dots are allowed on pods. My memory tricked me.

Best regards,

Roman

[Felix Matouschek]

Hi all!

I've posted https://github.com/kubevirt/kubevirt/pull/13913

Notice that I changed the syntax from the original proposal $KIND/$NAME to $NAMESPACE/$NAME as not to break known_hosts files.

With the original proposal two VMs in different namespaces but the same name would have collided otherwise.

Felix

[Felix Matouschek]

Hi,

concerning https://github.com/kubevirt/kubevirt/pull/13913:

After further offline discussion with Federico we came to the conclusion that this is not the way to go forward.

Originally the idea was to come closer the kubectl syntax, but this is now deviating in another way. (NAMESPACE/NAME vs kubectl's TYPE/NAME).

We've come up with the following solution going forward:

1. Deprecate TYPE being optional in the virtctl port-forward/ssh/scp syntax for release 1.6 (TYPE is mandatory in kubectl port-forward as well)
2. Make TYPE mandatory for release 1.7 and switch to the following syntax `TYPE/NAME[/NAMESPACE]`

This allows to retain extended semantics for interaction with SSH and its known_host file,

while also maintaining the original goal of coming closer to the kubectl syntax and fixing issues with dots in the name of VMs/VMIs or namespaces.

I will open a PR for step one today.

[Felix Matouschek]

Excuse my little off by one error. I got confused by the version numbers.

I meant deprecate optional TYPE in 1.5 and make it mandatory in 1.6.