| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
- Refactor both the base64 encoding and decoding into utility functions.
Also:
- Mechanically fix some other broken untested code.
|
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
* Temporarily skip the MAAS tests in py3 since they need to be ported to oauthlib.
|
| |/
|
|
|
|
| |
to be behind trunk.
`tox -e py27` passes full test suite. Now to work on replacing mocker.
|
| |
|
|
|
|
| |
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.
|
| |
|
| |
LP: #1316597
|
| | |
|
| |
|
|
|
|
| |
See LP: #1243287 for more information, but the easiest thing to do
here is just not run smartos on arm.
LP: #1243287
|
| |
|
|
| |
datasource for SmartOS runs. This patch creates the instance's directory.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
if write_boot_content is given somethign that starts with #!,
then there isn't a reason to invoke 'file' to tell us that it
starts with shebang.
This way, we only run file in 2 cases:
a.) binary content (don't really know if that is supported or not)
b.) magic "user meant to run this with /bin/bash but couldn't be bothered to
type that"
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
1. fixed conflation of user-data and cloud-init user-data. Cloud-init
user-data is now namespaced as 'cloud-init:user-data'.
2. user-scripts are now fetched from the meta-data service each boot and
executed as in the scripts directory
3. datacenter name is now namespaced as sdc:datacenter
4. user-scripts should be shebanged if there is no file magic
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
LP: #1236445
|
| |/ |
|
| |
|
|
|
| |
The use of availability-zone or availability_zone is provided by the base
classes's behavior.
|
| | |
|
| |
|
|
| |
makes it cloud agnostic.
|
| |
|
|
|
|
| |
Modified cc_mounts to identify whether ephermalX is partitioned.
Changed datasources for Azure and SmartOS to use 'ephemeralX.Y' format.
Added disk remove functionally
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also
* cloudinit/sources/DataSourceAzure.py: invalid xml in a file called
'ovfenv.xml' should raise BrokenAzureDatasource rather than
NonAzureDataSource
* cloudinit/sources/DataSourceSmartOS.py:
cloudinit/sources/DataSourceAzure.py
use 'ephemeral0' as the device name in builtin fs_setup
* tests/unittests/test_datasource/test_azure.py:
* always patch 'list_possible_azure_ds_devs' as it calls find_devs_with
which calls blkid, and dramatically was slowing down tests on my system.
* test_user_cfg_set_agent_command_plain:
fix this test to not depend on specific format of yaml.dumps().
* test_userdata_arrives: add a test that user-data makes it through
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we had this 'ephemeral_disk' entry in the datasource config
for Azure, and then we also copied some entries into the .cfg
for that datasource from the datasource config.
Ie, datasource['Azure']['disk_setup'] would be oddly copied
into the .cfg object that was returned by 'get_config_obj'
Now, instead, we have a BUILTIN_CLOUD_CONFIG, which has those same
values in it.
The other change here is that 'ephemeral_disk' now has no meaning.
Instead, we add a populated-by-default entry 'disk_aliases' to the
BUILTIN_DS_CFG, and then just return entries in it for
'device_name_to_device'
|
| |
|
|
|
|
|
|
|
|
| |
Changed cc_disk_setup to handle the file systems as a label, no longer
passing "log" around.
Tidied up the documentation to reflect the changes and made grammer,
spelling and improved the content a little.
Added disk_setup to the default modules list.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The most likely end user operation (or at least a valid one) for base64
encoding would be to encode the user-data, but leave all other values
as plaintext.
In order to facilitate that, the user can simply add:
b64-user-data=true
to indicate that user-data is base64 encoded.
Other changes here are to change the cloud-config and metadata keynames
that are used.
base64_all = boolean(True)
base64_keys = [list, of, keys]
Fixed up tests to accomodate.
|
| | |
|
| | |
|
| |
|
|
| |
Added documentation on SmartOS datasource.
|
| | |
|
| |
|
|
|
|
| |
initialized.
Added a mapping of attributes between cloud-init and smartos.
|
| | |
|
| |
|
