| Age | Commit message (Collapse) | Author |
|---|
|
Thanks to [1], the hostname is set prior to network bring-up.
The Azure data source has been bouncing the hostname during
setup(), occurring after the hostname has already been
properly configured.
Note that this doesn't prevent leaking the image's hostname
during Azure's _get_data() when it brings up ephemeral DHCP.
However, as are not guaranteed to have the hostname metadata
available from a truly "local" source, this behavior is to
be expected unless we disable `send host-name` from dhclient
config.
[1]: https://github.com/canonical/cloud-init/commit/133ad2cb327ad17b7b81319fac8f9f14577c04df
Signed-off-by: Chris Patterson <cpatterson@microsoft.com>
|
|
Some references were missed in the removal of the agent command
in PR #799. This simply removes the remaining references.
Signed-off-by: Chris Patterson <cpatterson@microsoft.com>
|
|
Also update all examples to include the cloud-config header if they don't have it
LP: #1876414
|
|
This proposal has been aligned in a human readable.
There are no changes to this except for spac
The indentation size is not specifically defined in the YAML RFC
$ make yaml has passed on my-machine
I set the indentation size to the largest number of articles in the repository (dictionary: 2)
(And also include nishigori as a CLA signer.)
|
|
|
|
LX-brand zones on Joyent's SmartOS use a different metadata source
(socket file) than the KVM-based SmartOS virtualization (serial port).
This patch adds support for recognizing the different flavors of
virtualization on SmartOS and setting up a metadata source file object.
After the file object is created, the rest of the code for the datasource
LP: #1540965
|
|
|
|
The most likely end user operation (or at least a valid one) for base64
encoding would be to encode the user-data, but leave all other values
as plaintext.
In order to facilitate that, the user can simply add:
b64-user-data=true
to indicate that user-data is base64 encoded.
Other changes here are to change the cloud-config and metadata keynames
that are used.
base64_all = boolean(True)
base64_keys = [list, of, keys]
Fixed up tests to accomodate.
|
|
|
|
See the added doc/sources/azure/README.rst for why this is necessary.
Essentially, we now are doing the following in the get_data() method
of azure datasource to publish this NewHostname:
hostname NewHostName
ifdown eth0;
ifup eth0
LP: #1202758
|
|
|
|
|
|
|
|
LP: #1115833
|
|
What this does is provide an second DataSource that could use the
kernel command line url=. For example:
ro root=/dev/vda url=http://example.com/i-abcdefg/
http://example.com/i-abcdefg/ would contain:
datasource:
NoCloud:
# default seedfrom is None
# if found, then it should contain a url with:
# <url>/user-data and <url>/meta-data
# seedfrom: http://my.example.com/i-abcde
seedfrom: http://example.com/i-abcdefg/
Then, the NoCloudNet DataSource would find that seedfrom config
and consume data at
http://example.com/i-abcdefg/user-data
and
http://example.com/i-abcdefg/meta-data
|
|
instead of MaaS or Maas, use MAAS consistently.
The only non 'MAAS' left are all lower case.
|
|
|
|
|
|
This increases the timeout for a metadata request to something that should
be easily satisfiable (50 seconds). But hopefully does so while still keeping
the case of no-metadata service in mind.
Previously, there was a small timeout and many retries (30) would be done.
Now,
- larger timeout (50 seconds) by default
- retry until a given "max_wait" is reached (120 seconds default)
The end result is that if we're hitting the timeout, there will only end up
being a couple attempts made. But if the requests are coming back quickly
then we'll still make several attempts.
There is one EC2DataSource config change, now 'retries' is not used, but rather
'max_wait' to indicate generally how long it should try to find a metadata
service.
|
|
|
|
|
|
|
|
This lowers the default retries from 100 to 30 (1050 seconds to 105 seconds)
|
