Failure with OpenStack datasource on bare metal servers

Bug #1815990 reported by Lars Kellogg-Stedman
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

I am booting Ubuntu 18.04 (so, cloud-init 18.4-0ubuntu1~18.04.1) on an OpenStack managed bare metal server. In order to activate the OpenStack data source, I have set an explicit data source on the kernel command line:

  # cat /proc/cmdline
  BOOT_IMAGE=/boot/vmlinuz-4.15.0-45-generic root=UUID=3efc28cb-98a4-458d-8fbe-a895461703ca ro rd.iscsi.firmware=1 ci.ds=OpenStack console=tty1 console=ttyS0

ds-identify has correctly activated the OpenStack data source:

  # tail -2 /run/cloud-init/ds-identity.log
  datasource 'OpenStack' specified.
  [up 45.23s] returning 0

The data source is in fact available:

 # curl

But cloud-init seems unable to find it:[DEBUG]: Looking for data source in: ['OpenStack', 'None'], via packages ['', 'cloudinit.sources'] that matches dependencies ['FILESYSTEM', 'NETWORK'][DEBUG]: Searching for network data source in: ['DataSourceOpenStack', 'DataSourceNone'][DEBUG]: start: init-network/search-OpenStack: searching for network data from DataSourceOpenStack[DEBUG]: Seeing if we can get any data from <class 'cloudinit.sources.DataSourceOpenStack.DataSourceOpenStack'>[DEBUG]: Update datasource metadata and network config due to events: New instance first boot
  .[DEBUG]: finish: init-network/search-OpenStack: SUCCESS: no network data found from DataSourceOpenStack.

This is because the `detect_openstack` method in `` performs the same dmi-based checks that were already performed by `ds-identify` even though the data source has been *explicitly selected* it still won't run.

In the same environment, cloud-init-18.2-1.el7.centos.1.x86_64 on CentOS 7 seems to work without a problem. It looks like that version of cloud-init does not have the `detect_openstack` method.

Tags: dsid
description: updated
description: updated
Scott Moser (smoser)
tags: added: dsid
Revision history for this message
Chad Smith (chad.smith) wrote :

When explicitly configured, cloud-init needs to honor the datasource configuration and ignore any secondary datasource validation on the system. The user told us so, so cloud-init should commit to it.

Plans are to 'force' the configuration datasource regardless of cloud-init's detection algorithms if only one datasource is configured.

Revision history for this message
Chad Smith (chad.smith) wrote :

This is a bug that we need to resolve shortly in cloud-init.

Changed in cloud-init:
status: New → Triaged
Revision history for this message
Brett Holman (holmanb) wrote :

I think there are three separate issues to address here:

1. Bare metal datasource detection on openstack is broken and unusable.
2. Command line configuration is underdocumented and inconsistent across datasources.
3. Request to allow cloud-init to force a datasource (no runtime detection).

Brett Holman (holmanb)
Changed in cloud-init:
status: Triaged → Fix Committed
Revision history for this message
Alberto Contreras (aciba) wrote : Fixed in cloud-init version 23.1.

This bug is believed to be fixed in cloud-init in version 23.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in cloud-init:
status: Fix Committed → Fix Released
Revision history for this message
Chad Smith (chad.smith) wrote :

Update to this bug the following upstream commit[1] allows anyone to specify a single datasource either via kernel cmdline parameters via `ci.ds=OpenStack` or via system config in the images in /etc/cloud/cloud.cfg.d/99-myoverrides.cfg
datasource_list: [OpenStack].

If just a single datasource is configured by cmdline or filesystem, cloud-init python code will try the get_data discovery of that datasource to see if endpoints are accessible.


Revision history for this message
Chad Smith (chad.smith) wrote :

Expect 23.1.1 or later to contain this fix. Plans are to provide a StableReleaseUpdate to Ubuntu 18.04. 20.04, 22.04, 22.10 with this content.

Revision history for this message
James Falcon (falcojr) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.