Cloudstack doc fix#707
Conversation
OddBloke
left a comment
OddBloke
left a comment
There was a problem hiding this comment.
Hi Olivier, thanks for taking the time to improve our docs! We really appreciate it.
Reading this through, I'm not sure that updating this to match OpenNebula's docs is the right change. Over there, we say:
This example cloud-init configuration (cloud.cfg) enables OpenNebula datasource only in ‘net’ mode.
Whereas here we say:
An example configuration with the default values is provided below:
The default value of datasource_list is not just CloudStack, however; it's a full list of all datasources (https://github.com/canonical/cloud-init/blob/master/cloudinit/settings.py#L21).
What do you think to either rewording the preceding sentence, or dropping these lines entirely (instead of dedenting them)?
|
@OddBloke You're right, it's not the default values. However, this Environment:
1st case: no configurationNo configuration (except what cloud-init's package in Fedora provides). In particular, no When I run a VM, cloud-init does not run, and Running 2nd case: with datasource_list configurationI create a second template with a file When starting a new VM from that template, cloud-init works perfectly (creates user with ssh key pair provided by CloudStack).
3rd caseThis is quite strange but I reproduced it multiple times: if I use datasource_list:
- CloudStack
- Noneinstead of |
This is where we're tripping up. ds-identify uses, amongst other things, Lines 726 to 730 in 6c4e87b So the fact that your platform is identifying itself as "VMWare Virtual Platform" means that we don't detect it as CloudStack.
These lines indicate that if we don't find a datasource at all, then cloud-init should be disabled.
And we can see that ds-identify also identifies that the OVF datasource (used for VMWare) is not applicable: there are no applicable datasources, so cloud-init disables itself.
What you're seeing here is, in the absence of the output of ds-identify which indicates which exact datasource to use, cloud-init attempting every datasource in order, until one works. As we now have networking, we don't have to use DMI, so we do detect CloudStack correctly (and then prompt you to file a bug for the mismatch between ds-identify behaviour and cloud-init behaviour).
This is the key: as you configured cloud-init with only one datasource, ds-identify trusts you so does not perform its own detection: Lines 1655 to 1660 in 6c4e87b
The configuration is YAML, but ds-identify is implemented in shell (for a variety of reasons), and so only supports the array spelling: see https://github.com/canonical/cloud-init/blob/master/tools/ds-identify#L568 for the implementation. So this is both expected behaviour and quite strange. :) |
|
So, to summarise: if you can configure VMWare to present a different DMI product name, then that will address the issue you're seeing. Otherwise, you'll need to instruct cloud-init on which datasource to use: you can write a file as you've found, or provide |
|
Thank you very much for your very detailed and intelligible explanation! 👍
So CloudStack documentation here was twice wrong:
I agree that it may be best to simply drop these lines in documentation. |
In CloudStack configuration, datasource_list should be a top-level object, not nested in the datasource configuration. We remove it from here because it is not a default value.
2 participants
Proposed Commit Message
Fix CloudStack documentation
In CloudStack configuration,
datasource_listshould be atop-level object, not nested in the datasource configuration.
Additional Context
See OpenNebula documentation for example.
Test Steps
Manually: datasource list was not detected with configuration copied from online documentation. It is detected when the configuration is changed.
Checklist:
(doc only)