Jerry Jelinek wrote: > During testing of the zone "update on attach" feature > we have encountered a problem with IDRs on S10. > > If you are not familiar with an IDR, it is a temporary, > one-time patch that is issued to try to solve a problem > before an official patch is released. Because these > are temporary, one-time patches, there is no metadata > in official patches to tell us if the IDR is obsoleted or > not. Because we don't know if the IDR is obsoleted by > some other patch, "update on attach" will require > that any IDRs installed on the source system must also be > installed on the target system. > > If you have a zone that you are migrating because of > a disaster recovery situation where the original system > is no longer available, and the original system had > an IDR installed that is not on the target (e.g. s10u4 > with IDR to S10u6 where IDR is not needed), then there is > no way to migrate the zone and update it to match the > target if the IDR does not apply to the target system. > > If the original system is still available, you can work > around this by removing the IDR before migrating the zone. > > I have a few different ideas for how to handle this. > > 1) change the meaning of attach -u -F > Right now -F just forces the attach, changes the zone > state to installed and we're done. No update occurs. We > could change the interaction of these two options so that > we still do the update but ignore any verification warnings. > However this would allow a potentially major downgrade. > > 2) attach -u -p xxxxxxx -p yyyyyyy .... > Add a new -p option which allows you to specify patches to > ignore. We would use this to specify IDRs which don't > exist on the target, although it could also be used for > regular patches that might be broken. > The user would have to understand this at a pretty good > level to know when to use the option. We might want to extend > this idea to specify pkgs as well, in case we have a broken > pkg. This allows a potentially major downgrade if the user > specifies a lot of patches.
I am not sure I have an opinion yet, as I am not sure what "major downgrade" means. If that would allow you detach the zone from the new system and re-attach on the original, I can see a benefit. (The inability to attach a zone on its original system is my biggest concern with the upgrade on attach.) One thought with 2) is to also consider -P filename, where filename lists the patches or packages. Similar to -x and -X for flarcreate. Steffen > > 3) attach -u -i > Add a new -i option which means ignore all IDRs. > This is pretty specific to the IDR issue, doesn't require a > lot of thought for the user, but doesn't give much flexibility > if we hit a different problem with bad patches or pkgs. > This forces the user to think about the impact of ignoring > the IDRs before an update is done. > > 4) attach -u > No change to the CLI but change the implementation to > always ignore all missing IDRs. > This might still allow a pretty big downgrade with no > user input if you had a lot of IDRs on the source system for > some reason. This is pretty specific to the IDR issue, doesn't > require any thought for the user, but doesn't give much flexibility > if we hit a different problem with bad patches or pkgs. > > Let me know what you think about these choices or if there is > another idea that seems better. > > Thanks, > Jerry > _______________________________________________ > zones-discuss mailing list > zones-discuss@opensolaris.org _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
