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 waaaaay 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 back to only having one 'plain partition' choice and one 'LVM' choice (whether it's 'regular' LVM or thinp LVM), and relegating other choices to the 'custom' path.
QA's angle on this is that it's really extremely difficult to develop a plausible set of storage release criteria and validation tests with the current situation. If we map out all the possible paths through the 'non-custom' path it still comes out to something like 80, given the current level of choice, and it's pretty impractical to test 80 different routes at every TC/RC build. Or even at every milestone. So if we don't change the design, QA is effectively forced to test only a reduced subset of the 'non-custom' path choices, whether we *plan* to do that or we pretend we're going to test them all but, inevitably, don't. Yet the installer design doesn't really communicate in any way that some paths through 'non-custom' install are more tested/reliable than others.
Anyhow, that's kind of where we left off back in December or January, and we probably really ought to get around to looking at this again - and, as I said, incorporating the perspectives of the different Product WGs and the question of variant anacondas (whether any of the Products actually wants one, and if so, whether that's actually viable) pretty soon.
On Feb 21, 2014, at 1:20 PM, Adam Williamson awilliam@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
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.
----- 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
anaconda-devel@lists.stg.fedoraproject.org