=== tds1 is now known as tds
=== tds3 is now known as tds
=== cpaelzer__ is now known as cpaelzer
=== hjensas|afk is now known as hjensas
[12:29] <andras-kovacs> I really don't get it now how the max_wait parameter works with OpenStack :(
[12:36] <andras-kovacs> max_wait: 100 without any other timeout related settings tries to curl the metadata seems like forever (I was waiting for more than 5minutes)
[12:37] <andras-kovacs> But     max_wait: 100,      timeout: 10,    retries: 5 waits for 130 seconds before gave up (which will be fine). Maybe it's my dumbness but I can't make the math.
[12:53] <andras-kovacs> and it doesn't work like it should... again :D
[13:42] <andras-kovacs> so cloud-init with rhel 7.8 is not timing out for me
=== tds4 is now known as tds
[15:39] <blackboxsw> woot!  cloud-init | 20.1-10-g71af48df-0ubuntu3         | focal           | source, all
[15:39] <blackboxsw> looks like focal cloud-init cherry-picks got released Odd_Bloke/rharper
[15:39] <rharper> blackboxsw: \o/
[15:46] <Odd_Bloke> \o/
[18:27] <neale> I'm building my own cloud. How can I get cloud-init to configure the network if I don't have access to the local filesystem (it's a PXE booted squashfs that I don't want to regenerate for every node)? Is my best bet using the EC2 dataset provider and retooling my management network to include the link-local subnet?
[18:28] <rharper> neale: cloud-init can read network-config via /proc/cmdline
[18:28] <rharper> it also parses ip=  klibc formats
[18:28] <neale> rharper: the base64-encoded v2 configuration?
[18:29] <rharper> https://cloudinit.readthedocs.io/en/latest/topics/network-config.html
[18:29] <rharper> or v2
[18:29] <rharper> or v1
=== tds9 is now known as tds
[18:29] <neale> rharper: okay, cool. Is there no way to do it with the cloud-init yaml file?
[18:30] <rharper> so, network-config needs to be provided by the datasource or the system config as we bring networking up to fetch user-data
[18:30] <rharper> https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
[18:30] <neale> Right, I'm already doing that configuration with `ip=::::${IPv4}:BOOTIF` and the `hwaddr=` cmdline argument.
[18:31] <neale> But I think I have my answer, thank you very much!
[18:31] <rharper> cool
[18:57] <Odd_Bloke> FYI folks, I have a unit test doc PR at https://github.com/canonical/cloud-init/pull/311 and a pytest improvement PR at https://github.com/canonical/cloud-init/pull/304
[21:43] <Odd_Bloke> blackboxsw: rharper: FYI: ^
[21:45] <rharper> Odd_Bloke: thanks,  will review ... pushing up all the curtin PRs stuck behind the multipath one
[21:45] <rharper> blackboxsw: I didn't forget your PR for daily builds too
[22:04] <blackboxsw> rharper: no problem, was just wrapping up a review in ua-tools land
[22:05] <blackboxsw> rharper: on my daily recipe build now.
[22:05] <blackboxsw> will likely use git revert -n notation instead of git reset HEAD~#
[22:05] <blackboxsw> will be cleaner, and less individual commits for our bulk --pop-all, new cherry-pick etc.
[22:38] <rharper> blackboxsw: ah, ok
[22:38] <rharper> sounds nicer
[22:45] <andras-kovacs> your bugzilla is great! I really don't mind now that I got registered
[23:16] <andras-kovacs> Do you have any idea which would be the most sophisticated way to increase LVM with cloud-init?