IsCloudInitEnabled does not consider /etc/cloud/cloud.cfg.d

[smoser]

Currently UseCloudInitWorkflow/IscloudInitEnabled only looks in the single file /etc/cloud/cloud.cfg for disable_vmware_customization: false.

Its generally better practice to put local changes like this into /etc/cloud/cloud.cfg.d/somefile.cfg.

If the user did that, then it would not be picked up by IsCloudInitEnabled.

cloud-init can definitely improve here and provide some sort of mechanism to query its configuration.

The right way to fix this is probably to have the two projects work together better. The ideal situation is for cloud-init to not need this configuration file change by the user, but rather to "just work".

[PengpengSun]

Hi Scott,

Thanks for bring up this.

cloud-init can definitely improve here and provide some sort of mechanism to query its configuration.

Does this mean that cloud-init can query the configuration path by some sort of mechanism. Then IsCloudInitEnabled will get the path and detect if disable_vmware_customization: false exists in it. The configuration path is like /etc/cloud/cloud.cfg.d/somefile.cfg

And yes, we could let cloud-init "just work" on Linux distro which proved to "working fine".

[russell-argo]

I too have been experiencing this issue.

It seems it would help for to the code check both areas.

ie: /etc/cloud.cfg AND /etc/cloud.cfg.d/*.cfg

That would cover the majority of cases?

[PengpengSun]

@russell-argo Yes, currently UseCloudInitWorkflow/IscloudInitEnabled checks /etc/cloud/cloud.cfg only for disable_vmware_customization: false. Before we get the ideal solution for cloud-init 'just work', this flag will be kept using. To include /etc/cloud/cloud.cfg.d/somefile.cfg search path for this flag, changes are needed on both VMTools and Cloud-init side, for now, please set this flag in /etc/cloud/cloud.cfg to make it work.