Hi all,
The following proposal summarizes the current import scheme, the
problems we have encountered and complaints we have heard so far and
proposed solutions to address them. Please take a close look at and
send your feedback/opinion to the alias. Your participation is
very important to the project and is greatly appreciated.
TIA
Steve
Summary
-------------
The purpose of this write-up is to give people enough background to
understand
the existing manifest import scheme, the problems and complaints with
the current
scheme, the proposed solutions and concerns.
Existing scheme
---------------------
With the current scheme, new services are delivered by placing a set of
manifest
files under /var/svc/manifest and by using the manifest class in the
package.
Service upgrades are delivered by replacing the manifest files under
/var/svc/manifest with new content.
Current framework requires a minimum set ('seed') of services to be
available to
get the system to the point where it can import manifests stored under
/var/svc/manifest. Essentially, the / and /usr filesystems must be mounted
writable so we can utilize tools under /usr and write to the persistent
/etc/svc/repository.db repository. /var filesystem needs to be mounted
to be
able to import non-seeded manifests.
These essentially put some restrictions on the current import scheme:
- Require rw / to do import.
- All manifests and profiles are in /var which gets mounted fairly late.
- Current use of contracted private /var/svc/profile/upgrade may rely on all
filesystems in filesystem/minimal to be available.
Problems/Complaints
-----------------------------
Since manifest import runs at relatively late in boot process, this can
cause
some problems for services that run early in the boot process and do not or
can not have dependency on the manifest-import service. A number of common
problems and complaints follows.
- Individual services which do not depend on manifest-import risk having
changes
during upgrade made after the service has started.
- Changes to early-boot services are challenging. Deleting an early
boot service
requires integrating a method which does nothing until manifest-import
can get
around to actually removing the service. Upgrades required before the
services
can start require significant manual intervention.
- Workaround is required to enable and run services which do not have
dependency on
manifest-import. Datalink management is a good example where a
workaround needs
to be in place to enable network/datalink-management service early in
the boot
process since manifest-import runs pretty late in the boot.
Proposed Solution
------------------------
As you all can figure out now, the two major problems that prevent the
manifest-import
service from running at early boot process are writable root filesystem
and mount of
/var filesystem.
The recent putback of the RFE (6351623) work lays the groundwork to
address the root
filesystem concern. It provides the framework the ability to import
services into an
alternate filesystem location including one located on /etc/svc/volatile
tmpfs.
The final phase of the project will be focusing on the /var issue and
make manifest-import
actually happen before any services are started during boot. Currently
I am proposing:
- Default manifest location moves from /var/svc/manifest to
/etc/svc/manifest. Explicitly
handle move of existing manifests during upgrade. Sun-delivered
manifests explicitly
delivered to /etc/svc/manifest.
- Profile location moves from /var/svc/profile to /etc/svc/profile.
Explicitly handle
the move of existing profile files during upgrade.
- I am proposing a two-step import service model. The first import
service handles tasks
which are suitable for early boot process such as importing services
from /etc/svc/manifest
and applying profiles from /etc/svc/profile. The second step import
service will handle
tasks which may not feasible for early boot process such as
application of the
/var/svc/profile/upgrade profile which may rely on other writable
filesystems or availability
of other services. Also the manifests delivered into the current
/var/svc/manifest location
by 3rd parties can still be handled by the second import service.
Boot order today looks like this:
- Kernel mounts / read-only, /usr read-only, mounts /etc/svc/volatile
writable
- Init -> svc.startd -> svc.configd
- svc.startd starts,
- filesystem/root: fsck /, mount /usr r/o
- filesystem/usr: mount / and /usr r/w
- filesystem/minimal: mount /var and other filesystems
- manifest-import: import all services
The new proposed boot order will look like this:
- Kernel mounts root read-only, /usr read-only, mounts
/etc/svc/volatile writable
- Init -> svc.startd -> svc.configd
- The first step import service imports manifests and profiles in
/etc/svc/manifest and
/etc/svc/profile to the volatile repository (under
/etc/svc/volatile) before starting any
services.
- svc.startd reads the graph and starts all services.
- Eventually / gets mounted r/w and /var is mounted.
- The second step of import service commits changes made to the
volatile repository to the
persistent repository and also makes compatibility link for each
manifest under /etc.
Scan and import any service delivered in /var.
Concerns and proposed solution
------------------------------------------
We can have Sun-delivered manifests delivered into /etc/svc/manifest but
for the backward
compatibility concern, we may need to create links from /var to /etc and
yet we still
need to take into account the fact that 3rd parties can deliver
manifests into /var.
In this case, link from /var/svc/manifest to /etc/svc/manifest may not
work. To address
this concern, I am proposing that we deliver /var/svc/manifest tree as
it is now which
allows 3rd parties to deliver their manifests into /var and have the 2nd
step of import
create link for each manifest under /etc to address the backward
compatibility concern.
