17:00:10 <pboyHB> #startmeeting fedora-server
17:00:10 <zodbot> Meeting started Wed Sep  1 17:00:10 2021 UTC.
17:00:10 <zodbot> This meeting is logged and archived in a public location.
17:00:10 <zodbot> The chair is pboyHB. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:10 <zodbot> The meeting name has been set to 'fedora-server'
17:00:16 <eseyman> hello, folks
17:00:22 <pboyHB> #topic Welcome / roll call
17:00:44 <pboyHB> Welcome to our IRC meeting!
17:00:46 <jwhimpel> .hello jwhimpel
17:00:46 <eseyman> .hello
17:00:46 <zodbot> jwhimpel: jwhimpel 'John Himpel' <john@jlhimpel.net>
17:00:50 <zodbot> eseyman: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
17:00:59 <eseyman> .hello eseyman
17:01:00 <zodbot> eseyman: eseyman 'Emmanuel Seyman' <emmanuel@seyman.fr>
17:01:38 <dcavalca> .hi
17:01:39 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
17:01:54 <pboyHB> Hi eseyman. hi jwhimpel. hi dcavalca
17:02:05 <pboyHB> Good to meet you!
17:02:17 <pboyHB> I’ll post the agenda in a few minutes
17:02:28 <pboyHB> we'll give a few minutes for folks to show up
17:03:52 <pboyHB> #topic Agenda
17:04:01 <pboyHB> #link https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/thread/6JS7MSAECHVZZZWJU2J5AEISMQBDXLJZ/
17:04:09 <pboyHB> 1. Follow up actions
17:04:18 <pboyHB> 2. Max size arm-32 exceeded, install media blocked
17:04:26 <pboyHB> 3. Facilitated deployment of key services by combining rpm and Ansible
17:04:33 <pboyHB> 4. Open Floor
17:04:40 <pboyHB> Any additions?
17:05:12 <eseyman> not from me
17:05:22 <pboyHB> Ok.
17:05:25 <pboyHB> 1. libvirt test day, anything new about this?
17:05:42 <pboyHB> langdon: Are you lurking?#
17:06:40 <pboyHB> Ok. langdon just wrote me he'll back next meeting.
17:06:58 <pboyHB> 2. Issues #32 & #48: Synchronize Server full install and net install iso images, I suppose there is nothing new?
17:07:30 <pboyHB> Obviously not.
17:07:41 <pboyHB> #proposed TASK: Synchronize Server full install and net install iso images (ticket 32 & 48) postponed until after release Fedora 35
17:07:57 <pboyHB> any objections?
17:08:12 <eseyman> sounds fair
17:08:33 <pboyHB> #agreed TASK: Synchronize Server full install and net install iso images (ticket 32 & 48) postponed until after release Fedora 35
17:08:47 <pboyHB> #topic Max size arm-32 exceeded, install media blocked
17:08:58 <pboyHB> #link https://bugzilla.redhat.com/show_bug.cgi?id=1963007
17:09:09 <pboyHB> #link https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/thread/GP2J52JX3XETIOFH5BRIETHD2D6DAEZR/
17:09:17 <pboyHB> This matter is beyond my domain of expertise.
17:09:27 <pboyHB> As far as I know we have first to check Tdawsons hint there might be an unnecessary kernel module crept in.
17:09:35 <pboyHB> Arm-32 are incredible tiny devices (from a x86_64 perspective), so we should not just enlarge the max size parameter.
17:09:55 <jwhimpel> Has anyone checked to see if this is a release blocker?  I saw on the development M/L someone saying this may soon affect other editions as well.
17:09:58 <pboyHB> How do we proceed?
17:11:09 <jwhimpel> This is beyond my expertise as well.  Perhaps we could ask Adam Williamson of the QA team for assistance or mentoring.
17:11:12 <pboyHB> I'm not sure. But it is an official part of the distribution as fas as I know.
17:11:40 <eseyman> I was convinced that Neal was going to investigate. Am I misremembering?
17:12:04 <pboyHB> Stephen Gallagher is our most experienced member regarding installation media?
17:12:50 <pboyHB> eseyman: You are right. But I heard nothing from him
17:13:10 <pboyHB> sgallagh: Are you around ??
17:13:31 <sgallagh> I am, yes
17:13:51 <nirik> hum, looks to me like the limit has been changed to 4gb now...
17:14:22 <pboyHB> 4 gb is a lot for arm-32
17:14:32 * sgallagh reading the bug
17:15:24 <jwhimpel> pboyHB: If I remember correctly, this is a storage issue not a memory issue.
17:15:25 <nirik> hum, oh, I'm looking at only the list of blocking ones, this one is not blocking
17:16:12 <sgallagh> Right, armv7hl is only blocking for the xfce media, IIRC
17:16:21 <nirik> anyhow, it would be nice to get it smaller, but that will need work.
17:16:46 <pboyHB> Not only storage. Evtl is the kernel that is loaded disproportionately large according to Dawson.
17:17:20 <pboyHB> a potential prob for arm-32 devices
17:17:27 <sgallagh> Do we actually care about the netinst image for ARM?
17:17:46 <nirik> probibly not too much.
17:18:00 <sgallagh> I think our only realistic installation path for ARM devices is the disk images, not the installer.
17:18:41 <jwhimpel> If you're talking 32 bit than okay.  But net install for 64 bit is a big deal for me.
17:18:45 <pboyHB> sgallagh: ++
17:18:49 <dcavalca> sgallagh: I've seen the installed used for systems that support the EFI / SystemReady thing
17:18:58 <dcavalca> but that's all aarch64 iirc
17:19:02 <dcavalca> * installer
17:19:53 <cmurf[m]> adamw: https://bugzilla.redhat.com/show_bug.cgi?id=1963007 did the script that generates this bug report get triggered because netinstallers are all taken together?
17:20:11 <sgallagh> Right, I'm talking about 32-bit only here
17:20:20 <cmurf[m]> https://fedoraproject.org/wiki/Releases/35/ReleaseBlocking
17:20:20 <cmurf[m]> those are the release blocking images
17:20:29 <nirik> which this one is not
17:20:38 <cmurf[m]> line 4, >Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-_RELEASE_MILESTONE_.iso
17:20:45 <nirik> thats x86_64
17:20:58 <cmurf[m]> i wonder if the script considers any netinstaller as busting the 700M limit
17:21:17 <nirik> might be
17:21:29 <cmurf[m]> the netinstallers are based on boot.iso with a small number of add-ons for each edition/spin/arch
17:21:51 <cmurf[m]> so if 32bit arm is busting the limit, i'd expect all netinstallers are close to busting it
17:22:14 <cmurf[m]> but i'm not sure how the test script for this works :D
17:22:48 <nirik> yes, it appears that it checks all of them against 700
17:23:43 <cmurf[m]> also I think we had a way at blocker review to hand wave them through at beta for being too big, but also note that each working group and sig can just say "our limit is X" and change it to whatever value you want
17:24:11 <cmurf[m]> anyway, since 32 bit arm isn't blocking, then the bug is not actually blocking
17:24:21 <cmurf[m]> so you can just ignore the issue for now too
17:24:25 <cmurf[m]> (my 2 cents)
17:24:55 <pboyHB> We should achive a solution and be able to close the bug.
17:25:14 <pboyHB> May be just enlarge the limit to 800 ?
17:25:35 <pboyHB> (4 gb seems to be strange for arm-32)
17:25:37 <cmurf[m]> If you want, I can just write a comment in the bug and say "this is not a release blocking image, closing" and close it.
17:25:58 <nirik> FWIW, the current sizes: https://paste.centos.org/view/8b4147c0
17:26:08 <pboyHB> cmurf: ++
17:26:22 <cmurf[m]> It's 4G for Spins/armhfp/images/Fedora-Minimal-armhfp-RELEASE_MILESTONE-sda.raw.xz
17:26:30 <nirik> 32bit arm is likely larger because of the 2 kernels.
17:26:35 <cmurf[m]> but that is not the image in the bug, it's the netinstaller ISO
17:27:23 <cmurf[m]> the actual sizes is interesting, and a bit of a hunt for someone curious why there is such a huge range based on arch
17:27:39 <pboyHB> #proposed cmurf  write a comment in the bug and say "this is not a release blocking image, closing" and close it.
17:27:45 <cmurf[m]> like aarch64 is smaller than x86_64 by a lot, and yet 32bit arm is a lot bigger
17:28:02 <cmurf[m]> but that's sort of a trivia question, rather than urgently needing an answer
17:28:11 <cmurf[m]> that image is non-blocking so anyone can just say that and close the bug
17:28:41 <cmurf[m]> +1 i'm working on it now anyway
17:28:49 <nirik> closing it isn't a good solution IMHO
17:29:00 <pboyHB> cmurf: but we should take care about it as server wg.
17:29:11 <nirik> because it will just be still over the limit and a new bug will be opened on the next compose. ;)
17:29:17 <pboyHB> nirik: what can we do instead?
17:29:22 <pboyHB> nirik: ++
17:29:31 <nirik> ask for the limit to be raised...
17:30:04 <pboyHB> nirik: can we raise the limit for that iso?
17:30:09 <nirik> :If the maximum size used for this comparison is wrong, please add a comment and file a bug against relval at https://pagure.io/fedora-qa/relval/issues and it will be corrected. If you believe the canonical maximum size for an image should be changed, please follow the appropriate process before filing a relval bug."
17:30:28 <nirik> I think the appropriate process here is this group deciding to do it. :)
17:30:47 <jwhimpel> Does anyone on this chat know how to unpack an iso and compare the list of packages in each?
17:31:29 <cmurf[m]> OK so cmurf can also file an issue with QA and ask the limit be raised
17:31:34 <cmurf[m]> and i'll cite this bug
17:31:45 <cmurf[m]> if someone wants to look into the huge range in installers, super
17:31:58 <cmurf[m]> s/installers/netinstaller sizes/
17:32:55 * nirik notes again it's likely due to 2 kernels on arm32. We ship a normal and a lpae kernel there... so it has 2x the size. I suppose it could additionally be something else too...
17:33:20 <cmurf[m]> jwhimpel: ahh you could loop mount it and do some find and sort thing? or it might be easier to look at the image creation logs and find out if there's some package being included in some images but not others
17:33:45 <pboyHB> nirik: I feel a little lost on the subject. Could you take over and coordinate?
17:33:45 <sgallagh> nirik: Is there a strong reason to ship the non-PAE kernel?
17:34:00 <jwhimpel> I'll later ask PRobinson if both kernels are still needed via the ARM list.
17:34:17 <cmurf[m]> or also just check the current kernel build in koji and see if: kernel-core, kernel-modules, kernel-modules-extras have any significant size differences among the three archs in question
17:34:21 <nirik> sgallagh: the lape one isn't too good if you have less than 4gb memory?
17:34:30 <cmurf[m]> both kernels?
17:34:58 <cmurf[m]> ohhh there's an extra kernel included for the 32-bit arm ISO?
17:35:03 <cmurf[m]> well that'd explain it
17:35:06 <nirik> but I have no idea how many people use the lpae kernel. We do for our 32bit arm builders, but I bet we are one of the only places that does. ;)
17:35:34 <sgallagh> OK, can we stop shipping the LPAE one then, since almost no ARM32 devices have that much memory? ✌️
17:35:47 <cmurf[m]> (a) update the script to 800M (b) tell the script to not check armhfp netinstaller images
17:35:53 <nirik> sure, all it takes is someone working on it. ;)
17:36:56 <cmurf[m]> (a) I'm told is easy
17:37:02 <jwhimpel> pboyHB:  Put me down for a to-do to contact PRobinson asking if there is a need for a dual kernel on ARM netinstall.
17:37:32 <pboyHB> jwhimpel: yes. thanks.
17:37:54 <cmurf[m]> just use #action jwhimpel...
17:38:08 <pboyHB> #action jwhimpel will contact PRobinson asking if there is a need for a dual kernel on ARM netinstall.
17:38:26 <pboyHB> cmurf: I had to type in.  :-)
17:39:05 <pboyHB> Anythink else now or should we wait for the answer?
17:39:36 <pboyHB> OK, net topic
17:39:48 <pboyHB> #topic  Facilitated deployment of key services by combining rpm and Ansible
17:39:58 <pboyHB> We make progress with our work project:
17:40:06 <pboyHB> #link https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/thread/7DAT6CSQATOAHUL4YLLAFOG5LRWEEACQ/
17:40:21 <pboyHB> Floor is open
17:40:30 <jwhimpel> I've got the Wildfly install working, but it needs some cleanup work.  It should work for RHEL as well as Fedora.
17:40:47 <pboyHB> jwhimpel: ++
17:41:17 <nirik> cool
17:41:18 <jwhimpel> Wildfly is deprecating vault and replacing it with another subsystem.  So I need to work on that also.
17:41:50 <jwhimpel> Vault will be dropped from the next major Wildfly release.
17:42:34 <jwhimpel> I also need to refactor the basic install vs the configuration steps.
17:43:54 <jwhimpel> Hopefully in October I will be asking where to store the results so others can review and test.
17:43:59 <pboyHB> Besides the technology is an important question how distribute
17:44:10 <pboyHB> I would prefer a Fedory server centered way
17:44:17 <pboyHB> There was a discussion about that
17:45:30 <jwhimpel> There is an Fedora Ansible repository that I believe is maintained by Fedora Infrastructure.  I would hope we could put our content in that repository.
17:46:17 <nirik> no, thats for managing fedora infrastructure... not for distributing end user things
17:46:28 <pboyHB> Would be goot. I didn't know ttere is one at all
17:46:34 <nirik> I'd suggest a collection/ansible galaxy...
17:46:55 <eseyman> +1 for ansible galaxy
17:46:58 <jwhimpel> Then perhaps they could find some disk space and run an ansible galaxy instance for us.
17:48:08 <nirik> whats the advantage there over regular ansible galaxy?
17:48:30 <sgallagh> jwhimpel: Why not just use the public one?
17:48:59 <nirik> basically make a collection (stored in github/pagure/whatever) and publish to galaxy...
17:49:10 <jwhimpel> Good question.  I'm unfamiliar with using that facility.  So I'll try to do some research.
17:49:35 <nirik> and... package it up for fedora and we can ship it on the media/as a rpm
17:50:06 <pboyHB> sgallagh: We need some "profile bulding" and visability. How can we achive that?
17:50:06 <eseyman> I'll argue that ansible galaxy is the most visible place it makes sense to put our playbooks at
17:50:12 <jwhimpel> I also need to study up on Molecule as I assume we will want test cases as well.
17:50:44 <sgallagh> pboDefine "profile building" for me?
17:51:07 <sgallagh> s/pboDefine "profile building" for me?/pboyHB: Define "profile building" for me?/
17:51:28 <nirik> being able to find it in main ansible galaxy seems much more discoverable/higher profile than our own instance no one knows about.
17:51:55 <jwhimpel> Nirik: It can't be shipped as an rpm as it contains binary jars.  I do not have the bandwidth or knowledge to locate, maintain sources for hundreds of jars.
17:52:02 <sgallagh> nirik: +1
17:52:41 <nirik> jwhimpel: oh, I thought this was just the playbooks to download and install that. I am not suggesting packaging wildfly, but just the scripts for the user to download and install/etc?
17:53:08 <pboyHB> sgallagh: Product visibility and differentiation / specific characteristics in contrast to others. I admit, it's kind of marketing
17:53:33 <jwhimpel> Nirik: your suggestion for public Ansible Galaxy makes sense, I just need to do the research to see how to accomplish it.
17:53:55 <nirik> sure, I'm not sure whats involved myself. ;)
17:54:30 <sgallagh> jwhimpel: It's not too difficult; I can try to get you access to some good learning resources.
17:54:39 <jwhimpel> IMHO, I don't think it makes sense to package into rpm format ansible roles.
17:54:56 <jwhimpel> sgallagh: Thanks
17:54:58 <sgallagh> jwhimpel: We actually already have some.
17:55:26 <sgallagh> jwhimpel: https://koji.fedoraproject.org/koji/packageinfo?packageID=27782
17:55:37 <nirik> yes, there's a number of collections packaged now.
17:56:29 <jwhimpel> sgallgh:  Thanks for the reference.  I'll look further at this possiblity.
17:56:39 <pboyHB> Folks, time is going up. I would like to switch to Open Floor in a minute.
17:57:23 * sgallagh pulls the lever and the trapdoor swings open beneath us
17:57:48 <pboyHB> #topic 4. Open Floor
17:58:12 <pboyHB> Nothing specific from me here. Any news?
17:59:15 <pboyHB> I FORGOT: Big thanks to jwhimpel for his work. I am very excited!
18:00:21 <sgallagh> jwhimpel++
18:00:23 <zodbot> sgallagh: Karma for jwhimpel changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
18:00:43 <pboyHB> Time is up. Many thanks to everybody! see you in 2 weeks
18:01:04 <pboyHB> #endmeeting