| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
1. Remove the usage of the path.join function
now that all code should be going through
the util file methods (and they can be
mocked out as needed).
2. Adjust all occurences of the above join
function to either not use it or replace
it with the standard os.path.join (which
can also be mocked out as needed)
3. Fix pylint from complaining about the
tests folder 'helpers.py' not being found
4. Add a pylintrc file that is used instead
of the options hidden in the 'run_pylint'
tool.
|
|
|
|
are used that lazily load the metadata from the
ec2 metadata service.
1. Add a ec2_utils module that checks which version
of boto is being used and under the right versions
the metadata dictionary will be expanded.
2. Use this new ec2_utils module in the cloudstack and ec2
datasources as there entrypoints into boto.
|
|
Use only util methods for reading/loading/appending/peeking
at files since it is likely soon that we will add a new
way of adjusting the root of files read, also it is useful
for debugging to track what is being read/written in a central
fashion.
|
|
to ensure that even if they are found that they
are also valid, before they are assumed to be
the correct device name.
|
|
Also fix the extraction of the metadata key name
since it actually uses 'dashes' instead of being
a single word.
|
|
translate the device name to a actual device using
logic that will try the ec2 metadata (if avail) or
will try using 'blkid' to find a corresponding label.
LP: #1062540
|
|
we map 'hostname' to 'local-hostname'
so that the modules work correctly with
the cfgdrive style of data.
|
|
|
|
|
|
This fixes (tested) bug 978127. The server was actually returning a 401
not a 403. As such, the fix here was insufficient. This will now take
either of those 2 error codes. I've also tested it by changing the clock
in the cloud-init upstart job with a stanza like below, and verifying
that we do see the problem and then it resolve itself:
pre-start script
offset="10 minutes ago"
past=$(date -R --date "$offset")
date --set "$past" &&
echo ===== "set date to $past [$offset]" ===== ||
echo ===== "failed to set date to $past [$offset]" ====
end script
LP: #978127
|
|
|
|
|
|
In the event of a 403 (Unauthorized) in oauth, try set a 'oauth_clockskew'
variable. In future headers, use a time created by 'time.time() +
self.oauth_clockskew'. The idea here is that if the local time is bad (or even
if the server time is bad) we will essentially use something that should be
similar to the remote clock.
This fixes LP: #978127.
LP: #978127
|
|
|
|
|
|
at files since it is likely soon that we will add a new
way of adjusting the root of files read, also it is useful
for debugging to track what is being read/written in a central
fashion.
|
|
|
