| === vrubiolo1 is now known as vrubiolo | ||
| otubo | smoser: quick question about the (now dead) pull request #721 - https://github.com/canonical/cloud-init/pull/721 | 12:50 |
|---|---|---|
| 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? | 12:51 |
| smoser | otubo: this is to resize the PV, right? | 13:54 |
| otubo | smoser: yep. I think we should resize all, right? | 13:54 |
| smoser | the general goal of growpart functionality is to have the root filesystem grown to take any "extra space" that was previously unallocated. | 13:55 |
| 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:56 |
| 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...) | 13:59 |
| otubo | smoser: also: can I see cloud-init logs while running tox on my laptop? | 14:38 |
| 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:39 |
| smoser | otubo: i ust put a long comment on 721 | 14:41 |
| smoser | https://github.com/canonical/cloud-init/pull/721 | 14:41 |
| 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:46 |
| 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:47 |
| 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:48 |
| smoser | otubo: i think just ignore it for now. | 14:49 |
| 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:50 |
| 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:51 |
| 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:53 |
| smoser | its really a train wreck | 14:54 |
| 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:56 |
| 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:58 |
| 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. | 14:59 |
| smoser | that write fails | 15:00 |
| smoser | cloud-init is correctly recording that failure. | 15:00 |
| 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:01 |
| smoser | oh.. yeah, i totally just combined those two modules in my head. | 15:04 |
| smoser | and in my comments. | 15:04 |
| sblk | Nice @smoser , but how do I "remove console=ttyS0" on cloud-init? I've never append it by my own... | 15:15 |
| smoser | you cannot | 15:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| smoser | nobody wants to fix the problem | 15:24 |
| 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:50 |
| otubo | ¯\_(ツ)_/¯ | 15:51 |
| otubo | Also, I'm having lots of dependency errors for azure stuff on my tox/pylint | 15:52 |
| otubo | smoser: just finished my rework on that PR. Looking forward for your opinion. Thanks for the input so far :) | 16:06 |
| 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:08 |
| smoser | otubo:quick one. | 16:09 |
| smoser | use update_env= rather than env= | 16:09 |
| minimal | s/Though/Thought/ | 16:09 |
| 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:10 |
| smoser | the serial device code is probably circa 1998 or earlier. | 16:11 |
| smoser | otubo: second one '--options=pvname' rather than ['-o', 'pvname'] | 16:12 |
| otubo | smoser: OH, --options work :) | 16:12 |
| 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:14 |
| 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:15 |
| otubo | smoser: totally agree with the point. | 16:16 |
| otubo | Odd_Bloke: sure, hold on | 16:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| otubo | Odd_Bloke: perhaps it's important to notice I'm running this on my RHEL-8.3 | 16:20 |
| 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:06 |
| smoser | but if it is just default behavior and we can't do it, then it is just info or debug. | 17:07 |
| Odd_Bloke | otubo: I can reproduce on Ubuntu bionic (which also has Python 3.6). | 17:10 |
| 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:23 |
| 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.) | 17:24 |
| 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:26 |
| rharper | Odd_Bloke: ugh | 22:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!