John Ross created ARIES-1383:
--------------------------------

             Summary: 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

        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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to