~ubuntu-branches/ubuntu/saucy/cloud-init/saucy

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