kubevirt: Set transient hostname from metadata

[qinqon]

"Closes: #xxxx"

- What I did
At KubeVirt the hostname is usually set using DHCP on the case of fcos/rhcos but at some use cases this is not the case and at least the transient hostname should be set from the metadata. This change runs the afterburn service that read metadata and dump and env file that can be used later on with hostnamectl to set the transient hostname.

Closes: https://issues.redhat.com/browse/CNV-33668

journal of unit running at an hypershift kubevirt node before and after restart

$ journalctl -u afterburn-transient-hostname
Nov 02 16:11:48 localhost.localdomain systemd[1]: Starting Set Transient Hostname from KubeVirt meta_data...
Nov 02 16:11:48 foo-741a4add-ckjwp systemd[1]: afterburn-transient-hostname.service: Deactivated successfully.
Nov 02 16:11:48 foo-741a4add-ckjwp systemd[1]: Finished Set Transient Hostname from KubeVirt meta_data.
-- Boot f65d0299191c4c76a7db69a6dc97f7c8 --
Nov 02 16:14:13 localhost systemd[1]: Starting Set Transient Hostname from KubeVirt meta_data...
Nov 02 16:14:13 foo-741a4add-ckjwp systemd[1]: afterburn-transient-hostname.service: Deactivated successfully.
Nov 02 16:14:13 foo-741a4add-ckjwp systemd[1]: Finished Set Transient Hostname from KubeVirt meta_data.

- Description for the changelog
kubevirt: Set transient hostname from metadata

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: qinqon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• templates/common/kubevirt/OWNERS [qinqon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jlebon]

I'm a bit confused by this. The VMI schema has an explicit spec.hostname field that users can set. That seems more authoritative than DHCP. The field is optional IIUC, so if it's not provided then DHCP will win. It's not clear in the original implementation (coreos/afterburn#725) whether not having afterburn-hostname.service run on KubeVirt was on purpose or an oversight.

I guess what I'm asking is:

1. Is this really what OCP wants?
2. Is this what any consumer of KubeVirt would want? I.e. would it make sense to merge kubevirt: Run afterburn-hostname service coreos/afterburn#1005 because it's the expected behaviour, and if OCP wants to differ, it can add a systemd service like it does here?

[qinqon]

I'm a bit confused by this. The VMI schema has an explicit spec.hostname field that users can set. That seems more authoritative than DHCP. The field is optional IIUC, so if it's not provided then DHCP will win. It's not clear in the original implementation (coreos/afterburn#725) whether not having afterburn-hostname.service run on KubeVirt was on purpose or an oversight.

I think it may be don on purpose since doing so whould not allow users with secondary networks to override the hostname.

I guess what I'm asking is:

1. Is this really what OCP wants?

At ocp hypershift kubevirt is the only want that uses the rhel image with kubevirt provider, and there the current behaviour is working for us, so doing the this change would "alter" that since we are not setting it using DHCP.

2. Is this what any consumer of KubeVirt would want? I.e. would it make sense to merge kubevirt: Run afterburn-hostname service coreos/afterburn#1005 because it's the expected behaviour, and if OCP wants to differ, it can add a systemd service like it does here?

We can skip this PR and address it if we use there are problems u/s, kubevirt support at fcos/rhcos is quite new.

[jlebon]

I think it may be don on purpose since doing so whould not allow users with secondary networks to override the hostname.

Let's dig into this more. Why should DHCP from a secondary network have precedence over spec.hostname?

If a user wants the hostname set by DHCP, can't they just not set spec.hostname?

[qinqon]

In the case of hypershift kubevirt, the VM is not created by user so there is no control over spec.hostname on that case the user can have their own DHCP server deliver the hostname per deliver IP.

[jlebon]

In the case of hypershift kubevirt, the VM is not created by user so there is no control over spec.hostname on that case the user can have their own DHCP server deliver the hostname per deliver IP.

Thanks, this is making more sense now. :) So this is specific to HyperShift + KubeVirt. (Or I guess a cluster where users don't have ACLs to create VMIs directly.) What's the UX through which the user requests the VM to be created?

[qinqon]

In the case of hypershift kubevirt, the VM is not created by user so there is no control over spec.hostname on that case the user can have their own DHCP server deliver the hostname per deliver IP.

Thanks, this is making more sense now. :) So this is specific to HyperShift + KubeVirt. (Or I guess a cluster where users don't have ACLs to create VMIs directly.) What's the UX through which the user requests the VM to be created?

So on default scenario user create a cluster and that's all, user don't really care of VM hostname normally. And that hostname is the vm generated name passed over DHCP by an internal dhcp server at each of them, that's how kubevirt works by default.

[jlebon]

Personally, I think it's a bug that Afterburn isn't currently setting the hostname on KubeVirt. So I think we do want coreos/afterburn#1005, but yes, it'll require some design work to ensure we still get the right behaviour in the HyperShift + KubeVirt + Multus case. So fine to defer for now.

[jlebon]

Shouldn't this have

ConditionPathExists=!/etc/hostname

?

We don't want to set a hostname if one has already been set (e.g. via Ignition).

[qinqon]

Well not sure, it depends on what the we want do at the end, maybe we want to convert the static into transient hostname.

[jlebon]

The comment says to mark as optional, but this is missing the optional marker.

Also if it's truly missing, then we'd be setting the transient hostname to the empty string, which is not what we want. Likely instead we should add ConditionPathExists=/run/metadata/afterburn to the unit?

[openshift-ci]

@qinqon: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-gcp-op-single-node	05bd19b	link	true	/test e2e-gcp-op-single-node

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[qinqon]

/hold

Looks like /etc/hostname is also created, maybe a byproduct of calling the afterburn service.

System reports that hostname is transiently being set

 systemd-hostnamed[1719]: Hostname set to <foo-660875e1-crhdw> (transient)

Looks like mco is storing it as static so it cannot be overriden, so our scenario where user sets the hostname with DHCP server is not compatible with seting it transient from metadata.

Nov 06 09:28:30 foo-660875e1-crhdw mco-hostname[2075]: waiting for non-localhost hostname to be assigned
Nov 06 09:28:30 foo-660875e1-crhdw mco-hostname[2075]: node identified as foo-660875e1-crhdw
Nov 06 09:28:30 foo-660875e1-crhdw mco-hostname[2075]: saving hostname to prevent NetworkManager from ever unsetting it