[08:49] <jbg> how can i disable network configuration in cloud-init entirely?
[08:49] <jbg> the documentation tells me to add "network:\n  config: disabled" to /etc/cloud/cloud.cfg
[08:49] <jbg> i have done that and also added "disable_network_activation: true"
[08:50] <jbg> yet cloud-init still tries to run dhclient before fetching user-data
[08:51] <waldi> which data source? several of them require working network, so they do the minimal thing they can
[08:51] <waldi> and it's going to be overriden by the real network setup anyway shortly after
[08:52] <jbg> waldi: i've moved cloud-init to run after the network comes up, since i am only using it to write a handful of files and nothing else
[08:53] <jbg> there seems to be some bug with the ephemeral DHCP handling which only manifests on Vultr and not on other clouds we use, but it's a bit annoying having to debug something that i would rather not even have
[08:53] <waldi> jbg: so you don't use the init-local instance?
[08:53] <jbg> nope, but whenever it tries to load user-data it seems to run the dhcp code regardless?
[08:54] <jbg> i might just put the files in user-data with mime multipart or something and parse them out with a script
[08:56] <waldi> which data source do you use?
[08:57] <jbg> same image is deployed in many different environments, and they all (or maybe just most, i haven't looked rigorously) seem to do an extra DHCP roundtrip, but the DHCP breakage is happening specifically with vultr
[08:58] <jbg> in that it actually fails to do its "ephemeral" DHCP thing and thus fails to load the user data, even though it actually has network connectivity
[08:58] <waldi> well. the vultr data source is coded this way
[08:58] <jbg> i can ssh in and curl the userdata just fine, but it doesn't try because the DHCP part fails
[08:59] <jbg> i don't really understand the motivation for that; the provider supports DHCP and the distro supports DHCP, why does it need to do DHCP again instead of just running slightly later?
[08:59] <waldi> because you need an address to access the meta data service, but the meta data service is going to tell you how to setup the network
[09:00] <jbg> but the most common case is "just do DHCP"
[09:01] <jbg> anyway, i don't think it's necessary to go over this, i think i see the issue in the data source code
[09:02] <jbg> and i think cloud-init has a much larger scope than we need
[09:03] <waldi> now the question is: is this a overall brokeness in the vultr platform or just in your usecase?
[09:05] <jbg> i think there is certainly some bug in the vultr data source; systemd-networkd does DHCP fine but vultr's datasource claims to fail (though doesn't log any error)
[09:06] <jbg> in terms of our usecase, it does seem a bit difficult in general to make cloud-init "just take three files from user data and write them and promise to do nothing else at all"
[09:06] <jbg> there are a lot of individual things that have to be turned off which will otherwise bite you, sometimes only on some cloud providers (e.g. vendor data)
=== jmcgnh_ is now known as jmcgnh