Albert White wrote: > Hi Dave, > > I'm about to go off on vacation but here are a couple of initial comments > based on past experience and some recent customer issues we have ran into. > I'll frame them as requirements, and when I say upgrades below, I'm > thinking of the patches we have at present. Perhaps some of these belong > more with redesigning our packaging structure. Anwyay... >
Most of your comments I think apply more directly to the Packaging and Patching strategy, but as there's obvious overlap, I'll take a stab at them to start with. > * Upgrades must not clobber a users configuration (I've some bugs open at > the moment for .conf files that are type f and are clobbered by > patches). Agreed, that's certainly my definition of upgrade; what you're describing specifically are clearly bugs in those packages, but being clear about the definition of expected upgrade and patch behavior is important to the architecture. > - How do we address significant changes to configuration files > without harassing the user? In particular for changes which we have > backported, the backport of Native LDAP 2 to Solaris 8 in 108993-18 despite > a lot of testing still managed to cause a lot of problems. > I guess I don't have a good answer initially, other than use SMF (getting into a standard form with supported upgrade semantics is good architecture, after all :-) Seriously, those strike me as design flaws, though I'm unfamiliar with the details of the situation you're mentioning. If we're upgrading without providing compatibility, especially in patches, then we're just asking for a world of hurt. > * Users should be able to select the minimum set of changes needed to > address their needs. (eg. to get a bugfix, users should not have to upgrade > to the latest features also. If you want to fix libc on s10x FCS you need > to upgrade to grub first.) > That's a controversial topic. There's the point of view you express, and then there's the one which says that the combinatorial testing problem of allowing that granularity is pretty expensive, both for the vendor and the customer, so that perhaps we're all better off with coarser granularity. I think the increasingly tight integration between various pieces of the OS works against fine granularity, though our preference for well-defined interface boundaries between components encourages the possibility. In the end, I don't think it's up to this strategy to define direction for the system in this respect; installation technology probably needs to support fine granularity, and the product teams can decide how much to make use of it. > * How should reboots and service restarts be handled during an upgrade? > Our preference would be to eliminate reboots in favor of service restarts. But I'm not sure what you're looking for here; can you elaborate? > * re 2. ... graphical and _automate-able_ text environments. > My thinking is more that the installation process can be automated (requirement #18), rather than the actual interactive interface. Is there a reason you'd like automation support for the UI? > * re 25 A user must be able to revert a particular distinct part of an > upgrade. (In current terms, user can apply patch A then B then C; but then > remove A provided there are no dependencies. The present language implies > reverting is a strictly sequential process). > I can see that for patches, but since the focus here is on an upgrade of the OS, I'm not seeing the value of such a requirement here - we don't let you run mixed Solaris 9 and 10 bits, and I don't have any data saying we should. > * re 26. In addition to applying the software we need to ensure that it is > correctly patched, or at least show that it is not in whatever update tool > there is. In todays terms: If a user installs package A, then a patch X-01 > which applies to packages A and B, patch installation will succeed. If the > user later installs package B, it appears that because patch X-01 is > installed that package B is up to date even though it is not - the user > needs to re-apply X-01. > That one's clearly in the Package and Patch strategy's court. It's a big problem, and was raised by at least one of my preliminary reviewers, but I'm considering it out of scope for this discussion. > * re 39. I'm all for speedup! The current situation with patching zones is > not good. However Solaris customers may wish to patch only every six months > say; this may require a slightly different focus than aiming for 'daily > upgrades'. > That should be requirement #30, for those trying to follow along. This particular requirement is aimed at obviating the need for the per-consolidation upgrade scripts we presently have, such as BFU. Their existence (for which there are reasons, or at least were when they were created) means their users don't use the install and upgrade tools we supply to customers regularly, and that's step 1 on the quality death spiral - it's one reason why the problem survey in this paper is 17 pages long. That requirement applies to a very small, but very important, section of the user base. It seems to me that a solution which is fast enough for that demanding segment will go a long ways toward satisfying the more typical customer, whose patch/upgrade cycle times are more likely to be what you describe. > * The installation interface must allow the user to select a minimised > version of the distribution. In doing so it must automatically satisfy > requirements for what the user has selected. > Agree. The discussion at the end of 2.2.8 was added relatively late and didn't get fed into the later sections. > * The ability to upgrade the installation media rather than post > installation on the system must be provided. Currently flash archives > provide this, but we do not provide any way for a user to freshbit patches > onto an jumpstart install image. The latter would be useful for adding > hardware support, in particular for x86 systems where the current boot disk > ITU process makes installation complicated, eg[1]. > I think this is what I'm saying with requirement #14, but if it could be made more clear, I'm open to suggestion. > * Updates applicable to a minimised system must apply to a minimised > system. We come across patches in testing occasionally which should patch > the minimum solaris cluster, but require patches which only apply to say > SUNWCuser. That's fodder for patching, I think. > - Earlier on you mention that "Solaris user who are not developers are > few > and far between these days". I disagree, within Sun we have plenty of non > technical staff using desktops, or at least sunrays. Regardless, we should > provide a 'metacluster' which would be appropriate for a non devleoper end > user. Though I'd agree with the End User metacluster at present being > essentially meaningless; in fact I think that all metaclusters are fairly > meaningless. In the grand scheme of things, the numbers of those people are very small, so they're not a category I think should be catered to in the mainline experience at this point. Sun Rays are really a server installation by an administrator, not the end users, and would seem to often be on servers that are providing more than just a desktop. > > Right, time to go to Turkey for an eclipse! I'm sure I'll have thought of > more to add by the time I get back! > Thanks Al. Dave
