James, James Carlson wrote: > Jerry Jelinek writes: >> We can handle 'update on attach' from s10 to nv, although nv isn't an >> official release yet and something might happen which breaks this (maybe >> IPS?). We don't support 'update on attach' of s8 or s9, although I have >> played >> around with that and it kind of works. There are some other issues there >> which need to be looked at before we would support that. One thing we've >> considered, but which is not part of this proposal, is to use 'update >> on attach' to convert an S8 or S9 branded zone into a native zone >> running S10. There hasn't been any demand for that feature yet, so >> its not currently one we're working on. > > Perhaps it's "not this project," but it'd be interesting to see where > this feature set is headed.
There are different possibilities, such as I've mentioned; updating s8 and s9 branded zones to native, or p2v for pre-s10 systems, or making update on attach be more like a true upgrade, or update on attach between different pkging systems (svr4 to IPS). What we actually do will depend on the demand and the priority vs. other features. > I would expect that since we support non-native brand zones, the user > has to choose (somehow) whether he wants to have his imported zone > become upgraded to the current system or whether he wants it to stay > as-is. Yes, so if you configure the zone with the 'native' brand, then that means something different than if you configure it to be a 'solaris8' or 'solaris9' branded zone. > Since we (intentionally?) make branded zones available only for minor > releases -- and not for individual KUs -- this means that the user > should expect that he's forced into an upgrade of some sort that > emulates patching when importing an S10 zone onto an S10 system. But > should he expect this otherwise? When we differ by a minor release, > there are two paths (as-is branded or upgrade to native), and it's not > clear which gets used or should be used. When attaching a zone to a new system, the zone configuration's brand dictates the behavior. For solaris8 or solaris9 branded zones, nothing is done to the zone. For native-branded zones, either the zone is already in sync with the global zone (making it usable) or it is not in sync and you must use 'update on attach' to complete the migration. > Otherwise, if he's always forced into an upgrade, then that means > branded zones eventually go away, doesn't it? No. If the zone was a solaris8 or solaris9 branded zone to begin with, then it remains that way (assuming the brand is supported on the new host). > Or does giving the user this sort of control open the possibility for > different zones on an S10 system that run different S10 Updates? We don't have a solaris10-brand at this time so the issue doesn't apply. It sounds like you might be thinking of the following RFE: 6666646 Solaris 10 zones on OpenSolaris binary (supported) distributions > Obviously, I'm confused. :-/ > >>> Is that correct? If so, then at least the administrative aspects of >>> patching are relevant here: the result is as though the required >>> patches were installed into the newly-attached zone, regardless of how >>> it's implemented internally. (And just as patching doesn't work >>> across minor releases, it doesn't work here.) >> When crossing a minor release boundary (like s10 to nv) all of the pkg >> version numbers change, so patches aren't a factor. We see that there >> are new versions of the pkgs, so we know those pkgs need to be updated. > > I think that misses the point. I wasn't expecting "upgrade on attach" > to do anything across a minor release boundary; I was expecting it to > do what it does on S10, which (from a user's point of view, not an > implementation view) is effectively upgrade the bits as though patches > were added due to the differing patch levels of the source archive and > the running machine. > > I'm surprised that it might do something different. Yes, it does that. I didn't mean to imply it did something different. "update on attach" always uses the same mechanism to update pkgs within the zone, whether the pkg varies by version number or by the patches applied to the pkg. Thanks, Jerry _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
