| johnsonshi | Odd_Bloke: Here are the results of my experiment (RHEL 7.7, cloud-init 19.4 daily) https://pastebin.com/QiVZAbGu | 00:23 |
|---|---|---|
| johnsonshi | Odd_Bloke: What seems to be happening is that cloud-init would run the swap directive first, then run the mount directive (towards the bottom of the pasted log). | 00:23 |
| johnsonshi | Odd_Bloke: In the docs at https://cloudinit.readthedocs.io/en/latest/topics/modules.html#mounts , with the way that the example is laid out, it seems to hint that the swap directive is run after the mount directive. | 00:32 |
| johnsonshi | Odd_Bloke: In the upstream code, what's happening is that the swapfile is created first at https://github.com/canonical/cloud-init/blob/87cd040ed8fe7195cbb357ed3bbf53cd2a81436c/cloudinit/config/cc_mounts.py#L465 , the swapfile is then activated at https://github.com/canonical/cloud-init/blob/87cd040ed8fe7195cbb357ed3bbf53cd2a81436c/cloudinit/config/cc_mounts.py#L511 , and finally entries in /etc/fstab are mounted at https://github.com/canonical/c | 00:34 |
| johnsonshi | loud-init/blob/87cd040ed8fe7195cbb357ed3bbf53cd2a81436c/cloudinit/config/cc_mounts.py#L520 | 00:34 |
| johnsonshi | https://github.com/canonical/c | 00:35 |
| johnsonshi | <johnsonshi> loud-init/blob/87cd040ed8fe7195cbb357ed3bbf53cd2a81436c/cloudinit/config/cc_mounts.py#L520 | 00:35 |
| johnsonshi | Ooops (sigh IRC formatting). and finally entries in /etc/fstab are mounted at https://github.com/canonical/cloud-init/blob/87cd040ed8fe7195cbb357ed3bbf53cd2a81436c/cloudinit/config/cc_mounts.py#L520 | 00:35 |
| johnsonshi | Odd_Bloke: By the way for context, our team's goal is to mount the Azure ephemeral resource disk at /mnt/resource, and then afterwards, create a swapfile within the mounted ephemeral resource disk. | 00:37 |
| johnsonshi | Odd_Bloke: Apologies. The first pastebin was badly formatted. Here is a better one: https://pastebin.com/3cu364dD | 00:54 |
| rharper | johnsonshi: I believe you're an edge case here; the ephemeral device mount is not processed until until cloud-init runs the mount -a; however, we also attempt to create the swap , in your config you're referencing a path that doesn't exist yet (and even if we were to "mkdir -p /mnt/resource" that would *not* be on the ephemeral disk as it's not been mounted when the swap_create runs; | 01:19 |
| johnsonshi | rharpher: Yes indeed :( The code runs swapfile creation and swapfile activation before it mounts drives. | 01:21 |
| rharper | johnsonshi: what you could do is to partition the ephemeral disk into two partitions, one is the size of the swap you wanted, the second would be whatever else space you wanted mounted at /mnt/resource ; during disk_setup, the ephemeral drive would be partitioned and mkswap would be run on the swap partition, and the fs partition would get formated with ext4 (or whatever you wanted) then in cc_mounts, it will swapon -a (no need to create a swap | 01:22 |
| rharper | since that's done via disk_setup/fs_setup; just an entry in fstab and swapon -a | 01:22 |
| rharper | have you filed a bug for us yet ? | 01:22 |
| rharper | I can see a number of things that would need changing to support your particular goal | 01:22 |
| johnsonshi | Not yet. Is this a bug or is cloud-init intended to run swap-related stuff first before mount-related stuff? | 01:23 |
| rharper | johnsonshi: it is a bug; but an edge case where the swap config is referencing a path that is to-be-mounted | 01:24 |
| johnsonshi | rharper: OK I will file a bug in Launchpad. Thanks for your help! | 01:24 |
| rharper | the other bug is in the swap create which does not ensure it has a path to the file (if you specify a directory that does not yet exist ) | 01:24 |
| rharper | johnsonshi: thanks! | 01:25 |
| === vrubiolo1 is now known as vrubiolo | ||
| otubo | meena: I agree I can remove -? from the regex, but the wait it's written it work great for me. | 10:06 |
| otubo | meena: I mean, I can compare kernel_version <= 4.18 and it works fine, not sure I really need to make that dance with tuples and stuff | 10:06 |
| meena | otubo: but, float(4.4) > float(4.18), while Version(4.4) < Version(4.18) | 10:30 |
| meena | otubo: when you compare it as (4, 4) < (4, 18) — as tuples, it works. | 10:30 |
| otubo | meena: ohhhh you're right | 10:34 |
| otubo | meena: stupid me, gonna fix that | 10:34 |
| meena | otubo: i'm merely relaying what i've been taught a week ago; you must've missed it | 10:34 |
| === vrubiolo1 is now known as vrubiolo | ||
| === vrubiolo1 is now known as vrubiolo | ||
| boolman | hi guys, am I looking at this wrong, but is the network setup being done to late? http://ix.io/2ce7 | 15:54 |
| Odd_Bloke | smoser: We ran into some issues with the version tooling and new upstream releases in GitHub; I've proposed a fix here: https://github.com/canonical/cloud-init/pull/223/ and your thoughts would be much appreciated. | 15:57 |
| Odd_Bloke | smoser: (If you don't have time to look at this today, we may need to land it to cut the 20.1 release; later conversation would be welcome to make sure we have it right going forward.) | 15:58 |
| Odd_Bloke | blackboxsw: rharper: Your reviews on https://github.com/canonical/cloud-init/pull/223/ would also be appreciated, of course. :) | 15:58 |
| rharper | k | 16:00 |
| boolman | anyone? im trying to get ubuntu bionic to work with cloud-init on vmware/vsphere. And it seems like during the time of execution. the network isnt setup yet | 16:11 |
| blackboxsw | Odd_Bloke: looks good. running through the package build stuff I normally run to vet it. | 16:13 |
| Odd_Bloke | boolman: Could you file a bug at the URL in the topic and attach the tarball that `cloud-init collect-logs` creates on a failing instance? | 16:13 |
| blackboxsw | boolman that log shows it didn't detect the datasource properly. so it's probably using invalid network config | 16:14 |
| blackboxsw | 2020-01-30 12:32:30,158 - cc_final_message.py[WARNING]: Used fallback datasource | 16:14 |
| blackboxsw | but yes please file a bug https://bugs.launchpad.net/cloud-init/+filebug | 16:14 |
| Odd_Bloke | smoser: Thanks for the review! (And the trust. ^_^) | 16:50 |
| blackboxsw | minor question on 223 Odd_Bloke but otherwise +1 | 17:03 |
| Odd_Bloke | blackboxsw: Thanks; responded. | 17:05 |
| blackboxsw | oops Odd_Bloke, glad you reminded me about that, forgot we added it last upstream cut, and didn't adjust the upstream trello template for it. | 17:11 |
| rharper | meena: do you know if the free/net bsd images have util-linux available (in particular wondering if sfdisk is present) ? | 17:49 |
| meena | https://www.freshports.org/search.php?stype=name&method=match&query=until-Linux&num=10&orderby=category&orderbyupdown=asc&search=Search&format=html&effort=1&branch=head | 18:09 |
| meena | https://www.freshports.org/search.php?stype=pkg-plist&method=match&query=sfdisk&num=10&orderby=category&orderbyupdown=asc&search=Search&format=html&branch=head aaaaand, maybe | 18:11 |
| rharper | meena: do the cloud images typically have that or do they use gpart ? | 18:12 |
| meena | of course not | 18:12 |
| rharper | ok, thanks | 18:13 |
| meena | let's find out what you want from sfdisk, and how to do that with what we have | 18:14 |
| rharper | oh, working on cc_growpart changes and was wondering whether freebsd images ever end up taking the path down use of growpart (which relies on either sfdisk or sgdisk); from the code, I would expect gpart to be used on bsd; and growpart on linux; | 18:15 |
| rharper | hoping to confirm that | 18:15 |
| meena | it's easier on zfs, which is what i use | 18:18 |
| meena | but, yeah, gpart resize should have you set | 18:30 |
| Goneri | rharper, I've some prebuilt images here https://bsd-cloud-image.org/ | 18:32 |
| Goneri | rharper, you may find that useful | 18:32 |
| rharper | Goneri: thanks ! | 19:03 |
| Odd_Bloke | smoser: master failed as expected: https://travis-ci.org/canonical/cloud-init/builds/653174091 | 21:00 |
| Odd_Bloke | rharper: blackboxsw: Could I get one of you to review https://github.com/canonical/cloud-init/pull/224 please? (ubuntu/devel for the focal upload.) | 21:55 |
| blackboxsw | grabbing | 21:55 |
| blackboxsw | comparing against mine | 21:56 |
| Odd_Bloke | Thanks! | 21:57 |
| blackboxsw | Odd_Bloke: +1 are you going to build-and-push then | 21:59 |
| blackboxsw | I think we intentionally don't merge those PRs | 21:59 |
| blackboxsw | specifcally: /home/csmith/src/uss-tableflip/scripts/build-and-push is what I was referring to | 22:00 |
| Odd_Bloke | I've not used that script before, let me take a look. | 22:09 |
| Odd_Bloke | I don't seem to have that script locally? | 22:10 |
| Odd_Bloke | I'll just build/push manually as I have in the past. | 22:11 |
| Odd_Bloke | blackboxsw: Do we have docs on how to do https://trello.com/c/5kz3z848/18-publish-to-copr-el-testing-repo ? | 22:13 |
| blackboxsw | Odd_Bloke: only that checklist, which at the moment is broken because of our py3 switch and paride is intending to look at things after Utah py3 | 22:14 |
| blackboxsw | I think we might have to block that aspect of things as run-contraner centos/7 etc won't work at the moment. | 22:14 |
| Odd_Bloke | blackboxsw: I don't see a checklist? | 22:16 |
| Odd_Bloke | blackboxsw: (And what's the problem with `run-container centos/7` ATM?) | 22:16 |
| blackboxsw | https://trello.com/c/oDCHFP8W/6-publish-upstream-version-to-copr-el-testing-repository | 22:16 |
| rharper | Odd_Bloke: cent7 + py3 = broken build | 22:16 |
| blackboxsw | Odd_Bloke: sorry I thought we were looking at the same card. weird the card copy didn't contain that checklist | 22:17 |
| rharper | Odd_Bloke: since the py2 drop, we don't have a building cloud-init daily on cent7 as cent7 doesn't have proper py3 support | 22:17 |
| Odd_Bloke | Right, I'm aware of that. | 22:17 |
| blackboxsw | Odd_Bloke: rharper right, and otubo mentioned he might be able to find us a contact in CentOS/7 space that could help us locate the correct missing python3 package deps for CentOS/7 and or 8. | 22:17 |
| rharper | ISTR, we effectively want cent7 daily to be held at 19.4 (origin/stable-19.4) | 22:18 |
| Odd_Bloke | Just wasn't sure what that had to do with run-container? | 22:18 |
| rharper | and the fedora-build branch I proposed enables F28+ and centos8 to work on py3 | 22:18 |
| rharper | Odd_Bloke: nothing directly | 22:18 |
| blackboxsw | Odd_Bloke: right, my magic missing checklist has those steps which rely on run-container centos/7 to build the rpm spec file that we upload to copr | 22:18 |
| Odd_Bloke | OK, fair enough. | 22:18 |
| Odd_Bloke | blackboxsw: OK, and (hopefully) finally: https://trello.com/c/gYoMXSdz/30-bump-cloudinit-revision-to-upstreamnewversion looks to me like it's done as part of other steps now, can it be garbage collected? | 22:20 |
| Odd_Bloke | Or am I misunderstanding it? | 22:20 |
| blackboxsw | Odd_Bloke: did you happen to copy over the checklist into the trello card https://trello.com/c/oDCHFP8W/6-publish-upstream-version-to-copr-el-testing-repository just now? | 22:20 |
| blackboxsw | oooooh we have duplicate copr upload cards | 22:20 |
| blackboxsw | one in Cutting SRU and one in pre-sru lane | 22:20 |
| blackboxsw | and the one in pre-sru lane doesn't have the steps | 22:20 |
| Odd_Bloke | Haha, OK, that explains it. | 22:21 |
| Odd_Bloke | So are we skipping the COPR step entirely, or am I building a SRPM and publishing it anyway? | 22:21 |
| blackboxsw | Odd_Bloke: and yes that card on bumping upstream version needs garbage collection (and removal from template) | 22:21 |
| blackboxsw | it was pre me writing that silly uss-tableflip/script/upstream-release at end of last upstream | 22:22 |
| blackboxsw | Odd_Bloke: I think we can skip and talk about that at standup tomorrow | 22:22 |
| blackboxsw | I think it should block on us resolving our tools/run-container issue with centos/7 & 8 builds | 22:22 |
| blackboxsw | per paride's work | 22:22 |
| Odd_Bloke | Cool. | 22:24 |
| Odd_Bloke | blackboxsw: Speaking of that script, I found a few hard-coded values: https://github.com/CanonicalLtd/uss-tableflip/pull/35 | 22:25 |
| blackboxsw | Odd_Bloke: for reference as well rharper wrote up this manual build process and discussion for el-stable and el-testing if we decide eventually to drop some of tools/run-container support https://github.com/CanonicalLtd/uss-tableflip/blob/master/doc/copr-repo-el-repos.md | 22:26 |
| blackboxsw | but I'm guessing you've seen that already | 22:26 |
| Odd_Bloke | blackboxsw: I'll pick up those documentation/script fixes tomorrow. | 22:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!