=== cpaelzer__ is now known as cpaelzer
[07:30] <meena> shibumi: unless you only have one interface and use dhcp, then it's pretty much clear what to do ;)
[08:55] <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:59] <meena> \o/
[13:31] <Odd_Bloke> otubo: :)
[13:34] <meena> Good morning Odd_Bloke — have you fixed all my bugs yet?
[13:35] <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:36] <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:46] <shibumi> Odd_Bloke: yep and yep
[13:46] <shibumi> Odd_Bloke: but we still have issues with cloud-init
[15:15] <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:17] <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:19] <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:38] <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:39] <rharper> it wasn't clear why that was done;
[15:41] <shibumi> We thought it's maybe related to  ln -s /dev/null /etc/systemd/network/99-default.link
[15:42] <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:43] <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:44] <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:45] <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?
=== hggdh-msft is now known as hggdh
[15:45] <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:46] <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:47] <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:48] <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:49] <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:51] <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:52] <rharper> shibumi: yes; and it depends on your goals for the image if you want that behavior or not
[15:53] <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:54] <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:55] <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:56] <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:57] <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:58] <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:59] <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
[16:36] <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:57] <shibumi> Odd_Bloke: vagrant and qcow2 images are a different thing in our project
[16:58] <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