| === cpaelzer__ is now known as cpaelzer | ||
| meena | shibumi: unless you only have one interface and use dhcp, then it's pretty much clear what to do ;) | 07:30 |
|---|---|---|
| otubo | meena: rharper Odd_Bloke thanks a lot for the always good review. I'll consider all the comments and will update the PR leter on. :-) | 08:55 |
| meena | \o/ | 08:59 |
| Odd_Bloke | otubo: :) | 13:31 |
| meena | Good morning Odd_Bloke — have you fixed all my bugs yet? | 13:34 |
| Odd_Bloke | meena: Yep, any that remain are contained entirely within your head. | 13:35 |
| Odd_Bloke | (Good morning!) | 13:35 |
| meena | cool. | 13:35 |
| meena | i should put my head back into development / testing then. | 13:35 |
| Odd_Bloke | shibumi: Interesting! I'm not super-familiar with Arch's ecosystem, is that discussion about the official Arch cloud images? And is the proposal to set net.ifnames=0 on all cloud images? | 13:36 |
| shibumi | Odd_Bloke: yep and yep | 13:46 |
| shibumi | Odd_Bloke: but we still have issues with cloud-init | 13:46 |
| rharper | shibumi: generally we do no rely on the predictiable names; even before systemd/networkd lo is a standard interface name; w.r. t to things like eth0; there is no guarantee that a virtual nic will get the name "eth0"; and even if there is a nic named "eth0" it may not be the nic you intend; as soon as there are more than one interface there needs to be some way to ensure that the config is applied to the correct interface. We cover many | 15:15 |
| rharper | scenarios such as shutdown, remove nic, boot up; many platforms may modify the nic properties (mac address) between boots; multiple nics may be added either dynamicall, or staticly (offline) | 15:15 |
| rharper | cloud-init does attempt to ensure the config is applied to a specific nic; as such, it will either utilize udev to emit rules akin to the 70-net-persistent.rules ; or if on systemd, emit configuration files which match the specific nic (independent of the name); cloud-init also will rename interfaces to match a network-config provided so that when the OS networking layer comes up; the existing on-disk config will still apply; | 15:17 |
| rharper | w.r.t renaming nics; the eth* namespace is problematic since the kernel effectively owns/manages this namespace and renaming devices within the namespace race with the kernel itself (and additional nic adds/removes); | 15:17 |
| rharper | I would strongly advise against encoding net.ifname0 in images as this leads to other challenges down the road where images are utlized in multi-nic scenarios, ordering of devices based on the platform you run upon (different virt technologies do not always provide a persistent address (pci bus slot) between reboots or other operations) | 15:19 |
| shibumi | rharper: do you have a different solution to the problem we encounter? | 15:38 |
| rharper | did you find out why you don't get a 'lo' interface ? | 15:38 |
| rharper | I saw some discussion of something symlinking the systemd defaults config | 15:38 |
| rharper | it wasn't clear why that was done; | 15:39 |
| shibumi | We thought it's maybe related to ln -s /dev/null /etc/systemd/network/99-default.link | 15:41 |
| rharper | shibumi: ok, re-reading; w.r.t the default image; you do not need to bake in any existing network-configuration; cloud-init already provides a default of dhcp on the best interface (where best is a heuristic that cloud-init uses , skips certain interfaces like bonds or bridges, nics that have no carrier, etc;) it's better than just assuming that you can dhcp a kernel device named eth0 | 15:42 |
| rharper | Ubuntu images do not bake any network config in them and rely on cloud-init to auto generate this config; on platforms which do provide network config (Like openstack, azure, ec2) the datasource reads the platform network config and then cloud-init will render that to the OS renderer | 15:43 |
| shibumi | rharper: ok interesting. Btw is this the right method to enable cloud-init in images? https://github.com/archlinux/arch-boxes/blob/master/provision/cloud-init.sh | 15:44 |
| rharper | so, I believe if you can sort out getting your lo interface back, and remove the baked in netplan config; the image will generate a dhcp on the best interface on the fly | 15:44 |
| shibumi | I was unsure if we enable too much | 15:44 |
| rharper | shibumi: if you have systemd, then that's too much | 15:44 |
| shibumi | rharper: we have systemd | 15:44 |
| rharper | cloud-init uses a systemd generatator to dynamically enable cloud-init IIF there is a datasource | 15:45 |
| shibumi | rharper: so I can actually just install cloud-init and I don't need to enable the services manually? | 15:45 |
| === hggdh-msft is now known as hggdh | ||
| shibumi | or do I need to enable just 1-2 services from the 4? | 15:45 |
| rharper | ideally yes, though it depends on your distro packaging | 15:45 |
| rharper | zero if you install the cloud-init-generator | 15:45 |
| shibumi | what do you mean with 'install'? do I need to enable that cloud-init-generator service? or is this just a binary that I need to drop in the right place? | 15:46 |
| rharper | it's a binary (script) that's put in the place where other systemd generators are installed | 15:47 |
| shibumi | cloud-init usr/lib/systemd/system-generators/cloud-init-generato | 15:47 |
| shibumi | we install it there ^ | 15:47 |
| rharper | /lib/systemd/system-generators/cloud-init-generator | 15:47 |
| rharper | looks right to me | 15:47 |
| shibumi | rharper: lib is a symlink to /usr/lib in arch ;) | 15:47 |
| shibumi | ok cool | 15:48 |
| rharper | so you could skip your service enables and boot that image with NoCloud datasource , I think your Issue has some steps on creating a datasource iso and attaching that to the VM to test | 15:48 |
| rharper | ## create a disk to attach with some user-data and meta-data (require cdrkit) | 15:48 |
| rharper | $ genisoimage -output seed.iso -volid cidata -joliet -rock user-data meta-data | 15:48 |
| rharper | so the volid 'cidata' is one of the bits of info that cloud-init generator will detect and then enabling all of the cloud-init services | 15:49 |
| rharper | shibumi: the goal of the generator is to not have cloud-init run if there is nothing for it to do (ie if someone just booted your cloud image not on a cloud) it shouldn't try to call out to Ec2 metadata services, | 15:49 |
| shibumi | rharper: well, so if somebody boots up the qcow2 image without cloud image datasource the image will have actually no network configuration (if I remove that network configuration) is this correct? | 15:51 |
| rharper | shibumi: yes; and it depends on your goals for the image if you want that behavior or not | 15:52 |
| shibumi | rharper: good question. Would be cool if we could satisfy both (normal users who want to boot that up in qemu and cloud users) | 15:53 |
| shibumi | rharper: are we gonna to have problems if we just leave that dhcp configuration for ethernet devices there? cloud-init should change this via netplan, is this correct? | 15:54 |
| rharper | the question you have to answer is for the local boot, do they, or do they not want networking enabled by default; in the case where no network is available (but they have a nic) then you sit and wait for networking service to come up | 15:54 |
| rharper | which can be 120s | 15:54 |
| rharper | that's not a nice experience | 15:54 |
| shibumi | or true | 15:54 |
| rharper | shibumi: you can use a more generate match in your baked in config, of match: {'name': 'en*}; which will match any ethernet device; as you'll never know the mac address of the VM you boot upon | 15:55 |
| rharper | however, if the user runs the image on a platform which has finer grain control over network-config and wants to provide static IPs in addition to dhcp on the interface, there may be network config conflict | 15:56 |
| shibumi | mh I see | 15:56 |
| rharper | now, the distro class controls this | 15:56 |
| rharper | see cloudinit/distros/debian.py:_maybe_remove_legacy_eth0() | 15:56 |
| shibumi | then the best choice is that we declare the images as 'cloud only' and refer to the vagrant images if somebody wants to use a box on their laptop | 15:56 |
| rharper | you could add step like this in arch distro class to detect if you should remove the baked in config or not | 15:57 |
| rharper | or augment it | 15:57 |
| rharper | another thought is a drop-in config in systemd which could remove this baked in config file if cloud-init is going to run | 15:58 |
| rharper | so, you could have a cloud-init-local.service.d/10-remove-config.conf ; in which you have [Unit] ExecStartPre=/bin/rm -f /path/to/baked/in/config | 15:58 |
| rharper | if cloud-init is enabled, that would run and remove your baked in config (and cloud-init will handle bringing up networking) | 15:59 |
| rharper | but without a datasource, cloud-init does not run at all , and your built-in config would be used instead | 15:59 |
| Odd_Bloke | shibumi: You shouldn't need baked-in config for Vagrant to work; "DHCP on the first interface" is appropriate behaviour there (in my experience). | 16:36 |
| shibumi | Odd_Bloke: vagrant and qcow2 images are a different thing in our project | 16:57 |
| shibumi | Odd_Bloke: vagrant used netctl for Arch Linux in the past (that is deprecated and therefore not supported right now) | 16:58 |
| shibumi | the newest version will use systemd-networkd instead | 16:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!