| Age | Commit message (Collapse) | Author |
|---|
|
The idea is that in the future, the DataSources get_data could
check to see if there were ssh keys provided. if there were, it could
poll and wait (or inotify) until the <fp>.crt files appeared in the
/var/lib/walinux directory. Once they did, it'd populate the metadata's
public keys.
|
|
|
|
|
|
|
|
Optical drives may show up in RHEL systems as /dev/sr1;
this extends a prior fix to handle that use case. It's applicable to systems
with 2.6 kernels where blkid needs a little prodding.
If we have to go back here with '/dev/sr2', then we should probably come
up with a fix that doesn't doesn't make us come back again.
|
|
This is not really a problem, because nothing would call transport_iso9660
with 'require_iso' as False, but if it did, then we would have still
required iso9660 filesystem on the mount.
|
|
Extend a prior fix which helped discovery of media on systems using 2.6
kernels. /dev/sr0 covers only some of the use cases, /dev/sr1 is also
common.
|
|
Couple of things here:
* do not re-try on user-data (404 means 'not here')
* re-generate headers on retry requests
LP: #1172742
|
|
|
|
This patch fixes issues in Fedora 18 (and upcoming RHEL 7) which are
present due to their use of systemd:
- store locale configuration in /etc/locale.conf
- store hostname in /etc/hostname
- use a symlink for /etc/localtime (prior code would set the timezone
but corrupt data in /usr/share/zoneinfo due to presence of symlink)
It also contains fixes for issues unrelated to systemd adoption:
- explicitly scan /dev/sr0 with blkid in order to get the optical drive
in the blkid cache. This prevents an issue on systems running 2.6
kernels (such as RHEL 6) in which config disks on some devices won't
be detected unless the device has previously been queried.
(For reference, see https://patchwork.kernel.org/patch/1770241/)
- append a newline when rewriting sysconfig files, as this is customary
text configuration file formatting and is expected by some parsers
(such as the ifcfg-rh plugin for NetworkManager)
|
|
cloudinit/sources/DataSourceCloudStack.py and
cloudinit/sources/DataSourceEc2.py are reverted entirely back to trunk versions
now, rather than the non-behavior change that was left in place.
Also, remove inadvertantly added trailing newline from cloudinit/ec2_utils.py
Overall, this just makes the diff when merged to trunk carry more focused
changes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Last addition to DataSourceNoCloud left it looking for a filesystem
named 'None'.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
LP: #1115833
|
|
previously, there was an attempt in the config drive source to limit
the source device to a "full block device" rather than a partition.
This was done by a simplistic approach of checking that the last
character of the name was not a number. That was filtering out
CD-rom devices (sr0).
Now, we have a bit more sophisticated approach to that same problem.
We filter out block devices that have a 'partition' entry in
/sys/class/block/DEVICE_NAME/partition .
LP: #1100545
|
|
Changes in revision 753 broke cloud-init on ubuntu, as it has a different
dhclient directory than Fedora where the change was developed and tested.
This change does 2 things:
* searches multiple directories (including /var/lib/dhcp) for the lease
files.
* adds a fallback to the old code path of choosing the default route
as the virtual router if there were no virtual routers found in the
lease files.
LP: #1089989
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In CloudStack's documentation, it is stated that meta/user-data can be
retrieved from CloudStack's Virtual Router [1].
However, cloud-init retrieves these information from default gateway. VR
and default gateway may be the same machine (i.e. have the same address)
in some cases, but that is not be always true (actually, in my case, it is
not).
This change searches the lease files in /var/lib/dhclient to pick out
the dhcp-server-identifier.
It admittedly does make this specific to dhclient.
--
[1] http://incubator.apache.org/cloudstack/docs/en-US/Apache_CloudStack/4.0.0-incubating/html/Admin_Guide/user-data-and-meta-data.html).
LP: #1089989
|
|
This does a couple things:
* separates out the 'normalize_public_keys' from the DataSource's get_public_ssh_keys
* uses that from config-drive datasource
* supports config drive v1 or v2 public-keys
* adds a test.
LP: #1077700
|
|
|
|
'public_keys'
|
|
|
|
other datasources populate 'public-keys' rather than 'public_keys'
and there is a more complete handler in the base DataSource.
So, to take advantage of that, have DataSourceConfigDrive copy
public_keys to public-keys, and remove the 'get_public_ssh_keys'
from the DataSourcEConfigDrive.
LP: #1077700
|
|
These changes were pulled out of the previous merge (cc_yum_add_repo)
as they were unrelated there. Re-applying them here.
|
