[ 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-provision-dependencies. The possible values
are "install" and "start", 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-SymbolicName header. A value of "start" indicates
that dependencies should not be provisioned at installation time. Rather, this step will occur
when the subsystem is started.
A subsystem with apachearies-provision-dependencies:=start 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 "start" 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:=start is in the INSTALLING state after
a successful installation.
(3) Subsystem with apachearies-provision-dependencies:=start is available as a service after
a successful installation.
(4) Subsystem with apachearies-provision-dependencies:=start does not have its dependencies
installed after a successful installation.
(5) Subsystem with apachearies-provision-dependencies:=start undergoes the following state
transitions when starting: INSTALLING -> INSTALLED -> RESOLVING -> RESOLVED ->
STARTING -> ACTIVE.
(6) Subsystem with apachearies-provision-dependencies:=start has its dependencies installed
after a successful start.
(7) Subsystem with apachearies-provision-dependencies:=start is in the INSTALL_FAILED state
after an unsuccessful installation.
(8) Subsystem with apachearies-provision-dependencies:=start is not available as a service
after an unsuccessful installation.
(9) Subsystem with apachearies-provision-dependencies:=start 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 "start".
(11) Subsystem with apachearies-provision-dependencies:=start undergoes the following state
transitions when starting fails due to a runtime resolution failure: INSTALLING -> INSTALLED
-> RESOLVING -> INSTALLED.
(12) Subsystem with apachearies-provision-dependencies:=start 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:=start. 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:=start. 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.
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-provision-dependencies. The possible values
are "install" and "start", 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-SymbolicName header. A value of "start" indicates
that dependencies should not be provisioned at installation time. Rather, this step will occur
when the subsystem is started.
A subsystem with apachearies-provision-dependencies:=start 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 (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 "start" 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:=start is in the INSTALLING state after
a successful installation.
(3) Subsystem with apachearies-provision-dependencies:=start is available as a service after
a successful installation.
(4) Subsystem with apachearies-provision-dependencies:=start does not have its dependencies
installed after a successful installation.
(5) Subsystem with apachearies-provision-dependencies:=start undergoes the following state
transitions when starting: INSTALLING -> INSTALLED -> RESOLVING -> RESOLVED ->
STARTING -> ACTIVE.
(6) Subsystem with apachearies-provision-dependencies:=start has its dependencies installed
after a successful start.
(7) Subsystem with apachearies-provision-dependencies:=start is in the INSTALL_FAILED state
after an unsuccessful installation.
(8) Subsystem with apachearies-provision-dependencies:=start is not available as a service
after an unsuccessful installation.
(9) Subsystem with apachearies-provision-dependencies:=start 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 "start".
(11) Subsystem with apachearies-provision-dependencies:=start undergoes the following state
transitions when starting fails due to a runtime resolution failure: INSTALLING -> INSTALLED
-> RESOLVING -> INSTALLED.
(12) Subsystem with apachearies-provision-dependencies:=start 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:=start. 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:=start. 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.
> 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
> 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 "start", 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-SymbolicName header. A value of "start" indicates
that dependencies should not be provisioned at installation time. Rather, this step will occur
when the subsystem is started.
> A subsystem with apachearies-provision-dependencies:=start 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 "start" 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:=start is in the INSTALLING state
after a successful installation.
> (3) Subsystem with apachearies-provision-dependencies:=start is available as a service
after a successful installation.
> (4) Subsystem with apachearies-provision-dependencies:=start does not have its dependencies
installed after a successful installation.
> (5) Subsystem with apachearies-provision-dependencies:=start undergoes the following
state transitions when starting: INSTALLING -> INSTALLED -> RESOLVING -> RESOLVED
-> STARTING -> ACTIVE.
> (6) Subsystem with apachearies-provision-dependencies:=start has its dependencies installed
after a successful start.
> (7) Subsystem with apachearies-provision-dependencies:=start is in the INSTALL_FAILED
state after an unsuccessful installation.
> (8) Subsystem with apachearies-provision-dependencies:=start is not available as a service
after an unsuccessful installation.
> (9) Subsystem with apachearies-provision-dependencies:=start 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 "start".
> (11) Subsystem with apachearies-provision-dependencies:=start undergoes the following
state transitions when starting fails due to a runtime resolution failure: INSTALLING ->
INSTALLED -> RESOLVING -> INSTALLED.
> (12) Subsystem with apachearies-provision-dependencies:=start 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:=start.
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:=start.
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)