You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe:
The access credentials API [1] allows to inject SSH public keys into virtual machines.
At the moment the supported propagation methods for this are cloud-init config drives and the QEMU guest agent. [2]
Describe the solution you'd like:
It would be useful to add support for cloud-init NoCloud data sources to the access credentials API. This would allow the use of the more versatile and vendor neutral NoCloud data source, instead of being limited to the OpenStack orientated config drive.
The config drive propagation method is using the OpenStack metadata format to inject SSH public keys. This format allows to set only a limited amount of parameters. [3]
It should be possible to use the NoCloud metadata to inject SSH public keys too. [4]
While as a first step this would allow to inject SSH public keys with NoCloud data sources too, this could allow to inject even more settings provided by the hypervisor (e.g. activation credentials) in the future, see #10343.
Describe alternatives you've considered:
Staying with config drives is suboptimal, as this limits the possibility of KubeVirt supplying parameters to virtual machines to the parameters supported by the OpenStack metadata. It also limits the support of network configuration formats to the older ENI legacy format, while the NoCloud data source is able to use all available network configuration formats. [5]
Additional context:
When using the access credentials API with the config drive propagation method it is required to use a cloud-init config drive. IIUC it is not possible to simultaneously use a NoCloud datasource. Therefore the limitations above apply to all virtual machines using this method.
Is your feature request related to a problem? Please describe:
The access credentials API [1] allows to inject SSH public keys into virtual machines.
At the moment the supported propagation methods for this are cloud-init config drives and the QEMU guest agent. [2]
Describe the solution you'd like:
It would be useful to add support for cloud-init NoCloud data sources to the access credentials API. This would allow the use of the more versatile and vendor neutral NoCloud data source, instead of being limited to the OpenStack orientated config drive.
The config drive propagation method is using the OpenStack metadata format to inject SSH public keys. This format allows to set only a limited amount of parameters. [3]
It should be possible to use the NoCloud metadata to inject SSH public keys too. [4]
While as a first step this would allow to inject SSH public keys with NoCloud data sources too, this could allow to inject even more settings provided by the hypervisor (e.g. activation credentials) in the future, see #10343.
Describe alternatives you've considered:
Staying with config drives is suboptimal, as this limits the possibility of KubeVirt supplying parameters to virtual machines to the parameters supported by the OpenStack metadata. It also limits the support of network configuration formats to the older ENI legacy format, while the NoCloud data source is able to use all available network configuration formats. [5]
Additional context:
When using the access credentials API with the config drive propagation method it is required to use a cloud-init config drive. IIUC it is not possible to simultaneously use a NoCloud datasource. Therefore the limitations above apply to all virtual machines using this method.
[1] https://kubevirt.io/api-reference/v1.0.0/definitions.html#_v1_accesscredential
[2] https://kubevirt.io/api-reference/v1.0.0/definitions.html#_v1_sshpublickeyaccesscredentialpropagationmethod
[3] https://cloudinit.readthedocs.io/en/latest/reference/datasources/configdrive.html
[4] https://cloudinit.readthedocs.io/en/latest/reference/datasources/nocloud.html
[5] https://cloudinit.readthedocs.io/en/latest/reference/network-config.html#network-configuration-sources
The text was updated successfully, but these errors were encountered: