| Age | Commit message (Collapse) | Author |
|---|
|
ovf_vmware_transport_guestinfo is not currently tested.
It used '$1' instead of '$out' when checking for xml content in
the output of vmware-rpctool.
|
|
This adds support for reading OVF information over the
'com.vmware.guestInfo' tranport. The current implementation requires
vmware-rpctool be installed in the system.
LP: #1807466
|
|
When deploying an OVA, at least some versions of vmware
attach a cdrom with an ISO9660 filesystem label of 'OVF ENV'.
This was seen on Vmware vCenter Server, 6.0.0, 2776510.
In order to accomplish this we had to change the content of
the DI_ISO9660_DEVS variable to be comma delimited rather
than space delimited.
|
|
There was a typo in the doc string at the top of ds-identify
(disable -> disabled). That is fixed here as well as adding some
better examples on content in /etc/cloud/ds-identify.cfg.
|
|
This adds a Oracle specific datasource that functions with OCI.
It is a simplified version of the OpenStack metadata server
with support for vendor-data.
It does not support the OCI-C (classic) platform.
Also here is a move of BrokenMetadata to common 'sources'
as this was the third occurrence of that class.
|
|
SuSE builds were not getting a PATH set in generator's environment.
This may seem like mis-configuration on the system, but caused ds-identify
to fail to find blkid (or any other program).
The change here just ensures that we get /sbin /usr/sbin /bin /usr/bin
into the PATH when main is run.
LP: #1771382
|
|
In playing with a SmartOS container I found that ds-identify did
not identify the container there as a container. Systemd-detect-virt
identifies it as 'container-other'.
Also here are tests for ds-identify for the SmartOS platform
identification, and some indentation fixes in ds-identify.
|
|
We had two calls to is_ds_enabled, and the debug message looked
something like this:
is_ds_enabled returned 1: ConfigDrive NoCloud
Now instead we have just one call, and the debug message like:
is_ds_enabled(IBMCloud) = true
|
|
This fixes warnings reported by shellcheck at 0.4.6.
The complaints that we are ignoring globally (top of the file) are:
2015: Note that A && B || C is not if-then-else. C may run if A is true.
2039: In POSIX sh, 'local' is undefined.
2162: read without -r will mangle backslashes.
2166: Prefer [ p ] && [ q ] as [ p -a q ] is not well defined.
Most of the complaints were just noise, but a few unused variables
were reported and fixed.
Related shellcheck issues opened:
- https://github.com/koalaman/shellcheck/issues/1191
- https://github.com/koalaman/shellcheck/issues/1192
- https://github.com/koalaman/shellcheck/issues/1193
- https://github.com/koalaman/shellcheck/issues/1194
|
|
Ubuntu images on IBMCloud for 16.04 have some seed data in
/var/lib/cloud/data/seed/nocloud-net. In order to have systems with
IBMCloud enabled, we modified ds-identify detection to skip that seed
if the system was on IBMCloud. That change did not consider the
fact that IBMCloud might not be in the datasource list.
There was similar logic in the ConfigDrive datasource in ds-identify
and the datasource itself.
Config drive is now updated to only check and avoid IBMCloud if IBMCloud
is enabled. The check in ds-identify for nocloud was dropped. If a
user provides a nocloud seed on IBMCloud, then that can be used.
This means that systems running Xenial will continue to get their
old datasources.
LP: #1766401
|
|
When images are deployed from template in a production environment
the artifacts of the provisioning stage (provisioningConfiguration.cfg)
that cloud-init referenced are cleaned up. However, when provisioned
in "debug" mode (internal to IBM) the artifacts are left.
This changes the 'is_ibm_provisioning' implementations in both
ds-identify and in the IBM datasource to identify the provisioning
stage more correctly. The change is to consider provisioning only
if the provisioing file existed and there was no log file or
the log file was older than this boot.
LP: #1767166
|
|
This adds a specific IBM Cloud datasource.
IBM Cloud is identified by:
a.) running on xen
b.) one of a LABEL=METADATA disk or a LABEL=config-2 disk with
UUID=9796-932E
The datasource contains its own config-drive reader that reads
only the currently supported portion of config-drive needed for
ibm cloud.
During the provisioning boot, cloud-init is disabled.
See the docstring in DataSourceIBMCloud.py for more more information.
|
|
Open Telekom Cloud gen1 (Xen) hosts do not provide nova product
names in DMI but Xen HVM domU. They can however be safely identified
by the OpenTelekomCloud Chassis asset tag. OpenTelekomCloud does
use the network OpenStack DataSource, so we better detect it.
LP: #1756471
|
|
The Hetzner Cloud metadata service is an AWS-style service available
over HTTP via the link local address 169.254.169.254.
https://hetzner.com/cloud
https://docs.hetzner.cloud/
|
|
On few 64-bit platforms, the open-vm-tools package is installed at
/usr/lib64/. The DataSourceOVF is changed to search look there for the
'customization plugin'
|
|
This fixes a bug in parsing of 'blkid -o export' output. The result
of the bug meant that DI_ISO9660_DEVS did not get set correctly and
is_cdrom_ovf would not identify devices in most cases.
The tests are improved to demonstrate both multiple iso devices
and also a cdrom that doesn't sort "last" in blkid output.
The code change is to use DEVNAME as the record separator when
parsing blkid -o export rather than relying on being able to read
the empty line.
LP: #1749980
|
|
Ubuntu core seeds information to nocloud via a bind-mount of
/writable/system-data/var/lib/cloud over /var/lib/cloud.
When ds-identify runs as a systemd generator that mount is not
guaranteed to have been done. It is guaranteed at
cloud-init-local.service time, but not generator time.
Images built with 'ubuntu-image --cloud-init=user-data-file'
would have cloud-init disabled.
The fix here is just to consider the seed dir under /writable/system-data.
LP: #1747070
|
|
Fujitsu Cloud Service attaches a ovf iso transport with a label
'OVFENV'. This seems to be a reasonable value as a label.
While the for bug 1731868 would likely fix cloud-init on fujitsu
cloud, this change will find it faster.
LP: #1698669
|
|
New mkfs.vfat and fatlabel tools included in the dosfsutils package no
longer support creating vfat disks with lowercase labels. They silently
default to an all uppercase label eg CONFIG-2 instead of config-2. This
change makes cloud-init handle either upper or lower case.
LP: #1598783
|
|
The previous OVF datasource change added a debug message that referenced
an un-used variable. The failure path would be triggered if an image was
booted with a iso9660 filesystem attached to a device that was not a
cdrom.
A unit test is added for the specific failure found.
Additional safety to avoid 'cidata' labels is also added to the OVF
checker.
LP: #1737704
|
|
Previously the OVF transport would not be identified except for when
config files set 'ovf_vmware_guest_customization'. It would also
return DS_MAYBE almost always.
The change here is to add support to ds-identify for storing the
iso9660 filesystems that it finds (ISO9660_DEVS). Then the OVF check
will check that the iso9660 filesystem has ovf-env.xml on it. The least
wonderful part of this is that the check is done by 'grep' for case
insensitive ovf-env.xml.
Future improvement would be to identify VMware's OVF by label or UUID
so we could avoid the grep.
LP: #1731868
|
|
OpenStack Nova identifies itself only to Intel guests.
Make ds-identify return 'MAYBE' for OpenStack on non-intel arches.
An unnecessary change here is to rename the 'policy_nodmi' kwarg
to 'policy_no_dmi' in the related unit tests.
LP: #1715241
|
|
Here we add and enable by default a datasource for Scaleway cloud.
The datasource quickly exits unless one of three things:
a.) 'Scaleway' found as the system vendor
b.) 'scaleway' found on the kernel command line.
c.) the directory /var/run/scaleway exists (this is currently created
by the scaleway initramfs module).
One interesting bit of this particular datasource is that it requires
the source port of the http request to be < 1024.
|
|
This allows the user to seed NoCloud in a trivial way from qemu/libvirt,
by using a stock image and passing a single command line flag. No custom
command line, no filesystem modification, no bootstrap disk image.
This is particularly handy now that Ec2 backend is discouraged from use
under bug 1660385.
LP: #1691772
|
|
Azure sets a known chassis asset tag to 7783-7084-3265-9085-8269-3286-77.
We can inspect this in both ds-identify and DataSource.get_data to
determine whether we are on Azure.
Added unit tests to cover these changes
and some minor tweaks to Exception error message content to give more
context on malformed or missing ovf-env.xml files.
LP: #1693939
|
|
AliYun cloud platform is now identifying themselves by setting the dmi
product id to the well known value "Alibaba Cloud ECS". The changes here
identify that properly in tools/ds-identify and in the DataSourceAliYun.
Since the 'get_data' for AliYun now identifies itself correctly, we can
enable AliYun by default.
LP: #1638931
|
|
If the user configured:
datasource_list: ["Ec2", "None"]
then ds-identify would write
datasource_list: ["Ec2", "None", "None"]
which would break the logic to avoid warning.
|
|
This adds several unit tests for ds-identify, and fixes a bug
in Ec2 detection that I found while writing these tests.
The method of testing is to use the ds-identify code as a shell
library. The TestDsIdentify:call basically does:
* populate a (temp) directory with files that represent what
ds-identify would see in /sys or other locations it reads.
* create a file '_shwrap' that replaces the 3 programs that are executed
in ds-identify code path. It supports setting their stdout, stderr,
and exit code.
* set the default policies explicitly (DI_DEFAULT_POLICY) so we can
support testing different builtins. This is necessary because the
Ubuntu branches patch the builtin value. If we did not explicilty set
it, then testing there would fail.
* execute sh to source the script and call its main.
|
|
Apparently signals were crossed when this implementation was done.
Cloud-init was reading 'platform' in the environment of pid 1, but
nova-lxd was setting 'product_name'.
The fix is being made here in cloud-init to instead read product_name.
LP: #1685810
|
|
We were checking /var/lib/cloud/openstack/latest/meta_data.json instead
of /var/lib/cloud/seed/config_drive/openstack/latest/meta_data.json.
LP: #1673637
|
|
The reading of MAAS datasource configuration was simply broken.
it was looking in /etc/cloud/*maas*.cfg rather than
/etc/cloud/cloud.cfg.d/*maas*.cfg.
along side here there is also:
* doc improvement on check_config
* remove the path restrictions when searching for values in both
maas and ovf_vmware_guest_customization. that was done to improve
performance as check_config's parsing is slow.
* change to maas to search all config files rather than restricting
to a subset as it tried before. that was done for
* better variable names.
- rename path_cloud_confd to path_etc_cloud
- PATH_ETC_CLOUD: /etc/cloud
- PATH_ETC_CI_CFG: /etc/cloud/cloud.cfg
- PATH_ETC_CI_CFG_D: /etc/cloud/cloud.cfg.d
LP: #1677710
|
|
If the only the None datasource was listed in datasource_list, then
ds-identify would write a cloud.cfg witih:
datasource_list: [None, None]
The fix is to just append None if the list only has None.
|
|
OpenStack clouds installed with RedHat RDO have the nova product
configured in /etc/nova/release to be 'OpenStack Compute' rather than
upstream nova default of 'OpenStack Nova'.
This was first reported on Finnish provider Nebula (http://nebula.fi).
LP: #1675349
|
|
While documentation indicates that the smbios product name should
contain 'Google Compute Engine', experimentation and bug reports
indicate that is not always the case. The change here is to change
the check for GCE to also consider a serial number that starts with
'GoogleCompute-'.
Also, ds-identify was not currently searching for GCE if no config of
datasource_list was found. Most images have a datasource_list defined.
So update the list to include GCE.
LP: #1674861
|
|
This is thie cloud-init part of a fix to allow nova-lxd to provide
config drive data. The other part will be done in nova-lxd.
The agreement here is that nova-lxd will copy the contents of the
config drive to /config-drive in the container.
LP: #1673411
|
|
The path for checking presence of Bigstep datasource was simply wrong.
Set the correct path.
LP: #1674766
|
|
The script is written to have the protection of disabling filename
expansion (set -f) and explicitly enabling expansion when needed.
However, the check_config function failed to disable it after enabling.
|
|
Change policy so that 'report' can be overridden.
In xenial we had set the builtin default to be 'report', expecting
that Ubuntu core would install config that changed it to 'search'.
However, if report was already set, there was no way to unset it.
The change here is to make 'report' basically 'search-dryrun', so
that one or the other can be set.
The other change here is that report would actually exit disabled
if it did not find a datasource and notfound=disabled. That was
unexpected and would turn cloud-init off, which is not what we wanted.
Additionally, consistently use 'enabled' or 'disabled' versus
'enable' and 'disable'.
LP: #1669949
|
|
Rather than having the dscheck_Ec2 just know the setting, move
it up to a more formal declaration. This will make it look more
clean when a distro carries a patch to change it to warn.
|
|
On a 'not found' result, was not being written at all.
That had the unintended effect of '--force' not working.
Now, on a 'not found' result:
- if reporting: write the list as found (with just 'None').
- if not reporting: only report that there was nothing found.
this means that the warning cloud-init will write about ds-identify
failing to find a datasource will be written, but cloud-init will
still search its fully configured list.
|
|
Now, when ds-identify runs in report mode, it still writes to
/run/cloud-init.cfg as search does, but it will namespace the
result under the top level 'di_report' entry.
|
|
In the interest of speed I had skipped the parsing of
/etc/cloud/cloud.cfg for the ec2 strict_id setting. In hindsight
it seems reasonable for people to put settings there.
|
|
ovf_vmware_guest_customization defaults to true in cloud-init, meaning
that such customization is disabled. We just missed a return value
causing ovf_vmware_guest_customization to effectively default to on.
Also, when looking for setting look at /etc/cloud/cloud.cfg.
This had been omitted in interest of performance, but we should
be looking there.
|
|
cloud-init by default sets 'disable_vmware_customization' to True.
So in ds-identify, we will enable the ovf datasource if:
- virt is vmware
- 'libdeployPkgPlugin.so' exists as installed by vmware-tools or
open-vm-tools.
- disable_vmware_customization is configured to True
|
|
Brightbox will identify their platform to the guest by setting the
product serial to a string that ends with 'brightbox.com'.
LP: #1661693
|
|
Based on the setting Datasource/Ec2/strict_id, the datasource
will now warn once per instance.
|
|
ds-identify will now read this setting, and thus allow the user
to modify ds-identifies behavior via either:
1. builtin setting here cloud-init/ds-identify builtin
2. ds-identify config (/etc/cloud/ds-identify.cfg)
3. system config (/etc/cloud/cloud.cfg.d/*Ec2*.cfg)
4. kernel command line (ci.datasource.ec2.strict_id=true)
|
|
A check function that returns found or maybe can also now
return config that will be written to the resultant /run/cloud.cfg.
They do so by setting the variable _RET_excfg.
|
|
This just adds checking of the Ec2 seed directory.
|
|
The following can have cause issue:
FOO="bar ; wark"
showit() {
local b=$FOO
echo $b
}
4: local: ;: bad variable name
The answer is just to use more quotes.
|
