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