=== vrubiolo1 is now known as vrubiolo
[12:50] <otubo> smoser: quick question about the (now dead) pull request #721 - https://github.com/canonical/cloud-init/pull/721
[12:51] <otubo> smoser: According to you comment about the whole block becoming a function that would return an array of PVs, how can I be sure which partition the user really wants to enlarge? Should I choose the bigger one as default?
[13:54] <smoser> otubo: this is to resize the PV, right?
[13:54] <otubo> smoser: yep. I think we should resize all, right?
[13:55] <smoser> the general goal of growpart functionality is to have the root filesystem grown to take any "extra space" that was previously unallocated.
[13:56] <smoser> the extra space probably appeared as a result of hypervisor just adding zeros to the end of the disk.
[13:56] <smoser> (just trying to state the goals, so then we can try to acheive those goals here)
[13:59] <smoser> you could dig deeper with lvm to determine which PV the root filesystem is on (which could be 2 or more due to linear layout or raid or stripes...)
[14:38] <otubo> smoser: also: can I see cloud-init logs while running tox on my laptop?
[14:39] <smoser> otubo: idont know. i dont remember.
[14:39] <smoser> you can absolutely print stuff and invoke tox with --no-capture-output or something
[14:39] <smoser> and then you'll see it.
[14:41] <smoser> otubo: i ust put a long comment on 721
[14:41] <smoser> https://github.com/canonical/cloud-init/pull/721
[14:46] <minimal> smoser: it would be more complicated if its LVM-on-LUKS :-)
[14:46] <otubo> smoser: good comments, we're on the same page :-) except that I thought we needed support for resizing VG that spams across multiple PV. That's an extra step that I'm banging my head right now.
[14:47] <otubo> minimal: that's something that's on my list, got some errors testing on my laptop (that uses LUKS) and took a while to find out why
[14:48] <minimal> otubo: yeah I intend to go down the LVM-on-LUKS route for some physical machines using cloud-init (where I'm dd'ing a prepared OS image onto the machine's disk so its minimally sized and needs to grow to fill the disk)
[14:49] <smoser> otubo: i think just ignore it for now.
[14:50] <smoser> you could attempt to resize all the pvs if you wanted. but that isn't really the simple "cloud image" case.
[14:50] <smoser> minimal: yeah, you can have layers on top of layers of layers even circular (lvm -> luks -> lvm)
[14:50] <sblk> I get errors about ssh-authkey-fingerprints and ssh-authkey-fingerprints  (on a Ubntu VirtualBox guest)    the details are at https://paste.ubuntu.com/p/sw8sWvgBsc/ , please could you help me? Tell me of you need more detail
[14:51] <minimal> smoser: yeah getting the simple working first makes sense. BTW I've not yet tried growpart with the basic partitions-on-LUKS case yet either (i.e. no LVM in the mix)
[14:51] <smoser> software!
[14:53] <smoser> sblk: you need to add a serial device. or remove console=ttyS0 from the kernel command line.
[14:53] <smoser> https://bugs.launchpad.net/maas/+bug/1061977 is related.
[14:53] <ubot5> Ubuntu bug 1061977 in MAAS "Machine fails to commission when console=ttyS0 is present on kernel opts" [Critical,Fix released]
[14:53] <smoser> also  and bug 1122245
[14:53] <ubot5> bug 1122245 in libvirt (Ubuntu) "booting from a cloud image hangs until virsh console is used" [Medium,Won't fix] https://launchpad.net/bugs/1122245
[14:54] <smoser> its really a train wreck
[14:56] <sblk> Sorry I don't understand the connection with  ssh-authkey-fingerprints and ssh-authkey-fingerprints  and "serial device". I can login, but I wonder why do those errors occur
[14:58] <smoser> sblk: your system has booted with 'console=ttyS0' on the kernel command line (a serial device). but you do not have a serial device.
[14:59] <smoser> so systemd hooks up /dev/console writes to go to ttyS0
[14:59] <smoser> cloud-init's output goes to /dev/console
[14:59] <smoser> cloud-init writes the ssh fingerprints to its stdout so that you can see them.
[15:00] <smoser> that write fails
[15:00] <smoser> cloud-init is correctly recording that failure.
[15:01] <smoser> the easiest solution is to just remove console=ttyS0 as it is wrong for you.
[15:01] <minimal> smoser: for the normal-partitions-on-LUKS "cryptsetup resize" would need to be called, though this would be in cc_resizefs rather than cc_growpart I assume. I'll try and find some time to look at that scenario and see if I can put together a MR for it
[15:04] <smoser> oh.. yeah, i totally just combined those two modules in my head.
[15:04] <smoser> and in my comments.
[15:15] <sblk> Nice @smoser , but how do I  "remove console=ttyS0"  on cloud-init? I've never append it by my own...
[15:20] <smoser> you cannot
[15:21] <smoser> that is part of why the whole thing is such a mess.
[15:21] <smoser> ubuntu tries to create one cloud image that "just works"
[15:22] <smoser> and "just works" means that you should be able to see text console log... because that is extremely useful.
[15:22] <smoser> but if you do that, by adding 'console=ttyS0' and there is no ttyS0 the kernel just behaves really poorly.
[15:23] <smoser> it takes writes for a while, and then starts failing.
[15:23] <smoser> and programs that have writes fail should bubble up those failures, not just ignore them.
[15:24] <smoser> nobody wants to fix the problem
[15:50] <otubo> The user requested python-simplestreams 0.1.0 (from git+https://git.launchpad.net/simplestreams)
[15:50] <otubo> pycloudlib 18.8 depends on python-simplestreams 0.1.0 (from git+https://git.launchpad.net/simplestreams@21c5bba2a5413c51e6b9131fc450e96f6b46090d)
[15:51] <otubo> ¯\_(ツ)_/¯
[15:52] <otubo> Also, I'm having lots of dependency errors for azure stuff on my tox/pylint
[16:06] <otubo> smoser: just finished my rework on that PR. Looking forward for your opinion. Thanks for the input so far :)
[16:08] <minimal> smoser: if you have "console=tty1 console=ttyS0" does that also cause problems? Though I'd used that in the past to cater for VMs that may or may not have a serial console.
[16:09] <smoser> otubo:quick one.
[16:09] <smoser> use update_env= rather than env=
[16:09] <minimal> s/Though/Thought/
[16:10] <smoser> minimal: yes. it causes problems. the cloud-imagesi from ubuntu have console=tty0 console=ttyS0 (i think... bu tthey have both)
[16:10] <smoser> the kernel is just stupid
[16:11] <smoser> the serial device code is probably circa 1998 or earlier.
[16:12] <smoser> otubo: second one '--options=pvname' rather than ['-o', 'pvname']
[16:12] <otubo> smoser: OH, --options work :)
[16:14] <smoser> and you  missed comment on type(resizer).__name__ == "ResizeGrowPart" also
[16:14] <smoser> always (whenver tool allwos) use --long-opt=value
[16:14] <smoser> as opposed to :
[16:14] <smoser>   --long-opt value
[16:14] <smoser>    -l value
[16:15] <smoser> as the first is most obvious to the reader oon what it does *and* that those are option=value not 'flag argument'
[16:15] <otubo> smoser: I indeed forgot about __name__ == "ResizeGrowPart". Will fix that.
[16:15] <smoser> (i thinkk the 100%FREE use falls into that too)
[16:15] <Odd_Bloke> otubo: Still seeing those tox installation failures?  Could you pastebin a log?
[16:16] <otubo> smoser: totally agree with the point.
[16:16] <otubo> Odd_Bloke: sure, hold on
[16:17] <otubo> Odd_Bloke: https://pastebin.com/UYFbDJT0
[16:17] <smoser> and then get_pvs_for_lv() still will return possibly a \n delimtied list
[16:18] <smoser> and the onecaller is assuming (i htink) that it returns a sngle device string
[16:18] <smoser> it should reutrn a list
[16:18] <smoser> and that is all i can do now
[16:18] <otubo> Odd_Bloke: if I comment out the Azure stuff on cloud-tests-requirements.txt I still get the error I pasted above.
[16:19] <otubo> smoser: so, if we're assuming cloud-init will support only a single PV per VG, I'll just return an error incase a list appears.
[16:20] <otubo> Odd_Bloke: perhaps it's important to notice I'm running this on my RHEL-8.3
[17:06] <smoser> otubo: or just do nothing ?
[17:06] <smoser> debug (or maybe info message)
[17:06] <smoser> i'd say it is an error if the user explicitly said to do something and we couldn't do it
[17:07] <smoser> but if it is just default behavior and we can't do it, then it is just info or debug.
[17:10] <Odd_Bloke> otubo: I can reproduce on Ubuntu bionic (which also has Python 3.6).
[17:23] <Odd_Bloke> And it looks like the issue is that the cloud test requirements conflict with the integration test requirements (which is only a problem when we try and coinstall them, to run pylint).
[17:24] <Odd_Bloke> (I think we can just drop linting cloud_tests, we don't intend to introduce new code there; I'll propose that today, but feel free to object.)
[22:26] <Odd_Bloke> rharper: Your eyes on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1912844 would be much-appreciated!
[22:26] <ubot5> Ubuntu bug 1912844 in cloud-init (Ubuntu) "Bond with OVS bridging RuntimeError: duplicate mac found! " [Undecided,New]
[22:41] <rharper> Odd_Bloke: ugh