| Age | Commit message (Collapse) | Author |
|---|
|
The end result of all of these changes is to get mounts managed by
cloud-init to occur only after cloud-init.service is done. We need to do
that so that filesystems that are set up by cloud-init (in disk_setup)
do not get mounted by stale entries in /etc/fstab before
the setup occurs.
This can occur in 2 ways:
a.) new instance with old /etc/fstab
b.) same instance where disk needs adjusting (Azure resize will re-format
the ephemeral disk).
The list of changes here is:
- move mounts and disk_setup module to cloud-init.service rather
than config. cloud-init.service runs earlier in boot so it
can get those mount points done earlier.
- on systemd add 'x-systemd.requires=cloud-init.service' to fstab options
- cloud-init-local.service: add Before=basic.target
- cloud-init.service:
- extend After, Before, and Wants to multiple lines rather than one
long line.
- sort consistently with cloud-init-local.service
- add DefaultDependencies=no
- add Before=default.target
- add Conflicts=shutdown.target
LP: #1611074
|
|
This adds some function to the generator to maintain the presense of a
flag file '/run/cloud-init/enabled' indicating that cloud-init is enabled.
Then, only run the dhclient hooks if on Azure and cloud-init is enabled.
The test for is_azure currently only checks to see that the board vendor
is Microsoft, not actually that we are on azure. Running should not be
harmful anywhere, other than slowing down dhclient.
The value of this additional code is that then dhclient having run
does not task the system with the load of cloud-init.
Additionally, some changes to config are done here.
* rename 'dhclient_leases' to 'dhclient_lease_file'
* move that to the datasource config (datasource/Azure/dhclient_lease_file)
Also, it removes the config in config/cloud.cfg that set agent_command
to __builtin__. This means that by default cloud-init still needs
the agent installed. The suggested follow-on improvement is to
use __builtin__ if there is no walinux-agent installed.
|
|
It is more efficient and cross-distribution safe to use the hooks function
from dhclient to obtain the Azure endpoint server (DHCP option 245).
This is done by providing shell scritps that are called by the hooks
infrastructure of both dhclient and NetworkManager. The hooks then
invoke 'cloud-init dhclient-hook' that maintains json data
with the dhclient options in
/run/cloud-init/dhclient.hooks/<interface>.json .
The azure helper then pulls the value from
/run/cloud-init/dhclient.hooks/<interface>.json file(s). If that file does
not exist or the value is not present, it will then fall back to the
original method of scraping the dhcp client lease file.
|
|
|
|
|
|
|
|
Changing this interface to allow for easy change later.
The thing that this will enable is:
a.) maas datasource to look at the system config and see if it
is configured with the same consumer_key
b.) datasource config could allow setting a variable that it
would look at.
|
|
This adds a check in cloud-init to see if the existing (cached)
datasource is still valid. It relies on support from the Datasource
to implement 'check_instance_id'. That method should quickly determine
(if possible) if the instance id found in the datasource is still valid.
This means that we can still notice new instance ids without
depending on a network datasource on every boot.
I've also implemented check_instance_id for the superclass and for
3 classes:
DataSourceAzure (check dmi data)
DataSourceOpenstack (check dmi data)
DataSourceNocloud (check the seeded data or kernel command line)
LP: #1553815
|
|
Update make check target to run pep8 and run pyflakes or pyflakes3
depending on the value of 'PYVER'. This way the python3 build
environment does not need python2 and vice versa.
Also have make check run the 'yaml' test.
tox: have tox run pep8 in the pyflakes
|
|
|
|
This replaces the use of SharedConfig.xml in both the walinuxagent case,
and the case where we communicate with the Azure fabric ourselves.
|
|
Azure has or will be offering shortly the ability to directly define the SSH
key value instead of a fingerprint in the ovf-env.xml file. This patch
favors defined SSH keys over the fingerprint method (LP: #1506244).
|
|
Azure has or will be offering shortly the ability to directly define the SSH
key value instead of a fingerprint in the ovf-env.xml file. This patch
favors defined SSH keys over the fingerprint method (LP: #1506244).
|
|
Azure's ephemeral disks are not guaranteed to be assigned the same name by
the kernel every boot. This causes problems on ~2% of Azure instances, and
can be fixed by using udev rules to give us a deterministic path to mount;
this patch introduces those udev rules and modifies the Azure data source
to use them.
Changes to a couple of config modules were also required. In some places,
they just needed to learn to dereference symlinks. In cc_mounts this
wasn't sufficient because the dereferenced device would have been put in
/etc/fstab (rather defeating the point of using the udev rules in the
first place). A fairly hefty refactor was required to separate "is this a
valid block device?" from "what shall I put in fstab?".
LP: #1411582
|
|
|
|
The ephemeral disk will not necessarily be assigned the same name at
each boot (LP: #1411582), so we use some udev rules to ensure we always
get the right one.
|
|
The fabric provides the user password in plain text via the CDROM,
and cloud-init has previously wrote the ovf-env.xml in /var/lib/waagent
with the password in plain text. This change redacts the password.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Including minor refactoring to make mocking considerably easier.
|
|
This should fix the Azure data source on Python 3, and is appropriate as
XML shouldn't really be read as a string.
|
|
Specifically, this is to support Azure's G-series VMs (which come with
disks up to 6500GB).
|
|
|
|
|
|
|
|
Fixed all complaints from running "make pep8". Also version locked
pep8 in test-requirements.txt to ensure that pep8 requirements don't
change without an explicit commit.
|
|
|
|
|
|
|
|
per instance. Under a variety of circumstances, the ephemeral device may
be presented as a default device. This patch detects when that situation
happens and triggers CC modules disk-setup and mounts to run again.
Details of changes for cloudinit/sources/DataSourceAzure.py:
- auto-detect the location of ephemeral0
- check each boot if ephemeral0 is new
- done via NTFS w/ label of "Temporary Storage" w/ no files on it
- if device is mounted, datasource will unmount it
- if is new, change mounts and disk-setup to always for that boot only
|
|
|
|
|
|
|
|
as the previous instance (LP: #1269626).
|
|
We were passing a unicode string to 'runcmd' in the path to the .crt file.
That is because the keyname was coming from ovf file as unicode.
Ie:
u'/var/lib/waagent/6BE7A7C3C8A8F4B123CCA5D0C2F1BE4CA7B63ED7.crt'
Then, logging was extending not appending errors.
|
|
LP: #1232175
|
|
makes it cloud agnostic.
|
|
Modified cc_mounts to identify whether ephermalX is partitioned.
Changed datasources for Azure and SmartOS to use 'ephemeralX.Y' format.
Added disk remove functionally
|
|
in general block device mappings should be to block devices, not
partitoins.
|
|
Also
* cloudinit/sources/DataSourceAzure.py: invalid xml in a file called
'ovfenv.xml' should raise BrokenAzureDatasource rather than
NonAzureDataSource
* cloudinit/sources/DataSourceSmartOS.py:
cloudinit/sources/DataSourceAzure.py
use 'ephemeral0' as the device name in builtin fs_setup
* tests/unittests/test_datasource/test_azure.py:
* always patch 'list_possible_azure_ds_devs' as it calls find_devs_with
which calls blkid, and dramatically was slowing down tests on my system.
* test_user_cfg_set_agent_command_plain:
fix this test to not depend on specific format of yaml.dumps().
* test_userdata_arrives: add a test that user-data makes it through
|
|
Previously we had this 'ephemeral_disk' entry in the datasource config
for Azure, and then we also copied some entries into the .cfg
for that datasource from the datasource config.
Ie, datasource['Azure']['disk_setup'] would be oddly copied
into the .cfg object that was returned by 'get_config_obj'
Now, instead, we have a BUILTIN_CLOUD_CONFIG, which has those same
values in it.
The other change here is that 'ephemeral_disk' now has no meaning.
Instead, we add a populated-by-default entry 'disk_aliases' to the
BUILTIN_DS_CFG, and then just return entries in it for
'device_name_to_device'
|
