| Age | Commit message (Collapse) | Author |
|---|
|
This allows a single file to declare and activate this data source.
This could come from:
* cloud-config-url on kernel cmdline
* /etc/cloud/cloud.cfg.d
* debian preseed of 'cloud-init/local-cloud-config'
Also here is
* some tests
* a small fix to parse_cmdline_data found when writing those tests.
LP: #1115833
|
|
Add a base set for ec2 and datasource none.
|
|
Start moving the current README for
datasources to a RST format and include
those files in the rtd site.
LP: #1113650
|
|
LP: #1115833
|
|
The write_files documentation incorrectly used 'perms' rather than
'permissions'.
LP: #1111205
|
|
This change adds the ability to provide specific package versions to
Distro.install_packages and subsequently Distro.package_command. In order
to effectively use Distro.install_packages, one is now able to pass a
variety of formats in order to easily manage package requirements.
These are examples of what can be passed:
- "package"
- ["package1","package2"]
- ("package",)
- ("package", "version")
- [("package1",)("package2",)]
- [("package1", "version1"),("package2","version2")]
This change also adds the option to install a specific version for the
puppet configuration module. This is especially important here as
successful puppet deployments are highly reliant on specific puppet
versions.
|
|
Augmenting the package version support to be available when specifying
extra packages to be installed at boot via the 'packages:' yaml key. This
change also improves type checking and add a configuration example to the
docs.
|
|
|
|
|
|
|
|
Managing resolv.conf can be quite handy when running in an environment
where you would like to control DNS resolution, despite being provided
DNS server information by DHCP. This module will allow one to define the
structure of their resolv.conf and write it PER_ONCE.
Right now this makes the most sense on RedHat, and therefore, has defined 'distros' as such.
Note that when a config drive is used, and dhcp is not used that this module
may not be applicable since in the RedHat based distros the config drive typically
contains a ubuntu style network configuration which contains nameservers that can
be used in /etc/resolv.conf, but for other types of datasources it is useful to
have a module which can be specifically configured to write out /etc/resolv.conf
|
|
As per harlowja's suggestion addding an example to the doc directory for
cc_resolv_conf.py
|
|
|
|
|
|
|
|
Include a new set of docs that can be used to
create a readthedocs.org site, which includes
examples, directory layout, capabilities and
such. This in-code documentation then allows
for readthedocs.org to create a website directly
from the cloud-init codebase.
|
|
Thanks to Anatoliy Dobrosynets
|
|
|
|
This allows the user to easily run stuff even after cloud-init-final
has finished. The initial reason for it is to be able to run
/sbin/poweroff and not have cloud-init complain loudly that it is
being killed.
LP: #1064665
|
|
|
|
and fix the cases where the cc yaml
is not correct.
|
|
2. Added example cloud-config
3. Added functioning test for yum config
|
|
|
|
Remove the need to have 'default_user' and 'default_user_groups' groups be
hard coded into the distro class, instead let that set of configuration be
located in the config file where it should be specified instead.
|
|
|
|
responsible only for creating users and groups and
normalizing a input configuration into a normalized
format that splits up the user list, the group list
and the default user listsand let the add user/group config
module handle calling those methods to add its own users/groups
and the default user (if any).
2. Also add in tests for this normalization process to ensure
that it is pretty bug free and works with the different types
of formats that users/groups/defaults + options can take.
|
|
LP: #1042764
|
|
|
|
support in a cloud-archive format as well as a cloud-config
format and explain how this will affect the final userdata
available to an instance.
|
|
|
|
on Ubuntu systems via cloud-config (LP: #1041384).
- Fixed bug with user creation on Ubuntu where the default user groups are
not set properly (LP: #1044044).
- Fixed documentation for user creation (LP: #1044508).
|
|
move the section on user and group adds into
doc/examples/cloud-config-user-groups.txt
|
|
configurations were applied. The result of this bug was that cloud-config
supplied SSH public keys would fail to apply since the configured user
may or may not exist. (LP: #1042459).
cloudinit/config/cc_ssh_import_id.py:
ssh_import_id.py now handles all user SSH import IDs.
cloudinit/distros/ubuntu.py:
Removed create_user class override as cruft, since ssh_import_id
now handles all users.
config/cloud.cfg:
Moved users_groups to run under cloud_init_modules.
doc/examples/cloud-config.txt:
Added missing documentation on user and group creation.
|
|
Added "userless" mode to cloud-init for handling the creation of the users
and the default user on Ubuntu. The end goal of this is to remove the need
for the 'ubuntu' user in the cloud images and to allow individuals to
choose the default user name.
LP: #1028503
|
|
users and the default user on Ubuntu.
cloudinit/config/cc_users_groups.py: new cloud-config module for creating
users and groups on instance initialization.
- Creates users and group
- Sets "user" directive used in ssh_import_id
cloudinit/config/cc_ssh_import_id.py: module will rely upon users_groups
for setting the default user. Removed assumption of 'ubuntu' user.
cloudinit/distros/__init__.py: Added new abstract methods for getting
and creating the default user.
cloudinit/distros/ubuntu.py: Defined abstract methods for getting and
and creating the default 'ubuntu' user on Ubuntu instances.
cloudinit/util.py: Added ability to hide command run through util.subp to
prevent the commands from showing in the logs. Used by user_groups
cloud-config module.
config/cloud.cfg: Removed "user: ubuntu" directive and replaced with new
user-less syntax.
doc/examples/cloud-config.txt: Documented the creation of users and groups.
|
|
Each datasource had a bit of doc with it, and those were just
landing in doc/. I've moved them to doc/sources now.
|
|
These changes add a new data source to cloud-init to support passing user
data to RHEVm and vSphere. The user data is passed to RHEVm v3.0 (current
version) using a floppy injection hook and to vSphere via cdrom device.
RHEVm v3.1 will use a method similar to vSphere. Once available support
for that is also expected.
|
|
As described in the bug, enough non-cloud users experienced issues with
cloud-init selecting a mirror due to consumer level network providers using
dns server redirection.
We're turning this off by default.
LP: #974509
|
|
|
|
This implements file writing via cloud-config. It also
* adjusts other code to have user/group parsing in util instead
of in stages.py,
* renames decomp_str to decomp_gzip since it is more meaningful when named
that (as thats all it can decompress).
LP: #1012854
|
|
Adjust the examples file to reflect this.
|
|
happens first, which will examine the incoming encoding, and decide the
neccasary decoding types needed to get the final resultant string and
then use these normalized decoding types to actually do the final decode.
Also change the name of the config key that is looked up to 'write_files'
since 'files' is pretty generic and could have clashes with other modules.
Add an example that shows how to use this in the different encoding formats
that are supported.
|
|
cloud-init expands $RELEASE in a source so it can easily be used.
|
|
|
|
|
|
Also added some comments and captured the output
|
|
What this does is provide an second DataSource that could use the
kernel command line url=. For example:
ro root=/dev/vda url=http://example.com/i-abcdefg/
http://example.com/i-abcdefg/ would contain:
datasource:
NoCloud:
# default seedfrom is None
# if found, then it should contain a url with:
# <url>/user-data and <url>/meta-data
# seedfrom: http://my.example.com/i-abcde
seedfrom: http://example.com/i-abcdefg/
Then, the NoCloudNet DataSource would find that seedfrom config
and consume data at
http://example.com/i-abcdefg/user-data
and
http://example.com/i-abcdefg/meta-data
|
|
|
|
|
|
instead of MaaS or Maas, use MAAS consistently.
The only non 'MAAS' left are all lower case.
|
