| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
might have to rewrite this for Python 2.6.
Disable Cepko tests (test_cs_util.py) since they are essentially worthless.
Convert test_azure to unittest.mock.
|
|
to be behind trunk.
`tox -e py27` passes full test suite. Now to work on replacing mocker.
|
|
|
|
|
|
|
|
just so we don't come to rely on it being set to 'base64' or ''.
rather the default case is that it wont be present at all.
|
|
|
|
--ignore was being called with ',E121,E...' rather than
'E121,E...'.
that resulted in odd behavior, missing the pep8 errors that are fixed
here.
|
|
|
|
|
|
This adds a DataSource for DigitalOcean's metadata service. The service is
documented at https://developers.digitalocean.com/metadata/ .
|
|
|
|
|
|
|
|
|
|
There are a couple new test cases that are now erroring out.
- A usage of the non helper unit testcase base which is trigging
and error on python 2.6 due to lack of method, fix this by using
the base helper class.
- A freebsd distro test check thats looking for /etc/resolv.conf and
examining its contents, which won't exist due to our mocking routine
that does not allow that file to be read.
- A freebsd distro test where the distro class tries to call into
['ifconfig', '-a'] for a set of values, those values don't exist on
the machine I am running on (and likely others machines) so we should
mock the subp function out (that the distro class calls) and correctly
return values that will work for the testcase.
|
|
For now, this vendor data handling is just added to openstack.
However, in an effort to allow sanely handling of multi-part vendor-data
that is namespaced, we add openstack.convert_vendordata_json .
That basically takes whatever was loaded from vendordata and takes
the 'cloud-init' key if it is a dict. This way the author can
namespace cloud-init, basically telling it to ignore everything else.
|
|
instead of taking a version that they should look for,
the readers now just select the highest supported version.
definitely a use case later for having version= but nothing
is using it now.
|
|
make pyflakes now passes.
|
|
|
|
|
|
Fixed all complaints from running "make pep8". Also version locked
pep8 in test-requirements.txt to ensure that pep8 requirements don't
change without an explicit commit.
|
|
This change works around a bug in CloudStack's EC2 api implementation.
That is filed upstream at [1].
The fix is safe for openstack and EC2 use cases as well.
EC2 and OpenStacks' EC2 metadata service both return a list with
access to either of:
<url_base>/latest/meta-data
<url_base>/latest/meta-data/
Additionally, the responses explicitly contain a trailing '/' for
items that have a child. The ec2_utils code then just re-uses the trailng
/ there. Thus, only the top level request for 'meta-data/' needs
the explicit fix.
This also changes test cases. Those test cases failed without fixing
them. If ever this regressed, those would fail again.
--
[1] https://issues.apache.org/jira/browse/CLOUDSTACK-7405
LP: #1356855
|
|
|
|
previously this would fail:
http_proxy=http://foo.bar make test
now it will pass. This works around a bug where httpretty is not able to
patch http operations if http_proxy is set.
https://github.com/gabrielfalcao/HTTPretty/issues/122
|
|
|
|
|
|
A few of the current tests have been continually failing
in python 2.6 based systems, due to lack of unit test
functions that are now added to ensure we can run the
unit tests (and not have to ignore those failures) on
python 2.6
|
|
LP: #1316597
|
|
On systems with a ttyS1 and nothing attached, the read attempts
that the cloud sigma datasource would do would block.
Also, Add timeouts for reading/writting from/to the serial console
LP: #1316475
|
|
LP: #1303986
|
|
|
|
|
|
|
|
Instead of just trying to see if userdata decodes as the indication that
it should be encoded, the user must explicitly set this.
The "just try it" will fail in the case where the user had other use
of user-data and wanted a blob of data to go through unrecognized by
cloud-init.
In cases where there can be mistake in automatic behavior,
and some users may be relaying on old behavior, its best to just require
explicit use.
|
|
|
|
This adds the ability to read a 'base64_fields' entry in the metadata,
and if cloud-init-userdata is listed in that, then content will be
base64 decoded first.
|
|
Similar test-hack as the SmartOS one.
Here we just pretend that we're running on x86_64 so as to avoid
re-writing the tests to expect otherwise on arm.
|
|
|
|
|
|
See LP: #1243287 for more information, but the easiest thing to do
here is just not run smartos on arm.
LP: #1243287
|
|
This test case isn't really valid any more as we've changed
the way this works.
|
|
This allows users of CloudSigma's VM to encode their user data with base64.
In order to do that thet have to add the ``cloudinit-user-data`` field to
the ``base64_fields``. The latter is a comma-separated field with
all the meta fields whit base64 encoded values.
|
|
This reduces how much cloud-init is explicitly involved in what "vendor-data"
could accomplish. The goal of vendor-data was to provide the vendor with a
channel to run arbitrary code that accomodate for their specific platform.
Much of those accomodations are currently being done in cloud-init.
However, this now moves some of those things to default "vendor-data", instead
of cloud-init proper.
Basically, now we have an 'sdc:vendor-data' key in the metadata.
If that does not exist, then cloud-init will use the default.
The default, provides a boothook. That boothook writes a file into
/var/lib/cloud/per-boot/ . That file will be both written on every boot
and then executed at rc.local time frame (by 'scripts-per-boot').
It will then execute /var/lib/cloud/instance/data/user-script
and /var/lib/cloud/instance/data/operator-script if they exist.
So, the things that cloud-init is now doing outside of the default vendor-data
that I would rather be done in vendor-data is:
* managing the population of instance/data/user-script and
instance/data/operator-script. These could very easily be done
from the boothook, but doing them in cloud-init removes the necessity
for having a 'mdata-get' command in the image (or some other way for
the boothook script to query the datasource).
* managing the LEGACY things.
|
|
|
|
default #cloud-config that writes per-boot script that fetches subsequent
sdc:operator-scripts and executes it.
|
