[13:10] 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] * I can't find anything in the docs. [14:25] 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] I wish we had something like Apache Httpd has, which tells you which sections you can put a directive in [14:27] but, basically, most of them just go into user-data, except networking configuration, and the id goes into meta-data [14:38] Thanks meena. But what I would like to understand is why vendor-data overrides the configuration in /etc/cloud/cloud.cfg [14:38] Is this an intended behavior? [14:42] psykotox: same, i opened a bug for that [14:45] https://bugs.launchpad.net/cloud-init?field.searchtext=merg&search=Search i can't find mine [16:41] oh, cool, I tried fixing a typo, and now I'm knee deep in bugs again [16:47] https://bugs.launchpad.net/cloud-init/+bug/1991567 [16:47] Launchpad bug 1991567 in cloud-init "OpenBSD: migrate PKG_PATH from ftp to https" [Undecided, New] [16:49] https://github.com/canonical/cloud-init/pull/1758 ready for merge (or review, as it may be;) [16:49] Pull 1758 in canonical/cloud-init "Distro manage service: Improve BSD support" [Open] [19:18] 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] holman: got another question on that PR [21:35] i should do a full review, but brain tired [21:42] 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,