[
https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Ross updated ARIES-1383:
-----------------------------
Description:
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.
was:
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
start() : INSTALLING -> INSTALLED -> STARTING -> ACTIVE
INSTALLING -> INSTALLING (if resolution or installation of
dependencies fails)
INSTALLING -> INSTALLED -> STARTING -> INSTALLED (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.
> 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
>
> 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)
