[05:29] <lplearn> hi~
[06:05] <Guest90> do  we have any audio discuss? 
[06:26] <Guest49> what  tool dou you  use 
[11:41] <hexa-> hm, is there no support for slaac in network config v2?
[13:24] <hexa-> rough, so I'm not sure how to configure networking on a vsphere cluster because it doesn't let me provide meta-data via the vapp for an ubuntu cloud image ovf/ova
[14:36] <hexa-> how is meta-data supposed to be passed on local vsphere clusters?
[14:37] <hexa-> we have machines that basically only have slaac on their network segment, and deploying them via terraform times out, because the ubuntu cloud image wants to do DHCP by default AFAIU.
[14:38] <rbasak> Continuing on from #ubuntu-server
[14:38] <rbasak> I just looked at https://cloudinit.readthedocs.io/en/latest/topics/datasources.html
[14:39] <rbasak> AIUI, both meta-data and user-data must come from one of those sources.
[14:39] <rbasak> cloud-init logs will tell you which was used in your case I think.
[14:39] <rbasak> Maybe https://cloudinit.readthedocs.io/en/latest/topics/datasources/ovf.html ?
[14:40] <rbasak>  /run/cloud-init/ds-identify.log might be useful
[14:40] <hexa-> https://paste.lossy.network/J6KA
[14:42] <hexa-> the referenced ovf env comes via cdrom https://paste.lossy.network/6KWA
[14:42] <hexa-> i stripped the user-data because it doesn't really matter
[14:46] <rbasak> I think you're using the OVF datasource then, and your question can be refined to asking how cloud-init does networking configuration when using the OVF datasource.
[14:46] <rbasak> I don't know the answer to that, but I hope that helps.
[14:47] <rbasak> I think the relevant code might be https://github.com/canonical/cloud-init/tree/main/cloudinit/sources/helpers/vmware/imc
[14:47] <hexa-> thanks for clarifying, that helps somewhat.
[14:48] <rbasak> Looking at *nic* in that directory, it looks to me like the configuration is grabbed from the platform NIC configuration somehow, but I don't see anything specific there about enabling/disabling DHCP.
[14:48] <rbasak> But I am just speculating, to be clear - this is beyond my current knowledge.
[15:08] <hexa-> looks like I need to somehow build upon https://github.com/canonical/cloud-init/pull/691
[15:08] <ubottu> Pull 691 in canonical/cloud-init "[VMware] Support cloudinit raw data feature" [Merged]
[17:23] <needs-help-guy> I'm looking for help finding a robust and clean solution for a problem related to systemd-resolve, GCE, cloud-init, and bad domain naming. I have ubuntu 20.04 servers in a GCP project that is DNS peered with a project that is providing .local TLDs for some internal names. systemd-resolve won't even try to resolve .local TLDs via the name server unless it's added as a search domain. I've tried a couple of different confi
[17:24] <needs-help-guy> config changes but I can't seem to find a way to add a search domain without knowing the interface name, which I'm not sure I can rely on when spinning up a bunch of cloud images.
[20:37] <smoser> bummer that needs-help-guy is gone
[20:37] <smoser> i was going to help.
[20:37] <smoser> my experience with .local domain is that nsswitch.conf editing can help
[20:38] <smoser> + hosts:                 files dns [NOTFOUND=return]
[20:38] <smoser> -files mdns4_minimal [NOTFOUND=return] dns
[23:05] <needs-help-guy> smoser, i'm still around, i'll check that out