=== hjensas__ is now known as hjensas
[14:31] <Goneri> meena, FYI, I'm build some new images with 655
[14:55] <meena> Goneri: does that use the resize feature?
[14:55] <Goneri> yes it does.
[14:56] <meena> Goneri: https://reviews.freebsd.org/D27161
[15:01] <Goneri> I saw this one, nice patch :-)
[15:03] <meena> once again, far from done, but a good start
[15:03] <meena> wait till you see my systemd for FreeBSD patchset
[15:07] <meena> this is half serious, btw, but a) i need a better name, or metaphor, and SMF is closer to what i want, and b) there's alot of groundwork missing in FreeBSD before that's possible
[15:23] <rrdr20> hello, i am trying to use ds=nocloud-net to configure network interfaces with a network-config file but it doesn't seem to be reading the data and using a fallback configuration
[15:24] <rrdr20> is anyone available to help me with the details?
[15:31] <meena> rrdr20: if i understand NoCloud's documentation correctly, it can't actually be used for networking configuration
[15:32] <smoser> meena: it can feed network.
[15:32] <smoser> you shoudlnt need ds=nocluod-net on the kernel command line if you have a nocloud disk
[15:33] <smoser> and strictly speaking noclould-net is *not* what you want.
[15:33] <smoser> you want nocloud (-net runs after network is up... "-net" there means it depends on the network)
[15:33] <smoser> but that may have been made to not matter, i'm not sure.
[15:34] <smoser> rrdr20: but you absolutely can feed nocloud networking
[15:34] <smoser>  https://asciinema.org/a/145772
[15:34] <rrdr20> due to the servers that we using (Dell R630) they are unable to boot from NVMe drives so we need PXE boot to get started which is why we opted  for nocloud-net
[15:34] <meena> smoser: i think maybe the NoCloud docs need more love then
[15:34] <rrdr20> currently user-data and meta-data are being picked up correctly but network-config (v2) is not
[15:36] <smoser> rrdr20: there may be some wierdness with network config and pxe.
[15:37] <smoser> as cloud-init considers pxe to be "command line" networking, and thus (i think) to override file configuration
[15:37] <smoser> (just as normally 'command name --option-here' would override a configuration file /etc/command.conf
[15:38] <smoser> rrdr20: but i'd suggest opening a bug. and attaching cloud-init logs and content of the files you're feeding it.
[15:39] <rrdr20> ahh i see, thank you for the insight, i will try a configdrive as Meena has suggested and will open up a bug
[15:39] <smoser> but in your case, if you're just pxe booting (kernel/initramfs) and not using anyremote mounts or anything, you dont need networking in the initramfs and that should not cost you.
[15:40] <meena> i did no such thing!
[15:40] <smoser> open a bug though. and attach tarball
[15:40] <meena> i think
[15:40] <smoser> i'd be curious to see a full console log. so please attach that too. it'll be important to see what the initramfs is doing.
[15:42] <rrdr20> will do
[15:44] <rrdr20> meena I apologize, what i mean was that both you and smoser explanations make me think that I should try attaching a drive
[15:45] <meena> ConfigDrive is different from a NoCloud drive
[15:46] <smoser> its different, but not a lot.
[15:46] <smoser> and nocloud is simpler.
[15:46] <smoser> so i'd suggest it. ;)
[15:47] <smoser> as configdrive is specifically for openstack, and if you don't look exactly like a real-world openstack, not specifically openstack then cloud-init might "fix" something that coudl break you.
[15:49] <rrdr20> ok, i have 3 files: user-data, meta-data and network config that i would add to an ISO and then attach the server
[15:50] <rrdr20> then in my ipxe kernel command i would use ds=nocloud;s=/dev/sr0 (or some path)
[15:50] <rrdr20> is that right?
[15:57] <smoser> i think that if you attach a correctly created nocloud disk (iso or "disk image"), that it should "just work".
[15:58] <smoser> again... the pxe boot could confuse it, but it really shouldn't.
[15:58] <smoser> and you should not need ds=nocloud on kernel cmdline as long as that is in datasource_list (and it usually is)
[16:26] <meena> can anyone answer falcojr's questions here? https://github.com/canonical/cloud-init/pull/655#pullrequestreview-527325337
[16:28] <meena> my intuition is that it's not caught anywhere, and fatally stop this module, which is better than potentially breaking the Filesystem
[16:45] <rrdr20> smoser I just tried booting via PXE with an ISO attached
[16:46] <rrdr20> the results were similar in that meta-data and user-data were picked up but network-config was not applied
[16:48] <rrdr20> at the end of my /var/log/cloud-init-output.log it says that it finished with Datasource [seed=/dev/sr0][dsmode=net]
[16:49] <rrdr20> so i think your assumption that PXE boot may be causing some confusion
[17:15] <smoser> rrdr20: open a bug... that will give us the info we need. ;)
[17:15] <smoser> and include the contents of your iso
[17:15] <smoser> basically... i can ask you for that stuff here, or look at it there (as well as other people can)
[17:16] <rrdr20> i will get one open when i return, thank you for your help so far
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson
[21:20] <meena> can somebody take a look at https://github.com/canonical/cloud-init/pull/588 's failing test? so far my only clue is that it might be python version related
[21:43] <Odd_Bloke> meena: That error is because of the autospeccing; evidently `assert_not_called` is not included in the object which autospec produces.
[21:44] <meena> evidently?
[21:44] <meena> it works on my machine!
[21:44] <Odd_Bloke> You need a crustier version of Python.
[21:44] <Odd_Bloke> A matured version of Python, which exhibits this behaviour.
[21:45] <Odd_Bloke> (It reproduces for me in 3.5, but not in 3.9.)
[21:45] <meena> i don't want to infest my system with python 3.5!!
[21:46] <Odd_Bloke> I'm using a container for this, you could create a jail?
[21:47] <meena> i actually develop on an Ubuntu… and i have different pythons installed with pyenv…
[21:47] <Odd_Bloke> meena: But I've checked and `call_count` is present, so you can do `assert 0 == m_generate_fallback_config.call_count` instead.
[21:48] <meena> i could
[21:48] <meena> can you "suggest a change"? cuz I'm in bed
[21:49] <meena> (reading the tests i've deleted, and pondering how to replace them)
[21:49] <Odd_Bloke> Done.
[21:55] <meena> also, a comment from somebody who knows stuff, would be greatly appreciated here https://github.com/canonical/cloud-init/pull/655#pullrequestreview-527325337
=== dionysus70 is now known as dionysus69