Set Azure to apply networking config every BOOT

[TheRealFalcon]

Proposed Commit Message

Set Azure to apply networking config every BOOT

In #1006, we set Azure to apply networking config every
BOOT_NEW_INSTANCE because the BOOT_LEGACY option was causing problems
applying networking the second time per boot. However,
BOOT_NEW_INSTANCE is also wrong as Azure needs to apply networking
once per boot, during init-local phase.

Additional Context

Test Steps

Run integration test

Checklist:

• My code follows the process laid out in the documentation
• I have updated or added any unit tests accordingly
• I have updated or added any documentation accordingly

[TheRealFalcon]

FYI @anhvoms

[anhvoms]

FYI @anhvoms

LGTM!

[blackboxsw]

still walking through test scenarios one minor question on the integration test

[blackboxsw]

@TheRealFalcon all good thanks for walking through this with me.

[xiachen-rh]

@TheRealFalcon
Hi James, why set Azure to apply networking config every BOOT? Some customers report a problem that this change disables the way they used to add additional search domains, then what is the correct way to manually add additional persistent search domains to a Azure VM now?

[TheRealFalcon]

Hi Amy, Setting search domains can be environment dependent, but a common method for RHEL-based distros is to use the Resolv Conf module: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#resolv-conf If you think that the change from this PR has caused a regression, please file a bug at https://bugs.launchpad.net/cloud-init and include the tarball from `cloud-init collect-logs --include-userdata` with any sensitive userdata redacted. Thanks, James

…

On Tue, Dec 6, 2022 at 6:23 AM Amy Chen ***@***.***> wrote: @TheRealFalcon <https://github.com/TheRealFalcon> Hi James, some customers report a problem that this change disables the way they used to add additional search domains, then what is the correct way to manually add additional persistent search domains to a Azure VM now? — Reply to this email directly, view it on GitHub <#1023 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABFQST7IWCHVECDOCMTUYDWL4V3BANCNFSM5EH76GOQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[xiachen-rh]

Hi James,
Thanks for your reply, and I will test the resolv conf module.
And could you tell me why setting Azure to apply networking config every BOOT please? I would like to know more background information about this PR.

Thanks,
Amy

[anhvoms]

@xiachen-rh Upon every boot, cloud-init needs to fetch network config again to make sure it has the most up-to-date network config for the VM because the user might add/remove network interface when the VM is stopped

[xiachen-rh]

@anhvoms I compared to other Cloud datasource file, and found that it seems only Azure and AWS Non-VPC (aka Classic) Ec2 instances need to rewrite network config file every boot. The AWS document shows that EC2-Classic network is going to retired (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-classic-platform.html). So my question is, why Azure needs to apply networking config every BOOT but other Cloud platforms don't need?

[TheRealFalcon]

@xiachen-rh , Anh answered your question. Some clouds issue a new instance id when network interfaces are changed on the system, causing cloud-init to refetch networking config. Azure does not, so it needs to fetch networking config every boot. This PR is not new behavior; it is a fix to me breaking this behavior in #1006. It's also important to know that until a few releases ago, Azure instances contained a script on boot that would remove cloud-init's cache such that every boot fetched networking data regardless of this value.

If something is broken, it'd be more helpful to file a bug that describes what behavior was working along with the first version you see broken. Include the results from cloud-init collect-logs --include-userdata whenever possible.

[zhaohuijuan]

@TheRealFalcon @anhvoms , thank you for the updates and explanations about this change, but as @xiachen-rh mentioned,
there are indeed some requirements from customers to persist their customized network config after reboot.
We can provide workaround for some customers' requirements, but as all the network configs will be over-written after reboot, maybe one specific workaround can not cover all scenarios, so I think we'd better considering how to enhance this patch and support the requirements. I reported a bug https://bugs.launchpad.net/cloud-init/+bug/2003048 to track this, could you please take a look?
Thanks a lot!