16:00:22 #startmeeting fedora_cloud_meeting 16:00:22 Meeting started Tue Jul 7 16:00:22 2020 UTC. 16:00:22 This meeting is logged and archived in a public location. 16:00:22 The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:22 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:22 The meeting name has been set to 'fedora_cloud_meeting' 16:00:29 #topic roll call 16:00:31 .hello2 16:00:31 .hello ngompa 16:00:31 dustymabe: dustymabe 'Dusty Mabe' 16:00:34 King_InuYasha: ngompa 'Neal Gompa' 16:00:46 .hello2 16:00:47 otubo: otubo 'Eduardo Otubo' 16:01:50 .hello2 16:01:51 clcollins: clcollins 'Chris Collins' 16:02:42 .hello2 16:02:43 michaelgugino: michaelgugino 'Michael Gugino' 16:03:26 #chair King_InuYasha otubo clcollins michaelgugino 16:03:26 Current chairs: King_InuYasha clcollins dustymabe michaelgugino otubo 16:03:32 thanks all for coming :) 16:03:34 #topic Action items from last meeting 16:03:55 * King_InuYasha to create a ticket to discuss possible future feature of 16:03:58 btrfs for cloud base 16:04:24 #info King_InuYasha created #308 for us to discuss btrfs 16:04:28 #link https://pagure.io/cloud-sig/issue/308 16:04:31 thanks King_InuYasha for that 16:04:37 no problem 16:04:58 the change for desktops is in FESCo right now 16:05:23 https://pagure.io/fesco/issue/2429 16:05:47 #topic regular releases: uploading to clouds 16:05:54 #link https://pagure.io/cloud-sig/issue/301 16:06:05 michaelgugino: any progress to report here? 16:06:17 No, sorry. 16:06:48 It happens 16:06:58 so... SUSE's got mash (yeah, I know...) which does this for *all the clouds*: https://github.com/SUSE-Enceladus/mash 16:07:48 King_InuYasha: the piece michaelgugino is working on right now is more of a "listen to messages and do $action" part 16:08:04 which we'll need for whatever $action ends up being 16:08:42 Yeah, I have no opinion on which part does the $upload portion. Whatever is easiest/best. 16:08:51 ah 16:09:32 anything else on this topic for now ? 16:10:23 #topic swaponzram for the cloud base image 16:10:29 #link https://pagure.io/cloud-sig/issue/307 16:10:33 so we discussed this last time 16:10:53 not much has changed since then, but I did want to bring up a point which might be interesting to some people 16:11:37 one sec 16:11:57 https://paste.centos.org/view/fe0cc4d0 16:12:30 what's interesting to me about this configuration file is `host-memory-limit` 16:12:46 which is "The maximum amount of memory (in MiB). If the machine has more RAM than this, zram device will not be created." 16:13:24 I think this might alleviate some concerns that michaelgugino and jdoss were having about setting up swap 16:13:35 .hello2 16:13:36 jdoss: jdoss 'Joe Doss' 16:13:44 we could theoretically set that value to whatever we wanted it to be 16:14:48 i'll add this info to the ticket, but figured I would check to see if that detail changed any opinions here 16:15:17 so swaponzram is happening for workstation 16:15:37 I am still neutral negative on it. I haven't had a need for swap on my VMs but it might be time to change that. 16:15:37 My thinking remains the same. Make this opt-in. If it's useful, people will use it. After some time, if many are using it without ill effect, maybe turn it on by default. I haven't heard any serious/compelling usecase yet. 16:16:02 jdoss: but how large are your VMs ? 16:16:27 depends. .larges to 8xlarges back in the day on AWS 16:16:54 and all of those have more than 8G of RAM 16:17:05 ya more than 8GB for most workloads 16:17:32 right so those would see no change 16:17:50 basically this would help out people with less than $host-memory-limit RAM 16:18:02 where $host-memory-limit is what we choose it to be (we could use the default or change it) 16:18:48 if you're a serious cloud user this would almost guaranteed not affect you 16:18:48 what is the right limit? I just don't know what the performance gains are for each different use case. I feel that is the part that is missing here. 16:19:47 jdoss: yes we don't have that information 16:19:49 right, need more data. Need data on what the median usecase is, which applications will be negatively impacted. This might be a benefit for something like a build server, but it might greatly impact someone's database in a negative way and that's bad. 16:20:12 is someone's database running on an instance with < 8G of RAM? 16:20:14 probably not 16:20:40 my point here is that we're helping small test/development use cases with this change, but we're not hurting the large server use case at all 16:20:44 definitely possible. I would use a small instance for running a single wordpress site or something like that. 16:21:31 right and why would you use a small instance for that? 16:21:35 $$$$ right? 16:21:50 I don't know how we would test the "Cloud users that are using small RAM instances" does zswap really help? Do we know what the tipping point where actually having zswap is a negative? I think that is my biggest worry here. 16:22:38 right, we don't have that data 16:23:07 but can we agree that because of `host-memory-limit` we aren't worried about affecting large cloud instances ? 16:25:35 anyone ? 16:26:08 I would use whatever size instance I determined I needed. It might be 2G, it might be 8G, it might be 16G. I think lots of smaller projects are running on smaller instances obviously due to not using what you don't need. 16:27:26 michaelgugino: what about this statement? 16:27:31 can we agree that because of `host-memory-limit` we aren't worried about affecting large cloud instances ? 16:30:23 * dustymabe feels like he is alone in the room 16:30:45 sorry, was afk for sec 16:30:56 lurking - don't know enough to comment 16:31:20 me too 16:31:42 dustymabe: I'm not worried about impacting large instances if this stuff is disabled by default on large instances. 16:32:02 right. so we separate the problem space into two buckets 16:32:15 for large instances this isn't a problem because they see no change 16:32:25 for smaller instances we are interested in more data 16:32:46 and that should be enough of an update for the ticket for the discussion to continue along 16:32:57 I think that's fair. 16:33:20 though, can/should we decide to include the package in cloud for f33 already (i.e. the generator but not the config to enable it) 16:34:05 IIUC they are already broken out into two separate packages so just installing one is sufficient 16:35:29 If it's not on by default, I think maybe no. Keeping images smaller is ideal. 16:37:29 ok we'll leave it with just the problem separation update for now 16:37:36 anything else before we move to open floor? 16:38:43 #topic open floor 16:39:59 dustymabe: do you happen to know where the OKD rpms live? Are those hosted by fedora? 16:40:34 michaelgugino: I 16:40:55 I'm not super familiar with it all but I think they are built by openshift in their CI 16:41:46 I'm trying to sort out if there are 1) RPMs available somewhere I can download 2) SRPMs I can modify. 16:42:36 I'm naively assuming that FedoraCoreOS is using RPMs to build an RPM OSTree, lol. 16:42:59 for FCOS we only deliver RPMs built in Fedora 16:43:11 for OKD they layer stuff on top and deliver a modified OSTree 16:43:28 https://github.com/openshift/release/blob/248d72a6beb742f8dd8c71454034ab0a09ff670f/ci-operator/jobs/openshift/release/openshift-release-release-4.5-periodics.yaml#L580 16:43:37 you might be able to glean some information from ^^ 16:43:52 anything else before we close out the meeting? 16:44:03 anybody else want to volunteer to run the meeting next time? 16:52:27 Sorry I got pulled AFK 16:53:10 I think I am on vacation for the next meeting so I will be out. 16:59:31 dustymabe: openshift is not built as rpms currently 16:59:39 as far as I know, anyway 16:59:42 I could be wrong 17:02:49 * King_InuYasha is away to OKD WG meeting 17:21:01 I'm going to just end this meeting, it seems like we're done here... 17:21:04 #endmeeting