canonical / cloud-init

Official upstream for the cloud-init: cloud instance initialization
https://cloud-init.io/
Other
2.86k stars 855 forks source link

[enhancement]: Add ability to pass specific ipv4/ipv6 options to network renderers #4621

Open ani-sinha opened 9 months ago

ani-sinha commented 9 months ago

Enhancement

Please see the discussion in https://github.com/canonical/cloud-init/pull/4474 . Currently network renderers use various default settings for ip configurations. For example, settings for IPV4_FAILURE_FATAL and IPV6_FAILURE_FATAL in ifcfg files and may-fail settings for nm keyfiles. See tables 70 and 71 in https://people.freedesktop.org/~lkundrak/nm-docs/nm-settings-ifcfg-rh.html for various ipv4 and ipv6 options that can be set and how they translate to ifcfg files and keyfiles. Unfortunately, the defaults may not be appropriate for some use cases and it may be required to override the default values with specific values for some of these settings. My ask here to add to cloud-init ability to override some of these values. For example it could be similar to dhcpv6-override and dhcp4-override options that are currently available https://netplan.readthedocs.io/en/latest/netplan-yaml/#dhcp-overrides . Since the above override options seems set in stone and we cannot add arbitrary options, we can introduce a new set of override options, like ipv4-override or ipv6-override that maybe passed on to the renderers and then renderers can consume it appropriately.

ani-sinha commented 9 months ago

See also https://github.com/canonical/cloud-init/issues/4439 .

holmanb commented 9 months ago

@ani-sinha see my comment here

holmanb commented 9 months ago

@ani-sinha is this still relevant given the approach in https://github.com/canonical/cloud-init/pull/4622?

ani-sinha commented 9 months ago

@ani-sinha is this still relevant given the approach in https://github.com/canonical/cloud-init/pull/4622?

It might be relevant later if we wanted to override default values for some other use case. For now we got past it.

ani-sinha commented 9 months ago

@ani-sinha is this still relevant given the approach in #4622?

It might be relevant later if we wanted to override default values for some other use case. For now we got past it.

This ticket is more generic than the fix for #4622 and if we can come up with a mechanism, it may be useful for other cases.

jsf9k commented 8 months ago

It would certainly be useful to override the default setting of false for dhcp[46]-overrides.use-domains. We want to upgrade our AMIs from Debian Bullseye to Debian Bookworm; however, on our Bookworm AMIs cloud-init uses the instance metadata to create a netplan config that does not specify dhcp[46]-overrides.use-domains and hence search domains from DHCP get ignored.

It looks like this user was experiencing the same problem a few years back. Does anyone know a workaround for dealing with this, other than modifying the systemd-networkd configurations after they are generated?

holmanb commented 8 months ago

Hey @jsf9k, thanks for the comment. I want to make sure that I understand correctly, so I'll rephrase and ask you to confirm.

You are saying that you wish to set dhcp[46]-overrides.use-domains to true, but you cannot do that because you cannot control the instance metadata provided by the cloud. @jsf9k is that correct?

jsf9k commented 8 months ago

Thanks for the quick response @holmanb!

You're very close. I don't think that dhcp[46]-overrides.use-domains is specified in the instance metadata at all, but I'd still like to override the default value of false.

(I'm assuming that cloud-init generates the /etc/netplan/50-cloud-init.yaml file based on information collected from the instance metadata, but maybe I'm wrong about that.)

holmanb commented 8 months ago

I don't think that dhcp[46]-overrides.use-domains is specified in the instance metadata at all

Which cloud are you using? It should be possible (from cloud-init's perspective) for the cloud to define this setting to true, but I think you are saying that they don't, right?

but I'd still like to override the default value of false.

Got that. Cloud-init doesn't currently allow users to - at runtime - define their own network settings. Currently network settings can only be set 1) by the datasource (via metadata), 2) by the user (by setting the configuration in /etc/cloud/cloud.cfg.d/*), and 2) in some cases via the kernel command line.

It sounds like you want to set this key yourself, since the datasource's instance metadata isn't doing it.

@jsf9k I just created this issue to track the request for users to define networking configuration to be applied at runtime.

jsf9k commented 8 months ago

I don't think that dhcp[46]-overrides.use-domains is specified in the instance metadata at all

Which cloud are you using? It should be possible for the cloud to define this setting to true, but I think you are saying that they don't, right?

I'm using AWS. :man_shrugging:

but I'd still like to override the default value of false.

Got that. Cloud-init doesn't currently allow users to - at runtime - define their own network settings. Currently network settings can only be set 1) by the datasource (via metadata), 2) by the user (by setting the configuration in /etc/cloud/cloud.cfg.d/*), and 2) in some cases via the kernel command line.

It sounds like I'll have to use runcmd to edit the /etc/netplan/50-cloud-init.yaml file that cloud-init produces, then run netplan generate. Do you see any other workaround?

It sounds like you want to set this key yourself, since the datasource's instance metadata isn't doing it.

@jsf9k I just created this issue to track the request for users to define networking configuration to be applied at runtime.

Thanks for creating an issue! Yes, I want to set this key myself. There are several other keys under dhcp[46]-overrides that folks might want to override for other use cases.

holmanb commented 8 months ago

Thanks for creating an issue! Yes, I want to set this key myself. There are several other keys under dhcp[46]-overrides that folks might want to override for other use cases.

No problem, I'm glad we're on the same page.

This issue's title reads similarly to the new one I created, but this is actually a different topic. This issue is related to changing the existing configuration to define new keys, not to adding users' ability to define network configuration.

Lets continue the conversation over on the new issue, since this one is a separate topic. I'll respond to your question over there.