[
https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15038091#comment-15038091
]
John Ross commented on ARIES-1383:
----------------------------------
NOTABLE DESIGN DECISIONS
(At least some of these may be mere simplifications and do not represent how
things must be.)
(1) The new directive will be applied to the Subsystem-Type header.
(2) The new directive syntax is: 'apache-aries-provision-dependencies' ':=' (
'install' | 'resolve' )
(3) Features MAY NOT override the apache-aries-provision-dependencies value of
a parent subsystem.
(4) Implicitly installed scoped subsystems MAY NOT override the
apache-aries-provision-dependencies value of a parent subsystem.
(5) A subsystem MAY NOT be explicitly installed into a parent subsystem that is
in the INSTALLING state.
NOTABLE NOTES
(1) Installing an application as the child of an already existing application
will not update the parent sharing policy. This would be a problem, for
example, if a dependency of the child needed to be provisioned to root.
However, the sharing policy chain will be configured appropriately when
installing everything as part of a single archive. This is by design.
The new apache-aries-provision-dependencies directive introduces a wrinkle.
It's possible to have a whole chain of subsystems in the INSTALLING state then
start the top level parent. The sharing policy chain must be configured
appropriately independently of how they were installed.
Therefore, explicitly installing a child into a parent in the INSTALLING state
is not allowed. Note this does not apply when installing an archive containing
child subsystems as content.
(2) A target region is associated with a "controlling scoped subsystem". This
is the subsystem without which the region would not exist. Recall that the
subsystem graph is a directed acyclic graph with one, and only one, source
vertex, namely the root subsystem. A target region, therefore, consists of all
successors of the controlling scoped subsystem having no intervening scoped
predecessor.
NOTABLE FIXES
(1) State transitions associated with INSTALL_FAILED will now occur according
to the specification.
(2) Only one instance of the same application will appear when installing into
two features within the same region.
(3) Scoped children are now included as part of the target region.
NOTABLE IMPROVEMENTS
(1) When locating a region to use for capability validation purposes, the
search now stops at the first scoped ancestor whose sharing policy has already
been set rather than blindly using the immediate parent. This covers the case
of multiple subsystems from the same archive being installed. The sharing
policy is "set" upon entering the INSTALLED state.
(2) When installing multiple subsystems as part of the same archive, the local
repository should reflect the capabilities of any child subsystems so that the
parent
resolution will succeed in order to create the correct sharing policy. This is
necessary for the case where dependencies were packaged as part of the archive
of a child
subsystem.
(3) Subsystem-Content header will now have closed version ranges when computed.
This was necessary because of the change that allows all local repositories to
be visible for implicit installations. Recall that an implicit installation is
a subsystem that was included in the archive of another.
NOTABLE OUTSTANDING ISSUES
(1) Potential performance issue with bottlneck when starting subsystems.
Starting subsystems is now synchronous in order to allow for circular
dependencies. This is admittedly a sledgehammer. A more granular approach is
needed.
(2) The archived contents of subsystems with
apache-aries-provision-dependencies:=resolve must be retained at least until
all dependencies are provisioned. Strictly speaking, only the dependencies need
to be retained. This is necessary, for example, in the case of a restart.
Therefore, temporary files created for
apache-aries-provision-dependencies:=resolve are currently not automatically
deleted. They continue to be be removed for standard subsystems.
> 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: apachearies-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 apachearies-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 apachearies-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 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 "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 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.
> 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 apachearies-provision-dependencies:=resolve is in the
> INSTALLING state after a successful installation.
> (3) Subsystem with apachearies-provision-dependencies:=resolve is available
> as a service after a successful installation.
> (4) Subsystem with apachearies-provision-dependencies:=resolve does not have
> its dependencies installed after a successful installation.
> (5) Subsystem with apachearies-provision-dependencies:=resolve undergoes the
> following state transitions when starting: INSTALLING -> INSTALLED ->
> RESOLVING -> RESOLVED -> STARTING -> ACTIVE.
> (6) Subsystem with apachearies-provision-dependencies:=resolve has its
> dependencies installed after a successful start.
> (7) Subsystem with apachearies-provision-dependencies:=resolve is in the
> INSTALL_FAILED state after an unsuccessful installation.
> (8) Subsystem with apachearies-provision-dependencies:=resolve is not
> available as a service after an unsuccessful installation.
> (9) Subsystem with apachearies-provision-dependencies:=resolve is in the
> INSTALLING state when dependencies cannot be provisioned after invoking the
> start method.
> (10) Subsystem fails installation if the apachearies-provision-dependencies
> directive has a value other than "install" or "resolve".
> (11) Subsystem with apachearies-provision-dependencies:=resolve undergoes the
> following state transitions when starting fails due to a runtime resolution
> failure: INSTALLING -> INSTALLED -> RESOLVING -> INSTALLED.
> (12) Subsystem with apachearies-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 apachearies-provision-dependencies:=install.
> (14) Subsystem with explicit apachearies-provision-dependencies:=install
> works as before.
> (15) Unscoped subsystem with a value of apachearies-provision-dependencies
> that is different than the scoped parent fails installation.
> (16) Unscoped subsystem with a value of apachearies-provision-dependencies
> that is the same as the scoped parent installs successfully.
> (17) Scoped subsystem with a value of apachearies-provision-dependencies that
> is the same as the scoped parent behaves accordingly.
> (18) Scoped subsystem with a value of apachearies-provision-dependencies that
> overrides the scoped parent behaves accordingly.
> (19) Scoped subsystem with only features as parents is able to override the
> value of apachearies-provision-dependencies.
> (20) Install a scoped subsystem, S1, with
> apachearies-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
> apachearies-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)
