| ananke | minimal: the problem was identifying what's causing the discrepancy: identical image, different network device names. netplan config was showing as written by cloud-init, so that was the first stop at the debugging tree | 00:01 |
|---|---|---|
| minimal | ananke: but what is the problem? using differing interface names is not in itself a problem | 00:02 |
| minimal | if network works then it works regardless of the names used | 00:02 |
| ananke | minimal: it is, if you have to manage images that have to operate on either scheme, with multiple network interfaces. when apps/services require configs that reflect appropriate network interface names, then eth1 vs ens6 can break things | 00:04 |
| minimal | ananke: so add "net.ifnames=0" to the cmdline as I mentioned earlier | 00:04 |
| minimal | then all interfaces will be named ethX | 00:04 |
| ananke | minimal: I feel like we're talking in circles. I'm not looking for a solution, I was trying to identify the root cause | 00:05 |
| minimal | ananke: and I mentioned that I suspected that the vif driver does not support predictable interfaces names, perhaps it is hardcoded to only use ethX | 00:06 |
| minimal | but as I can't find the source for it I can't confirm that suspicion | 00:07 |
| ananke | perhaps, but I was pretty much done with the debugging process at this point: 14:41 ananke> looks like this may be related to the network driver: vif vs ena | 00:07 |
| ananke | beyond that I was just entertaining your questions, I imagine you were interesting in more detail. I wasn't looking for a solution past that point | 00:07 |
| minimal | well that didn't really identify a root cause though | 00:08 |
| ananke | from my perspective, it did | 00:08 |
| ananke | for further detail, here's a post explaining the difference between the drivers used on t2 and t3 instances : https://www.mail-archive.com/debian-cloud@lists.debian.org/msg04285.html | 00:12 |
| minimal | ananke: actually I'm wrong, predictable names are handled by udev, not the kernel, so perhaps there's a missing udev rule for that device type | 00:13 |
| minimal | yes that explains it - they're not pci devices (which is why lspci didn't show them) | 00:16 |
| minimal | and that article makes exactly the same point I made - disable predictable names if you want t2 and t3 to have same naming | 00:17 |
| minimal | more info in the systemd source code in docs/PREDICTABLE_INTERFACE_NAMES.md | 00:19 |
| ananke | I'm actually thinking of using altnames, rather than falling back on the legacy mode. we can prop up old stuff only for so long, it's time to move on | 00:46 |
| ananke | though it will be interesting to figure out how to set those to be persistent in our images, but that's a problem for another day | 00:49 |
| minimal | ananke: I have physical machines where I use cloud-init's network-config's "set-name" to set interface names like "lan" and "wan" to make things clear | 00:51 |
| ananke | minimal: those type of names are actually very much in line of what I was thinking of, the issue though may be the fact that currently cloud-init's network is not something we can control | 00:53 |
| minimal | ananke: yes it different for a local physical/VM setup where you can control the network YAML and a cloud where the cloud provider presents it to cloud-init | 00:55 |
| ananke | it would be nice if we could merge those, and simply have a custom 'first network interface should have altname X, second network interface should have altname Y'. the network cards we assign via AWS show up in the expected order, so that would be ideal | 00:58 |
| ananke | beyond that, I can't rely on anything else. we don't know the MAC addresses, IP ranges, default routes, etc. | 00:58 |
| minimal | ananke: well that's what the EC2 IMDS is for :-) | 01:02 |
| ananke | minimal: not sure how that helps me | 01:04 |
| minimal | it doesn't really - you (and cloud-init) are limited to what IMDS presents | 01:05 |
| MICROburst | how to add more than one line for a source using apt: ? | 09:41 |
| holmanb | MICROburst: Why do you want that? Is this for rfc822? | 12:37 |
| holmanb | MICROburst: the apt config module doesn't support 822 yet, but you canuse write_files to add a new source file to /etc/apt/sources.list.d if you want rfc822 definitions | 12:40 |
| waldi | moin. i have a small design question. i want to add support for mirror+file:/// in apt-configure module (see apt-transport-mirror). how would you design the knob to enable this feature? | 12:41 |
| waldi | - config entry, similar to apt.preseve_source_list | 12:41 |
| waldi | - detect if hard coded files exist (like /etc/apt/mirror.list/cloud-init-security.list) | 12:42 |
| holmanb | waldi: Not very familiar with it, but it probably warrants adding a new config key for enabling the feature. | 13:08 |
| waldi | hmm, do ubuntu images really contain a complete set of metadata in /var/lib/apt/lists/? because the apt-configure module does not run apt-get update if it only changes the main apt config, but tries to rename existing files | 13:19 |
| waldi | holmanb: yeah… | 13:19 |
| MICROburst | holmanb: Are you sure your are referring to the correct RFC? https://www.rfc-editor.org/info/rfc822 | 15:27 |
| MICROburst | write_files does not seem to work properly for me | 15:27 |
| blackboxsw | holmanb: falcojr https://github.com/canonical/pycloudlib/pull/211 for less Azure logs during integration tests | 19:39 |
| ubottu | Pull 211 in canonical/pycloudlib "azure: reduce logging noise to only warnings for every HTTP request" [Open] | 19:39 |
| cjp256 | should obj.pkl be updated after get_data()? i'm not seeing an update to the pkl and the cache updates made during init-local are being lost | 20:14 |
| cjp256 | and `applying net config names for ...` ends up using the previous config | 20:16 |
| holmanb | MICROburst: https://manpages.ubuntu.com/manpages/jammy/en/man5/deb822.5.html | 20:51 |
| holmanb | MICROburst: "does not seem to work properly for me" -> will require more information to debug, you probably want to check for warnings in your /var/log/cloud-init.log | 20:56 |
| cjp256 | https://github.com/canonical/cloud-init/pull/1667 | 21:30 |
| ubottu | Pull 1667 in canonical/cloud-init "stages: sync datasource cache after updating metadata" [Open] | 21:30 |
| MICROburst | holmanb: It does not substitute variables like §RELEASE, the stuff goes verbatim into the file. | 21:37 |
| holmanb | MICROburst: Correct. If you need more complicated logic you'll need to use runcmd or a different user-data format. | 21:41 |
| holmanb | or bootcmd/etc | 22:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!