cloud-init-dev team mailing list archive

[Joshua Harlow <harlowja@xxxxxxxxx>]

Joshua Harlow has proposed merging lp:~harlowja/cloud-init/better-todo into lp:cloud-init.

Requested reviews:
  cloud init development team (cloud-init-dev)

For more details, see:
https://code.launchpad.net/~harlowja/cloud-init/better-todo/+merge/224934

Move to a rst format for the TODO file
-- 
https://code.launchpad.net/~harlowja/cloud-init/better-todo/+merge/224934
Your team cloud init development team is requested to review the proposed merge of lp:~harlowja/cloud-init/better-todo into lp:cloud-init.

=== renamed file 'TODO' => 'TODO.rst'
--- TODO	2012-07-10 03:32:50 +0000
+++ TODO.rst	2014-06-29 18:36:16 +0000
@@ -1,46 +1,46 @@
-- Consider a 'failsafe' DataSource
-  If all others fail, setting a default that
-   - sets the user password, writing it to console
-   - logs to console that this happened
-- Consider a 'previous' DataSource
-  If no other data source is found, fall back to the 'previous' one
-  keep a indication of what instance id that is in /var/lib/cloud
-- Rewrite "cloud-init-query" (currently not implemented)
-  Possibly have DataSource and cloudinit expose explicit fields
-   - instance-id
-   - hostname
-   - mirror
-   - release
-   - ssh public keys
+==============================================
+Things that cloud-init may do (better) someday
+==============================================
+
+- Consider a ``failsafe`` ``DataSource``,  if all others datasources fail,
+  using a default ``DataSource`` that does the following would be really nice:
+
+  - sets the user password, writing it to console
+  - logs to console that this happened
+
+- Consider a ``previous`` ``DataSource``, if no other data source is
+  found, fall back to the ``previous`` one that worked.
+- Rewrite ``cloud-init-query`` (currently not implemented)
+- Possibly have a ``DataSource`` expose explicit fields:
+
+  - instance-id
+  - hostname
+  - mirror
+  - release
+  - ssh public keys
+
 - Remove the conversion of the ubuntu network interface format conversion
   to a RH/fedora format and replace it with a top level format that uses
   the netcf libraries format instead (which itself knows how to translate
-  into the specific formats)
-- Replace the 'apt*' modules with variants that now use the distro classes
-  to perform distro independent packaging commands (where possible)
-- Canonicalize the semaphore/lock name for modules and user data handlers
-  a. It is most likely a bug that currently exists that if a module in config
-     alters its name and it has already ran, then it will get ran again since
-     the lock name hasn't be canonicalized
+  into the specific formats). See for example `netcf`_ which seems to be
+  an active project that has this capability.
+- Replace the ``apt*`` modules with variants that now use the distro classes
+  to perform distro independent packaging commands (wherever possible).
 - Replace some the LOG.debug calls with a LOG.info where appropriate instead
-  of how right now there is really only 2 levels (WARN and DEBUG)
-- Remove the 'cc_' for config modules, either have them fully specified (ie
-  'cloudinit.config.resizefs') or by default only look in the 'cloudinit.config'
-  for these modules (or have a combination of the above), this avoids having
-  to understand where your modules are coming from (which can be altered by
-  the current python inclusion path)
-- Depending on if people think the wrapper around 'os.path.join' provided
-  by the 'paths' object is useful (allowing us to modify based off a 'read'
-  and 'write' configuration based 'root') or is just to confusing, it might be 
-  something to remove later, and just recommend using 'chroot' instead (or the X 
-  different other options which are similar to 'chroot'), which is might be more 
-  natural and less confusing...
-- Instead of just warning when a module is being ran on a 'unknown' distribution
-  perhaps we should not run that module in that case? Or we might want to start
-  reworking those modules so they will run on all distributions? Or if that is
-  not the case, then maybe we want to allow fully specified python paths for
-  modules and start encouraging packages of 'ubuntu' modules, packages of 'rhel'
-  specific modules that people can add instead of having them all under the 
-  cloud-init 'root' tree? This might encourage more development of other modules
-  instead of having to go edit the cloud-init code to accomplish this.
+  of how right now there is really only 2 levels (``WARN`` and ``DEBUG``)
+- Remove the ``cc_`` prefix for config modules, either have them fully
+  specified (ie ``cloudinit.config.resizefs``) or by default only look in
+  the ``cloudinit.config`` namespace for these modules (or have a combination
+  of the above), this avoids having to understand where your modules are
+  coming from (which can be altered by the current python inclusion path)
+- Instead of just warning when a module is being ran on a ``unknown``
+  distribution perhaps we should not run that module in that case? Or we might
+  want to start reworking those modules so they will run on all
+  distributions? Or if that is not the case, then maybe we want to allow
+  fully specified python paths for modules and start encouraging
+  packages of ``ubuntu`` modules, packages of ``rhel`` specific modules that
+  people can add instead of having them all under the  cloud-init ``root``
+  tree? This might encourage more development of other modules instead of
+  having to go edit the cloud-init code to accomplish this.
 
+.. _netcf: https://fedorahosted.org/netcf/