14:59:20 #startmeeting fedora_cloud_meeting 14:59:20 Meeting started Thu Aug 19 14:59:20 2021 UTC. 14:59:20 This meeting is logged and archived in a public location. 14:59:20 The chair is davdunc. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:20 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:59:20 The meeting name has been set to 'fedora_cloud_meeting' 14:59:52 #topic roll call 14:59:55 .hi 14:59:56 dustymabe: dustymabe 'Dusty Mabe' 15:00:16 #chair dustymabe 15:00:16 Current chairs: davdunc dustymabe 15:00:55 .hi 15:00:56 dcavalca: dcavalca 'Davide Cavalca' 15:01:03 #chair dcavalca 15:01:03 Current chairs: davdunc dcavalca dustymabe 15:02:32 okay. we'll let others filter in. 15:02:42 .hello ngompa 15:02:43 Eighth_Doctor: ngompa 'Neal Gompa' 15:02:55 #chair Eighth_Doctor 15:02:55 Current chairs: Eighth_Doctor davdunc dcavalca dustymabe 15:03:01 #topic Action items from last meeting 15:03:31 alright, since I borked the meeting details last week I had to dig for action items. 15:03:50 one was the state of the cloud talk. 15:03:58 That is done. 15:04:42 Any other action items we need to make sure are on the roll? 15:04:59 none that I know of 15:05:36 okay - do we have specific issues we want to cover today. I don't think anything is marked with meeting tag. 15:06:25 I don't have anything specific 15:06:31 do we have any changes we should plan for f36? 15:06:37 probably can close https://pagure.io/cloud-sig/issue/333 15:06:49 dcavalca: if we have any now would be a good time :) 15:07:00 yea. that's a great topic. 15:07:20 #topic changes we should plan for f36 15:07:38 I think we solved pretty much everything 15:08:01 I would like for Fedora Cloud to become available in Azure at some point 15:08:21 yeah, I was going to bring up images for more cloud provides, but I dunno if that needs a Change 15:08:29 for `$DAYJOB`, we're using both AWS and Azure, and it'd be great to have Fedora Cloud Azure images... 15:08:33 doesn't need a change 15:08:33 yes. Let's make that happen for f36 15:08:48 ha - i've been trying to make that happen for years 15:08:57 I'll work on the Azure Marketplace discussions. 15:09:11 actually, do we have a GCP image already? last I checked I couldn't find one on the marketplace 15:09:20 if themayor can make it happen for his distro, we can too. 15:09:28 dcavalca: we have one yes 15:09:47 oh good, I probably just missed it then 15:09:47 it's not necessarily in the marketplace 15:09:49 we had a request for this for a while too: https://pagure.io/cloud-sig/issue/309 15:10:10 yea. The images are on the cloud page. 15:10:17 https://alt.fedoraproject.org/cloud/ 15:10:38 #link https://pagure.io/cloud-sig/issue/309 15:10:44 davdunc: they actually are already uploaded too 15:10:45 cool, yeah I think in general we should strive to get these in the various marketplaces for visibility 15:10:57 blech, Matrix is being slow to sync, so I'm on IRC now 15:10:59 and also to make it harder for people to publish fake fedora images with malware and stuff 15:10:59 .hello ngompa 15:11:00 King_InuYasha: ngompa 'Neal Gompa' 15:11:16 but yeah, we have AWS and GCP now, but Azure is missing 15:11:18 dcavalca: the specific problem with the marketplace presence is the contracts. 15:11:23 #chair King_InuYasha 15:11:23 Current chairs: Eighth_Doctor King_InuYasha davdunc dcavalca dustymabe 15:11:35 with us now producing UEFI based images, we can actually ship to Azure something useful 15:11:46 that's the big thing! 15:11:49 https://pagure.io/cloud-sig/issue/328 has notes where I uploaded the GCP image 15:12:06 although, I just found out that those images are not compatible with AWS snow* devices. 15:12:13 Azure requires us to upload flat, fat VHD files 15:12:26 davdunc: snow* devices? 15:12:36 King_InuYasha: table for chatter. :D 15:12:46 got it 15:13:03 but yeah, since we're in a good place for Cloud Edition, we should push to get it in Azure 15:13:12 it's the remaining major one missing 15:13:22 +1 15:14:24 okay. I'll take the action to pick up the conversation with our Azure contacts and determine what needs to be done there. 15:14:44 awesome 15:14:47 #action davdunc create a plan of action for Azure images 15:15:18 is there anything we want to include in the images additionally? 15:15:46 probably the HyperV/Azure agent 15:15:56 that makes sense. 15:16:10 do we do that for the GCP images as well? 15:16:14 yes 15:16:41 yea. seems obligatory. 15:16:53 is it packaged already? 15:16:55 we used to just do plain cloud-init for GCP, but ericedens asked to swap things over to their stuff 15:16:57 so we did 15:17:28 King_InuYasha: they value their boot time and it's part of how they get it. It's understandable. 15:17:29 we do have WALinuxAgent in Fedora: https://src.fedoraproject.org/rpms/WALinuxAgent 15:17:57 super, so including it won't be complicated and we can just add that image. 15:18:13 do we have a testing account dustymabe ? 15:18:19 for.. azure? 15:18:22 yes. 15:18:24 no 15:18:33 okay. I'll add that to the plan. 15:18:41 well . let me check 15:18:41 we also need to be able to produce Azure VHD files 15:18:46 I can get one via FB if needed 15:19:10 I won't be able to give you account access, but I can probably spin up a few boxes that we can use for testing 15:19:14 it would be best if we had an account gifted to us from MSFT specifically for fedora 15:19:18 yeah 15:19:21 dcavalca: we will need somewhere to publish the images officially. it's better if we can have them sponsor it for fedora. 15:19:25 but yeah, we should get a proper Fedora account 15:19:36 dustymabe types faster. 15:19:45 https://docs.microsoft.com/en-us/azure/virtual-machines/linux/create-upload-centos 15:20:05 we have to create fat, fixed disk VHD files (no thin provisioned dynamic VHDX image files) 15:20:23 I don't know how we create the image files, so whatever mechanism that is needs to be extended 15:20:54 understood. it's image-factory, no? 15:20:55 and apparently we need UDF support (that's the first time in a while I've heard of UDF...) 15:20:58 davdunc: yep 15:21:24 that's not too hard. 15:21:46 * dustymabe notes FCOS creates azure images 15:22:15 https://getfedora.org/en/coreos/download?tab=cloud_operators&stream=stable 15:22:36 they don't upload to Azure either, though 15:22:42 nope. same problem 15:23:00 so we'll collectively work with fedora-cloud to break down that barrier 15:23:10 well, if we solve it for cloud, we solve it for coreos 15:23:20 yea. 15:23:27 that'd be nice 15:23:38 it will be fun to do. 15:23:39 that may also unblock other Microsoft-y things 15:23:42 like WSL 15:23:47 mmm. 15:23:52 iirc, it's all gated around the same problem 15:24:41 is there anything else we want to add to f36? 15:24:50 well.. 15:25:02 subvolumes requirements? additional boot parameters? 15:25:06 fcos has a couple of broad level changes we'd like to start pushing at a higher level 15:25:12 we probably want to deprecate BIOS in f36 15:25:17 i.e. sane defaults for "server like" editions 15:25:21 and evaluate subvol stuff for cloud-y things 15:25:42 and maybe we can work with cloud to help push those through 15:25:48 one thing that'd be nice to do as fedora cloud + fedora coreos + fedora desktop is moving rpmdb path 15:25:52 and dnfdb path 15:26:00 King_InuYasha: "deprecate BIOS" -> doubtful 15:26:06 i mean... bios is not going away for a lot of instance types at Amazon EC2 , but I like the idea. 15:26:16 dustymabe: note, not *retire* 15:26:30 ah. 15:26:34 retiring is quite a different thing, but we need to signal providers to start caring about UEFI at some point 15:26:42 otherwise we're stuck 15:26:55 I hate to say it, I don't think we have any pull here 15:27:18 if our images stop working I don't think the providers are going to care that much 15:27:22 yea. that reaches back into the snow* discussion and I'll get back to that, but yes.. deprecated should be a goal. 15:27:28 if it was centos or RHEL or ubuntu, maybe 15:27:35 well, with the exception of AWS, we're all UEFI 15:27:41 fedora first. 15:27:44 and davdunc is working to move AWS Fedora to UEFI 15:27:52 the reality is that's basically deprecated anyway; basically no work goes into it. 15:27:58 King_InuYasha: I think it's a good direction for us. 15:28:15 The older instance types aren't really a target for new or burstable workloads. 15:28:15 and the actual hardware is finally starting to go away (though that doesn't matter for virt) 15:28:16 dustymabe: there's certainly an opportunity to coordinate with RHEL folks on this 15:28:19 almost every VM I run on my local system runs BIOS.. I doubt many people use `--boot uefi` 15:28:34 dustymabe: yes, we'll need to start flipping defaults in the KVM stack too 15:28:47 flipping that default would really help things 15:28:48 deprecation of BIOS means we need to work with *everyone* to start preferring UEFI 15:28:59 King_InuYasha: that's a good point. 15:29:24 ok, but yeah. I think we need to coordinate more with other distros 15:29:28 we need to do it anyway because I expect the CSM is gone from UEFI implementations starting next year 15:29:32 if we do it by ourselves people are just going to use something else 15:29:36 sure 15:29:46 but again, I'm not suggesting retiring anything 15:30:05 what exactly do you mean by "deprecate" then? 15:30:07 we have hybrid BIOS+UEFI images, I don't expect that to go away anytime soon 15:30:08 if it's deprecated for some indefinite period, I think we are good. 15:30:26 King_InuYasha: regardless of the status of shipping CSM, intel's not shipping int 10h graphics drivers on new platforms 15:30:29 King_InuYasha: it might be a worthy goal to make a change for f36 or 37 to change the default for virt-install 15:30:36 f36 for sure 15:30:39 sooner the better 15:30:51 and we should ask rhel-virt team to see if they'd be willing to add that to el9 15:30:51 yes 15:31:22 pjones: are you saying, yes, tothe willing part? 15:31:35 or just "yes" to asking? 15:31:36 davdunc: no, I can't speak for them, I'm agreeing we should ask 15:31:52 dustymabe: deprecate means deprioritize bios and start the conversations to use UEFI 15:31:59 awesome. I thought you might know something I didn't know. 15:32:04 +1 King_InuYasha 15:32:04 King_InuYasha: means *formally* doing so. 15:32:11 pjones: yes 15:32:32 yea. like the common lisp library has been deprecated in emacs for the last several years. 15:32:33 I went through the crap this cycle to do hybrid boot so we could start doing that 15:33:34 I think it's a plan. 15:33:50 dustymabe: ideally, I'd like to coordinate with RHEL to see if we can do f36 + el9 work for this 15:33:59 it's not a *ton* of technical work, mostly policy work 15:34:17 King_InuYasha: perhaps you can discuss with the opensuse team? 15:34:25 certainly 15:34:27 I think that they are probably ready now. 15:34:33 all openSUSE images have been hybrid for ~5 years 15:34:36 King_InuYasha: you might be able to get some guidance from mhayden 15:34:58 or at least, they're supposed to be hybrid 15:35:12 davdunc: if you know of any not working in UEFI, let me know and we'll fix that 15:35:30 will do. 15:35:41 I can easily get SUSE on board through openSUSE work 15:35:47 provided we can flip libvirt's default to UEFI 15:36:01 well, that will be our stretch goal. 15:36:04 Or at least virt-manager if not libvirt itself? 15:36:07 indeed 15:36:10 and cockpit 15:36:12 yeah 15:36:21 #chair pjones 15:36:21 Current chairs: Eighth_Doctor King_InuYasha davdunc dcavalca dustymabe pjones 15:36:33 get in here pjones! 15:36:38 :D 15:37:05 btw, we *are* continually testing UEFI and BIOS now for Fedora Cloud 35 and Rawhide 15:37:08 (I am literally about to walk down the street to pick up my lunch in between post-tropical-depression-fred downpours... ;) 15:37:41 even for the minute you are here. You matter. 15:37:42 if it breaks, adamw will definitely tell us :D 15:37:59 perfect. 15:38:23 y'know, if i notice. 15:38:29 lol 15:38:30 .fire adamw 15:38:30 adamw fires adamw 15:38:33 sorry - habit 15:38:42 I don't think it works like that dustymabe :D 15:38:54 it's not recursive? 15:39:15 it has a limit! 15:39:46 okay. 15:39:50 so there it is. 15:39:57 I see a list forming. 15:40:17 We have two directives now for f36 timeline - 15:40:30 - Azure Images for f36 15:40:42 - deprecate BIOS along with our friends. 15:41:23 does anyone know if KVM UEFI includes a CSM? 15:41:33 I do not. 15:41:33 davdunc: it would be pretty cool to get an aarch64 image for vagrant 15:41:43 but unfortunately I can't really work on any of it 15:41:50 oh yeah, we probably want aarch64 vagrant images because M1 macs 15:41:51 King_InuYasha: I don't recall if they do or not, if they do it's just another seabios wrapper 15:41:55 dustymabe: that's something I can take on. 15:42:05 pjones: do you know who I can talk to about that? 15:42:16 I'd mail lersek 15:42:29 sweet 15:42:36 #action davdunc to work on aarch64 vagrant images 15:43:13 okay. anything else to add to our list? I have 3 initiatives here. 15:44:03 how about publishing metrics? 15:44:27 or at least collecting some performance indicators so we can add that to our goals? 15:44:34 do we have the ability to do those? 15:44:54 we could weave them into some CI work. 15:45:33 there's also dustymabe asking about doing some beneficial stuff for fcos + fedora cloud like moving rpmdb to /usr/lib/sysimage/rpm like openSUSE did 15:45:36 what kind of metrics do you have in mind? 15:45:40 oh right. 15:45:49 and in addition, moving dnfdb too like I did in openSUSE 15:46:03 dcavalca: boot time, disk i/o ... the basics. 15:46:12 which makes system snapshotting workable 15:46:33 would also be useful for desktop variants and if fedora server changes to btrfs 15:46:47 okay King_InuYasha yes. moving rpmdb and dnfdb is another one that makes complete sense. 15:47:06 again it should be coordinated with dustymabe and the coreos team too. 15:47:09 yep 15:47:11 +server. 15:47:18 et. al. 15:47:19 and desktop folks (workstation/kde) 15:47:43 that'll open the door for fancier subvolume setups 15:47:44 just had to get the kde in there didn't you? 15:47:46 yea. 15:47:46 :D 15:48:18 like separate /var like cmurf keeps asking for 15:48:32 and other things of that nature 15:48:45 on the metrics dcavalca we have some specific metrics that are industry identified as "forward thinking" we should probably be identifying where we hit or miss the mark. 15:50:22 #topic open floor 15:50:28 got it, yeah that makes sense 15:50:41 alright. We have ten minutes left. Any new business we need to attend to? 15:50:57 "to which we need to attend..." for your grammarians. 15:51:05 lol 15:51:23 I don't have anything, though I'm excited at what we're doing with Fedora Cloud 15:51:34 what about the containers side of the house? 15:52:09 we talked about basically adopting that for the sake of keeping it alive and interesting. Is that reasonable? 15:52:23 I think we're kind of stuck on finding out what the containers uses to evaluate storage graph drivers 15:52:35 ah yes. 15:52:50 I definitely think we should switch Fedora Cloud to btrfs driver for things, but we need to know how to judge said driver first 15:53:11 eventually I want to also do transactional-update fedora cloud variant 15:53:35 https://pagure.io/cloud-sig/issue/332 (btrfs driver for container tools) 15:54:05 King_InuYasha: I think that would be good, but we got the early push back on the use case. I don't think we should abandon it. 15:54:17 #topic https://pagure.io/cloud-sig/issue/332 15:54:26 yeah, I don't want to abandon it 15:54:42 my understanding is that the btrfs driver is supposed to support all rootless and rootful cases 15:54:52 but we don't know how containers team evaluates this stuff 15:55:18 cmurphy was talking about how we need the testing in place first. That's a good place to start. 15:55:23 yup 15:55:43 using btrfs as the backing driver has the potential to improve I/O performance considerably, too 15:55:46 we should keep that discussion open in #fedora-cloud for now and maybe work as a team on that deliverable. 15:56:46 #topic open floor 15:56:54 anything else? 15:57:06 3 minutes. 15:57:10 nope 15:57:27 okay then. .. great meeting everyone! 15:57:34 #endmeeting