16:07:06 <dustymabe> #startmeeting fedora_cloud_meeting
16:07:06 <zodbot> Meeting started Tue Jun  8 16:07:06 2021 UTC.
16:07:06 <zodbot> This meeting is logged and archived in a public location.
16:07:06 <zodbot> The chair is dustymabe. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:07:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:07:06 <zodbot> The meeting name has been set to 'fedora_cloud_meeting'
16:07:12 <dustymabe> #topic roll call
16:07:14 <King_InuYasha> hey cmurf[m]
16:07:18 <dustymabe> .hi
16:07:20 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:07:42 <cyberpear> .hi
16:07:43 <zodbot> cyberpear: cyberpear 'James Cassell' <fedoraproject@cyberpear.com>
16:07:46 <King_InuYasha> hmm laggy
16:07:49 <King_InuYasha> .hello ngompa
16:07:51 <zodbot> King_InuYasha: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:07:52 <Eighth_Doctor> hey cmurf
16:08:02 <cmurf[m]> I'm confused. When I joined the #fedora:matrix.org rooms last week, I ended up in freenode...
16:08:18 <michel> not all rooms get converted at once I think
16:08:22 <Eighth_Doctor> they were rehomed last week
16:08:29 <King_InuYasha> oh dear, the backlog is syncing to IRC now
16:08:30 <Eighth_Doctor> and some still haven't changed
16:08:31 * michel notes this room is not in the Fedora Space yet either
16:08:31 <dcavalca> .hi
16:08:32 <zodbot> dcavalca: dcavalca 'Davide Cavalca' <dcavalca@fb.com>
16:09:05 <King_InuYasha> we're almost caught up to Matrix :)
16:09:06 <Eighth_Doctor> oddly enough, cmurf entering here stopped the bridge
16:09:14 <michel> crap
16:09:22 <michel> so... that happens when someone who's not bridged properly to IRC joined
16:09:23 <cmurf[m]> And the Element UI doesn't tell me what irc server im actually chatting in.
16:09:31 <Eighth_Doctor> it's not sending messages to IRC anymore, presumably because he's still not correctly logged into libera.chat
16:09:34 <Eighth_Doctor> oh, there we go
16:09:46 <michel> at least that's what someone in #libera-matrix:libera.chat said as a diagnosis
16:09:55 <Eighth_Doctor> .hello ngompa
16:10:00 <michel> .hello salimma
16:10:00 <zodbot> Eighth_Doctor: ngompa 'Neal Gompa' <ngompa13@gmail.com>
16:10:03 <zodbot> michel: salimma 'Michel Alexandre Salim' <michel@michel-slm.name>
16:10:39 * michel fires zodbot
16:10:51 <michel> .fire zodbot
16:10:53 <zodbot> adamw fires zodbot
16:10:57 <cmurf[m]> I see zodbot. How can i be bridged wrong if i see zodbot replies?
16:11:14 <dustymabe> let me know when I should proceed with the meeting
16:11:28 <King_InuYasha> I'll let you know
16:11:28 <michel> cmurf: looks like appservice finally noticed you, it just took a while
16:11:33 <michel> and until then sync was off
16:11:35 <cmurf[m]> .hello chrismurphy
16:11:36 <zodbot> cmurf[m]: chrismurphy 'Chris Murphy' <bugzilla@colorremedies.com>
16:12:01 <cmurf[m]> Ok now no zodbot reply
16:12:09 <Eighth_Doctor> just wait a sec, the events are synchronizing
16:13:01 <dustymabe> .hire zodbot
16:13:01 <zodbot> adamw hires zodbot
16:13:08 <King_InuYasha> haha
16:14:07 <dustymabe> proceed yet?
16:14:26 <King_InuYasha> Matrix is stuck it seems
16:14:37 <King_InuYasha> it's getting IRC events, but now Matrix events aren't coming back
16:14:52 <Eighth_Doctor> okay, now, let's see if we're in sync yet...
16:14:52 <michel> did zodbot drop Davide's intro?
16:14:57 <King_InuYasha> let's just start anyway...
16:15:01 <Eighth_Doctor> no, it was earlier up
16:15:10 <dcavalca> michel: still here
16:15:46 <cmurf[m]> That was fast
16:15:48 <King_InuYasha> dustymabe: let's start the meeting
16:15:50 <dustymabe> #chair King_InuYasha cmurf[m] michel dcavalca
16:15:50 <zodbot> Current chairs: King_InuYasha cmurf[m] dcavalca dustymabe michel
16:15:54 <michel> oh yeah, we're synced now
16:16:01 <dustymabe> davdunc around?
16:16:05 * King_InuYasha pokes davdunc
16:16:11 <dustymabe> #topic Action items from last meeting
16:16:14 <Eighth_Doctor> no we're not, IRC is going to Matrix faster than the other way
16:16:17 <davdunc> I am in the background.
16:16:22 <dustymabe> * davdunc will work on a Change proposal for switching to GPT with
16:16:25 <dustymabe> hybrid BIOS+UEFI
16:16:27 <dustymabe> * davdunc will investigate the issue with Fedora 34 Cloud nightly images
16:16:29 <dustymabe> not booting in AWS
16:16:31 <dustymabe> #chair davdunc
16:16:31 <zodbot> Current chairs: King_InuYasha cmurf[m] davdunc dcavalca dustymabe michel
16:16:32 <davdunc> .hello2
16:16:33 <zodbot> davdunc: davdunc 'David Duncan' <davdunc@amazon.com>
16:16:45 <davdunc> in an engineering meeting at the same time.
16:16:59 <dustymabe> any updates on action items?
16:17:22 <cmurf[m]> Please proceed.
16:17:36 <King_InuYasha> dustymabe: davdunc has submitted the GPT + hybrid boot proposal: https://fedoraproject.org/wiki/Changes/FedoraCloudHybridBoot
16:17:57 <dustymabe> #info davdunc has submitted the GPT + hybrid boot proposal: https://fedoraproject.org/wiki/Changes/FedoraCloudHybridBoot
16:18:02 <davdunc> yes. I think that this is a good time to seek alignment with the project as a whole.
16:18:14 <King_InuYasha> I don't know much about the progress on the nightly images though
16:18:40 <davdunc> they are working, but the openQA is not booting them.
16:18:47 <davdunc> need to look at why that is exactly.
16:19:01 <dustymabe> davdunc: so they work in AWS but not in openQA?
16:19:15 <davdunc> correct. I can upload and boot.
16:19:54 <dustymabe> can you run in QEMU/Libvirt?
16:20:24 <davdunc> I haven't attempted. I was too keenly focused on the target environment.
16:20:44 <dustymabe> might be a good data point
16:20:56 <davdunc> but there should be no blockers and I will add that as a test point.
16:21:04 <dustymabe> #info still debugging f34 cloud nightly image boot issues
16:21:31 <davdunc> I do want to know how we can update the openQA to include a worker on the specific cloud environments.
16:22:04 <dustymabe> #topics for this meeting
16:22:10 <dustymabe> #topic topics for this meeting
16:22:23 <dustymabe> What do you all want to discuss today. Throw out some links and I'll make a list
16:22:28 <dustymabe> https://pagure.io/cloud-sig/issues
16:22:56 <King_InuYasha> https://pagure.io/cloud-sig/issue/325
16:23:24 <dustymabe> anything else?
16:23:59 <King_InuYasha> https://pagure.io/cloud-sig/issue/329
16:24:37 <King_InuYasha> https://pagure.io/cloud-sig/issue/320
16:24:58 <dustymabe> ok
16:25:00 <King_InuYasha> that last one is mostly asking if we're actually *done* implementing this yet
16:25:08 <dustymabe> #topic Please publish Fedora AMI to af-south-1
16:25:12 <dustymabe> #link https://pagure.io/cloud-sig/issue/325
16:25:19 <davdunc> King_InuYasha: I am the bottleneck on 320
16:25:56 <King_InuYasha> maybe we can clear that out with the other changes for F35 images?
16:26:15 <dustymabe> ok so issues with af-south-1 region?
16:26:45 <King_InuYasha> I don't know much about this, but it's been lingering...
16:27:06 <davdunc> it's an "opt-in" wrappter
16:27:12 <dustymabe> davdunc: do accounts have to be "activated" when they first try to use a new region?
16:27:26 <davdunc> yes the region has to be added to the valid regions.
16:27:28 <dustymabe> i.e. "do you really want to use this region"
16:27:31 <dustymabe> ok
16:27:41 <dustymabe> any links you know of we could share with mobrien?
16:27:44 <davdunc> It's Capetown.
16:28:20 <davdunc> https://aws.amazon.com/blogs/security/setting-permissions-to-enable-accounts-for-upcoming-aws-regions/
16:28:38 <King_InuYasha> is there a reason we shouldn't have every region except CN ones enabled?
16:28:48 <davdunc> there is not.
16:29:28 <King_InuYasha> can we make it so it works that way instead?
16:29:48 <King_InuYasha> (I guess we could also have CN regions enabled too, but IIRC CN is "special")
16:29:49 <dustymabe> I just added a comment for mobrien
16:30:10 <dustymabe> some of the FCOS stuff detects new regions automatically
16:30:23 <dustymabe> let me check to see if we have an image in that region for FCOS
16:30:31 <King_InuYasha> davdunc: as you can tell, I'm cloud-dumb ^_^;;
16:30:46 <davdunc> CN is special, but I am working on pushing images to the Marketplace.
16:30:50 <dustymabe> `af-south-1: ami-06c96d24608e629c0 `
16:30:50 <davdunc> Ihave permissions.
16:31:11 <dustymabe> so FCOS is using it
16:31:22 <dustymabe> and it should be the same account
16:32:48 <dustymabe> so not sure why fedimg is getting the error
16:33:49 <dustymabe> should we move to the next topic?
16:34:09 <davdunc> maybe it was a one-time issue, but it's been fixed.
16:34:54 <dustymabe> #topic Add Ignition support to Fedora Cloud
16:34:57 <dustymabe> #link https://pagure.io/cloud-sig/issue/320
16:35:03 <dustymabe> I think jdoss has been hacking on this as a side project
16:35:36 <davdunc> that would be awesome.
16:35:38 <dustymabe> I personally think this is a no go unless we can figure out how to support them both
16:36:02 <King_InuYasha> I think the goal is to do both
16:36:20 <King_InuYasha> we need to figure out how to have cloud-init disable ignition and vice versa, though
16:36:21 <dustymabe> in that case, It's a neat idea
16:36:41 <dustymabe> King_InuYasha: I think they should just cue off of the metadata
16:36:52 <dustymabe> #cloud-config -> cloud-init
16:37:18 <dustymabe> json -> ignition
16:37:26 <King_InuYasha> cloud-config is yaml, so it can be json too
16:37:33 <cmurf> so ship and support both but deconflict, so that they are mutually exclusive at install time?
16:37:43 <dustymabe> cmurf: that's the goal
16:37:44 <King_InuYasha> no, they'll be both installed
16:37:53 <King_InuYasha> they're going to be mutually exclusive at runtime
16:38:03 <cmurf> got it
16:38:08 <dustymabe> i think that's what cmurf meant
16:38:31 <cmurf> runtime for ignition is installation part 2, or whatever the nomenclature would become
16:39:01 <dustymabe> cool - anything else to discuss on this ticket?
16:39:40 <King_InuYasha> I think we should come up with some tests to verify sanity of a dual ign+c-i setup
16:39:46 <King_InuYasha> but I don't know what that would be
16:41:01 <dustymabe> King_InuYasha: yeah I mean there's a lot that Ignition does (reformatting disks, etc) that might not work out of the box
16:41:08 <dustymabe> it's going to take some effort
16:41:55 <dustymabe> anything else for this topic?
16:42:01 <King_InuYasha> nope
16:42:51 <dustymabe> #topic fedora cloud image: enable ipv6 (accept RAs by default)
16:42:54 <dustymabe> #link https://pagure.io/cloud-sig/issue/320
16:43:28 <dustymabe> davdunc: I think you mentioned this earlier?
16:43:35 <jdoss> .hi
16:43:36 <zodbot> jdoss: jdoss 'Joe Doss' <joe@solidadmin.com>
16:44:00 <King_InuYasha> hey jdoss, you just missed us talking about ign+c-i on cloud images :)
16:44:03 <davdunc> i did. I said I would work on it and I have had other prioties here.
16:44:26 <jdoss> King_InuYasha: yah I see that. All good. I think what was talked about is spot on.
16:45:05 <dustymabe> davdunc: no worries
16:45:15 <dustymabe> davdunc: move to open floor then?
16:45:20 <dustymabe> Should we bring up the btrfs stuff?
16:45:22 <davdunc> thanks. it's still on my list and yes.
16:45:42 <King_InuYasha> I guess that's what cmurf and dcavalca are here for :)
16:45:56 <dustymabe> actually let me hit on this other topic real quick
16:46:04 <dustymabe> #topic  systemd-oomd by default
16:46:09 <dustymabe> #link https://pagure.io/cloud-sig/issue/324
16:46:21 <King_InuYasha> what do we need to do to do this?
16:46:26 <King_InuYasha> just finish implementing swap on zram?
16:46:50 <dustymabe> I'm thinking we enable swap on zram and then systemd-oomd
16:46:55 <dcavalca> I've added anitazha to that ticket in case she wants to chime in
16:47:00 <King_InuYasha> I'm good with that :)
16:47:04 <dcavalca> but yeah, you'll need swap for oomd to work properly
16:47:10 <King_InuYasha> hilariously, I thought we already did this in F34
16:47:10 <dcavalca> this seems like a good plan
16:47:15 <King_InuYasha> and found out we didn't :o
16:47:20 <cmurf> but also cgroups work for processes needs to happen
16:47:22 <michel> there's a reported issue on systems with too much physical RAM - but that won't affect cloud usages normally right?
16:47:31 <michel> it's just a matter of tweaking the defaults anyway
16:47:31 <cmurf> since oomd clobbers things by cgroup, not by process
16:47:40 <King_InuYasha> super, super, super unlikely to have _too much_ physical RAM
16:47:48 <dustymabe> dcavalca: what are the negatives of run systemd-oomd without swap at all?
16:48:03 <dcavalca> dustymabe: it won't work properly
16:48:06 <cyberpear> michel: what were those "too much RAM" issues?
16:48:22 <michel> King_InuYasha: yeah, I think it was an unintentional slippage, not including Cloud there. or... what does Cloud ship now for oom?
16:48:26 <cmurf> it can't kill based on swap pressure because there is none; so you get a ton of reclaim which looks similar to swap thrashing, but the process won't get killed
16:48:33 <dcavalca> dustymabe: see "setup information" in https://man7.org/linux/man-pages/man8/systemd-oomd.service.8.html
16:49:04 <dustymabe> dcavalca: should the service require swap then (as a condition check or something)
16:49:04 <cmurf> michel: nothing, earlyoom is not installed or enabled
16:49:21 <cmurf> ok nothing is incorrect, there is still the kernel's OOM killer
16:49:46 <dcavalca> dustymabe: that's a good point, I'll bring it up with Anita
16:49:51 <michel> cmurf: ah, then it makes sense, we were focused on replacing earlyoom. hmm.. ISTR the 'too much RAM' issue is different, but let me try and find it
16:49:57 <cmurf> but kernel OOM killer only triggers if the kernel thinks its life is threatened
16:50:09 <dustymabe> ^^ eat or be eaten
16:50:20 <King_InuYasha> hah
16:50:27 <davdunc> :)
16:50:40 <cmurf> too much RAM won't be an issue for zram because there is a cap by default; 100% RAM or 8G whichever is smaller
16:50:56 <Eighth_Doctor> oomd should be fine with the zram combo, then
16:50:56 <dustymabe> ok so to bring this back - enable swap on zram
16:51:00 <cmurf> so 8G /dev/zram0 device has fairly minimal overhead
16:51:07 <dustymabe> and systemd-oomd
16:51:19 <Eighth_Doctor> dustymabe: yup, swaponzram+systemd-oomd
16:51:25 <dustymabe> and maybe tweak systemd-oomd such that if someone turns off swap-on-zram, it just won't start
16:51:32 <Eighth_Doctor> which realigns us with everyone else
16:51:43 <King_InuYasha> #chair Eighth_Doctor
16:51:43 <zodbot> Current chairs: Eighth_Doctor King_InuYasha cmurf[m] davdunc dcavalca dustymabe michel
16:51:50 <dustymabe> we're trying to evaluate this for FCOS too
16:52:07 <jdoss> #chair jdoss
16:52:15 <King_InuYasha> #chair jdoss
16:52:15 <zodbot> Current chairs: Eighth_Doctor King_InuYasha cmurf[m] davdunc dcavalca dustymabe jdoss michel
16:52:22 <Eighth_Doctor> k8s systems would probably benefit from this by having two levels of swap
16:52:35 <Eighth_Doctor> the first level being "fast swap" and the second level being "slow swap"
16:52:48 <jdoss> IIRC k8s doesn't support swap yet or at least it is something that is being looked at as it is a blocker for FCOS?
16:52:51 <dustymabe> dcavalca: so anitazha would be able to tell us if we can have a condition check on swap for systemd-oomd service ?
16:52:52 <dcavalca> k8s doesn't work with swap
16:53:03 <dcavalca> dustymabe: yeah, I just pinged her
16:53:19 <cmurf> i'm reluctant to encourage two swaps on cloud, due to priority inversions
16:53:29 <dustymabe> cool, could you have her update the ticket with the answer to that question?
16:53:32 <Eighth_Doctor> cmurf: we wouldn't set up two swaps by default
16:53:36 <Eighth_Doctor> only zram swap
16:53:38 <dcavalca> dustymabe: yup, will do
16:53:51 <dcavalca> https://github.com/kubernetes/kubernetes/issues/53533 tracks swap support for k8s
16:53:54 <jdoss> swap-ception. swap within a swap
16:54:00 <dcavalca> looks like it's slated for 1.22
16:54:04 <dustymabe> dcavalca: if we get that behavior then for FCOS we can just enable systemd-oomd
16:54:04 <michel> dustymabe: so use different thresholds based on if swap is enabled?
16:54:20 <jdoss> Is k8s a blocker for fedora cloud too?
16:54:23 <dustymabe> then if the user set up swap, then they get systemd-oomd. If not, then it just will not start itself (condition check)
16:54:25 <cmurf> if you want two levels of swap you'd looking at zswap (front cache) and a conventional swap, that would be fine due to it's "least recently used" model for pushing things out of the cache and onto disk
16:54:55 <jdoss> because I really don't want k8s to dictate what we do for fedora cloud. It's one usecase.
16:54:58 <Eighth_Doctor> jdoss: k8s is not a blocker for cloud
16:55:00 <dustymabe> jdoss: no
16:55:06 <dustymabe> michel: i'm not sure I understand the question
16:55:13 <Eighth_Doctor> but it's a consideration for fcos, which dustymabe brought up
16:55:25 <dustymabe> yeah, sorry for polluting the conversation
16:55:29 <dustymabe> :)
16:55:46 <cmurf> but as it relates to cloud: zram based swap is probably better than no swap, and easy to disable for the k8s use case just by touching /etc/systemd/zram-generator.conf
16:55:58 <dustymabe> #proposed for f35 fedora cloud we will enable swap-on-zram and sytemd-oomd
16:56:09 <jdoss> +1
16:56:10 <dustymabe> ack/nack?
16:56:10 <Eighth_Doctor> besides, having zram swap might encourage k8s people to look into it more :)
16:56:20 <michel> +1
16:56:20 <Eighth_Doctor> dustymabe: +1
16:56:22 <michel> (if guests can vote)
16:56:37 <dcavalca> +1
16:56:39 <Eighth_Doctor> Michel Alexandre Salim: we'll make you a member soon, you've been helping us :)
16:56:47 <Eighth_Doctor> same for dcavalca
16:56:52 <dustymabe> #agreed for f35 fedora cloud we will enable swap-on-zram and sytemd-oomd
16:57:01 <dustymabe> michel: we don't have super strict rules
16:57:04 <jdoss> You gotta take a few laps around the datacenter tho...
16:57:06 <dustymabe> just happy to have participation
16:57:16 <Eighth_Doctor> 😆
16:57:20 <michel> Conan Kudo: I feel voluntold :p
16:57:29 <Eighth_Doctor> Michel Alexandre Salim: welcome to my world 😛
16:57:42 <dustymabe> #topic Btrfs as the default filesystem\
16:57:46 <dustymabe> #link https://pagure.io/cloud-sig/issue/308
16:57:55 <dustymabe> Eighth_Doctor: was this the one we wanted to bring up?
16:58:01 * michel will have spare time once he does not have to care about nvidia anymore
16:58:02 <Eighth_Doctor> here we go...
16:58:04 <Eighth_Doctor> dustymabe: yes
16:58:11 <michel> we have, uh, 2 mins?
16:58:26 <dustymabe> yeah, sorry. We got a late start and the matrix bridge was acting funny
16:58:29 <jdoss> I'll get the fire proof blanket for you Eighth_Doctor
16:58:38 <Eighth_Doctor> haha
16:58:58 <Eighth_Doctor> anyway, davdunc has taken the charge on this and has done a great job with the change proposal
16:59:14 <davdunc> yes.
16:59:21 <davdunc> if you need a punching bag. I am here.
16:59:41 <cmurf> .hire davdunc
16:59:41 <zodbot> adamw hires davdunc
16:59:49 <davdunc> LOL.
16:59:50 <cmurf> that's as strong as it gets around here
16:59:54 <dustymabe> anything in particular to discuss?
16:59:55 <King_InuYasha> the only significant feedback was... oddly from pboy, which seems to be more about some kind of cloud+server merge that nobody agreed to
17:00:04 <King_InuYasha> otherwise, everyone seems to be "meh" about it
17:00:27 <jdoss> the derailment in that thread was unfortunate.
17:00:39 <dustymabe> to be fair we've (at least I was involved) been talking on and off about a server/cloud wg merge for some time
17:00:53 <dustymabe> mostly because of lack of interest/resources
17:00:56 <King_InuYasha> right
17:01:03 <King_InuYasha> I think at this point we can consider the Cloud WG revived
17:01:28 <King_InuYasha> with the F35 release, I will ask the Council to restore our presence on the main site
17:01:32 <King_InuYasha> as an Edition
17:01:42 <dustymabe> King_InuYasha: perhaps, I'm still interested in seeing more involvement over time. And I'd really like to see someone other than myself become the de-facto "leader"
17:01:43 <King_InuYasha> (we technically haven't lost edition status, but...)
17:01:55 <King_InuYasha> dustymabe: I'd promote davdunc :)
17:02:01 <jdoss> Dusty you can't ever leave us...
17:02:02 <King_InuYasha> he's done a great job with the cloud-y things
17:02:03 <michel> dustymabe: can we arrange a joint meeting with server just so we can settle this issue (if only to say "no merger planned for immediate future"?
17:02:20 <michel> so we don't have this uncertainty hanging over our heads
17:02:25 <davdunc> I'll be more actively involved after july 7
17:02:30 <jdoss> You have to show up Dusty otherwise you are going to get fined.
17:02:33 <dustymabe> michel: I talked with matthew miller recently about it. He's going to bring some people together to discuss the future
17:02:44 <michel> dustymabe++
17:02:44 <zodbot> michel: Karma for dustymabe changed to 6 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:02:59 <dustymabe> jdoss: haha. I don't want to leave, but I do want to be more of a watcher/adviser rather than someone who does a lot
17:03:03 <King_InuYasha> dustymabe: also, we love you Dusty, we don't want you to leave :)
17:03:20 <michel> dustymabe: hello management :)
17:03:35 <dustymabe> yeah. definitely don't want to leave. I just don't want to have anxiety about cloud languishing and it being my fault because I'm not putting enough time into it
17:03:42 <jdoss> The problem with merging with Server IMO is it has things like Cockpit on by default and that on Cloud is not something I personally think is a good idea.
17:03:49 <jdoss> anyways, lets talk some butter
17:03:56 <dustymabe> yes. btrfs:
17:03:58 <King_InuYasha> well, I think the larger issue is there are different types of people
17:04:02 <King_InuYasha> but again, for later
17:04:18 <cmurf> my two cents is merger or no merger, file system is unrelated. But if anything, btrfs makes cloud more like server's lvm+xfs -> integrated volume manager, reflinks, snapshots, subvolumes for separation.
17:04:30 <cmurf> they're not 1:1 but closer than just plain ext4
17:04:50 <davdunc> +1 to cmurf's point.
17:04:57 <dustymabe> I've said it a few times. If it was just me I probably wouldn't make the change, but I'm happy people are here and interested in doing the work
17:04:59 <jdoss> I think it is a good idea to use the same FS as the other main editions.
17:05:13 <dustymabe> and I do use btrfs, so I'm not afraid of it
17:05:27 <jdoss> I think there is a lot of FUD w/r/t btrfs
17:06:43 <cmurf> it is a very effective early warning system :)
17:06:45 <dustymabe> yeah, I'm sure some people got scarred many years ago. I've never had an issue
17:07:08 <King_InuYasha> I've been personally running it since 4.0 krneel
17:07:17 <michel> a mix of past issues and actual hardware issues that stays silent on other file systems
17:07:34 <cmurf> chances are we won't see the issues in cloud that we see with desktops: memory bitflips have been the most common, possibly tied with the occasional drive that just flat out drops critical writes or gets them out of order (i.e. not properly honoring flush/fua)
17:07:37 <dustymabe> has anybody brought up any points in the ML discussion that are worth bringing up here?
17:07:57 <dustymabe> other than cloud/server WG merge
17:08:02 <cmurf> but me doing desktop triage for btrfs issues, there's been in some sense surprisingly few problems
17:08:05 <michel> can we assume most Cloud usage has ECC RAM? or not so much depending on which provider
17:08:09 <jdoss> I think we should move forward with the change since King_InuYasha is leading the charge. We have the personpower to get it done.
17:08:49 <michel> dustymabe: I did not see anything. maybe we should do another request for comments, specifically excluding the server issue, and mention that that will be discussed separately?
17:08:49 <dustymabe> cmurf: thanks for sticking around and helping people when they do have problems
17:09:30 <cmurf> michel: +1 i agree that we should draw a line in the sand on that and refresh the thread to bring up legit concerns about the change
17:09:57 <cmurf> no one else seconded that particular concern
17:10:40 <dustymabe> works for me
17:10:53 <jdoss> So bump thread and be like for reals, we are going to move forward unless you give us a legit reason(s) not to?
17:10:54 <dustymabe> let's just get this on the record though
17:11:14 <dustymabe> jdoss: yeah something like that.. maybe with lighter tone :)
17:11:23 <dustymabe> davdunc: I think you've got it
17:11:30 <jdoss> gotta keep for reals in there tho...
17:11:33 <davdunc> I can do it.
17:11:47 <davdunc> I'll bump the thread and declare our intention.
17:12:14 <jdoss> King_InuYasha: give davdunc the blanket
17:13:17 * King_InuYasha hands davdunc the blanket and his secret cape
17:13:25 <dustymabe> #proposed the cloud wg will move to btrfs for the f35 unless techincal hurdles are hit or we decide not to for organizational reasons (cloud/server working together)
17:13:26 <davdunc> :D
17:13:38 <dustymabe> I added the last clause in there for a reason
17:14:10 <dustymabe> as I said, we are in the midst of a discussion about fedora cloud's future (hopefully invite going out soon)
17:14:44 <dustymabe> regardless of what we do I think moving to btrfs should be fine, I just want to leave an escape hatch in case we end up not doing it
17:15:01 <davdunc> King_InuYasha: thanks. . . I think.
17:15:29 <dustymabe> ack/nack/discuss?
17:15:35 <jdoss> +1
17:15:42 <King_InuYasha> dustymabe: I'd rather leave out the latter
17:15:50 <King_InuYasha> honestly that's unfair to us as a group
17:15:58 <jdoss> yeah I guess I am in that camp too
17:16:08 <dustymabe> ehh, i'm implying the group would be involved in that decision
17:16:29 <jdoss> Because we should be able to operate as a WG and move forward on things such as this without dealing with what ifs
17:16:36 <dustymabe> i.e. we'd have to agree and say "ok yes we think the benefits outweigh XYZ, we'll delay this until f36"
17:17:15 <dustymabe> does that make sense?
17:18:43 <King_InuYasha> I think the first half of your sentence is enough
17:18:59 <King_InuYasha> #proposed the cloud wg will move to btrfs for the f35 unless techincal hurdles are hit
17:20:24 <dustymabe> I have my reasons for wanting to include the latter. It's mostly for diplomatic purposes
17:20:36 <dustymabe> but I guess we can have that conversation later
17:20:38 <dustymabe> ack
17:21:01 <dustymabe> any other people want to weigh in
17:21:46 <dustymabe> +1 -1 - ack/nack ?
17:21:56 <dustymabe> jdoss: davdunc: cmurf: ?
17:22:13 <davdunc> +1
17:23:20 * dustymabe waiting on at least one more vote
17:24:22 <dustymabe> well I think jdoss voted in spirit earlier
17:24:30 <dustymabe> #agreed the cloud wg will move to btrfs for the f35 unless techincal hurdles are hit
17:24:36 <dustymabe> #topic open floor
17:24:40 <dustymabe> anything for open floor
17:24:47 <davdunc> I am good for now.
17:24:50 <King_InuYasha> nothing from me
17:24:59 <King_InuYasha> I'm in three meetings atm
17:25:04 <King_InuYasha> that makes this a bit hard :)
17:25:13 <dustymabe> ok will end the meeting soon
17:25:50 <dustymabe> #endmeeting