[
https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058133#comment-15058133
]
John Ross commented on ARIES-1383:
----------------------------------
Also http://svn.apache.org/viewvc?rev=1720173&view=rev and
http://svn.apache.org/viewvc?rev=1720174&view=rev. I forgot to do a Git
interactive rebase before svn dcommit.
> 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.6, subsystem-2.0.8
> 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: apache-aries-provision-dependencies. The
> possible values are "install" and "resolve", 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-Type header. A value of "resolve" indicates that dependencies
> should not be provisioned at installation time. Rather, this step will occur
> when the subsystem is resolved which typically happens as part of the start
> process.
> A subsystem with apache-aries-provision-dependencies:=resolve 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 apache-aries-provision-dependencies:=start:
> install() : <void> -> INSTALLING
> <void> -> INSTALLING -> INSTALL_FAILED -> UNINSTALLING
> -> UNINSTALLED (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 apache-aries-provision-dependencies value
> of the first scoped ancestor unless explicitly overridden. Unscoped
> subsystems always inherit the apache-aries-provision-dependencies value of
> the first scoped ancestor and may not override the value. The root subsystem
> always has a value of apache-aries-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 apache-aries-provision-dependencies directive
> with a value of "resolve" 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 apache-aries-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 apache-aries-provision-dependencies that conflicts
> with the scoped subsystem within the same region.
> TEST CASES
> ------------------
> (1) A set of subsystems with interleaving content dependencies are able to be
> independently, simultaneously, and successfully installed and started.
> (2) Subsystem with apache-aries-provision-dependencies:=resolve is in the
> INSTALLING state after a successful installation.
> (3) Subsystem with apache-aries-provision-dependencies:=resolve is available
> as a service after a successful installation.
> (4) Subsystem with apache-aries-provision-dependencies:=resolve does not have
> its dependencies installed after a successful installation.
> (5) Subsystem with apache-aries-provision-dependencies:=resolve undergoes the
> following state transitions when starting: INSTALLING -> INSTALLED ->
> RESOLVING -> RESOLVED -> STARTING -> ACTIVE.
> (6) Subsystem with apach-earies-provision-dependencies:=resolve has its
> dependencies installed after a successful start.
> (7) Subsystem with apache-aries-provision-dependencies:=resolve is in the
> INSTALL_FAILED state after an unsuccessful installation.
> (8) Subsystem with apache-aries-provision-dependencies:=resolve is not
> available as a service after an unsuccessful installation.
> (9) Subsystem with apache-aries-provision-dependencies:=resolve is in the
> INSTALLING state when dependencies cannot be provisioned after invoking the
> start method.
> (10) Subsystem fails installation if the apache-aries-provision-dependencies
> directive has a value other than "install" or "resolve".
> (11) Subsystem with apache-aries-provision-dependencies:=resolve undergoes
> the following state transitions when starting fails due to a runtime
> resolution failure: INSTALLING -> INSTALLED -> RESOLVING -> INSTALLED.
> (12) Subsystem with apache-aries-provision-dependencies:=resolve undergoes
> the following state transitions when starting fails due to a start failure:
> INSTALLING -> INSTALLED -> RESOLVING -> RESOLVED -> STARTING -> RESOLVED.
> (13) The root subsystem has apache-aries-provision-dependencies:=install.
> (14) Subsystem with explicit apache-aries-provision-dependencies:=install
> works as before.
> (15) Unscoped subsystem with a value of apache-aries-provision-dependencies
> that is different than the scoped parent fails installation.
> (16) Unscoped subsystem with a value of apache-aries-provision-dependencies
> that is the same as the scoped parent installs successfully.
> (17) Scoped subsystem with a value of apache-aries-provision-dependencies
> that is the same as the scoped parent behaves accordingly.
> (18) Scoped subsystem with a value of apache-aries-provision-dependencies
> that overrides the scoped parent behaves accordingly.
> (19) Scoped subsystem with only features as parents is able to override the
> value of apache-aries-provision-dependencies.
> (20) Install a scoped subsystem, S1, with
> apache-aries-provision-dependencies:=resolve. Install two features, F1 and
> F2, independently as children of S1. F1 has bundle B1 as content. F2 has
> bundle B2 as content. B2 has B1 as a dependency. B1 should be a constituent
> of F1 but not of the root subsystem.
> (21) Install a scoped subsystem, S1, with
> apache-aries-provision-dependencies:=resolve. Install two features, F1 and
> F2, independently as children of S1. F1 has bundle B1 and B2 as content. F2
> has bundle B2 and B3 as content. B2 is shared content. B1 has a dependency on
> bundle B4, B2 has a dependency on bundle B5. B3 has a dependency on bundle
> B6. Start F1. Dependency bundles B4 and B5 should be provisioned but not B6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
