cloud-init-dev team mailing list archive

[Dan Watkins <daniel.watkins@xxxxxxxxxxxxx>]

Diff comments:

> === modified file 'doc/merging.rst'
> --- doc/merging.rst	2013-04-02 18:51:54 +0000
> +++ doc/merging.rst	2016-05-26 11:24:31 +0000
> @@ -181,8 +182,13 @@
>  Other uses
>  ----------
>  
> -The default merging algorithm for merging 'conf.d' yaml files (which form a initial
> -yaml config for cloud-init) was also changed to use this mechanism so its full
> +In addition to being used for merging user-data sections, the default merging
> +algorithm for merging 'conf.d' yaml files (which form an initial yaml config
> +for cloud-init) was also changed to use this mechanism so its full
>  benefits (and customization) can also be used there as well. Other places that
> -used the previous merging are also similar now extensible (metadata merging for
> -example).
> +used the previous merging are also, similarly, now extensible (metadata
> +merging, for example).
> +
> +Note, however, that merge algorithms are not used *across* types of
> +configuration.  As was previously the case, merged user-data will still

I agree that it's confusing; I went with this because the document starts with "This was implemented because"; the entire document is framed as describing changed behaviour.  I'm also trying to make it clear 

How about "As was the case before merging was implemented, user-data will overwrite conf.d configuration without merging."?

> +overwrite conf.d configuration.


-- 
https://code.launchpad.net/~daniel-thewatkins/cloud-init/merging-doc-clarification/+merge/295822
Your team cloud init development team is requested to review the proposed merge of lp:~daniel-thewatkins/cloud-init/merging-doc-clarification into lp:cloud-init.