cloud-init team mailing list archive

[Denis Krienbühl <denis@xxxxxxx>]

Hi Dan,

Thanks for getting back to me so quickly with a lot of useful information. I appreciate it.

We indeed use the default Ubuntu config, which confirms what I was seeing.

Cheers!

Denis

> On 12 May 2020, at 16:56, Daniel Watkins <daniel.watkins@xxxxxxxxxxxxx> wrote:
> 
> Hi Denis,
> 
> Thanks for using cloud-init, and for reaching out!
> 
> On Tue, May 12, 2020 at 10:06:25AM +0200, Denis Krienbühl wrote:
>> Everything works great, and it seems as though cloud-init considers
>> the config drive first. The logs tell me as much as cloud-init now
>> uses the drive as a source, and not the metadata service.
>> 
>> I was wondering though, in what order does cloud-init consider
>> sources? Say with cloud-init 19.2, Ubuntu 18.04, OpenStack.
> 
> The order in which datasources are considered is configurable.  You'll
> want to look for datasource_list configuration setting in
> /etc/cloud/cloud.cfg and /etc/cloud/cloud.cfg.d/* to discover if this is
> configured on your system.  (On Ubuntu, you should see this configured
> in /etc/cloud/cloud.cfg.d/90_dpkg.cfg, which is populated based on
> debconf selections).
> 
> If no such configuration is present, then cloud-init will fall back to
> using its builtin configuration:
> https://github.com/canonical/cloud-init/blob/master/cloudinit/settings.py#L20-L59
> 
> In both the shipped Ubuntu config and the fallback config, ConfigDrive
> is the second datasource that will be considered (before everything but
> NoCloud).
> 
>> Everything works, but it would be nice to know if this is by accident
>> or for good reason :-).
> 
> It's not by accident, certainly. :)  Generally, we prefer local data
> sources over network data sources.  One example of why: datasources can
> provide network configuration, which means we have a chicken/egg problem
> with network data sources.  We (usually; this is datasource-specific
> behaviour) have to bring up an ephemeral DHCP connection to fetch the
> metadata, and mounting an ISO locally is more robust (and I would guess
> quicker, though I have no data to back that up), so we'll do that
> instead given the option.
> 
> 
> Cheers,
> 
> Dan