On 12/20/11 01:07, Menno Lageman wrote:
For the LDoms Manager we currently ship a single version as the
'ldomsmanager' IPS package. This version supports all current hardware
from T2 to T4. We have a requirement to be able to ship multiple
versions of LDoms Manager in order to support future platforms which
will not run on the current version of LDoms Manager, while still
allowing customers with existing systems to run the current version of
LDoms Manager. This could be done by delivering multiple
ldomsmanager-<version> packages that deliver their files in versioned
paths and using mediated links to select the version to run. Since
ldomsmanager is in the default Solaris software payload, a fresh install
of Solaris should result in the most appropriate version of LDoms
Mananager being selected by default.
However, the current implementation of mediators does not offer us a way
to select the best version based on the hardware platform it is
installed on. E.g. for T2 systems version 2.1 should be selected, while
a future platform would require some version greater than 2.1. Setting
mediator-priority to higher values in later versions of the
ldomsmanager-<version> packages would not help since that would select a
version not supporting T2 systems if later versions were installed.
Would there be value in filing a RFE to extend the mediator mechanism to
allow more specific control or is there a better IPS mechanism to do
this?. (There are no platform-specific packages we could declare a
dependency on). The alternative would be to deliver a run-once service
ourselves (in a generic ldoms package) that would determine the most
appropriate version from those installed and run pkg set-mediator during
self-assembly to set that version as default.
The issue is this: we want the default install of the image to work on
all systems, not just the kind of system we originally created the
image. As a result, such install time specialization should not be
the default behavior, so use of mediated links, etc. seems the wrong
approach. Image portability is important to support live migration
between hosts of different types, so we need at least one bit of
run-time evaluation as to the best version of ldomsmanager to run.
Clearly, you'll need to deliver multiple packages w/ different names
if later versions of ldm drop support for earlier T series machines.
What causes the problem here is that you want newer versions of
ldomsmanager to drop support for earlier platforms; otherwise
the simple latest-is-best model would work. If this is a constraint, you
might consider using platform specific directories where each version of
ldoms manager could deliver links where that version was supported. This
has been made more difficult because the platform names of all the sun4v
machines is the same, but you can resolve that problem :). I would then
have /usr/sbin/ldm pick the latest version to run out of the right
platform directory. Alternatively, you could use a mediated link per
platform.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[email protected] http://blogs.sun.com/barts
"You will contribute more with Mercurial than with Thunderbird."
"Civilization advances by extending the number of important
operations which we can perform without thinking about them."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
