[
https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Ross reassigned ARIES-1383:
--------------------------------
Assignee: John Ross
> Provide option to disable the provisioning of dependencies at install time.
> ---------------------------------------------------------------------------
>
> Key: ARIES-1383
> URL: https://issues.apache.org/jira/browse/ARIES-1383
> Project: Aries
> Issue Type: Improvement
> Components: Subsystem
> Affects Versions: subsystem-2.0.2
> Reporter: John Ross
> Assignee: John Ross
>
> PROBLEM
> -------------
> The Subsystems specification states that all dependencies of a subsystem must
> have been installed in order to attain the INSTALLED state. If required
> dependencies are not found, the installation must fail.
> This functionality was described in order to achieve fail-fast functionality.
> If an environment cannot support the dependencies of a subsystem, it is
> rejected right away.
> However, there are deployment situations where it is valuable to delay the
> installation of dependencies. For example, you may wish to independently and
> simultaneously install a suite of subsystems whose contents have interleaving
> dependencies. This is currently not possible because the local repository of
> one subsystem is not available to others. The resources will not be available
> to others until they become part of the System Repository (assuming a
> compatible sharing policy) once the INSTALLED state is acquired. In the
> meantime, the other subsystems fail installation.
> There are three potential workarounds to this issue, none of which may be
> acceptable to a particular Subsystems consumer.
> (1) Provide all content as part of a remote repository. Note that this would
> require the Subsystem-Content header to be computed by the subsystem provider
> and not by the implementation.
> (2) Package all subsystems into a single ESA and make use of parent-child
> relationships.
> (3) Manage the install order manually. Note that this would not handle the
> case of circular dependencies.
> A solution that will allow for the independent and simultaneous installation
> of multiple subsystems with interleaving content dependencies, thus giving a
> deployer more flexibility, is desirable.
> PROPOSED SOLUTION
> -----------------------------
> A custom directive is introduced: apachearies-install-dependencies. The data
> type is boolean. The default value is "true" which results in the current
> behavior. This directive may be specified as part of the
> Subsystem-SymbolicName header. A value of "false" indicates that dependencies
> should not be resolved and installed at subsystem installation time. Rather,
> this step will occur when the subsystem is started.
> A subsystem with apachearies-install-dependencies:=false will remain in the
> INSTALLING state until it is started. This is an indication to administration
> programs monitoring subsystems via the service registry that the subsystem
> has not yet had its dependencies installed. When the subsystem is started,
> the transition from INSTALLING to INSTALLED will then occur as it does today.
> Assuming the resolution and installation of dependencies succeeds, the
> subsystem will then immediately transition into the STARTING state as normal.
> State transitions when apachearies-install-dependencies:=false:
> install() : <void> -> INSTALLING
> <void> -> INSTALLING -> INSTALL_FAILED (if
> installation fails for some reason other than dependency provisioning)
> start() : INSTALLING -> INSTALLED -> RESOLVING -> RESOLVED -> STARTING
> -> ACTIVE
> INSTALLING -> INSTALLING (if installation of dependencies
> fails)
> INSTALLING -> INSTALLED -> RESOLVING -> INSTALLED (if
> runtime resolution fails)
>
> INSTALLING -> INSTALLED -> RESOLVING -> RESOLVED ->
> STARTING -> RESOLVED (if starting fails)
> Child subsystems inherit the scoped parent's value of
> apachearies-install-dependencies unless explicitly overridden. The root
> subsystem always has a value of apachearies-install-dependencies:=true.
> ALTERNATIVE SOLUTIONS
> ---------------------------------
> (1) Make the local repositories of installing subsystems available to other
> installing subsystems. The specification does not allow local repositories to
> be registered as a Repository service, although it does not explicitly
> address the possibility of a particular implementation sharing them
> internally. Nevertheless, the intent of the spec seems clear in that it
> should not be assumed that a subsystem provider desires their content to be
> shared with others.
> POTENTIAL ISSUES
> -------------------------
> (1) The proposed solution will break the contract of the install methods
> specified on the Subsystem and AriesSubsystem interfaces, which require that
> either the returned subsystem is in the INSTALLED state or that the
> installation fails with an exception. However, it is assumed that the
> explicit declaration of the apachearies-install-dependencies directive with a
> value of "false" grants the implementation permission to do so. An
> alternative would be to return the Subsystem in the INSTALLED state even
> though none of the dependencies had been installed. However, this would also
> violate the specification and may confuse third party applications monitoring
> subsystem services via the registry.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
