On Wed, 2021-05-26 at 16:59 -0600, Chris Murphy wrote: > On Wed, May 26, 2021 at 5:30 AM Peter Boy <pboy@xxxxxxxxxxxxx> wrote: > > > Am 26.05.2021 um 08:51 schrieb Chris Murphy < > > > lists@xxxxxxxxxxxxxxxxx>: > > > What controversial discussion is being referenced? Currently before > > > us > > > is a proposal to switch to Btrfs for Cloud edition. > > > > I’m quite sure you know that discussion. Part to it was Red Hat’s > > decision to drop BTRFS in RHEL 8 (to my dismay, by the way, because I > > used it for some file systems on our servers). And because there is > > that decision and that discussion, I expect it will take a longer > > time to switch e.g. server to BTRFS as system wide default. So my > > casual 10-year forecast is not an overreaction as Neal put it (at > > most some pessimism). > > I understand you think it will take longer. What I don't understand is > why you think this, but I guess we can just skip over that. > > But let's keep the Red Hat aspect of the storyline in context though. > And not extrapolate beyond the available facts. > https://news.ycombinator.com/item?id=14907771 > > Whereupon Server SIG/WG perform an evaluation of Btrfs for their use > cases, and decide Btrfs should be the default in a compelling manner, > FESCo will approve it. And this plausibly could still happen for > Fedora 35, if folks really want it to happen. But I think it's neither > urgent nor requires a long delay. Server SIG can do anything they > want. Red Hat is doing the same. > > > > I think we have a misunderstanding here. My argument refers to > > expected hurdles of a possible changeover process, not to technical > > features. > > My opinion is to not worry about the process in advance of arriving at > the hurdle. You jump over the hurdle at the proper time. The vast > majority of the process is about technical features liabilities. > > For example, I expect Server folks probably prefer LVM LV's for > backing virtual machines, rather than raw or qcow2 no matter the file > system. Even if this can be approximated by fallocate (raw and qcow2 > support it, as as well as ext4, xfs, btrfs) to preallocate the backing > file, it's likely a lot of Server folks will just prefer using LVM for > this case. That's fine. > > A good question is to what degree can Server edition, via Anaconda > kickstart, divvy up a drive in boolean fashion? I know there's some > thresholds like, if the drive is below a certain size, don't create > /home, and so on. Could Server default installations default to a ~20G > Btrfs system volume; and either leave the rest unallocated (not > partitioned)? Or make all remaining space an LVM PV, added to a single > VG? And then just not create any LVs? I think I'd like to see each: > unallocated, PV only, PV + VG, in Cockpit's UI and get some feedback > from those folks because it'd be ideal if the overview of the > initially installed system can clearly show the layout, whatever it > is. > > Not often but sometimes folks ask "where has all the space gone?" > following a Server installation. They're not expecting or maybe not > discovering, that quite a lot is held in reserve in the VG. > > > > Again, it’s not about technical properties. We have (or probably > > had?) an agreement to align (or try to align) Server Edition and > > Cloud. That was 2 or 3 months ago. Regarding to that agreement, it is > > a step into the wrong direction. > > Is there a Server or Cloud meeting with minutes that this discussion > happened in? Or email thread you can point to? > As I recall it was very preliminary, and the suggestion is that the working groups can be merged at some point in the future. - mattdm brought it up back in December https://meetbot.fedoraproject.org/teams/serversig/serversig.2020-12-16-18.00.log.html (timestamp: 18:52:23) - there's discussion about talking to Cloud WG on April 7 https://meetbot.fedoraproject.org/teams/fedora-server/fedora-server.2021-04-07-17.01.log.html (timestamp: 17:44:55) I don't think there was ever a discussion of making the two products technically aligned (nor do I really see a need, even if the working groups end up being merged). There has not been an official proposal; to my recollection it has not been brought up at a Cloud WG meeting. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/michel@xxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
