Tony Nguyen writes:
> I'm proposing the addition of an upgrade method for each service to be a
> possible solution for various types of upgrade issues. Currently,
> updated services perform their customizations through adding commands
> into the /var/svc/profile/upgrade file which are executed after
> manifest-import completed.
Getting rid of the upgrade file is one of my long-standing goals. That's
why it remains a private interface -- so that we can delete it once
we've migrated current consumers over to a better interface.
Why's it a bad interface? Because it's a dumping ground for shell
commands. Only by virtue of the fact that it's a private interface
have we kept it to be an SMF-only mechanism. I've fielded more than
one request to put non-SMF shell commands in it. :( It's also
opaque today -- it's very difficult to tell that a command in the
upgrade script is why a property has been modified.
My niggling concern is that an upgrade method is just moving all of the
problems of the upgrade file to a new, public location. You've still
got a dumping ground for shell commands which do opaque things to the
system. But, on the other hand, at least they're attached to a
specific service.
That said, I'm not convinced I have a better solution to the whole of
the problem. I might have a better solution to 90% of the problem, but...
I think the upgrade method, combined with an early-boot manifest import
plus enhanced profiles takes care of all the use cases.
Thus, I'll try to articulate what I think are all the install/upgrade/
removal use cases around SMF. It doesn't describe things as they
are today, but describes the use cases people have either encoded in
their services over time or told us about explicitly. It also is
deliberately vague about SMF implementation detail -- we need to
understand the *requirements*, not just proposed solutions. Note that
these are categorized, rather than broken down into individual developer
"stories". I appreciate additions of other categories I overlooked,
or questions where the wording is vague.
I just heard from David that he's planning to address this similarly in
the Enhanced Profiles design document which will be forthcoming. So,
we'll use this as input to that document.
Types of install, upgrade, and removal:
- full OS image install/upgrade to a non-running root
* Reboot is required before changes are active.
* Running version of Solaris may be 2 releases less than version
being installed. (e.g. running Solaris 10, upgrading to S12)
- pkgadd -R to a non-running root
* Reboot is required before changes are active.
* Running version of Solaris may be either earlier or later than
version to which the pkgadd is being targetted.
- pkgadd/patchadd on a running system
* Reboot may not be required before changes are active. (In most
cases, a reboot is not acceptable.)
* Running version of Solaris is identical to the target version.
- pkgrm -R to a non-running root
* Reboot required before changes are active.
* Running version of Solaris may be either earlier or later than
version to which the pkgadd is being targetted.
- pkgrm to a running system
* Reboot may not be required before changes are active. (In most
cases, a reboot is not acceptable.)
* Running version of Solaris is identical to the target version.
Install use cases:
- Service is added to alternate root & appropriate profiles. Service
is imported during next boot. After the next boot, if declared
enabled either in the manifest or in a currently applied profile,
service should be enabled and started once its dependencies are
satisfied.
- Service is added to running system & appropriate profiles. If
declared enabled either in the manifest or in a currently applied
profile, service should be enabled and started once its dependencies
are satisfied.
- Service is added to running system & appropriate profiles.
If declared enabled in manifest or applied profile, developer
wants to *delay* service start until a system reboot has occurred.
Delete use cases:
- Service is removed from alternate root & appropriate profiles.
Either before or during next boot, service is deleted completely
before it has a chance to start. User customizations on the service
are removed.
- Service is removed from running system & appropriate profiles.
Service is deleted immediately, and any dependents not tolerant
to failure are stopped. User customizations on the service
are removed.
Upgrade use cases:
- pkgrm/pkgadd combination for packages that don't support upgrade
in-place. Users' customizations on the service should be
preserved.
- Default configuration upgrade. All properties delivered in the
old copy of the manifest are replaced by those in the new manifest.
Thus, if properties were deleted between the versions, they
should not appear in the new version. User customizations on
the service are preserved.
Changes should apply immediately if updated on a live system.
Changes should be applied before the service is started if updated
on an alternate root.
- Profiled configuration upgrade. Profiled configuration is
configuration dependent on a specific set of system capabilities
(e.g. platform), security policy, networking environment, etc.
In other words, static configuration that can be dynamically
applied.
The modifications that the upgraded service made on any profile
previously (regardless of whether the profile is currently active)
are replaced with the new configuration. User customization is
preserved.
Changes should apply immediately if updated on a live system.
Changes should be applied before the service is started if updated
on an alternate root.
- Dynamic configuration customization. Based on system state
(such as contents of files, output from other administrative
commands, or SMF repository content), a service developer may need
to make conditional changes to their service's configuration.
User customizations may be explicitly overridden or migrated
to a new format in this use case.
Changes should be evaluated immediately and apply immediately if
updated on a live system.
Changes should be evaluated and applied before the service is
started if updated on an alternate root. The choice between
evaluating on the alternate root, or waiting until next boot
to evaluate the changes that must be made either constrains
or frees the developer. If changes are evaluated immediately,
service developers would be restricted to using interfaces with
guarantees of forward compatibility. If changes are evaluated
once the new version is live, all interfaces are available to
the service developer.
User (non-developer) upgrade use cases:
- Determine differences between pre-upgrade configuration and
current configuration. (i.e. tell me what you did.)
- Determine if any of my explicit customizations was overridden.
(There are many many more user cases, but these are the only
ones that are upgrade-specific. Help me exercise restraint
against exploding use cases here, and articulate only cases which
are specific to the upgrade scenario...)
Phew. Those are a lot of cases to consider. Clearly the end-goal of
improvement in this area is to simplify things for the developer, not
to reveal each individual use case as a different mechanism. I think
that goes without saying, but I wanted to be clear I wasn't advocating
increasing complexity haphazardly. :)
As I mentioned, comments are appreciated on the formulation of "the
upgrade problem" above.
thanks,
liane
--
Liane Praza, Solaris Kernel Development
liane.praza at sun.com - http://blogs.sun.com/lianep
