[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15132841#comment-15132841 ] ASF subversion and git services commented on ARIES-1383: Commit 1728542 from [~jwr...@us.ibm.com] in branch 'aries/trunk' [ https://svn.apache.org/r1728542 ] [ARIES-1383] Provide option to disable the provisioning of dependencies at install time. Use the correct state when flagging an uninstall for re-entry protection. > 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 > Attachments: TEST-org.osgi.test.cases.subsystem-6.0.0.html > > > 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: apache-aries-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 apache-aries-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 apache-aries-provision-dependencies:=start: > install() : -> INSTALLING > -> 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 apache-aries-provision-dependencies value > of the first scoped ancestor unless explicitly overridden. Unscoped > subsystems always inherit the apache-aries-provision-dependencies value of > the first scoped ancestor and may not override
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15126964#comment-15126964 ] ASF subversion and git services commented on ARIES-1383: Commit 1727999 from [~jwr...@us.ibm.com] in branch 'aries/trunk' [ https://svn.apache.org/r1727999 ] [ARIES-1383] Provide option to disable the provisioning of dependencies at install time. Fix CT failures. All three were related to not honoring the specified start order of content resources. The implemented start order rules are as follows. (1) Dependencies are started first (-1). (2) Followed by content with no specified start order (0). (3) Followed by content whose start order was specified (>= 1). > 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 > Attachments: TEST-org.osgi.test.cases.subsystem-6.0.0.html > > > 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: apache-aries-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 apache-aries-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 apache-aries-provision-dependencies:=start: > install() : -> INSTALLING > -> 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
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122159#comment-15122159 ] John Ross commented on ARIES-1383: -- This is basically complete but I'll leave this open for just a bit longer for any tidying up tasks. Also, I still need to run the compliance tests. > 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: apache-aries-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 apache-aries-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 apache-aries-provision-dependencies:=start: > install() : -> INSTALLING > -> 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 apache-aries-provision-dependencies value > of the first scoped ancestor unless explicitly overridden. Unscoped > subsystems always inherit the apache-aries-provision-dependencies value of > the first scoped ancestor and may not override the value. The root subsystem > always has a value of apache-aries-provision-dependencies:=install. > ALTERNATIVE SOLUTIONS > - > (1) Make the local repositories of installing subsystems available to
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15122154#comment-15122154 ] ASF subversion and git services commented on ARIES-1383: Commit 1727424 from [~jwr...@us.ibm.com] in branch 'aries/trunk' [ https://svn.apache.org/r1727424 ] [ARIES-1383] Provide option to disable the provisioning of dependencies at install time. As part of the implemented locking strategy, three locks are used. The Global Read/Write Lock (GRWL) is used to ensure thread safety among all operations: install, install dependencies, resolve, start, stop, and uninstall. The write lock is acquired for install, install dependencies, and uninstall. The read lock is acquired for resolve, start, and stop. The Global Mutual Exlusion Lock (GMEL) is used to prevent cycle deadlocks when acquiring the state change locks of individual subsystems. Every subsystem has a Local State Change Lock (LSCL). These locks are used to prevent more than one state change operation at a time to occur for the same subsystem. A condition exists for the GMEL. The condition is used in order to notify waiting threads that the LSCL of at least one subsystem was released and that at least one thread may now be able to proceed. Threads that fail to acquire the LSCL of a subsystem while holding the GMEL will release all currently held locks and wait for the condition to apply. This is necessary because, when starting, the target subsystem must be locked before any other affected subsystems since the latter may only be computed after dependencies, which may include other subsystems, are installed. The consequences of this strategy is that installs and uninstalls are synchronous while resolutions, starts, and stops are asynchronous as long as the same subsystem is not affected. It may be possible to create an even more granular locking mechanism in the future if dictated by performance requirements. > 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: apache-aries-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 apache-aries-provision-dependencies:=resolve will remain in > the INSTALLING state until it is
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058123#comment-15058123 ] ASF subversion and git services commented on ARIES-1383: Commit 1720175 from [~jwr...@us.ibm.com] in branch 'aries/trunk' [ https://svn.apache.org/r1720175 ] [ARIES-1383] Provide option to disable the provisioning of dependencies at install time. Composites in the INSTALLING state and having apache-aries-provision-dependencies:=resolve must have their export sharing policies set in order for any offered capabilities to be considered valid as part of computing the dependencies of another subsystem having the same state and directive value. Currently, a brute force method is used whereby all composites fitting the above criteria will have their export policies temporarily enabled. Any that did not end up offering a capability used to resolve the other subsystem will have their policies rolled back. Plus test. > 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: apache-aries-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 apache-aries-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 apache-aries-provision-dependencies:=start: > install() : -> INSTALLING > -> 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
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058133#comment-15058133 ] John Ross commented on ARIES-1383: -- Also http://svn.apache.org/viewvc?rev=1720173=rev and http://svn.apache.org/viewvc?rev=1720174=rev. I forgot to do a Git interactive rebase before svn dcommit. > 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: apache-aries-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 apache-aries-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 apache-aries-provision-dependencies:=start: > install() : -> INSTALLING > -> 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 apache-aries-provision-dependencies value > of the first scoped ancestor unless explicitly overridden. Unscoped > subsystems always inherit the apache-aries-provision-dependencies value of > the first scoped ancestor and may not override the value. The root subsystem > always has a value of apache-aries-provision-dependencies:=install. > ALTERNATIVE SOLUTIONS > - > (1) Make the local repositories of installing subsystems
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15038262#comment-15038262 ] John Ross commented on ARIES-1383: -- Also created a 2.0.x subsystem branch just to be safe. http://svn.apache.org/viewvc?rev=1717825=rev > 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() : -> INSTALLING > -> 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
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15038258#comment-15038258 ] John Ross commented on ARIES-1383: -- http://svn.apache.org/viewvc?rev=1717826=rev > 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() : -> INSTALLING > -> 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
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15002464#comment-15002464 ] John Ross commented on ARIES-1383: -- I updated the description to reflect the Subsystem-Type rather than the Subsystem-SymbolicName header. I also updated it to reflect a change in one of the possible values for the new directive. The possible values are now "install" or "resolve". The value "resolve" is more accurate than "start" because dependencies must be provisioned before attempting a resolution. > 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 >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() : -> INSTALLING > -> 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 >
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14982516#comment-14982516 ] John Ross commented on ARIES-1383: -- To be consistent with the provision-policy directive, the apachearies-provision-dependencies directive will now be applied to the Subsystem-Type header rather than the Subsystem-SymbolicName header. > 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() : -> INSTALLING > -> 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
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14725262#comment-14725262 ] John Ross commented on ARIES-1383: -- I added the simplifying assumption discussed in (2) under POTENTIAL ISSUES to the PROPOSED SOLUTION in the description. > 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() : -> INSTALLING > -> 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
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14725326#comment-14725326 ] John Ross commented on ARIES-1383: -- Started the TEST CASE section in the description. > 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() : -> INSTALLING > -> 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
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14725428#comment-14725428 ] John Ross commented on ARIES-1383: -- Minor edits to the TEST CASES section in the description. > 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() : -> INSTALLING > -> 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
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14704571#comment-14704571 ] John Ross commented on ARIES-1383: -- I updated the description as follows. (1) The custom directive is now called apachearies-provision-dependencies and has the possible values of install and start. (2) Added discussion of the multiple parents issue. A simplifying assumption will be that unscoped subsystems may not override the value of apachearies-provision-dependencies from the scoped parent within the same region and must fail installation if they do so. 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 (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 subsystems inherit the apachearies-provision-dependencies value of the first scoped ancestor unless explicitly overridden. 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
[jira] [Commented] (ARIES-1383) Provide option to disable the provisioning of dependencies at install time.
[ https://issues.apache.org/jira/browse/ARIES-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14704705#comment-14704705 ] John Ross commented on ARIES-1383: -- Note that an additional issue with alternative solution (1) using local repositories is timing. Deployers would have no way of ensuring that an installing subsystem with content dependencies satisfied by content capabilities of another installing subsystem does not fail until the other subsystem comes on line. 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 (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 subsystems inherit the apachearies-provision-dependencies value of the first scoped ancestor unless explicitly overridden. 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
