15:01:42 <adamw> #startmeeting Fedora QA Meeting
15:01:42 <zodbot> Meeting started Mon Jul 20 15:01:42 2020 UTC.
15:01:42 <zodbot> This meeting is logged and archived in a public location.
15:01:42 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:42 <zodbot> The meeting name has been set to 'fedora_qa_meeting'
15:01:46 <adamw> #meetingname fedora-qa
15:01:46 <zodbot> The meeting name has been set to 'fedora-qa'
15:01:54 <adamw> #topic Roll call
15:01:57 <adamw> morning morning everyone
15:02:08 <tablepc> .hello2
15:02:09 <zodbot> tablepc: tablepc 'Pat Kelly' <pmkellly@frontier.com>
15:02:11 <coremodule> good morning!
15:02:16 <coremodule> .hello2
15:02:17 <zodbot> coremodule: coremodule 'Geoffrey Marr' <gmarr@redhat.com>
15:02:21 <lruzicka> .hello2
15:02:22 <zodbot> lruzicka: lruzicka 'Lukáš Růžička' <lruzicka@redhat.com>
15:02:24 <tablepc> Good moring all
15:02:50 <tflink> morning
15:02:52 <lruzicka> more ning
15:03:27 <frantisekz> .hello2
15:03:28 <tablepc> I know what "more" is, but what is "ning"
15:03:28 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
15:04:10 <adamw> how's everyone doing
15:04:29 <tablepc> .adamw did you get my agenda request
15:04:31 <adamw> tablepc: a profound question indeed
15:04:38 <lruzicka> relatively fine
15:04:40 <frantisekz> fresh from PTO... awesome :)
15:04:57 <adamw> tablepc: i did now!
15:04:57 <tablepc> PTO is alwas good
15:05:15 <adamw> if cmurf is around i suspect he'll be able to answer your questions, we can roll it into the f33 changes discussion
15:05:23 <adamw> was going to mention that change there anyhow
15:05:30 <cmurf> .hello chrismurphy
15:05:31 <zodbot> cmurf: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
15:05:32 <adamw> frantisekz: it's all downhill from here!
15:05:53 <frantisekz> adamw: noooo, it can't be :O :D
15:05:55 <lruzicka> adamw, SuperG?
15:06:23 <adamw> lruzicka: well, if you think of those ones who miss the gate and go cartwheeling into the safety fence...=)
15:06:43 <lruzicka> :D
15:07:07 <adamw> alllrighty, let's get this party started
15:07:17 <tablepc> I was never good at cartwheeling
15:07:17 <adamw> #topic Previous meeting follow-up
15:07:36 <adamw> tablepc: the good side of spectacular skiing fails is, you get to learn to cartwheel pretty much for free!
15:07:51 <adamw> welp, we had no action items again last time
15:07:55 <adamw> it was mostly a check-in meeting
15:08:13 <adamw> so, moving on..
15:08:17 <lruzicka> seems like we are all set then
15:08:19 <adamw> #info no action items at last meeting
15:08:23 <adamw> #topic Fedora 33 status and Changes
15:08:51 <adamw> #info Rawhide is mostly okay at the moment, aside from a few known issues that are on the blocker list (FreeIPA being broken etc.)
15:08:57 * cmurf chuckles at 40+18 changes
15:09:16 <adamw> #info Several major changes have landed recently, including:
15:09:21 <tablepc> That's a bit frightening
15:09:27 <adamw> #info https://fedoraproject.org/wiki/Changes/SwapOnZRAM
15:09:34 <adamw> #info https://fedoraproject.org/wiki/Changes/BtrfsByDefault
15:09:44 <adamw> any others i'm missing?
15:09:47 <cmurf> nano
15:10:03 <tablepc> I kind'a like nano
15:10:29 <lruzicka> cmurf, is it vi+nano or -vi+nano ?
15:10:59 <cmurf> well those three have something in common, almost like i'm a brand name lightening rod or living up to my reputation as a small blue gnome
15:11:43 <adamw> cmurf: did that land yet? bugzilla isn't updated if so
15:11:46 <coremodule> a smurf™?
15:12:12 <cmurf> vi is still installed, but nano will be the default editor
15:12:26 <cmurf> so 'git commit' will bring up nano
15:12:49 <cmurf> i thought i'd changed swaponzram and btrfsbydefault trackers to modified
15:12:54 <cmurf> should it be onqa now?
15:14:00 <cmurf> nano pr just happened so it's in the process of landing
15:14:44 <tablepc> If I type nano at the CL it comes up fine
15:15:05 <adamw> cmurf: those two are updated, i meant the nano one
15:15:14 <cmurf> just set it to modified
15:15:15 <adamw> tablepc: nano is already in some default installs, yes
15:15:28 <adamw> cmurf: i'd usually set it to POST if the pr is proposed but not yet merged, but hey
15:15:57 <adamw> #info https://fedoraproject.org/wiki/Changes/UseNanoByDefault should land shortly
15:17:34 <adamw> ok, so tablepc had some questions about the swaponzram change - did you see those, cmurf?
15:17:49 <cmurf> nope
15:18:18 <tablepc> Sent to the list this morning
15:18:27 <adamw> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/UXAX44ONG5ZZ2UKV5T63NVGZSWFOAH6G/
15:18:29 * cmurf looking
15:19:16 <cmurf> ok sorry, BUT...
15:19:30 <cmurf> the change proposal and the very long devel@ discussions do answer this multiple times
15:19:49 <cmurf> the /dev/zram0 device is *not* a preallocation of RAM
15:19:53 <cmurf> it's dynamic
15:20:20 <tablepc> Monitor shows it as havinig claimed 2GB.
15:20:23 <cmurf> so if your workload never touches swap, the cost of swaponzram is the cost of the zram kernel module
15:20:38 <cmurf> the size of the /dev/zram0 device is virtual
15:20:56 <cmurf> so it is a 2GB block device backed by about 100K of memory
15:21:17 * sumantro is late, but finally here
15:21:21 <tablepc> Yes, I understand the size will increase if swap is used, but it seems to already clain 2GB as an anchor
15:21:50 <adamw> no, that's what cmurf is saying
15:22:22 <tablepc> So the 2GB monitor reports in not correct?
15:22:45 <adamw> it's not exactly 'not correct', in that that is really the notional size of the device
15:22:46 <tablepc> Disks says it's 4GB
15:22:52 <adamw> but it's not really 'occupying' that much memory all the time
15:22:54 <adamw> you're interpreting the readout wrongly, it's not really 'occupying' 2GB of RAM. your running processes could still use up to 8GB before swapping actually starts to happen
15:22:55 <cmurf> it's a matter of perspective
15:22:59 <adamw> (if i'm understanding it correctly)
15:23:06 <cmurf> and you're right to be confused because it is confusing
15:23:10 <adamw> =)
15:23:19 <cmurf> and chances are the GUI is making this harder
15:23:45 <cmurf> but if your perspective is looking at the /dev/zram0 block device, it's really a 2G swap in your case
15:24:11 <cmurf> but since it's dynamically allocated, just like tmpfs is, it's not really using any memory until called for
15:24:40 <tablepc> so as long as swap is 0 then the ram usage is zero too?
15:24:50 <cmurf> approximately
15:25:08 <cmurf> the overhead is less than 0.1% the size of the /dev/zram0 size
15:25:17 <tablepc> So I've sort of reclaimed the fixed 1GB Swap that used to be on disk?
15:25:27 <cmurf> correct
15:25:57 <adamw> also I believe this change doesn't have anything to do with the btrfs change, cmurf?
15:25:57 <tablepc> Okay I Knew you'd be able to help me understand this. THanks.
15:26:02 <adamw> they're independent of each other?
15:26:22 <cmurf> uhhh hmmm
15:26:43 <cmurf> yes
15:27:07 <tablepc> Okay good I had assumed that it was also making up for a performance issue in btrfs
15:27:08 <cmurf> i'm not thinking of a way in which they relate
15:27:28 <cmurf> btrfs is faster at some things and slower at some things, compared to ext4
15:28:01 <cmurf> mainly swaponzram is related to getting rid of large swap partitions that just extend swap thrashing and terrible performance and GUI responsiveness
15:28:02 <frantisekz> cmurf, how does it look around btrfs compressions? that could be one of the selling points of btrfs change...
15:28:07 <tablepc> We are humans here so we aren't as sensitive to tiny delays as servers are.
15:28:44 <cmurf> the SQL performance on Btrfs is curiously variable, it does well with some kinds of SQL databases and quite poorly with others
15:28:49 <cmurf> so that's being investigated
15:29:19 <adamw> #info tablepc was concerned about the swap-on-ZRAM Change constantly 'occupying' a chunk of system RAM, cmurf explained this is not how it works and there is not a constant sizable memory overhead, also clarified that it is not intended to compensate for performance issues in btrfs as tablepc assumed, the swap-on-zram and btrfs-by-default changes are independent
15:29:56 <cmurf> compression is decently likely, but it's really contingent on where the changes belong
15:30:15 <tablepc> Will compression still be an option?
15:30:47 <cmurf> you mean ability to disable it?
15:30:49 <tablepc> I prefer not to use compression so the question.
15:31:16 <cmurf> if the mount option is used, it'll be in fstab and you can just remove it
15:31:21 <Southern_Gentlem> what happens on equipment with >2gb of ram will swampon Zram happen?
15:31:56 <cmurf> if the selctive XATTR approach is used you can also undo that if you want, but it'd be applied only to high value targets, that'd be the point of such a "curated" approach
15:32:26 <cmurf> Southern_Gentlem: the /dev/zram0 device is sized to 50% of RAM, with a 4G cap
15:32:28 <cmurf> this is configurable
15:32:42 <cmurf> and as we  learn more it's possible to push new defaults to folks
15:33:07 <cmurf> there is a suggestion to move the cap higher, 6G or 8G
15:33:21 <tablepc> I like simple check boxes in Anaconda
15:33:38 <pwhalen> I have a question wrt to the brtfs change,  installs now defaults to btrfs no matter the installation type- including minimal headless installs, is this intended? Reading the change it seems it was to be more targeted to laptops/desktops
15:33:40 <cmurf> i doubt more checkboxes will be added in anaconda
15:34:29 <adamw> pwhalen: it depends more on exactly how you're installing than on the package set...
15:34:57 <cmurf> pwhalen: do you have an example? it might be unintentional, kickstarts is realllly tricky
15:35:00 <pwhalen> adamw: headless network install.
15:35:07 <adamw> pwhalen: from what image?
15:35:11 <cmurf> you mean Everything netinstall?
15:35:11 <tablepc> Well if btrfs is no the default the the check box for compression the is currently used for ext4 can be reused for btrfs install.
15:35:18 <tablepc> NOW
15:35:18 <pwhalen> pxe boot, from Everything
15:35:32 <adamw> as the change is written, Everything should retain current default, i think..
15:35:55 <cmurf> tablepc: no compression is used for ext4? you mean he squashfs image on the ISO?
15:36:36 <pwhalen> I filed a bz, wanted to clarify before nominating it - https://bugzilla.redhat.com/show_bug.cgi?id=1857798
15:37:03 <tablepc> On the disk screen in Anaconda for ext4 there is a check box to check if you want compression. If you don't check it, you don't get compression.
15:37:26 <cmurf> tablepc: i've never seen that, no idea what it is
15:38:08 <adamw> yeah, that doesn't sound familiar to me either
15:38:12 <cmurf> i'll add it to my pile haha
15:38:14 <adamw> are you confusing compression and encryption?
15:38:17 <tablepc> Do an Anaconda install of an ext4 drop and in the disk screen you see the check box for compression.
15:38:31 <cmurf> is this like some buried option? like the bootloader linky thing? haha
15:38:46 <cmurf> never seen a compression option in anaconda
15:38:54 <adamw> pwhalen: i agree with your reading there, there's a conflict between how the Change is described and what we did to implement it
15:39:05 * bcotton comes in very late
15:39:07 <tablepc> I'll have to install an old drop and sent a not to the list
15:39:24 <pwhalen> adamw: thanks, I'll nominate it for the blocker meeting
15:40:16 <adamw> dunno if it's a release blocker...
15:40:55 <Southern_Gentlem> tablepc, under custom or under blivet ?
15:41:48 <tablepc> Not sure not I'll do an install of an old drop and send a note to the list
15:42:03 <cmurf> pwhalen: Server netinstall still defaults to lvm+xfs
15:42:32 <cmurf> Everything is sort of this catch all that no one really "owns" and is now the most common way for desktops to get netinstalls
15:42:35 <pwhalen> cmurf: right, mentioned that in the bz. Server is the only thing not affected
15:43:15 <cmurf> is there another netinstall that uses lvm+ext4?
15:43:35 <cmurf> i can't think of one off hand
15:43:47 <pwhalen> The change specifically mentioned desktops and laptops being targeted
15:43:51 <adamw> we only build server and everything netinst at this point
15:44:08 <adamw> pwhalen: i guess the issue is, you can see the Everything netinst as being for...anything :)
15:44:17 <adamw> you can't tell whether it's being used to deploy a desktop or not
15:45:14 <cmurf> i support asking fesco directly rather than making it a blocker review decision
15:45:16 <pwhalen> Understood. But as its written it isnt clear it will affect *everything*
15:45:58 <cmurf> yep i hear what you're saying, but there's no great way to carve this out with the Everything image
15:46:01 <pwhalen> cmurf: sure, no issues there. I was looking for clarification as it seems unintended
15:47:46 <cmurf> if Everything is btrfs by default then some non-desktop/laptop things get btrfs by default; and if Everything is lvm+xfs then a bunch of desktops get lvm+xfs by default
15:47:51 <adamw> simplest thing to do might be to clarify if in the Change...
15:47:52 <cmurf> so either way there are unintended consequences
15:48:13 <adamw> pwhalen: it's worth noting we don't actually advertise the Everything netinst very hard
15:48:28 <cmurf> i think for PXE boot you'd advertise Server netinstall
15:49:18 <cmurf> Everything is a sort of legacy arifact too i believe
15:49:47 <adamw> pwhalen: you have to click through to https://alt.fedoraproject.org/
15:49:56 <adamw> and even there Server netinst is given more prominence
15:50:04 <pwhalen> adamw: it's how we install headless arm devices
15:50:13 <adamw> and Everything netinst is marked "Experts only!"
15:50:25 <adamw> sure, but then, you're an expert ;)
15:51:11 <adamw> okay, we've actually nearly eaten up the meeting...
15:51:37 <adamw> #info pwhalen noted that Everything netinst adopts the btrfs-by-default change which may be unexpected, we will flag this for further discussion: https://bugzilla.redhat.com/show_bug.cgi?id=1857798
15:51:37 <tablepc> and a very meaty meeting at that.
15:51:49 <adamw> .fire tablepc for excessive punning
15:51:49 <zodbot> adamw fires tablepc for excessive punning
15:52:01 <pwhalen> adamw: thanks
15:52:07 <adamw> #topic Test Day / community event status
15:52:15 <adamw> sumantro: around?
15:53:29 <sumantro> adamw, are going to have another btrfs test week and have a fedora magazine post which will attract more testers
15:54:00 <sumantro> i18n has set the date of 2020-09-08 as the test day date
15:54:32 <sumantro> cmurf, when do we want to start working towards the next test weeks?
15:55:03 <cmurf> sumantro: yeah i'll keep the test day convo to the QA test day ticket
15:55:21 <cmurf> i defer to QA on the timing, I can be ready
15:55:54 <sumantro> Apart from that, we will soon have a virt test day. I am yet to firm up the details but we will have more information by next week
15:56:02 <sumantro> adamw, thats all from my side
15:56:07 <cmurf> (Workstation WG has a separate ticket for testing which is about soliciting/collecting feedback)
15:56:10 <adamw> thanks!
15:56:23 <adamw> #info i18n Test Day will be 2020-09-08
15:56:27 <adamw> #info expect a virt test day soon
15:56:48 <adamw> what are you planning test weeks for?
15:56:51 <adamw> btrfs and swaponzram?
15:56:58 <cmurf> also a GNOME test day or week? i think?
15:57:22 <sumantro> GNOME test week will surely happen, just need to talk to kalev
15:57:35 <cmurf> pretty sure the idea was to also go through the packageset during that week and make sure the size is right, and enabled services are intended, etc.
15:57:45 <sumantro> cmurf, I will respond to the ticket and set up the things accordingly
15:58:04 <cmurf> adamw: do you want another swaponzram test day?
15:58:36 <sumantro> cmurf, test week?^
15:58:50 <adamw> cmurf: i was just guessing :)
15:58:51 <tablepc> Good idea I would like to make sure the zram goes back to zero when it can
15:59:12 <adamw> #info GNOME test week also being planned
15:59:27 <adamw> #topic Open floor
15:59:29 <adamw> any other business, folks?
15:59:34 <cmurf> tablepc: that's up to the program to garbage collect those anon pages
16:00:07 <tablepc> yeah but let's make sure it works
16:00:49 <tablepc> cmurf: Thanks
16:01:01 <cmurf> np
16:01:19 <tablepc> Have a Great Day Everyone!
16:01:55 <lruzicka> Yes, have a great time
16:02:08 <sumantro> have a great time all :)
16:02:17 <frantisekz> bye everybody!
16:02:26 <adamw> thnaks folks!
16:02:26 <cmurf> blocker review!
16:02:29 <adamw> especially cmurf
16:02:48 <adamw> #endmeeting