223.2.4
by Scott Moser
* New upstream snapshot. |
1 |
- Consider a 'failsafe' DataSource |
60.1.14
by Scott Moser
* New upstream release. |
2 |
If all others fail, setting a default that |
3 |
- sets the user password, writing it to console |
|
4 |
- logs to console that this happened |
|
223.2.4
by Scott Moser
* New upstream snapshot. |
5 |
- Consider a 'previous' DataSource |
60.1.14
by Scott Moser
* New upstream release. |
6 |
If no other data source is found, fall back to the 'previous' one |
7 |
keep a indication of what instance id that is in /var/lib/cloud |
|
223.2.4
by Scott Moser
* New upstream snapshot. |
8 |
- Rewrite "cloud-init-query" (currently not implemented) |
9 |
Possibly have DataSource and cloudinit expose explicit fields |
|
60.1.14
by Scott Moser
* New upstream release. |
10 |
- instance-id |
11 |
- hostname |
|
12 |
- mirror |
|
13 |
- release |
|
14 |
- ssh public keys |
|
223.2.4
by Scott Moser
* New upstream snapshot. |
15 |
- Remove the conversion of the ubuntu network interface format conversion |
16 |
to a RH/fedora format and replace it with a top level format that uses |
|
17 |
the netcf libraries format instead (which itself knows how to translate |
|
18 |
into the specific formats) |
|
19 |
- Replace the 'apt*' modules with variants that now use the distro classes |
|
20 |
to perform distro independent packaging commands (where possible) |
|
21 |
- Canonicalize the semaphore/lock name for modules and user data handlers |
|
22 |
a. It is most likely a bug that currently exists that if a module in config |
|
23 |
alters its name and it has already ran, then it will get ran again since |
|
24 |
the lock name hasn't be canonicalized |
|
25 |
- Replace some the LOG.debug calls with a LOG.info where appropriate instead |
|
26 |
of how right now there is really only 2 levels (WARN and DEBUG) |
|
27 |
- Remove the 'cc_' for config modules, either have them fully specified (ie |
|
28 |
'cloudinit.config.resizefs') or by default only look in the 'cloudinit.config' |
|
29 |
for these modules (or have a combination of the above), this avoids having |
|
30 |
to understand where your modules are coming from (which can be altered by |
|
31 |
the current python inclusion path) |
|
32 |
- Depending on if people think the wrapper around 'os.path.join' provided |
|
33 |
by the 'paths' object is useful (allowing us to modify based off a 'read' |
|
34 |
and 'write' configuration based 'root') or is just to confusing, it might be |
|
35 |
something to remove later, and just recommend using 'chroot' instead (or the X |
|
36 |
different other options which are similar to 'chroot'), which is might be more |
|
37 |
natural and less confusing... |
|
223.3.7
by Scott Moser
* New upstream snapshot. |
38 |
- Instead of just warning when a module is being ran on a 'unknown' distribution |
39 |
perhaps we should not run that module in that case? Or we might want to start |
|
40 |
reworking those modules so they will run on all distributions? Or if that is |
|
41 |
not the case, then maybe we want to allow fully specified python paths for |
|
42 |
modules and start encouraging packages of 'ubuntu' modules, packages of 'rhel' |
|
43 |
specific modules that people can add instead of having them all under the |
|
44 |
cloud-init 'root' tree? This might encourage more development of other modules |
|
45 |
instead of having to go edit the cloud-init code to accomplish this. |
|
46 |