[06:05] <cpaelzer> themachine: I'm not sure if I got all of the backscroll on the topic, but you could force a defined serial to those disks in your qemu/libvirt setup. And then in the guest use them as /dev/disk/by-id/... independent to the (Filesystem-)UUID that it gets after formatting
[06:08] <themachine> cpaelzer: Thank you. I will look into that.
[06:14] <eggbean> Does anybody know what is wrong with this? It makes the server unreachable.
[06:14] <eggbean> bootcmd:
[06:14] <eggbean>        - [ printf, 'prepend domain-search "${domain}";', >>, /etc/dhcp/dhclient.conf ]
[06:14] <eggbean>        - [ systemctl, restart, systemd-resolved.service ]Y
[06:15] <eggbean> ^ should be two spaces
[06:16] <eggbean> bootcmd:
[06:16] <eggbean>   - [ cloud-init-per, once, edit-file, printf, 'prepend domain-search "${domain}";', >>, /etc/dhcp/dhclient.conf ]
[06:16] <eggbean>   - [ cloud-init-per, once, restart-service, systemctl, restart, systemd-resolved.service ]
[06:16] <eggbean> Y
[06:16] <eggbean> Do I need to escape the single quotes or something like that?
[06:28] <eggbean> Okay, I needed to enclose the >> in quotes
[06:29] <cpaelzer> glad you found that eggbean, but wouldn't that be more naturally go through v2 network https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html being netplan that allows dhcp overrides https://netplan.io/reference/#dhcp-overrides ?
[06:31] <eggbean> cpaelzer: This is Debian. When I read the AWS docs on doing this it mentioned netplan on Ubuntu, but there it doesn't appear to be present on Debian
[06:33] <eggbean> Yeah, netplan seems to be a ubuntu thing
[06:33] <eggbean> I suppose cloud-init is canonical as well
[06:34] <eggbean> Thanks for the tip though
[06:37] <cpaelzer> Network config v1 allows to set those without netplan, let me fetch some links for you to consider
[06:37] <eggbean> cheers
[06:37] <cpaelzer> like: https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v1.html?highlight=nameserver#nameserver maybe?
[06:38] <cpaelzer> I did not see/try to combine dhcp+search domain via that, so no guarantees
[06:38] <cpaelzer> but worth a try, OTOH if you are just happy with your cconfig that now works I have no reason to stop you from using it :-)
[06:38] <eggbean> That seems to be for changing the dns servers
[06:39] <eggbean> I am just adding a dns search domain here. But I can see that line in that code, so it is probably elsewhere on that page
[06:39] <cpaelzer> you are right, I was just quickly looking for the keywords in the docs ...
[06:40] <eggbean> Would I be able to just add that line, leaving the rest out (apart from parents)?
[06:41] <cpaelzer> I have not seen such a combination in the examples, but often found that cloud-init config variations are easy to try
[06:41] <cpaelzer> most of the cloud-init people that know what they talk about (=not me) will be up in ~8-9h - they might be able to help further :-)
[06:41] <eggbean> ok thanks. I find that the logs don't give much to go on with failures
[07:19] <themachine> cpaelzer: Thanks again. That was the final piece of my puzzle and one that I'm sure I'll reuse in the future.
[07:34] <cpaelzer> happy to hear that themachine
[22:32] <jchittum> looks like `httpretty==0.9.5` breaks on python==3.9.7` due to changes in `Threading`. I bumped to `1.1.4` for local testing and `xenial-dev` ran fine. This will cause some issues for folks running impish+ and developing `cloud-init`
[22:34] <jchittum> this is due to `threading.Thread().isAlive()` no longer existing: AttributeError: 'Thread' object has no attribute 'isAlive'
[22:34] <jchittum> also whopps. that's an amazing badly matched tick marks. good job me
[22:39] <jchittum> should i be using something like `pyenv` to do a python 3.5 environment to run the xenial tests?
[22:44] <falcojr> jchittum: we only specify `httpretty>=0.7.1` in the requirements file so we can use different versions depending on whats in the repos
[22:45] <falcojr> on travis it's grabbing 0.8.6 for 3.5 and 1.1.4 for 3.9
[23:25] <blackboxsw> jchittum: so `tox -e xenial-dev` will not work on hirsute ++ I think.  
[23:25] <blackboxsw> falcojr: It's probably not something we even want anymore in tox default targets. Cloud-init is no longer publishing releases to Xenial for cloud-init. Our CI also only runs `tox -e xenial` in Travis from a compatibility check standpoint  (note: not the xenial-dev target). 
[23:28] <blackboxsw> ultimately tox default test environements should probably only be py3,  flake8, pylint (and eventually "black" and "isort" too per your PR )
[23:34] <blackboxsw> that said: if we want to keep xenial-dev as a tox env in our local test rotation, I think we can bump it specifically to 1.1.4 in tox.ini at the moment. It'll at least then pass on hirsute++ which is probably where most of our dev envs are running anyway.
[23:55] <jchittum> ok. so with my pr for LP: 1954842 I'll leave the env untouched, and know that CI will pick a more correct matching version.
[23:56] <jchittum> blackboxsw: I'm just community on this, but i'd agree with just dropping it. and giant +1s to black and isort (do you want me to go ahead and run those manually now? I'll happily do so :) )