| 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:49 |
| jbg | yet cloud-init still tries to run dhclient before fetching user-data | 08:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| jbg | i might just put the files in user-data with mime multipart or something and parse them out with a script | 08:54 |
| waldi | which data source do you use? | 08:56 |
| 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:57 |
| 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:58 |
| 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 | 08:59 |
| jbg | but the most common case is "just do DHCP" | 09:00 |
| 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:01 |
| jbg | and i think cloud-init has a much larger scope than we need | 09:02 |
| waldi | now the question is: is this a overall brokeness in the vultr platform or just in your usecase? | 09:03 |
| 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:05 |
| 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) | 09:06 |
| === jmcgnh_ is now known as jmcgnh | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!