Hi, FESCo. Can you please discuss this issue at the next FESCo meeting? Thanks!
bcl has said that there is no chance the revamped anaconda in the F18 tree will support installation from the live environment by next Wednesday (the date for the next go/no-go meeting). So, we have several options, if we assume Alpha is otherwise ready to go at that point:
1) Release Alpha with no live images 2) Release Alpha with live images with no installer 3) Delay Alpha (and hence the rest of the schedule) until anaconda live install support is ready
It seems like this should be a fesco or board decision, I don't think qa/releng/anaconda team can just make this decision on our own, so I figured to bump it up the chain. Please consider the options and let us know what you think. Thanks!
This is yet another warning sign that the new installer is not in ready enough shape for F18 and should be delayed to F19 or the release simply slipped until it is ready enough.
There is nothing wrong with our criteria, our test cases nor our policy Anaconda simply is not meeting them ( in time ) and starting reducing it to meet the software in question not only is bad practice but it also set's bad example.
The thing is if the NewInstalllerUI Feature is wanted so badly in F18 then we simply have to face the music and slip another week if not then that feature should be dropped to it's contingency plan and the F17 Anaconda be used instead and the NewInstalllerUI Feature delayed to F19 when it's ready enough for our user base to consume.
What we really need (and that's what we do not have now) is a real Anaconda Roadmap with a promise what the team can deliver for Alpha, Beta and Final. So NewInstallerUI Feature Page should be extended. I think the Live image support breaks Feature Freeze criteria but let's give Anaconda team a chance to defend.
Adam, do you know what sort of problems blocks Live now?
Replying to [ticket:941 adamwill]:
Hi, FESCo. Can you please discuss this issue at the next FESCo meeting? Thanks! bcl has said that there is no chance the revamped anaconda in the F18 tree will support installation from the live environment by next Wednesday (the date for the next go/no-go meeting). So, we have several options, if we assume Alpha is otherwise ready to go at that point: 1) Release Alpha with no live images 2) Release Alpha with live images with no installer 3) Delay Alpha (and hence the rest of the schedule) until anaconda live install support is ready
FESCo is not meeting next week as too many people will be unavailable. The next FESCo meeting is Wed Sept 5, at 13:00 UTC. Any sort of decision will have to be handled through this ticket or on the lists. FYI.
1) Release Alpha with no live images
2) Release Alpha with live images with no installer
3) Delay Alpha (and hence the rest of the schedule) until anaconda live install support is ready
2) seems to me much preferable over 1) - at least it would be possible to test the other aspects of live image creation and use.
As for 2) vs. 3) - I can see two questions: a. Are our criteria for requiring installation from a live image by Alpha correct? Or would we be willing to release Alpha without this ability if there wasn't an anaconda GUI rewrite going on? b. When is it realistic to have live image installation working again?
Fedora QA is probably most qualified to decide on a. - what is their opinion?\
Could someone from anaconda help answer b.?
My not-really-informed view on a.: I see the purpose of Alpha to primarily allow integration of new versions of all the various components for the first time, and to test the resulting combination; for that, Alpha must be installable, but it's not necessarily required that all possible installation paths work (especially if making them work were an effort localized to anaconda, not requiring coordination/integration with other components - is that the case here?)
Replying to [comment:2 jreznik]:
Agreed
If the Anaconda project needs another week ( and can deliver ) we follow well established procedure and slip another week.
Options A) and B) are really not acceptable.
It's more important that we deliver something usable in the hands of our user base even if that means that we need to use the anaconda release that was in F17 and delay this feature to F19 instead of us start making exceptions from procedures to chase some release date.
Is there some RHEL rush going on here since the Anaconda team seems to be so insistent on pushing this NewUI features of theirs into F18 instead of F19 when it's in much better shape for our end user base?
mitr: to me, point a) is a complex question. My personal take on it is that I can conceive of cases where it'd make sense to waive release criteria; they don't have to be hell or high water.
To me the release criteria are written with a kind of 'steady state' in mind: they kind of have the assumption that the code to back them is basically written, and what we're dealing with would be bugs in that code. So the kind of situation the 'you must be able to install from the live images' criterion is envisaging is not really a situation where no-one's written the code to let you install at all yet. It's more a case of 'given that we have code for generating live images and code for installing from them, at Alpha, we must be able to build and ship installable live images, or we're clearly doing something really wrong'.
So the situation where we're completely re-writing the installer and the code just isn't done yet puts us...a bit out of bounds. I think the criterion is correct, in the general case where we're plugging together bits of code that have existed for years, we really shouldn't fail to build an installable live image at Alpha stage. But there can be situations where it would make sense to waive criteria.
Now, whether this is one of those situations isn't totally clear-cut, to me. I think you could make a pretty good case that we can reasonably apply the release criteria to an anaconda rewrite, and if the criteria aren't met, it's a good sign the anaconda rewrite just isn't on track and we need to either postpone to F19 or delay the release of F18, as johann says. But I'm not sure the question 'are the release criteria correct' covers every possibility.
Sorry for the waffly answer =)
So, I think we really need some anaconda folks input here... bcl: Can you comment, or add to cc anaconda team folks who can?
In my mind we need to know: When will install support on live media land? A few weeks? By Beta? Something else?
Personally, I think there is value in live media even if you cannot install from it. If the delay is short, I'd be ok slipping to get install in live media support landed. If it's longer, I would be ok with shipping live media with no install support (and shouting that fact out as best we can). If it's going to be much longer, I would as anaconda folks to look at reverting anaconda for f18 and punt new-ui to f19.
Another question related to this: Are we using livemedia-creator or livecd-tools for f18?
Dennis has said he intends to use livecd-tools, because the Koji integration for livemedia-creator is not yet done and he feels it's too late in the cycle to be faffing around trying to hook that up.
jreznik: sorry I missed your question - if you mean 'what's blocking the compose and delivery of live images', up till now it has been the fact that livemedia-creator was not really ready to be used for official purposes, but now dennis has decided to use livecd-creator, really nothing. I have been able to build working F18 live images with livecd-creator, so none of the changes from F17 to F18 have had the effect of completely breaking livecd-creator, so we should actually be able to deliver some lives with the next TC/RC I think.
If you mean 'what's blocking the live install from working', I don't know in detail, but broadly I believe it's simply adapting the code that allows anaconda to run within a working live environment to the changes brought in by newUI. bcl could give a more detailed answer.
This is Anaconda status/roadmap from Friday: https://fedoraproject.org/wiki/Anaconda/Task_Status - the current status of Live installer UI according to this list is 10%, Beta is target. So it really does not look like something that could be ready for Alpha, even with another slip...
Given our history of slips I'd say we should simply just slip. I see no reason why we shouldn't. We shouldn't ship with a less tested installer just to meet a release date. (Not having it working in alpha means that it will only gets testing from beta onwards and not from alpha as it is supposed to be).
Live install depends on having live images running newui so that the new packaging code can be written and tested. There is code there, but it has zero testing so far. Beta would be a much more realistic target for live installs.
livemedia-creator has been working since F17, and several people have been using it and providing feedback. But the newui rewrite broke some of the things that it depends on (kickstarts, virt-install and image installs for example). As of last week I had custom built boot.iso's that worked with lmc, so assuming all the bugs I found make it into anaconda, lorax and dracut lmc will work to make live images using virt-install at least.
livecd-creator has seen no changes related to secure boot, shim, grub2 so it isn't just a drop-in fix. All of my focus has been on getting lmc and the things it depends on working.
I am at Linux Plumbers the rest of this week, so the soonest I'll be able to get back to live install (whether it be lmc or livecd-creator) is 9/4.
Replying to [comment:7 kevin]:
So, I think we really need some anaconda folks input here... bcl: Can you comment, or add to cc anaconda team folks who can? In my mind we need to know: When will install support on live media land? A few weeks? By Beta? Something else? Personally, I think there is value in live media even if you cannot install from it. If the delay is short, I'd be ok slipping to get install in live media support landed. If it's longer, I would be ok with shipping live media with no install support (and shouting that fact out as best we can). If it's going to be much longer, I would as anaconda folks to look at reverting anaconda for f18 and punt new-ui to f19.
Alpha release is more about the installation testing than anything else and I'm sorry to say it but testing live media installs with the beta release is just too late in the game where we have more or less started to focus testing the *DE themselves and various test days.
In any case fesco needs to decided of the contingency plan of the NewUI feature should be put in place and Anaconda reverted and that decision is not something that can be delay because we arguably should be shipping alpha with the old installer should that be decided.
So I personally would like the Fesco members to go over the blocker bugs along with what has been said here then communicate with each other and decide this a.s.a.p at least way before Wed Sept 5 so we can ship the alpha with the "NewUI" or with the anaconda that got released in F17 and we don't delay the release any further.
Replying to [comment:8 adamwill]:
Do we know whose task this is, and what the roadmap of it is? I know it was postponed from F-17 due to schedule concerns; it's bit disconcerting to have what appears to be a simple repeat in F-18.
The Fedora QA team discussed this issue and ticket at our meeting today - http://meetbot.fedoraproject.org/fedora-meeting/2012-08-27/fedora-qa.2012-08-27-15.00.html - and agreed on a set of recommendations on behalf of Fedora QA as a body:
Point 1 is simply informational: at this point we're pretty much assuming Alpha is going to slip at least another week. Looking at the state of anaconda and the blocker list, it seems highly unlikely we will roll a build within the next two days which passes all validation tests.
To expand a bit on point 2 - it was noted that reverting to oldUI would not be a free action and would probably require a couple of weeks slippage in itself, and then we'd again be trying to integrate newUI for F19. We just felt that the reversion option wasn't a great fit for Fedora's principles, even though from a purely QA perspective it probably gives us the most certainty going forward.
On point 3, again purely as far as QA goes we have no problem with freezing for long periods, but we felt that for the project as a whole, if we decide to do a 'planned slip' of more than two weeks, it would be appropriate to have a non-frozen period to start the slip, so the delta between 'release' and 'updates-testing' doesn't get too big and inconvenient for the development team.
The following paragraph wasn't officially voted upon but represents my impressions of general feeling from the meeting, please feel free to verify it based on the logs:
There was a strong feeling that Jaroslav is right in wanting the anaconda team to produce a detailed review of what bits of newUI are done, what bits still need writing within the F18 cycle, and what bits are unlikely to be done within the current F18 schedule. I think it's correct to say that QA as a team endorses that request. I think it's also fair to stay that there's a strong current of concern within QA regarding the status of anaconda overall at this point: we seem to be generally sceptical that, if we attempt to go along with the current schedule, things will progress smoothly after Alpha. There is a general sense that newUI anaconda just isn't where it ought to be at this point on our current schedule. We would like to explicitly request FESCo consider the whole issue of anaconda's overall readiness and the likelihood that we will be able to meet or at least approximate the rest of the current schedule, not just restrict consideration strictly to the live installation issue: this seems the correct time and context in which to do it.
In this comment I'm speaking strictly personally, not representing QA: I'm posting separate comments to make this clear. After this morning's mini-blocker review, #anaconda chatter, and the discussion of this topic in the meeting, my personal feeling is that anaconda really isn't where it ought to be at present, and this live installer issue is only one manifestation of that. Other problems seem to be looming down the road: for instance, as far as I know, the code to handle upgrades with newUI isn't even written yet, and upgrades - including preupgrade - are supposed to work fully by Beta. It seems highly optimistic to expect this to be the case on the present schedule.
There's a general sense that the newUI code is still being written even as we're supposed to be validating and releasing it, and the devs seem to be harried and being forced into trade-offs between things which really all ought to be getting proper attention.
It would be nice to have a sense of what the anaconda devs feel, but at present, my personal opinion is that our best chance of a reasonably successful F18 release lies in a slip. Specifically, I think we ought to get the assessment from the anaconda team of what functionality isn't done that we all agree needs to be done, get an accurate - i.e. conservative - estimate of how long it will take to write that code, and announce a schedule delay of at least that length of time. The aim would be for the anaconda team to finish at least the initial work on all the features of anaconda that we really need in place for the Fedora 18 release: before we go back into the 'freeze and validate' part of the release process, all the basic code should at least be present. Then we could go back to trying to roll an Alpha release in a situation where all the anaconda team's resources would be available for fixing bugs discovered during the validation testing.
In practice I would imagine this would involve, say, a three week or one month slip, with an unfrozen period of a couple of weeks or so. But it would depend on the anaconda team's evaluation of the situation.
I spoke to David Cantrell (Anaconda Manager), and after discussing this issue with his team, he estimates that to get a functional liveinst for Alpha would be 3 additional weeks.
Like Kevin, I see value in having live media even if live install is not working. Particularly with an Alpha release, most people are likely only going to boot it at this point anyway. So I'd suggest we continue to spin live media regardless of whether we slip Alpha release or not. That will let testing progress in other areas.
I think newUI is an important feature, and I'd personally be willing to slip 2-3 weeks to allow it to succeed. Beyond that would be tough to allow.
At the same time, we need to really look hard at how we got into this situation. I don't think the blame entirely lies with the anaconda team.
Replying to [comment:16 notting]:
Replying to [comment:8 adamwill]: Dennis has said he intends to use livecd-tools, because the Koji integration for livemedia-creator is not yet done and he feels it's too late in the cycle to be faffing around trying to hook that up. Do we know whose task this is, and what the roadmap of it is? I know it was postponed from F-17 due to schedule concerns; it's bit disconcerting to have what appears to be a simple repeat in F-18.
It is my task, F17 we never even looked at it because it was requested too late in the cycle, F18 creapt up on me and I was working on other things. though as ive looked into it im not sure we can ever actually support livemedia-creator in koji because the way its designed to work does not work with how we have to do things in koji.
We need to create a chroot with the target livemedia-creator installed and libvirtd needs to be running inside the chroot, livemedia-creator then starts an install using virt-install, at least ive been told thats the way they want it to work. there is a no-virt option that could be made to work in koji but i was told thats not how its intended to be used.
spins-kickstarts will alos need quite a bit of work to work with livemedia-creator, which has not been started at all. It seems like the only really viable option for Alpha is no lives. there is a lot of work that would need to be done before beta regardless of how we make them.
Replying to [comment:19 spot]:
(adding dcantrell here).
What is the status of the other needed features for anaconda? (ie, upgrades, kickstarts, text mode, etc). The things in our release critera? http://fedoraproject.org/wiki/Fedora_Release_Criteria (look for anything starting with 'the installer must')
If we slip 3 weeks for liveinst, would we also expect all the other release blocking features to have been written and ready to test?
To keep things in-line, I'd summarize the requirements stated in the criteria as:
I might have missed something, but that's what I get with a quick distillation of the criteria as they stand. It'd be good to have a very quick status report on each of those elements. Plus any others anaconda team is aware of which I'm not, obviously.
Replying to [comment:24 adamwill]:
To keep things in-line, I'd summarize the requirements stated in the criteria as: Serial console support Kickstart-driven install, via 'all methods' of delivering the kickstart file (this is a bit vague) RAID: 0, 1 and 5, software, hardware and firmware Upgrade from previous release, and work with preupgrade
These are Beta criteria.
Basic dual-boot with Windows
Not sure about this one. But definitely not Alpha one and as we're talking about Alpha here...
One crazy idea by vpodzime - not sure it's possible, especially from releng side - to use old Anaconda but only as Live Installer (it would require old anaconda on live, python-meh).
Replying to [comment:20 jwboyer]:
Like Kevin, I see value in having live media even if live install is not working. Particularly with an Alpha release, most people are likely only going to boot it at this point anyway. So I'd suggest we continue to spin live media regardless of whether we slip Alpha release or not. That will let testing progress in other areas. I think newUI is an important feature, and I'd personally be willing to slip 2-3 weeks to allow it to succeed. Beyond that would be tough to allow.
Why do you think it's an important feature and why should it be pushed into F18 when it's not in better shape then this? What's the rush?
And I think if we are going to slip and we are passed the two week slippage mark we should slip with enough time an month instead of risk slipping to little and be forced to slip again.
Arguably the people that approve a feature are also responsible to oversee it's progress and enact the contingency plan if it's obvious that the necessary progress of the feature will not be meet in time.
If they either cant or wont do that, The overseeing and the authority to do deem it fit or not should be delegated to the QA community which it arguably better belongs in anyway.
Replying to [comment:23 kevin]:
Check https://fedoraproject.org/wiki/Anaconda/Task_Status
David Cantrell confirmed that three weeks mentioned above by spot in email conversation. Live installer is now more blocked on the livemedia-creator/livecd-creator side, Anaconda code is in place. Vpodzime took a look and he thinks he can fix top issues he found by the end of the week.
So there are three options: do not ship Live images at all (and provide some kind of semi-official pre-Alpha image for Test Days - Test Days starts next week! We have to be sure we can create/distribute one!) ship Live images without installer (and reconsider shipping installer if more than one week slip) * wait for liveinst - but we need an estimate from relengs/anaconda (ausil?) if they are able to make it in that three weeks (or less)... In this phase installer is only needed for testing installer itself (but it's a good reason, not to delay Beta in case of issue with new and barely tested code, so I understand QA...)
One thing that I am noticing on the [https://fedoraproject.org/wiki/Anaconda/Task_Status Anaconda status page] is that upgrade via preupgrade isn't scheduled to be complete until F19 beta and upgrades via anaconda aren't even mentioned. Are we going to support yum upgrade for F18? Are we going to only support upgrades via media for F18? Are we going to support F17 -> F19 preupgrade when the feature is completed?
Similar to what adam said in c19, I'm of the opinion that if another 3 weeks to a month will help the anaconda devs get live install and upgrade code done, let's slip that long and lift freeze for part of that slip. If they need longer than a month to get everything done, maybe it's time to start talking about reverting to oldui for F18 and push newui off to F19. Obviously, there is little point in talking about any of that without input from the anaconda team. There would be costs and penalties for rolling back but at some point, we need to figure out how long we're willing to slip or which features we're willing to cut in order to have newui for F18.
As far as I can tell, we have the usual selection of sub-optimal choices for software engineering: 1. Significant slip until all of the features are done 2. Cut features from the release (maybe some upgrade, live install etc.) and hope that we'll still release somewhat on time. 3. Plow forward, slip week by week until everything is ready for release pretending that everything will be OK if we just get the next fix out the door
I've seen a form of option 3 first hand and I'm not sure that I have words for how terrible of an idea I think that is. The environment was different but we were in firefighting panic mode for a year and a half, constantly testing new RCs to fix the last set of bugs that were found by customers and so caught up with getting it fixed NOW instead of correctly that we ended up spending far more time, resources and human sanity than if we had just slowed down and "done it at least somewhat right" the first time around. It's a great recipe for frustration, anger, burnout (dev and tester alike) and/or a release that is bad enough to alienate a non-insignificant chunk of our userbase.
At this point, I doubt that slipping a week at a time is going to help much of anything - it'll frustrate devs with an extended freeze, add extra time to the blocker review process, slow down anaconda progress with required blocker fixes, slow down progress on non-anaconda features for F18 due to the extended freeze and when we do have something that meets the alpha release requirements, we're just going to be right back where we are now for beta and upgrades.
If I'm wrong and we really just need another week to get a limited alpha out the door and the upgrade code is almost done, I'm happy to be wrong in this case. I'm not thrilled about the prospects of either a significant slip or cutting significant features. I just see that we're already a week late (working on 2) for alpha and we have no fully functional DVD installer, no lives or method for building lives and a netinstall that mostly works if you know all the workarounds.
Replying to [comment:27 johannbg]:
At the same time, we need to really look hard at how we got into this situation. I don't think the blame entirely lies with the anaconda team. Arguably the people that approve a feature are also responsible to oversee it's progress and enact the contingency plan if it's obvious that the necessary progress of the feature will not be meet in time.
Sure. I don't think that wasn't done here. Perhaps I wasn't clear enough with my comment, but I was talking about the specific technical issues that caused this feature to have the issues it's having. I don't think this is a governance/oversight problem.
For example, it makes complete and utter sense for the anaconda team to be developing newUI on a stable base (e.g. F17). To do otherwise would mean they were essentially herding cats and waiting for everyone else to fix the problems in rawhide. However, that doesn't mean we should not be trying to do more in rawhide itself. Perhaps we should be doing daily/weekly composes (throw-away or otherwise) of rawhide so that when the time comes for developers to really start focusing on the release it isn't in an utter state of chaos. That is simply an example of the kind of introspection I'm looking for, not necessarily the only thing, or even a thing at all, that could be improved.
jreznik: I listed all requirements for all release points, not just Alpha, on purpose. As has been said repeatedly, there is a wider question here of overall anaconda readiness; if we slip three weeks for liveinst then at Beta find we have to do this whole process over again and slip another three weeks for upgrades, is that really the best outcome? It seems better to nail down a definite status of all the required functionality now, so we know exactly where we stand.
Replying to [comment:30 jwboyer]:
Replying to [comment:27 johannbg]: At the same time, we need to really look hard at how we got into this situation. I don't think the blame entirely lies with the anaconda team. Arguably the people that approve a feature are also responsible to oversee it's progress and enact the contingency plan if it's obvious that the necessary progress of the feature will not be meet in time. Sure. I don't think that wasn't done here. Perhaps I wasn't clear enough with my comment, but I was talking about the specific technical issues that caused this feature to have the issues it's having. I don't think this is a governance/oversight problem. For example, it makes complete and utter sense for the anaconda team to be developing newUI on a stable base (e.g. F17). To do otherwise would mean they were essentially herding cats and waiting for everyone else to fix the problems in rawhide. However, that doesn't mean we should not be trying to do more in rawhide itself. Perhaps we should be doing daily/weekly composes (throw-away or otherwise) of rawhide so that when the time comes for developers to really start focusing on the release it isn't in an utter state of chaos. That is simply an example of the kind of introspection I'm looking for, not necessarily the only thing, or even a thing at all, that could be improved.
I do believe this is limited more or less to the Anaconda development model and how we are not releasing updated images which arguably could have fixed many of the problems user have experienced at release time in the past ( not limited to Anaconda itself ).
The Anaconda team has worked around that for distribution packages via the installers ability to install online with updated packages however that does not update Anaconda itself hence think we still need to update the GA release. Probably somekind of model that works with the arm community and their releases since it's kinda logical that Anaconda extends to flash devices and probably provide a standalone gui app to do that as well in the not so distant future.
I do agree with you we need to have weekly throwaways ( I think personally that daily's are a bit short both from development perspective along with testing one ) but based on experienced using rawhide for it wont work but an weekly throwaways with Anaconda latest snapshots at compose time on the GA release could work and could be used until feature freeze and things in rawhide have stabilized.
We just have to hear from releng/infra if it's doable and if it is then we in QA can implement the necessary framework within the QA community to work with that idea.
A few updates I was able to collect: vpodzime reports, that clumens sent a bunch of patches to live installer yesterday, he was able to use it and install F18, it crashed on known bug (#851653), should be fixed right now (affects also standard installer) we could use livecd-tools for Alpha, small patch needed for Koji, ausil should fix it by the end of the week... we will loose some features (probably UEFI?, SB?... we are not even sure we will make it by Alpha)
This looks a little bit more optimistic (no more 3 weeks slip hopefully needed) but integration is still needed to check if it's viable option and how it works.
Installable from live image, netinst, DVD (all written either to optical disc or USB stick), directly via kernel pair (PXE), all on BIOS or UEFI firmware
I sent off a whole pile of patches for live yesterday, which will be in today's build, and can verify live works as well as netinst/DVD did. That is, it stopped at the NTP thing just like everything else did. But there's a fix for that. USB and UEFI I've not tested.
Capable of using DVD, HTTP and FTP package sources
Works.
Basic graphics mode (anaconda must run with only the capabilities provided by vesa driver)
Text and graphical interfaces (though text requirement was waived by FESCo initially)
VNC support
Works. Falling back to VNC if graphical fails may not work yet, but that's easy.
Encryption of installed system
Doesn't work yet, but unlikely to be difficult. Remember all the backend storage code is still unchanged.
Rescue mode
Update image support
Works, though perhaps if you have more than one network device there's a bug. I've heard one report of this from the ppc guys.
Failure reporting
Works okay, needs improvement.
Serial console support
You would need to ask jlk for specifics, but I believe this works.
Kickstart-driven install, via 'all methods' of delivering the kickstart file (this is a bit vague)
I've not been able to test this recently due to anaconda/dracut interface problems, but it has worked in the past. You would need to ask wwoods for specifics.
RAID: 0, 1 and 5, software, hardware and firmware
UI-specific patches that have been in the works for a while went in today. Again, remember the backend storage code is still there for us to use.
Upgrade from previous release, and work with preupgrade
This is going to involve preupgrade and that systemd feature, and have nothing to do with anaconda. You'd need to ask wwoods for a status on this. He's been following it.
Network-attached storage, though this has been implicitly waived by FESCo as part of the feature proposal
Depends on how much configuration the storage needs, but yes this has been waived.
LVM
The basics work, but some of the most fancy UI stuff is not there yet.
Not tested.
Thanks a lot, Chris! Adding Will to CC. Will, could you expand on the thing clumens referred to you? Especially exactly what the plan is for upgrading, and how far along we are in implementing the plan.
Should all work fine.
There were some (network-related) problems using inst.ks=file:... and PXE booting but fixes for that are in progress - see bug 844478 and bug 845225.
inst.ks=file:...
Upgrades are going to be handled by a completely different tool/runtime image. There's prototype code but nothing to show yet. Little progress since I've been waylaid by Alpha bugs.
Realistically, do you think that if we slipped only one more week for Alpha, you would be able to have the upgrade code written in good time for the Beta release? Or would we just wind up going into another multi-week slip while waiting for it to be finished up?
Assuming an extra week's slip from the current schedule (which is a given at this point), Beta TC1 would be slated for 09-25. We'd really want to have the upgrade code in at TC1 time, given our experience with Alpha. If there's a significant chance it wouldn't be ready by then, I think we should consider adjusting schedule now rather than later.
Thanks!
Replying to [comment:36 wwoods]:
Upgrade from previous release, and work with preupgrade Upgrades are going to be handled by a completely different tool/runtime image. There's prototype code but nothing to show yet. Little progress since I've been waylaid by Alpha bugs.
AFAICT this is the first mention of the "completely different runtime image" for updates - is it an internal anaconda design aspect, or something like a new .iso that requires rel-eng and QA to know about it?
I can't help commenting that I have long felt that anaconda and some other core Fedora components should really be on separate early hard deadlines ahead of release milestones (for example one month before Alpha and Beta might be good). I believe this could help make Fedora much more testable during the main development cycle and save wasted Fedora development time. But probably I should better open a separate ticket to propose this for F19.
Replying to [comment:29 tflink]:
If upgrade support can't be done in time the feature is simply not ready and we should just revert to old anaconda. If the anaconda team needs more time so be it, but we shouldn't ship half finished stuff because of that.
Replying to [comment:38 mitr]:
Replying to [comment:36 wwoods]: Upgrade from previous release, and work with preupgrade Upgrades are going to be handled by a completely different tool/runtime image. There's prototype code but nothing to show yet. Little progress since I've been waylaid by Alpha bugs. AFAICT this is the first mention of the "completely different runtime image" for updates - is it an internal anaconda design aspect, or something like a new .iso that requires rel-eng and QA to know about it?
Internal, I guess. It'll be a different runtime image in the install media/tree - e.g. "images/upgrade.img" instead of "images/install.img".
The main user-visible difference would be that you don't boot the media to do an upgrade - you run an app on the system to be upgraded, like preupgrade. Or you insert the media and run the app from there.
Replying to [comment:41 wwoods]:
Internal, I guess. It'll be a different runtime image in the install media/tree - e.g. "images/upgrade.img" instead of "images/install.img". The main user-visible difference would be that you don't boot the media to do an upgrade - you run an app on the system to be upgraded, like preupgrade. Or you insert the media and run the app from there.
Ok, thank you for clarification. What's the expected time for upgrades delivery? If you say "by beta without problems" you got me :)
What's the current status and exactly what is the direction Anaconda is taking with regards to minimal/server installs given that the root password can no longer be set in the installer?
johann: for TC4 and Alpha final there will be an optional root password 'spoke' where you can set a root password, but you won't be forced to (so you can still shoot yourself in the foot). longer term something better will be done - I hear the current plan is to make the spoke mandatory if firstboot isn't in the set of packages to be installed (so you will either have to have a package set that includes firstboot or a root password set, to get to the install step).
We still don't seem to have an answer to the question of whether the upgrade re-implementation will be complete in time for Beta validation on the current schedule. Will, could you please let us all know about that? Thanks.
From 2012-09-05 FESCo meeting:
AGREED: FESCo agrees to proceed with alpha as planned in anaconda. The new upgrade code needs to be working at beta freeze per beta criteria. FESCo will revisit the state of this code one week before Beta Freeze; this review is currently scheduled for 2012-09-26.
A new ticket will be opened to track the upgrade functionality.
That ticket is ticket #946.
Login to comment on this ticket.