Age | Commit message (Collapse) | Author |
|
Add support for openstack's dynamic vendor data, which appears under openstack/latest/vendor_data2.json
This adds vendor_data2 to all pathways; it should be a no-op for non-OpenStack providers.
LP: #1841104
|
|
If cloud-init is enabled on VMware platform, cloud-init will wait until
its configuration file is ready and currently the max wait is 90
seconds by default. With our test, this configuration file should be
ready within 1 second, so change it to 15 seconds for better
performance. Also update the documentation about how to change the
default value in cloud-init configuration file.
|
|
|
|
This commit removes lines which are invalid configuration.
|
|
- use `sh` as highlight language of the code block
- change order so that the confusing indentation is less confusing
|
|
* pull ssh keys from imds first and fall back to ovf if unavailable
* refactor log and diagnostic messages
* refactor the OpenSSLManager instantiation and certificate usage
* fix unit test where exception was being silenced for generate cert
* fix tests now that certificate is not always generated
* add documentation for ssh key retrieval
* add ability to check if http client has security enabled
* refactor certificate logic to GoalState
|
|
Plus a minor formatting improvement.
|
|
Add support for VMware's vCD configuration setting DEFAULT-RUN-POST-CUST-SCRIPT.
When set True, it will default vms to run post customization scripts if the VM has not been configured in VMTools with "enable-custom-scripts" set False.
Add datasource documentation with a bit more context about this interaction on VMware products.
With this fix, the behavior will be:
* If VM administrator doesn't want others to execute a script on this VM, VMtools can set "enable-custom-scripts" to false from the utility "vmware-toolbox-cmd".
* If VM administrator doesn't set value to "enable-custom-scripts", then by default this script is disabled for security purpose.
* For VMware's vCD product , the preference is to enable the script if "enable-custom-scripts" is not set. vCD will generate a configuration file with "DEFAULT-RUN-POST-CUST-SCRIPT" set to true. This flag works for both VMware customization engine and cloud-init.
|
|
Also add landon912 to .github-cla-signers
|
|
|
|
LP: #1883666
|
|
* Document CloudStack data-server well-known hostname
* Document fallback to default gateway
* Add onitake to CLA signers list
|
|
I don't believe this has ever been supported, looking at the git
history, but it certainly isn't at the moment.
LP: #1875470
|
|
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.)
|
|
add SAP Converged Cloud as cloud provider
|
|
Add support for rendering secondary static IPv4/IPv6 addresses on
any NIC attached to the machine. In order to see secondary IP
addresses in Ec2 IMDS network config, cloud-init now reads metadata
version 2018-09-24. Metadata services which do not support the Ec2
API version will not get secondary IP addresses configured.
In order to discover secondary IP address config, cloud-init now
relies on metadata API Parse local-ipv4s, ipv6s,
subnet-ipv4-cidr-block and subnet-ipv6-cidr-block metadata keys to
determine additional IPs and appropriate subnet prefix to set for a
nic.
Also add the datasource config option apply_full_imds_netork_config
which defaults to true to allow cloud-init to automatically configure
secondary IP addresses. Setting this option to false will tell
cloud-init to avoid setting up secondary IP addresses.
Also in this branch:
- Shift Ec2 datasource to emit network config v2 instead of v1.
LP: #1866930
|
|
In cloud-init 19.2, we added the ability for cloud-init to detect
OpenStack platforms by checking for "OpenStack Compute" or "OpenStack
Nova" in the chassis asset tag. However, this was never reflected
in the documentation. This patch updates the datasources documentation
for OpenStack to reflect the possibility of using the chassis asset tag.
LP: #1669875
|
|
* cc_ssh: fix capitalisation of SSH
* doc: fix capitalisation of SSH
* cc_keys_to_console: fix capitalisation of SSH
* ssh_util: fix capitalisation of SSH
* DataSourceIBMCloud: fix capitalisation of SSH
* DataSourceAzure: fix capitalisation of SSH
* cs_utils: fix capitalisation of SSH
* distros/__init__: fix capitalisation of SSH
* cc_set_passwords: fix capitalisation of SSH
* cc_ssh_import_id: fix capitalisation of SSH
* cc_users_groups: fix capitalisation of SSH
* cc_ssh_authkey_fingerprints: fix capitalisation of SSH
|
|
|
|
Update ConfigDrive datasource documentation to point to the most recent
OpenStack documentation for ConfigDrive.
LP: #1852461
|
|
- rtd/index.rst: update sentence to read:
cloud-init will also parse and process any optional user data
- rtd/topics/datasources/rbxcloud.rst: fix rst link names to build
docs
- README.md:
- update travis badge url to project home: github/canonical/cloud-init
- update page title to:
Cloud-init official project upstream as of 11/2019
|
|
The Azure datasource was incorrectly listing the IP address. This
updates the address to match what is in the Azure provided IMDS
documentation.
LP: #1849508
|
|
e24cloud provides an EC2 compatible datasource.
This just identifies their platform based on dmi 'system-vendor'
having 'e24cloud'. https://www.e24cloud.com/en/ .
Updated chassis typo in zstack unit test docstring.
LP: #1696476
|
|
|
|
Resolve the following lints raised by 'make doc':
- doc/rtd/topics/datasources/zstack.rst:5: D001 Line too long
- doc/rtd/topics/datasources/zstack.rst:10: D001 Line too long
|
|
Zstack platform provides a AWS Ec2 metadata service, and
identifies their platform to the guest by setting the 'chassis asset tag'
to a string that ends with '.zstack.io'.
LP: #1841181
|
|
|
|
Oracle Cloud Infrastructure's Instance Metadata Service provides network
configuration information for non-primary NICs. This commit introduces
support, on Virtual Machines[0], for fetching that network metadata,
converting it to v1 network-config[1] and combining it into the network
configuration generated for the primary interface.
By default, this behaviour is not enabled. Configuring the Oracle
datasource to `configure_secondary_nics` enables it:
datasource:
Oracle:
configure_secondary_nics: true
Failures to fetch and generate secondary NIC configuration will log a
warning, but otherwise will not affect boot.
[0] The expected use of the IMDS-provided network configuration is
substantially different on Bare Metal Machines, so support for that
will be addressed separately.
[1] This is v1 config, because cloudinit.net.cmdline generates v1 config
and we need to integrate the secondary NICs into that configuration.
|
|
- dsidentify switches to the new Exoscale datasource on matching DMI name
- New Exoscale datasource added
Signed-off-by: Mathieu Corbin <mathieu.corbin@exoscale.ch>
|
|
NoCloud data source now accepts both 'cidata' and 'CIDATA'
as filesystem labels. This is similar to DataSourceConfigDrive's
support for 'config-2' and 'CONFIG-2'.
|
|
- Remove outdated waagent.conf recommendations
- Recommend using Provisioning.UseCloudInit
- Reorganise sections so walinuxagent recommendations are easier to find
|
|
AWS EC2 instances' network come in 2 basic flavors: Classic and VPC
(Virtual Private Cloud). The former has an interesting behavior of having
its MAC address changed whenever the instance is stopped/restarted. This
behavior is not observed in VPC instances.
In Ubuntu 18.04 (Bionic) the network "management" changed from ENI-style
(etc/network/interfaces) to netplan, and when using netplan we observe
the following block present in /etc/netplan/50-cloud-init.yaml:
match:
macaddress: aa:bb:cc:dd:ee:ff
Jani Ollikainen noticed in Launchpad bug #1802073 that the EC2 Classic
instances were booting without network access in Bionic after stop/restart
procedure, due to their MAC address change behavior. It was narrowed down
to the netplan MAC match block, that kept the old MAC address after
stopping and restarting an instance, since the network configuration
writing happens by default only once in EC2 instances, in the first boot.
This patch changes the network configuration write to every boot in EC2
Classic instances, by checking against the "vpc-id" metadata information
provided only in the VPC instances - if we don't have this metadata value,
cloud-init will rewrite the network configuration file in every boot.
This was tested in an EC2 Classic instance and proved to fix the issue;
unit tests were also added for the new method is_classic_instance().
LP: #1802073
Reported-by: Jani Ollikainen <jani.ollikainen@ik.fi>
Suggested-by: Ryan Harper <ryan.harper@canonical.com>
Co-developed-by: Chad Smith <chad.smith@canonical.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@canonical.com>
|
|
The change to datasources.rst here is obvious typo fix.
The change to azure is to reduce the two 'Customization' sections
to a single and clean up some other duplicate text.
|
|
Azure generates network configuration from the IMDS service and removes
any preexisting hotplug network scripts which exist in Azure cloud images.
Add a datasource configuration option which allows for writing a default
network configuration which sets up dhcp on eth0 and leave the hotplug
handling to the cloud-image scripts.
To disable network-config from Azure IMDS, add the following to
/etc/cloud/cloud.cfg.d/99-azure-no-imds-network.cfg:
datasource:
Azure:
apply_network_config: False
LP: #1798424
|
|
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.
|
|
OpenStack datasource is now discovered in init-local stage. In order to
probe whether OpenStack metadata is present, it performs a costly
sandboxed dhclient setup and metadata probe against http://169.254.169.254
for openstack data.
Cloud-init properly detects non-OpenStack on EC2, but it spends precious
time probing the metadata service also resulting in a confusing WARNING
log about 'metadata not present'. To avoid the wasted cycles, and
confusing warning, get_data will call a detect_openstack function to
quickly determine whether the platform looks like OpenStack before trying
to setup network to probe and crawl the metadata service.
LP: #1776701
|
|
Also document instance-data.json on the top-level datasource topic page.
|
|
Just add some documentation to readthedocs for AliYun.
|
|
Fix link to external openstack resource and to internal vendor data.
LP: #1721660
|
|
Add some minimal documentation for GCE datasource.
|
|
Add permitted keys to documentation on seeding NoCloud.
|
|
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
|
|
|
|
Add documentation for cloud-init networking configuration formats, default
behavior, policy and other specific details about how network config is
consumed and utilized.
|
|
The ConfigDrive datasource has read un-partitioned disks for quite
a while, but the documentation lagged behind.
LP: #1673818
|
|
* Fix small typo
* Fix ISO-Filename for consistency
|
|
This just fills out some of the documentation on the OpenStack datasource.
|
|
The biggest things here are:
* move doc/sources/*/README.rst to doc/rtd/topics/datasources
This gives each datasource a page in the rtd docs, which make
it easier to read.
* consistently use the same header style throughout.
As suggested at
http://thomas-cokelaer.info/tutorials/sphinx/rest_syntax.html
use:
# with overline, for parts
* with overline, for chapters
=, for sections
-, for subsections
^, for subsubsections
“, for paragraphs
Also, move and re-format vendor-data documentation to rtd.
|