Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
2014-02-22 3:08 GMT+01:00 Chris Murphy li...@colorremedies.com: On Feb 21, 2014, at 2:38 PM, john.flor...@dart.biz wrote: That makes a lot of sense, but I'd like to add that when doing custom partitioning, you can easily spend the bulk of your actual interaction time getting the partitioning customized exactly the way you want and when anaconda crashes, What you're essentially suggesting is the necessary trade off between stability and features isn't being balanced, in your experience. I'd agree with that assessment. I've done hundreds of Windows installs and thousands of OS X installs and those installers never crash. Ever. Seriously never. You can throw the most bizarre crap at them, even a disk with 42 partitions of just linux and BSD and they don't crash. And what interaction time? It's point and install. There's nothing to interact with because there are no options. However, when I have my admin hat on, I want flexibility. I don't find that a compelling argument for many reasons, not least of which is the tens of thousands of OS X and Windows admins who get few install time layout choices, and they seem quite content. The necessary context to add here is that both OS X and Windows have much better _post-install_ layout choices. Both can convert a non-encrypted filesystem to encrypted post-installation, online, without significant downtime. Re: LVM, IIRC OS X is setting up CoreStorage by default; Windows uses plain partitions, but can convert plain partitions into Dynamic Disks without backuprestore. The capabilities of the underlying storage stacks are different, so a great UI for one may not be an acceptable UI for the other. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Mar 3, 2014, at 10:42 AM, Miloslav Trmač m...@volny.cz wrote: 2014-02-22 3:08 GMT+01:00 Chris Murphy li...@colorremedies.com: On Feb 21, 2014, at 2:38 PM, john.flor...@dart.biz wrote: That makes a lot of sense, but I'd like to add that when doing custom partitioning, you can easily spend the bulk of your actual interaction time getting the partitioning customized exactly the way you want and when anaconda crashes, What you're essentially suggesting is the necessary trade off between stability and features isn't being balanced, in your experience. I'd agree with that assessment. I've done hundreds of Windows installs and thousands of OS X installs and those installers never crash. Ever. Seriously never. You can throw the most bizarre crap at them, even a disk with 42 partitions of just linux and BSD and they don't crash. And what interaction time? It's point and install. There's nothing to interact with because there are no options. However, when I have my admin hat on, I want flexibility. I don't find that a compelling argument for many reasons, not least of which is the tens of thousands of OS X and Windows admins who get few install time layout choices, and they seem quite content. The necessary context to add here is that both OS X and Windows have much better _post-install_ layout choices. I don't want to get ride of Anaconda's encryption options in Automatic or Manual partitioning UIs. I do want to get rid of ext2, ext3, vfat, and certainly RAID 4, in even the Manual Partitioning UI. And I question RAID 5/6 for rootfs. Both can convert a non-encrypted filesystem to encrypted post-installation, online, without significant downtime. Yes. At least Apple's is a live conversion (bi-directional) that permits rebooting, shutdown and sleep. Re: LVM, IIRC OS X is setting up CoreStorage by default; Windows uses plain partitions, but can convert plain partitions into Dynamic Disks without backuprestore. By default Apple uses plain partitions for single drive computers; and Core Storage marries an SSD and HDD as a single LV for computers with both and they call this Fusion Drive. When the user choose to encrypt, this is handled by Core Storage; the plain partition volume is converted to a Core Storage layout. I don't know how it works on Windows. The capabilities of the underlying storage stacks are different, so a great UI for one may not be an acceptable UI for the other. Sure. I only bring up Windows/OS X as a contra position to the idea it's a good thing to have massive piles of options in an installer. The vast majority of the world is OK with vanilla ice cream, in this context. Can we do better, and can we have more than that? Sure. But we should be sensitive to enabling features just because they can be done, rather than because they're good ideas. The examples in my 2nd sentence at top are compulsive. They have no efficacy. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Mon, Mar 03, 2014 at 11:19:29AM -0700, Chris Murphy wrote: On Mar 3, 2014, at 10:42 AM, Miloslav Trmač m...@volny.cz wrote: 2014-02-22 3:08 GMT+01:00 Chris Murphy li...@colorremedies.com: On Feb 21, 2014, at 2:38 PM, john.flor...@dart.biz wrote: The necessary context to add here is that both OS X and Windows have much better _post-install_ layout choices. I don't want to get ride of Anaconda's encryption options in Automatic or Manual partitioning UIs. I do want to get rid of ext2, ext3, vfat, and certainly RAID 4, in even the Manual Partitioning UI. And I question RAID 5/6 for rootfs. I could go along with getting rid of ext2, ext3, vfat, and RAID 4. I think RAID 5/6 are still too common to eliminate them. Both can convert a non-encrypted filesystem to encrypted post-installation, online, without significant downtime. Yes. At least Apple's is a live conversion (bi-directional) that permits rebooting, shutdown and sleep. Re: LVM, IIRC OS X is setting up CoreStorage by default; Windows uses plain partitions, but can convert plain partitions into Dynamic Disks without backuprestore. By default Apple uses plain partitions for single drive computers; and Core Storage marries an SSD and HDD as a single LV for computers with both and they call this Fusion Drive. When the user choose to encrypt, this is handled by Core Storage; the plain partition volume is converted to a Core Storage layout. I don't know how it works on Windows. There is a tool to convert ext4 to ext4-on-LVM in-place: https://github.com/g2p/blocks#readme -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 01:53 PM, Chuck Anderson wrote: On Mon, Mar 03, 2014 at 11:19:29AM -0700, Chris Murphy wrote: On Mar 3, 2014, at 10:42 AM, Miloslav Trmač m...@volny.cz wrote: 2014-02-22 3:08 GMT+01:00 Chris Murphy li...@colorremedies.com: On Feb 21, 2014, at 2:38 PM, john.flor...@dart.biz wrote: The necessary context to add here is that both OS X and Windows have much better _post-install_ layout choices. I don't want to get ride of Anaconda's encryption options in Automatic or Manual partitioning UIs. I do want to get rid of ext2, ext3, vfat, and certainly RAID 4, in even the Manual Partitioning UI. And I question RAID 5/6 for rootfs. I could go along with getting rid of ext2, ext3, vfat, and RAID 4. I think RAID 5/6 are still too common to eliminate them. Just to stop this conversation in its tracks: For right now, I recommend *strongly* against removing any feature of the manual partitioning UI. There is more than enough change happening this Fedora cycle. I'd much prefer we not muddy the waters with reducing existing functionality. If you have strong feelings on this matter, I'd suggest talking with the Anaconda folks *now* about a change for Fedora *22*. Also, please branch that into a new mailing list thread. This one has, I suspect, served out its useful life. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMU0JIACgkQeiVVYja6o6PrSQCePB69ki91wGEqYV9/lX9mAq5F J0gAnirqINtnwEp3sfOim2oj5P8tl3Op =siTi -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Wed, 2014-02-26 at 11:46 -0800, Adam Williamson wrote: On Wed, 2014-02-26 at 11:17 +0100, Karel Zak wrote: Don't try to be smart to everyone, it does not work. IMHO all you need is to support one or a very few scenarios (complete scenarios without customization) and a way how to switch from installer to manual partitioning by parted/fdisk/mdadm/mkfs/etc. The anaconda partitioning UI will never be smart enough for advanced users and it also does not make sense to duplicate effort, we *already have* tools to create all the unusual crazy disk layouts. We don't, really. Well, we do, but it really is tools plural, and some of them don't have GUIs at all. blivet and its anaconda GUI really is one of the most advanced partitioning tools in existence. There's no one-stop graphical tool that does everything blivet/anaconda does, AFAIK. gparted can't do anywhere near the LVM, RAID and btrfs stuff that blivet does: it really only does *partitions*. Just to let you know -- a guy from Prague Technical University is working on a bachelor thesis [1] focused on starting the development of a GUI partitioning/LVM/RAID/BTRFS tool based on blivet that should be embedable into other applications, Anaconda included. We've kind of boxed ourselves into a corner of unreasonably high expectations here now, though - we either commit to continuing to support all the functionality custom part currently supports, or we say reduce it and screw the complainers, but there *will* be complainers. There already are quite vociferous complainers for the very small amount of simplification that was done between oldUI custom part and newUI custom part. Possibly the most viable long-term option, and I think one the devs are gradually working towards, is to make the blivet GUI an independent component. That would mean it wouldn't kill your whole anaconda run if it crashed (you could just start over and try again), and you could use it from outside of anaconda (say, to pre-partition). And it'd maybe encourage other projects to adopt and contribute to it, which would definitely help take the load off - I've said it before but I'll say it again, it is kinda absurd that we have, what, about the equivalent of 1.5 full-time developers trying to maintain this extremely capable and complex partitioning backend *and* frontend. Another let you know -- I'm now starting to work on blivet for most of my work hours, so it will hopefully soon be equivalent of 2.5 full-time developers. Also, we have already discussed splitting out the Custom partitioning GUI into a separate tool with dlehman. I can soon (in March) jump on it and I believe it should be feasible. -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Thu, 2014-02-27 at 09:17 +0100, Vratislav Podzimek wrote: On Wed, 2014-02-26 at 11:46 -0800, Adam Williamson wrote: On Wed, 2014-02-26 at 11:17 +0100, Karel Zak wrote: Don't try to be smart to everyone, it does not work. IMHO all you need is to support one or a very few scenarios (complete scenarios without customization) and a way how to switch from installer to manual partitioning by parted/fdisk/mdadm/mkfs/etc. The anaconda partitioning UI will never be smart enough for advanced users and it also does not make sense to duplicate effort, we *already have* tools to create all the unusual crazy disk layouts. We don't, really. Well, we do, but it really is tools plural, and some of them don't have GUIs at all. blivet and its anaconda GUI really is one of the most advanced partitioning tools in existence. There's no one-stop graphical tool that does everything blivet/anaconda does, AFAIK. gparted can't do anywhere near the LVM, RAID and btrfs stuff that blivet does: it really only does *partitions*. Just to let you know -- a guy from Prague Technical University is working on a bachelor thesis [1] focused on starting the development of a GUI partitioning/LVM/RAID/BTRFS tool based on blivet that should be embedable into other applications, Anaconda included. The omitted link: [1] https://thesis-managementsystem.rhcloud.com/topic/show/180/a-tool-for-storage-configuration-on-gnulinux-os -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Fri, Feb 21, 2014 at 02:04:54PM -0800, Adam Williamson wrote: On Fri, 2014-02-21 at 16:38 -0500, john.flor...@dart.biz wrote: With the best of intentions, we'd gone from a reluctant exception to the 'no choice' design to a dropdown which included two very different complex choices: LVM and btrfs. So now the installer path which was originally supposed to be minimal-choice, very robust and testable and fixable, had become rather a lot more complex. Everything should be made as simple as possible, but not simpler. I don't think that precept applies very well to this area. The problem is that there are - and this is probably *literal*, not a rhetorical flourish - millions of Special Little Use Cases like yours (the one below, snipped for brevity) out there. *You* want it to be easy to skip /home. *She* wants it to be easy to resize a Slackware install. *That guy* wants to use btrfs. *My cat* likes RAID. It is becoming very, very clear that we just cannot undertake to support them all and guarantee that they are all going to work in a release. It's just _too much work_. Everyone agrees that it would be nice if we could, but then everyone agrees that it'd be nice if I had a solid gold toilet. Some nice things just don't happen. We do not have the resources to be in the business of writing the world's biggest disk configuration tool and guaranteeing that it'll never go wrong, which isn't *quite* what we're currently trying to do, but it's not far from it. Don't try to be smart to everyone, it does not work. IMHO all you need is to support one or a very few scenarios (complete scenarios without customization) and a way how to switch from installer to manual partitioning by parted/fdisk/mdadm/mkfs/etc. The anaconda partitioning UI will never be smart enough for advanced users and it also does not make sense to duplicate effort, we *already have* tools to create all the unusual crazy disk layouts. Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Wed, 2014-02-26 at 11:17 +0100, Karel Zak wrote: Don't try to be smart to everyone, it does not work. IMHO all you need is to support one or a very few scenarios (complete scenarios without customization) and a way how to switch from installer to manual partitioning by parted/fdisk/mdadm/mkfs/etc. The anaconda partitioning UI will never be smart enough for advanced users and it also does not make sense to duplicate effort, we *already have* tools to create all the unusual crazy disk layouts. We don't, really. Well, we do, but it really is tools plural, and some of them don't have GUIs at all. blivet and its anaconda GUI really is one of the most advanced partitioning tools in existence. There's no one-stop graphical tool that does everything blivet/anaconda does, AFAIK. gparted can't do anywhere near the LVM, RAID and btrfs stuff that blivet does: it really only does *partitions*. We've kind of boxed ourselves into a corner of unreasonably high expectations here now, though - we either commit to continuing to support all the functionality custom part currently supports, or we say reduce it and screw the complainers, but there *will* be complainers. There already are quite vociferous complainers for the very small amount of simplification that was done between oldUI custom part and newUI custom part. Possibly the most viable long-term option, and I think one the devs are gradually working towards, is to make the blivet GUI an independent component. That would mean it wouldn't kill your whole anaconda run if it crashed (you could just start over and try again), and you could use it from outside of anaconda (say, to pre-partition). And it'd maybe encourage other projects to adopt and contribute to it, which would definitely help take the load off - I've said it before but I'll say it again, it is kinda absurd that we have, what, about the equivalent of 1.5 full-time developers trying to maintain this extremely capable and complex partitioning backend *and* frontend. It would certainly make life much easier on us if we said 'screw it, disks are hard, let's go shopping' and just outsourced all the partitioning to gparted (like ubiquity does), but it'd definitely be a substantial drop in capability compared to what we have now. (And I doubt it'd be acceptable for RHEL, so in the end the same people would have to work on it anyway even if Fedora wasn't using it.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
From: awill...@redhat.com Date: 02/21/2014 17:05 Subject: Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs Sent by: devel-boun...@lists.fedoraproject.org On Fri, 2014-02-21 at 16:38 -0500, john.flor...@dart.biz wrote: With the best of intentions, we'd gone from a reluctant exception to the 'no choice' design to a dropdown which included two very different complex choices: LVM and btrfs. So now the installer path which was originally supposed to be minimal-choice, very robust and testable and fixable, had become rather a lot more complex. Everything should be made as simple as possible, but not simpler. I don't think that precept applies very well to this area. The problem is that there are - and this is probably *literal*, not a rhetorical flourish - millions of Special Little Use Cases like yours (the one below, snipped for brevity) out there. *You* want it to be easy to skip /home. *She* wants it to be easy to resize a Slackware install. *That guy* wants to use btrfs. *My cat* likes RAID. It is becoming very, very clear that we just cannot undertake to support them all and guarantee that they are all going to work in a release. It's just _too much work_. Everyone agrees that it would be nice if we could, but then everyone agrees that it'd be nice if I had a solid gold toilet. Brr... no thanks. Well okay, I'd take one for the monetary value. :-) Some nice things just don't happen. We do not have the resources to be in the business of writing the world's biggest disk configuration tool and guaranteeing that it'll never go wrong, which isn't *quite* what we're currently trying to do, but it's not far from it. It's worth trying some other installers out, just to reset your expectations. Have you seen the level of flexibility you get from Ubuntu's interactive installer? Windows'? OS X's? Thank God no. I last touched Ubuntu about 7 years ago. The early days of FC were so not the RHL (e.g. 7.3) that I'd loved so much. But then Ubuntu left me lacking in community. I filed so many bugs that never received a single response. The last time I installed Windows it required something like 20 1.4MB floppies (and that was probably the best part of the whole experience). I've only *used* a Mac twice, once with the originals back in the 80s(?) and again in the 90s -- I've never installed any Apple OS. Too damned different for this old dog. I appreciate your QA angle here. Every condition in a code path leads to exponential growth in testing. And development. This isn't just a QA problem. We do not have the development resources to commit to all this stuff working reliably every six months. Here's where you lost me. Yes, anaconda is going through a rewrite, but shouldn't all development be incremental improvement. You make it sound like it has to be gutted and redone every release. IMHO, nothing kills corner cases like polymorphism. Remove the conditions and you remove the dark corners where bugs like to hide. However, when I have my admin hat on, I want flexibility. I love LVM for that reason. However, if I'm setting up simple VMs whose backend storage resides in a LV, I have no need or desire for LVM within the VM. Does it hurt you to get it, though? Only in the sense you snipped out: resizing w/o LVM is much simpler when disk is virtual, there's just fewer steps. As I stated though, on the host I want/need LVM because in the physical world, LVM makes life way more easier. Yeah, I can live with it in all cases, but then I'm just as likely to do a complete reinstall of the VM as to resize the undersized file system. However, that's only practical because puppet is doing all the dirty work. Really my whole problem is MY problem though. I just have committed to the time of completely automating kickstart script generation and application. The GUI installer has been kind enough to me that I always seem to have higher priorities (like keeping all my services running atop the latest Fedora). -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
From: li...@colorremedies.com To: Bruno Wolff III br...@wolff.to Date: 02/22/2014 17:38 Subject: Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs Sent by: devel-boun...@lists.fedoraproject.org On Feb 22, 2014, at 9:39 AM, Bruno Wolff III br...@wolff.to wrote: On Fri, Feb 21, 2014 at 19:08:15 -0700, Chris Murphy li...@colorremedies.com wrote: The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora. What would you have people do instead? For example run a live image to do the partitioning, raid, lvm, dmcrypt, and file system setup before doing the install? Even then, you need some way to tell the installer which directories go on which file systems for the install. I'm mainly suggesting a decoupling of all of this effort from an installation only context, so that it can be used to create and modify storage stacks without installing an OS. I don't particularly care how it manifests - separate app, or a spoke within the current app. Communicating the layout can be done with a fstab-like metadata file. If there's no inclination to do this for a much broader use case, then why wedge so much capability and effort into a narrow installer-only use case? Bootable raid6 and raid4?? I actually like that idea of decoupling them. It would be good to see more of the *nix tradition here, do ONE thing and do it very well. Of course we'd need the two things (storage stack manager and installer) and the fun would be in making them appear seamless. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Sat, Feb 22, 2014 at 03:37:40PM -0700, Chris Murphy wrote: On Feb 22, 2014, at 9:39 AM, Bruno Wolff III br...@wolff.to wrote: On Fri, Feb 21, 2014 at 19:08:15 -0700, Chris Murphy li...@colorremedies.com wrote: The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora. What would you have people do instead? For example run a live image to do the partitioning, raid, lvm, dmcrypt, and file system setup before doing the install? Even then, you need some way to tell the installer which directories go on which file systems for the install. I'm mainly suggesting a decoupling of all of this effort from an installation only context, so that it can be used to create and modify storage stacks without installing an OS. I don't particularly care how it manifests - separate app, or a spoke within the current app. Communicating the layout can be done with a fstab-like metadata file. If there's no inclination to do this for a much broader use case, then why wedge so much capability and effort into a narrow installer-only use case? Bootable raid6 and raid4?? Decoupling can't happen given the hard requirement we have on supporting a wide range of storage configurations. Linux in general has far too many options in this area and everyone's corner case or configuration is most important. So, just to chime in on one of these threads, I can speak to what we are working on in the installer camp right now: 1) Storage configuration and management outside of anaconda. The storage library was broken out as blivet and is growing to support use cases outside of the installer environment. This will open the door to doing things like using the storage UI in anaconda as a standalone management app (as an idea, for example). 2) Supporting alternative partitioning UI projects (both inside and outside of the installer). A number of very quiet people have asked about the feasability of creating another storage configuration UI in the installer. We absolutely do not have the workforce to support multiple storage configuration frontends, but if you want to explore that on your own, feel free. We encourage people to build on top of our blivet library as we have done, but the UI can be whatever you make it. In fact, the more people that try this will probably learn that storage configuration is a highly complicated and political topic. :) 3) Spoke development through our addon API. One thing I have noticed through the posts from Fedora working groups is the request for installation specifics. That's understandable given that the whole idea of the working groups finally admitted that we have multiple target use cases. Anaconda is positioned now to facilitate this through the addon API. Anaconda can grow spokes via plugins. We have a developer guide and the past two DevConf events in Brno have had presentations on how to write an addon for anaconda. With an addon you can: a) Add a new spoke to the installer. b) Add a new text mode spoke. c) Add a kickstart command. d) Add an initial-setup (firstboot) spoke. And I will point out here that initial-setup in this context means the thing we wrote to replace our aging firstboot program. initial-setup is essentially the second hub in anaconda that runs when you first boot up the computer. It is not to be confused with gnome-initial-setup. And that's sort of the high level stuff. If you have any questions you want to ask in this area, I am happy to talk one on one or in a time-bounded meeting. I, unfortunately, do not have the time, patience, or intestinal fortitude to participate in the working group email threads. I can only skim them occassionally. I saw this stuff and just wanted to chime in. Thanks, -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
- Original Message - On Fri, 2014-02-21 at 17:08 +0100, Phil Knirsch wrote: Installer is still a hot topic, but thats nothing we could resolve during our meeting and which might have to be brought up with FESCO again. So, as cmurf has been trying to point out on desktop@ , we (QA) have some concerns in this area too, and I know the installer team is open to the idea of at least simplifying the non-custom partitioning path to some extent. This is an extremely complex topic area, though, and it may be tricky to get the right things done if multiple teams are considering it in different contexts in different meetings. It would probably be a Very Good Idea to get everyone with an interest - at least anaconda team, the product WGs (except possibly Cloud, depending on whether they intend to use anaconda in their deliverables at all), base WG, and fesco - together in some way to talk about it. devconf would've been great but it already happened. Flock would be great but it's too late. Should we try to set up some kind of special meeting / list / etherpad / wikipage / *something* where we can all talk it over? Well, the question is if installer changes are short term goals or more long terms and before trying to setup any meeting, it would be nice to collect more data from other groups. So personally, I'd say Flock would be great opportunity to discuss it but on the other hand, it's always nice to be prepared for such conversation. The other groups Tech Spec should be available within a week, then let's try to look for overlapping pieces and I'm definitely volunteer to work on it. Once we have it, it's going to be a good time to discuss details and as Base, we should incorporate it to our Base design. Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
- Original Message - On Sat, Feb 22, 2014 at 03:37:40PM -0700, Chris Murphy wrote: On Feb 22, 2014, at 9:39 AM, Bruno Wolff III br...@wolff.to wrote: On Fri, Feb 21, 2014 at 19:08:15 -0700, Chris Murphy li...@colorremedies.com wrote: The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora. What would you have people do instead? For example run a live image to do the partitioning, raid, lvm, dmcrypt, and file system setup before doing the install? Even then, you need some way to tell the installer which directories go on which file systems for the install. I'm mainly suggesting a decoupling of all of this effort from an installation only context, so that it can be used to create and modify storage stacks without installing an OS. I don't particularly care how it manifests - separate app, or a spoke within the current app. Communicating the layout can be done with a fstab-like metadata file. If there's no inclination to do this for a much broader use case, then why wedge so much capability and effort into a narrow installer-only use case? Bootable raid6 and raid4?? Decoupling can't happen given the hard requirement we have on supporting a wide range of storage configurations. Linux in general has far too many options in this area and everyone's corner case or configuration is most important. Well, as Fedora.next aims pretty much on productization and we'd like to set higher bar for these products, I think we can limit these everyone's corner case configuration and focus on what's really needed for our main products. And I understand, this is really more politics than technical issue and we're right in this politics time of Fedora.next - a good time to rethink what we do now. Of course the last but not least question is manpower of your team. There's possibility that if we would be able to simplify blocking paths in installer, we could get to the point there would be more time and will to touch proposed ideas... Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Fri, Feb 21, 2014 at 12:20:14PM -0800, Adam Williamson wrote: product WGs (except possibly Cloud, depending on whether they intend to use anaconda in their deliverables at all), base WG, and fesco - The Cloud plan is to generate images using anaconda. For that case, we don't care about the UI at all, but care very much about Kickstart. So while Cloud shouldn't be excluded from Anaconda concerns _in general_, this specific issue doesn't apply. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Fri, Feb 21, 2014 at 19:08:15 -0700, Chris Murphy li...@colorremedies.com wrote: The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora. What would you have people do instead? For example run a live image to do the partitioning, raid, lvm, dmcrypt, and file system setup before doing the install? Even then, you need some way to tell the installer which directories go on which file systems for the install. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Feb 22, 2014, at 9:39 AM, Bruno Wolff III br...@wolff.to wrote: On Fri, Feb 21, 2014 at 19:08:15 -0700, Chris Murphy li...@colorremedies.com wrote: The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora. What would you have people do instead? For example run a live image to do the partitioning, raid, lvm, dmcrypt, and file system setup before doing the install? Even then, you need some way to tell the installer which directories go on which file systems for the install. I'm mainly suggesting a decoupling of all of this effort from an installation only context, so that it can be used to create and modify storage stacks without installing an OS. I don't particularly care how it manifests - separate app, or a spoke within the current app. Communicating the layout can be done with a fstab-like metadata file. If there's no inclination to do this for a much broader use case, then why wedge so much capability and effort into a narrow installer-only use case? Bootable raid6 and raid4?? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Feb 21, 2014, at 1:20 PM, Adam Williamson awill...@redhat.com wrote: It would probably be a Very Good Idea to get everyone with an interest - at least anaconda team, the product WGs (except possibly Cloud, depending on whether they intend to use anaconda in their deliverables at all), base WG, and fesco - together in some way to talk about it. devconf would've been great but it already happened. Flock would be great but it's too late. Should we try to set up some kind of special meeting / list / etherpad / wikipage / *something* where we can all talk it over? Yes, please. Yet the installer design doesn't really communicate in any way that some paths through 'non-custom' install are more tested/reliable than others Yes. Any many more paths through custom aren't tested, and likewise users don't know this. Also my original estimate of 80 testable outcomes through Automatic/guided path is for single device. Anaconda permits selection of multiple devices in this path. Therefore it's 160 testable outcomes with 2 devices. The current four Partition Scheme choices have technical arguments for and against, but ultimately none significantly outweigh any other for the intended audience for this path, and it's non-obvious why the user would pick one versus another. Option A: Eliminate the Partition Scheme pop-up menu. There is one recommended default. Option B: Make the pop-up useful with Personas/Workload/Use Case options. Those selections cause a particular recommended layout to be used, layouts that are already tested via the Manual/custom partitioning path anyway because QA knows of certain commonly used layouts that really need to work. And also reduces dependency on custom partitioning These aren't mutually exclusive, Option A could be implemented in the short term, and Option B later, and even expanded as well tested recommended paths graduate to the Guided listing. and the question of variant anacondas (whether any of the Products actually wants one, and if so, whether that's actually viable) pretty soon. I agree it needs to be decided soon. I don't have an opinion which way it should go. Option B above suggests Server and Workstation could have different Use Case options. I don't think it's necessary to have actual separate anacondas. A single anaconda package could permit variants. Depending on how the products are selected by the user: At download time as unique media: anaconda is launched with a flag e.g. --server or --workstation or --cloud, that causes it to have the appropriate variant behavior. Within the installer UI: as a spoke within the hub, likewise causes the installer to be varied. Post-install: doesn't require variation of the installer at all. Treat the installer strictly as a means of getting Fedora booting successfully. Shave the ice, then flavor it. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
Main meeting agenda for today was a discussion about the Workstation Tech Spec and any implications, changes or actions it would require from Base. Matthias Clasen from the Workstaing WG joined us today and every a long discussion and review specifically around the Core Services and Features part we've came to the conclusion that at this point with only the Workstation WG tech spec there were no actions or changes required by Base yet. Once the other WGs provide theirs we will revisit that and see where overlaps, conflicts or items might come up that need to be resolved at the Base level. Installer is still a hot topic, but thats nothing we could resolve during our meeting and which might have to be brought up with FESCO again. Meeting ended Fri Feb 21 15:58:11 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2014-02-21/fedora_base_design_working_group.2014-02-21-15.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2014-02-21/fedora_base_design_working_group.2014-02-21-15.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2014-02-21/fedora_base_design_working_group.2014-02-21-15.00.log.html Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Fri, 2014-02-21 at 17:08 +0100, Phil Knirsch wrote: Installer is still a hot topic, but thats nothing we could resolve during our meeting and which might have to be brought up with FESCO again. So, as cmurf has been trying to point out on desktop@ , we (QA) have some concerns in this area too, and I know the installer team is open to the idea of at least simplifying the non-custom partitioning path to some extent. This is an extremely complex topic area, though, and it may be tricky to get the right things done if multiple teams are considering it in different contexts in different meetings. It would probably be a Very Good Idea to get everyone with an interest - at least anaconda team, the product WGs (except possibly Cloud, depending on whether they intend to use anaconda in their deliverables at all), base WG, and fesco - together in some way to talk about it. devconf would've been great but it already happened. Flock would be great but it's too late. Should we try to set up some kind of special meeting / list / etherpad / wikipage / *something* where we can all talk it over? To give a bit of background and detail in QA's interest: First, to ensure everyone actually knows what we're talking about, we tend to talk about two major partitioning 'paths' in anaconda: 'guided' and 'custom'. 'custom' may also be referred to as 'manual'. In both newUI and oldUI, 'guided' is simply what you get if you don't pick custom partitioning, when you are given the opportunity to do so. In oldUI, you had the screen which gave you about five choices of different partitioning 'approaches' (reformat the entire disk(s), reformat only the Linux partitions, resize existing partitions to create free space, just install into free space, maybe one or two others I forgot). In newUI there's a different workflow after you pick target disks on the Installation Destination spoke which, broadly, accomplishes the same options in a rather different way. Broadly, QA is interested in doing something similar to what desktop wants to do, for slightly different reasons. Historically, QA and anaconda more or less agreed on an approach whereby the 'guided' partitioning path would be expected to work extremely reliably: QA would undertake to test every (well, nearly every) route through that path regularly and proactively, and anaconda would undertake to fix the bugs. Custom partitioning was much more of a 'bonus' thing: if it worked, great. QA would test it as much as we had time for, and anaconda would fix as many bugs as they could after fixing higher priority stuff. I went back and looked at the history, and in the earlier days of Fedora, the guided path was consciously designed to be very 'choice free'. Later in the 'oldUI' days, the path to more complexity in the 'guided' path was opened up by a sort of hack. Some people did not want LVM (after it was made default way back in FC3 or something), and eventually this demand became so persistent that it was decided to stick a checkbox in the 'guided' partitioning path which let you get a plain ext(3/4) layout instead of an LVM layout. This was always a kind of ugly compromise, it wasn't intended to be a design decision. It was manageable, because a plain ext3/4 layout is a fairly simple thing that isn't likely to break much. This context was kind of lost in the newUI re-design, and the 'I don't want LVM' checkbox kind of got a promotion. It's not a very good UI, and the point of the newUI stuff was to make the UI better, so instead of this 'special' checkbox, newUI used a dropdown menu - and because we were all ra-ra for btrfs at the time and expecting it to be the default Real Soon Now, and we thought we should make it easy for people to test the thing that was soon going to be the default, it got btrfs added. So in F18 we had a dropdown with LVM, ext4 and btrfs choices (IIRC). With the best of intentions, we'd gone from a reluctant exception to the 'no choice' design to a dropdown which included two very different complex choices: LVM and btrfs. So now the installer path which was originally supposed to be minimal-choice, very robust and testable and fixable, had become rather a lot more complex. By F20 we'd really kind of lost track of the initial intent, so no-one (including QA) really worried much about adding LVM thinp to the drop-down - it's a drop-down! it's for choices! - and now, we've got *four* major choices on the path that was originally supposed to be very dependable and choice-free and testable and maintainable, and of course we wound up shipping one of them entirely broken out of the box. QA and anaconda have already discussed this and, I think, we came to a tentative agreement that we could look at at least reducing the level of choice in 'non-custom' partitioning, and remembering the original intent we had (which I think both QA and anaconda teams quite like). It may be difficult to entirely drop the selection, but it seems at least reasonable to go
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
From: awill...@redhat.com Date: 02/21/2014 15:20 Historically, QA and anaconda more or less agreed on an approach whereby the 'guided' partitioning path would be expected to work extremely reliably: QA would undertake to test every (well, nearly every) route through that path regularly and proactively, and anaconda would undertake to fix the bugs. Custom partitioning was much more of a 'bonus' thing: if it worked, great. QA would test it as much as we had time for, and anaconda would fix as many bugs as they could after fixing higher priority stuff. I went back and looked at the history, and in the earlier days of Fedora, the guided path was consciously designed to be very 'choice free'. That makes a lot of sense, but I'd like to add that when doing custom partitioning, you can easily spend the bulk of your actual interaction time getting the partitioning customized exactly the way you want and when anaconda crashes, it's not much fun to loose that effort. I've had this happen lots and still do. Unfortunately, I can never see the pattern to file a BZ for it. One thing I've generally learned *not to do* is click on something for exploration purposes only. I'm trying to think of a good example, but maybe I want to see what the btrfs layout looks like. Okay, but lets go back and take the default now. Poof! With the best of intentions, we'd gone from a reluctant exception to the 'no choice' design to a dropdown which included two very different complex choices: LVM and btrfs. So now the installer path which was originally supposed to be minimal-choice, very robust and testable and fixable, had become rather a lot more complex. Everything should be made as simple as possible, but not simpler. I appreciate your QA angle here. Every condition in a code path leads to exponential growth in testing. However, when I have my admin hat on, I want flexibility. I love LVM for that reason. However, if I'm setting up simple VMs whose backend storage resides in a LV, I have no need or desire for LVM within the VM. It only makes more work if I have to do an in place resize later on. Having LVM on those host makes that resizing oh so much simpler though, especially if additional drives are required. I feel much the same about the /home partitioning and wish there was an checkbox in anaconda for that. Having a separate /home partition is good practice, but I never use the feature because mine is on NFS, so it makes for lots of click work to get the auto layout, then remove the home. (I did learn accidentally with btrfs I can just ignore it and I've not lost any space on /.) So yes, simplicity is good, unless it makes everything else harder later. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Fri, 2014-02-21 at 16:38 -0500, john.flor...@dart.biz wrote: With the best of intentions, we'd gone from a reluctant exception to the 'no choice' design to a dropdown which included two very different complex choices: LVM and btrfs. So now the installer path which was originally supposed to be minimal-choice, very robust and testable and fixable, had become rather a lot more complex. Everything should be made as simple as possible, but not simpler. I don't think that precept applies very well to this area. The problem is that there are - and this is probably *literal*, not a rhetorical flourish - millions of Special Little Use Cases like yours (the one below, snipped for brevity) out there. *You* want it to be easy to skip /home. *She* wants it to be easy to resize a Slackware install. *That guy* wants to use btrfs. *My cat* likes RAID. It is becoming very, very clear that we just cannot undertake to support them all and guarantee that they are all going to work in a release. It's just _too much work_. Everyone agrees that it would be nice if we could, but then everyone agrees that it'd be nice if I had a solid gold toilet. Some nice things just don't happen. We do not have the resources to be in the business of writing the world's biggest disk configuration tool and guaranteeing that it'll never go wrong, which isn't *quite* what we're currently trying to do, but it's not far from it. It's worth trying some other installers out, just to reset your expectations. Have you seen the level of flexibility you get from Ubuntu's interactive installer? Windows'? OS X's? I appreciate your QA angle here. Every condition in a code path leads to exponential growth in testing. And development. This isn't just a QA problem. We do not have the development resources to commit to all this stuff working reliably every six months. However, when I have my admin hat on, I want flexibility. I love LVM for that reason. However, if I'm setting up simple VMs whose backend storage resides in a LV, I have no need or desire for LVM within the VM. Does it hurt you to get it, though? I do my VM installs with LVs. I don't really need them. But nothing explodes, and two hours later I forget all about it. In the end it's just bits. As long as the bits are where they need to be when things need to read them, who *gives* a monkey's tail? I did recognize that it would be tough sledding to get back to zero choice, and if you ask me to crystal ball it, we might have to wind up back at 'plain partitions or LVM'. But that's still a substantial improvement on where we are right now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Fedora Base Design Working Group (2014-02-21) meeting minutes and logs
On Feb 21, 2014, at 2:38 PM, john.flor...@dart.biz wrote: That makes a lot of sense, but I'd like to add that when doing custom partitioning, you can easily spend the bulk of your actual interaction time getting the partitioning customized exactly the way you want and when anaconda crashes, What you're essentially suggesting is the necessary trade off between stability and features isn't being balanced, in your experience. I'd agree with that assessment. I've done hundreds of Windows installs and thousands of OS X installs and those installers never crash. Ever. Seriously never. You can throw the most bizarre crap at them, even a disk with 42 partitions of just linux and BSD and they don't crash. And what interaction time? It's point and install. There's nothing to interact with because there are no options. However, when I have my admin hat on, I want flexibility. I don't find that a compelling argument for many reasons, not least of which is the tens of thousands of OS X and Windows admins who get few install time layout choices, and they seem quite content. And they don't even have a kickstart equivalent, so I think it's fair to say flexibility is served by kickstart. However, if I'm setting up simple VMs whose backend storage resides in a LV, I have no need or desire for LVM within the VM. It only makes more work if I have to do an in place resize later on. Having LVM on those host makes that resizing oh so much simpler though, especially if additional drives are required. I feel much the same about the /home partitioning and wish there was an checkbox in anaconda for that. Having a separate /home partition is good practice, but I never use the feature because mine is on NFS, so it makes for lots of click work to get the auto layout, then remove the home. (I did learn accidentally with btrfs I can just ignore it and I've not lost any space on /.) So yes, simplicity is good, unless it makes everything else harder later. Elsewhere the idea is that the OS installer actually just installs the OS successfully. After that comes such customizations that we are putting into the installer that really don't need to be in the installer. Post-install if I decide I want /home on NFS, if I want encrypted /home, if I want to buy another drive and put /home on raid1, what do I use? Not Anaconda, it's an install time specific tool. The idea of what Anaconda can do to create powerful storage stacks with open source software has significant merit. But it's in the wrong place. It's an anchor on the installer, and can only be leveraged during an install of RHEL, CentOS or Fedora. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
