If the partition cannot grow, then growpart will exit with 1 and
emit the NOCHANGE message to stdout. Allow growpart to exit
0 or 1 so we can parse the output for these expected scenarios.
All other exit codes are growpart exceptions. Add unittest for
both the changed and nochanged scenarios through the resize() method.
cc_growpart: refactor ResizeGrowPart to parse output
Now that we're logging growpart output, utilize this data to report the
before, after size values of the device after resizing. Add a get_size
method to the Resize objects, Gpart retains use of the original get_size
method which opens and seeks to end of the file. For growpart we drop
the --dry-run, and instead capture the stdout, stderr of the result and
parse the before and after size values from there.
Add a unittest to verify parsing and error handling.
cc_growpart: Add verbosity, locking and realpath translation
Growpart has its own internal logic for selecting which underlying
tools to use to modify the target device partition table. This
information is not visible in cloud-init logging which makes it difficult
to understand what may have occurred when debugging. Adding the
'--verbose' flag and logging the output will emit useful information
about which tool was used (sfdisk vs. sgdisk).
On some platforms the target device may point to a symbolic link,
e.g. /dev/disk/by-partuuid/XXXX; These symbolic links may be
unavailable during partition changes due to udev behavior. Use
os.path.realpath to expand the symbolic links to the real device
path (e.g. /dev/sda1) as this value use used in the get_size() method
cc_growpart uses to compare before and after device values.
Lastly get_size() will now make use of flock (1) to take a shared
lock against the device it will attempt to obtain the size preventing
cc_growpart from reading the size value while udev or other processes
are making changes.
azurecloud: fix issues with instances not starting (#205)
The azurecloud platform did not always start instances
during collect runs. This was a result of two issues. First
the image class _instance method did not invoke the start()
method which then allowed collect stage to attempt to run
scripts without an endpoint. Second, azurecloud used the
image_id as both an instance handle (which is typically
vmName in azure api) as well as an image handle (for image
capture). Resolve this by adding a .vm_name property to
the AzureCloudInstance and reference this property in
AzureCloudImage.
Also in this branch
- Fix error encoding user-data when value is None
- Add additional logging in AzureCloud platform
- Update logging format to print pathname,funcName and line number
This greatly eases debugging.
