Henrik Johansson wrote:
> Hi all,
> Some thoughts regarding update on attach, and why I don't think it
> will be as useful as it could be. Perhaps Jerry or someone could
> enlighten me or give me some feedback.
> This mainly applies to whole root zones, since they do not have any
> inherited package directories.
> The update to the local zone only updates packages that have the
> SUNW_PKG_ALL_ZONES set to true or are in a package inherited
> directory. This means it is not similar to an upgrade performed by the
> installation system or live upgrade.
> One useful scenario for update on attach was to have one node upgraded
> without zones and then migrate the zone one after the other to the
> upgraded host and have them upgraded on attach (quite useful when you
> have 20+ zones in one machine). This will leave the zone in a
> supported state, however the zone will have a mix of packages from the
> old and new machine, depending on if they are required to be
> consistent between all zones. Since many installations using local
> zones keeps the local zones in sync with the global zone, this is not
> an optimal situation. If we use update on attach today, that zone will
> be different from the other zones created after the upgrade or zones
> that have been upgraded at the same time as the global zone. In the
> case of one machine being upgraded to a later update of Solaris, that
> will be quite a few packages with different versions. This is not an
> acceptable solution for many environments.
This is a correct observation and is why I always try to distinguish
between a true upgrade and zone 'update on attach'.
> Shouldn't it be possible to implement the functionality to update all
> packages that have newer versions in the global zone? That could
> perhaps be an additional flag to attach -u, maybe -a?
> I know packages could be of different version on purpose, but then
> this option should not be used, or implement an option to supply a
> list of packages to upgrade or leave alone.
I think that just updating the non-global zone for every pkg
that is installed in the global is probably not quite right since
you want to be able to have different software in different zones,
including the global zone.
It would be possible to leverage the solution we have today so that
the list of pkgs that must be in-sync was augmented by some sort of
user input. For example, as you suggested, one idea might be for you
to set up a file containing a list of additional pkgs that should be
in-sync. You could pass that to the attach command and those additional
pkgs would be synced up. That would be fairly simple to do but it would
require the user to figure out what pkgs to put in the list. You'd have
to look at some released version of Solaris and decide which pkgs
to add. This might be a bit of a maintenance issue since the set of
pkgs changes over time and over each update release.
If this seems like something people are interested in, I'd like to
hear more comments and we could refine a proposal. I'll then file
an RFE and work up an ARC proposal.
zones-discuss mailing list