| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
userdata and metadata. Add in this crawling functionality
to the ec2_utils module that will fully crawl (not lazily)
the ec2 metadata and parse it in the same manner as boto.
1. Make the ec2 datasource + cloudstack now call into these.
2. Fix phone_home due to urllib3 change (TBD)
|
|
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.
|
|
|
|
EC2 and openstack provide 'launch_index' in their metadata. This allows
the user to specify cloud-config or multipart mime data that includes the
'Launch-Index' header.
If launch index is available in the metadata service, then:
* any part that contains a launch index other than the current launch-index
of this instance will be ignored.
* any part that does not contain a launch index will be considered as
for this instance.
If there is no such header, or launch_index is not available in the metadata
service, then no such filtering will be done.
LP: #1023177
|
|
can contain filters that serve this purpose only and add in
the initial launch-index filter and replace the code in
the datasource class that previously did this.
|
|
In searching for the metadata service, require 'instance-data' to be at the top
level domain. Previously any misconfigured 'search' in /etc/resolv.conf could
result in unintended use of a metadata server.
LP: #1040200
|
|
variable has a little more meaning and by default look in
metadata for 'launch-index' and have ec2 instead look for
a different variable (thus allowing more datasources to just work).
|
|
before we look into the payload as well as make the skip
test a function that the datasource module can also use.
|
|
|
|
userdata based on a launch-index (or leave userdata
alone if none is provided by the datasource). This
works by doing the following.
1. Adjusting the userdata processor to attempt to
inject a "Launch-Index" header into the messages
headers (by either taking a header that already exists
or by looking into the payload to see if it exists
there).
2. Adjust the get_userdata ds function to apply a filter
on the returned userdata (defaulting to false) that
will now use the datasources get_launch_index value
to restrict the 'final' message used in consuming
user data (the same behavior if not existent).
3. Further down the line processes that use the 'resultant'
userdata now will only see the ones for there own launch
index (ie cloud-config will be restricted automatically
and so on) and are unaffected (although they can now
ask the cloud object or the datasource for its launch index
via the above new ds method.
|
|
If 'latest' is found, but '2012-08-10' is not, we will log a warning
but attempt to use it.
|
|
at the point where we are getting the previous instance id, there
cloud-init hasn't performed the move yet. Therefore, the "previous"
is the one that /var/lib/cloud/data/ says is the current.
|
|
openstack metadata uses 'uuid' as an instances 'instance-id'.
just copy that to the metadata['instance-id']
|
