aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Ross (JIRA)" <>
Subject [jira] [Assigned] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
Date Wed, 19 Aug 2015 17:20:45 GMT


John Ross reassigned ARIES-1383:

    Assignee: John Ross

> Provide option to disable the provisioning of dependencies at install time.
> ---------------------------------------------------------------------------
>                 Key: ARIES-1383
>                 URL:
>             Project: Aries
>          Issue Type: Improvement
>          Components: Subsystem
>    Affects Versions: subsystem-2.0.2
>            Reporter: John Ross
>            Assignee: John Ross
> -------------
> 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
> 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.
> -----------------------------
> 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)
> 		     INSTALLING -> INSTALLING (if installation of dependencies fails)
>                      INSTALLING -> INSTALLED -> RESOLVING -> INSTALLED (if runtime
resolution fails)
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.
> ---------------------------------
> (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.
> -------------------------
> (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

View raw message