[13:10] <psykotox> Hi, I'm trying to configure cloud-init on an openstack instance but there is something I don't understand. I try to set `manage_etc_hosts: true`. In the vendor data I have `manage_etc_hosts: localhost`. If I set `manage_etc_hosts: true` in my user-data it works. However, if I put `manage_etc_hosts: true` in /etc/cloud/cloud.cfg it doesn't work, it takes the value of the vendor-data instead (`manage_etc_hosts: localhost`). Does anyone know why? I can't
[13:11] <psykotox> * I can't find anything in the docs.
[14:25] <meena> psykotox: what stuff goes into meta-data, which stuff goes into vendor-data, and stuff goes into user-data is, imo, heavily underdocumented.
[14:26] <meena> I wish we had something like Apache Httpd has, which tells you which sections you can put a directive in
[14:27] <meena> but, basically, most of them just go into user-data, except networking configuration, and the id goes into meta-data 
[14:38] <psykotox> Thanks meena. But what I would like to understand is why vendor-data overrides the configuration in /etc/cloud/cloud.cfg
[14:38] <psykotox> Is this an intended behavior?
[14:42] <meena> psykotox: same, i opened a bug for that
[14:45] <meena> https://bugs.launchpad.net/cloud-init?field.searchtext=merg&search=Search   i can't find mine
[16:41] <meena> oh, cool, I tried fixing a typo, and now I'm knee deep in bugs again
[16:47] <meena> https://bugs.launchpad.net/cloud-init/+bug/1991567
[16:49] <meena> https://github.com/canonical/cloud-init/pull/1758 ready for merge (or review, as it may be;)
[19:18] <cjp256> is there a case where `init-local` wouldn't be the first event?  considering a fix for invalid boot records under Azure and I see two obvious solutions.  (a) specifically look for start of `init-local` or (b) ignore azure-ds events from consideration when splitting boot records
[21:35] <meena> holman: got another question on that PR
[21:35] <meena> i should do a full review, but brain tired
[21:42] <blackboxsw> cjp256: the only images I've seen which didn't have init-local complete before init-network stage was due to errors in systemd dependency chains where cloud-init was evicted from the boot target because it was incompatible with other systemd services and ordering,