v3.2.1 release notes mention new functionality of creating initially-disabled tenants. Is there documentation on how this configuration change gets applied, and if it strictly needs to be set during the initialization of a deployment? Thanks, - Jesse

With respect to the first part of your question, Jesse, it looks like there's now a 'createDisabled="true"' attribute that you can add to the <tenant:tenantBinding ...> tag, alongside its existing attributes like 'displayName and 'version', in the relevant tenant-bindings-delta.xml file: http://fisheye.collectionspace.org/browse/cspace-service/services/config/src/main/resources/tenant.xsd?r2=c4d658c50ac2bd39c1a0b8eb3beb3d6d910468f3&r1=11d95c48c25e94c080f080da00cc1528447ace1c > ... if it strictly needs to be set during the > initialization of a deployment? Patrick's commit comment describes this in a bit more detail; he may wish to comment further: http://fisheye.collectionspace.org/changelog/cspace-service?showid=c4d658c50ac2bd39c1a0b8eb3beb3d6d910468f3 "CSPACE-5771 Allow admins to mark a tenant to be createdDisabled. This minimizes resources devoted to the tenant, and it will remain disabled until this setting is altered and the system restarted (the webapp reloaded). Permissions are created, as this cannot currently be done incrementally." My naive reading of Patrick's comments are that this functionality: * Allows a tenant to be initialized in a disabled state. * Later on, allows that tenant to (only) be enabled, by changing the 'createDisabled' attribute's value to "false", in its delta tenant bindings file, and restarting Tomcat. and (this is solely inferred from the above, and may thus be inaccurate - I have not tried this): * You can introduce the new tenant's folder, including its delta tenant bindings file that initially marks the tenant's state as "disabled," at any time: even *after* you've previously initialized your deployment with other tenant(s), such as the demonstration tenants that ship with CollectionSpace, or other custom tenants. Aron P.S. In the v3.2.1 release notes, I've also corrected the link to the relevant issue that introduced this functionality: it's CSPACE-5771, not CSPACE-5571, as was erroneously listed there previously: http://wiki.collectionspace.org/display/collectionspace/Release+3.2.1#Release3.2.1-Creatinginitiallydisabledtenants%28CSPACE5771 On Tue, May 14, 2013 at 3:08 PM, Jesse Martinez <mjesse@gmail.com> wrote: > v3.2.1 release notes mention new functionality of creating > initially-disabled tenants. Is there documentation on how this configuration > change gets applied, and if it strictly needs to be set during the > initialization of a deployment? > > Thanks, > > - Jesse > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >

If you were asking, "Is it possible to disable a previously-enabled tenant?", that may be a slightly different question, possibly answered in this follow-on JIRA: http://issues.collectionspace.org/browse/CSPACE-5772 (See item 4 in the Description of that issue.) Aron On Tue, May 14, 2013 at 3:28 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote: > With respect to the first part of your question, Jesse, it looks like > there's now a 'createDisabled="true"' attribute that you can add to > the <tenant:tenantBinding ...> tag, alongside its existing attributes > like 'displayName and 'version', in the relevant > tenant-bindings-delta.xml file: > > http://fisheye.collectionspace.org/browse/cspace-service/services/config/src/main/resources/tenant.xsd?r2=c4d658c50ac2bd39c1a0b8eb3beb3d6d910468f3&r1=11d95c48c25e94c080f080da00cc1528447ace1c > >> ... if it strictly needs to be set during the >> initialization of a deployment? > > Patrick's commit comment describes this in a bit more detail; he may > wish to comment further: > > http://fisheye.collectionspace.org/changelog/cspace-service?showid=c4d658c50ac2bd39c1a0b8eb3beb3d6d910468f3 > > "CSPACE-5771 Allow admins to mark a tenant to be createdDisabled. This > minimizes resources devoted to the tenant, and it will remain disabled > until this setting is altered and the system restarted (the webapp > reloaded). Permissions are created, as this cannot currently be done > incrementally." > > My naive reading of Patrick's comments are that this functionality: > > * Allows a tenant to be initialized in a disabled state. > * Later on, allows that tenant to (only) be enabled, by changing the > 'createDisabled' attribute's value to "false", in its delta tenant > bindings file, and restarting Tomcat. > > and (this is solely inferred from the above, and may thus be > inaccurate - I have not tried this): > > * You can introduce the new tenant's folder, including its delta > tenant bindings file that initially marks the tenant's state as > "disabled," at any time: even *after* you've previously initialized > your deployment with other tenant(s), such as the demonstration > tenants that ship with CollectionSpace, or other custom tenants. > > Aron > > P.S. In the v3.2.1 release notes, I've also corrected the link to the > relevant issue that introduced this functionality: it's CSPACE-5771, > not CSPACE-5571, as was erroneously listed there previously: > > http://wiki.collectionspace.org/display/collectionspace/Release+3.2.1#Release3.2.1-Creatinginitiallydisabledtenants%28CSPACE5771 > > On Tue, May 14, 2013 at 3:08 PM, Jesse Martinez <mjesse@gmail.com> wrote: >> v3.2.1 release notes mention new functionality of creating >> initially-disabled tenants. Is there documentation on how this configuration >> change gets applied, and if it strictly needs to be set during the >> initialization of a deployment? >> >> Thanks, >> >> - Jesse >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>

Ugh. My apologies for an over-quick reading ... the issue below deals solely with dynamic configuration changes in the Services layer, akin to the ability to reinitialize the Application layer while Tomcat is still running, and only discusses whether one can enable - not disable - a tenant dynamically via that mechanism. I simply don't know whether you can disable a previously-enabled tenant; that'd likely be a question best addressed by Patrick and/or Richard. On Tue, May 14, 2013 at 3:32 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote: > If you were asking, "Is it possible to disable a previously-enabled > tenant?", that may be a slightly different question, possibly answered > in this follow-on JIRA: > > http://issues.collectionspace.org/browse/CSPACE-5772 > (See item 4 in the Description of that issue.) > > Aron > > On Tue, May 14, 2013 at 3:28 PM, Aron Roberts > <aron@socrates.berkeley.edu> wrote: >> With respect to the first part of your question, Jesse, it looks like >> there's now a 'createDisabled="true"' attribute that you can add to >> the <tenant:tenantBinding ...> tag, alongside its existing attributes >> like 'displayName and 'version', in the relevant >> tenant-bindings-delta.xml file: >> >> http://fisheye.collectionspace.org/browse/cspace-service/services/config/src/main/resources/tenant.xsd?r2=c4d658c50ac2bd39c1a0b8eb3beb3d6d910468f3&r1=11d95c48c25e94c080f080da00cc1528447ace1c >> >>> ... if it strictly needs to be set during the >>> initialization of a deployment? >> >> Patrick's commit comment describes this in a bit more detail; he may >> wish to comment further: >> >> http://fisheye.collectionspace.org/changelog/cspace-service?showid=c4d658c50ac2bd39c1a0b8eb3beb3d6d910468f3 >> >> "CSPACE-5771 Allow admins to mark a tenant to be createdDisabled. This >> minimizes resources devoted to the tenant, and it will remain disabled >> until this setting is altered and the system restarted (the webapp >> reloaded). Permissions are created, as this cannot currently be done >> incrementally." >> >> My naive reading of Patrick's comments are that this functionality: >> >> * Allows a tenant to be initialized in a disabled state. >> * Later on, allows that tenant to (only) be enabled, by changing the >> 'createDisabled' attribute's value to "false", in its delta tenant >> bindings file, and restarting Tomcat. >> >> and (this is solely inferred from the above, and may thus be >> inaccurate - I have not tried this): >> >> * You can introduce the new tenant's folder, including its delta >> tenant bindings file that initially marks the tenant's state as >> "disabled," at any time: even *after* you've previously initialized >> your deployment with other tenant(s), such as the demonstration >> tenants that ship with CollectionSpace, or other custom tenants. >> >> Aron >> >> P.S. In the v3.2.1 release notes, I've also corrected the link to the >> relevant issue that introduced this functionality: it's CSPACE-5771, >> not CSPACE-5571, as was erroneously listed there previously: >> >> http://wiki.collectionspace.org/display/collectionspace/Release+3.2.1#Release3.2.1-Creatinginitiallydisabledtenants%28CSPACE5771 >> >> On Tue, May 14, 2013 at 3:08 PM, Jesse Martinez <mjesse@gmail.com> wrote: >>> v3.2.1 release notes mention new functionality of creating >>> initially-disabled tenants. Is there documentation on how this configuration >>> change gets applied, and if it strictly needs to be set during the >>> initialization of a deployment? >>> >>> Thanks, >>> >>> - Jesse >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>

Thank you for this research, Aron. I'll experiment and report back with these configuration changes and see how it works when adding the flags pre-initialization and then post-initialization. - Jesse On Tue, May 14, 2013 at 6:35 PM, Aron Roberts <aron@socrates.berkeley.edu>wrote: > Ugh. My apologies for an over-quick reading ... the issue below deals > solely with dynamic configuration changes in the Services layer, akin > to the ability to reinitialize the Application layer while Tomcat is > still running, and only discusses whether one can enable - not disable > - a tenant dynamically via that mechanism. > > I simply don't know whether you can disable a previously-enabled > tenant; that'd likely be a question best addressed by Patrick and/or > Richard. > > On Tue, May 14, 2013 at 3:32 PM, Aron Roberts > <aron@socrates.berkeley.edu> wrote: > > If you were asking, "Is it possible to disable a previously-enabled > > tenant?", that may be a slightly different question, possibly answered > > in this follow-on JIRA: > > > > http://issues.collectionspace.org/browse/CSPACE-5772 > > (See item 4 in the Description of that issue.) > > > > Aron > > > > On Tue, May 14, 2013 at 3:28 PM, Aron Roberts > > <aron@socrates.berkeley.edu> wrote: > >> With respect to the first part of your question, Jesse, it looks like > >> there's now a 'createDisabled="true"' attribute that you can add to > >> the <tenant:tenantBinding ...> tag, alongside its existing attributes > >> like 'displayName and 'version', in the relevant > >> tenant-bindings-delta.xml file: > >> > >> > http://fisheye.collectionspace.org/browse/cspace-service/services/config/src/main/resources/tenant.xsd?r2=c4d658c50ac2bd39c1a0b8eb3beb3d6d910468f3&r1=11d95c48c25e94c080f080da00cc1528447ace1c > >> > >>> ... if it strictly needs to be set during the > >>> initialization of a deployment? > >> > >> Patrick's commit comment describes this in a bit more detail; he may > >> wish to comment further: > >> > >> > http://fisheye.collectionspace.org/changelog/cspace-service?showid=c4d658c50ac2bd39c1a0b8eb3beb3d6d910468f3 > >> > >> "CSPACE-5771 Allow admins to mark a tenant to be createdDisabled. This > >> minimizes resources devoted to the tenant, and it will remain disabled > >> until this setting is altered and the system restarted (the webapp > >> reloaded). Permissions are created, as this cannot currently be done > >> incrementally." > >> > >> My naive reading of Patrick's comments are that this functionality: > >> > >> * Allows a tenant to be initialized in a disabled state. > >> * Later on, allows that tenant to (only) be enabled, by changing the > >> 'createDisabled' attribute's value to "false", in its delta tenant > >> bindings file, and restarting Tomcat. > >> > >> and (this is solely inferred from the above, and may thus be > >> inaccurate - I have not tried this): > >> > >> * You can introduce the new tenant's folder, including its delta > >> tenant bindings file that initially marks the tenant's state as > >> "disabled," at any time: even *after* you've previously initialized > >> your deployment with other tenant(s), such as the demonstration > >> tenants that ship with CollectionSpace, or other custom tenants. > >> > >> Aron > >> > >> P.S. In the v3.2.1 release notes, I've also corrected the link to the > >> relevant issue that introduced this functionality: it's CSPACE-5771, > >> not CSPACE-5571, as was erroneously listed there previously: > >> > >> > http://wiki.collectionspace.org/display/collectionspace/Release+3.2.1#Release3.2.1-Creatinginitiallydisabledtenants%28CSPACE5771 > >> > >> On Tue, May 14, 2013 at 3:08 PM, Jesse Martinez <mjesse@gmail.com> > wrote: > >>> v3.2.1 release notes mention new functionality of creating > >>> initially-disabled tenants. Is there documentation on how this > configuration > >>> change gets applied, and if it strictly needs to be set during the > >>> initialization of a deployment? > >>> > >>> Thanks, > >>> > >>> - Jesse > >>> > >>> _______________________________________________ > >>> Talk mailing list > >>> Talk@lists.collectionspace.org > >>> > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >>> >

Jesse – I am also hunting for some more docs on the service that controls running tenants. One note: changing the createDisabled flag to true, after a system has been running, will not have an effect. It is only considered on create. Patrick *From:* Talk [mailto:talk-bounces@lists.collectionspace.org] *On Behalf Of *Jesse Martinez *Sent:* Wednesday, May 15, 2013 9:01 AM *To:* Aron Roberts *Cc:* CollectionSpace Talk List *Subject:* Re: [Talk] how to deactivate unused tenants Thank you for this research, Aron. I'll experiment and report back with these configuration changes and see how it works when adding the flags pre-initialization and then post-initialization. - Jesse On Tue, May 14, 2013 at 6:35 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote: Ugh. My apologies for an over-quick reading ... the issue below deals solely with dynamic configuration changes in the Services layer, akin to the ability to reinitialize the Application layer while Tomcat is still running, and only discusses whether one can enable - not disable - a tenant dynamically via that mechanism. I simply don't know whether you can disable a previously-enabled tenant; that'd likely be a question best addressed by Patrick and/or Richard. On Tue, May 14, 2013 at 3:32 PM, Aron Roberts <aron@socrates.berkeley.edu> wrote: > If you were asking, "Is it possible to disable a previously-enabled > tenant?", that may be a slightly different question, possibly answered > in this follow-on JIRA: > > http://issues.collectionspace.org/browse/CSPACE-5772 > (See item 4 in the Description of that issue.) > > Aron > > On Tue, May 14, 2013 at 3:28 PM, Aron Roberts > <aron@socrates.berkeley.edu> wrote: >> With respect to the first part of your question, Jesse, it looks like >> there's now a 'createDisabled="true"' attribute that you can add to >> the <tenant:tenantBinding ...> tag, alongside its existing attributes >> like 'displayName and 'version', in the relevant >> tenant-bindings-delta.xml file: >> >> http://fisheye.collectionspace.org/browse/cspace-service/services/config/src/main/resources/tenant.xsd?r2=c4d658c50ac2bd39c1a0b8eb3beb3d6d910468f3&r1=11d95c48c25e94c080f080da00cc1528447ace1c >> >>> ... if it strictly needs to be set during the >>> initialization of a deployment? >> >> Patrick's commit comment describes this in a bit more detail; he may >> wish to comment further: >> >> http://fisheye.collectionspace.org/changelog/cspace-service?showid=c4d658c50ac2bd39c1a0b8eb3beb3d6d910468f3 >> >> "CSPACE-5771 Allow admins to mark a tenant to be createdDisabled. This >> minimizes resources devoted to the tenant, and it will remain disabled >> until this setting is altered and the system restarted (the webapp >> reloaded). Permissions are created, as this cannot currently be done >> incrementally." >> >> My naive reading of Patrick's comments are that this functionality: >> >> * Allows a tenant to be initialized in a disabled state. >> * Later on, allows that tenant to (only) be enabled, by changing the >> 'createDisabled' attribute's value to "false", in its delta tenant >> bindings file, and restarting Tomcat. >> >> and (this is solely inferred from the above, and may thus be >> inaccurate - I have not tried this): >> >> * You can introduce the new tenant's folder, including its delta >> tenant bindings file that initially marks the tenant's state as >> "disabled," at any time: even *after* you've previously initialized >> your deployment with other tenant(s), such as the demonstration >> tenants that ship with CollectionSpace, or other custom tenants. >> >> Aron >> >> P.S. In the v3.2.1 release notes, I've also corrected the link to the >> relevant issue that introduced this functionality: it's CSPACE-5771, >> not CSPACE-5571, as was erroneously listed there previously: >> >> http://wiki.collectionspace.org/display/collectionspace/Release+3.2.1#Release3.2.1-Creatinginitiallydisabledtenants%28CSPACE5771 >> >> On Tue, May 14, 2013 at 3:08 PM, Jesse Martinez <mjesse@gmail.com> wrote: >>> v3.2.1 release notes mention new functionality of creating >>> initially-disabled tenants. Is there documentation on how this configuration >>> change gets applied, and if it strictly needs to be set during the >>> initialization of a deployment? >>> >>> Thanks, >>> >>> - Jesse >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>>