[
https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14725262#comment-14725262
]
John Ross commented on ARIES-1383:
----------------------------------
I added the simplifying assumption discussed in (2) under POTENTIAL ISSUES to
the PROPOSED SOLUTION in the description.
> 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-provision-dependencies. The
> possible values are "install" and "start", which indicate the time at which
> dependency provisioning should occur. The default value is "install" which
> results in the current behavior. This directive may be specified as part of
> the Subsystem-SymbolicName header. A value of "start" indicates that
> dependencies should not be provisioned at installation time. Rather, this
> step will occur when the subsystem is started.
> A subsystem with apachearies-provision-dependencies:=start 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 provisioned. When the subsystem is started,
> the transition from INSTALLING to INSTALLED will then occur as it does today.
> Assuming the provisioning of dependencies succeeds, the subsystem will then
> immediately transition into the RESOLVING state and proceed as normal.
> State transitions when apachearies-provision-dependencies:=start:
> 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 provisioning of dependencies
> fails)
> INSTALLING -> INSTALLED -> RESOLVING -> INSTALLED (if
> runtime resolution fails)
>
> INSTALLING -> INSTALLED -> RESOLVING -> RESOLVED ->
> STARTING -> RESOLVED (if starting fails)
> Child scoped subsystems inherit the apachearies-provision-dependencies value
> of the first scoped ancestor unless explicitly overridden. Unscoped
> subsystems always inherit the apachearies-provision-dependencies value of the
> first scoped ancestor and may not override the value. The root subsystem
> always has a value of apachearies-provision-dependencies:=install.
> 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-provision-dependencies directive with
> a value of "start" 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 have been installed. However, this would also
> violate the specification and may confuse third party applications monitoring
> subsystem services via the registry.
> (2) A subsystem may have more than one parent but at most one scoped parent.
> This means that additional parents will always be features (or other unscoped
> subsystems). The question is how should apachearies-provision-dependencies
> inheritance work when there are multiple parents with conflicting values. A
> simplifying assumption would be that features may not override the value of
> the scoped parent. This implies that features should fail installation if
> they contain a value of apachearies-provision-dependencies that conflicts
> with the scoped subsystem within the same region.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
