Module development - Module.VersionInfo in KINI table

Hi there,

this is kind of best practices mixed with just a wondering what this is for. I've noticed that some modules (but not all) will insert a record into KINI in the Module.VersionInfo INI section. When they do that, it means that every server in the cluster must have that module loaded. most of the time this is good practice. However, occasionally, you might want to load a temporary module on one server in the cluster, have it do some work, then uninstall it, but you don't want to install it everywhere.

Initially, I thought that the entry in KINI happened automagically, but looking at the KINI table on one of our dev instances, I can see not all modules are represented here, leading me to believe that this isn't so.

So I guess my questions are 1) Is the KINI Module.VersionInfo created automagically or do you need to call it explicitly, and 2) are there best practices around this KINI entry? I would assume that you would want something like this if your module defined a custom node type so that all servers in the cluster could retrieve it.

-Hugh

Find more posts tagged with

Comments

eLink User

Oscript allows you to insert that "automagically" as well as update the schema in a newer release.

DBWIZAPIROOT:ExecPkg will give you a Object and then you will need to supply the SQL for Oracle & SQLserver

The UpdateSchema will allow you to do something like return .ProcessScripts( { pkg.upd1000_sql } )

which really means go and execute the sql who is a orphan of DBWIZAPIRoot:Scripts(incidentally this is what the core upgrade does execute the named script and the named sql packages)

Inside the DBWIZAPIRoot:ModuleDBObject is a Object called HowToAddAVersionUpdate & HowToAddSchemaToAModule

If you have the old builder documentation see the section that says "Add Schema to your module"

Now if you look most of the new code from OT now makes it kind of like this.

If say you have a module that used to insert schema (For e.g Transmittals ) after the kini insert/update

they make it a administrator chore to do the individual table alters from the GUI.

If you want to run a non cluster aware module I believe you cannot have the kini module.versionInfo

Another thing that has been part of OT Bible .One shall not put your values into KINI which causes a reload of kini while it is running.

Incidentally your **** friend Ossie and another good friend John has a much better db utility way which we use here.

.....appu appnair appunair

Well, if I called the wrongnumber, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

On Mon, Jun 13, 2016 at 2:28 PM, eLink Entry: Content Server Development Forum <development@elinkkc.opentext.com> wrote:

Module development - Module.VersionInfo in KINI table Posted byFerguson, HughOn 06/13/2016 03:26 PM

Hi there, this is kind of best practices mixed with just a wondering what this is for. I've noticed that some modules (but not all) will insert a record into KINI in the Module.VersionInfo INI section. When they do that, it means that every server in the cluster must have that module loaded. most of the time this is good practice. However, occasionally, you might want to load a temporary module on one server in the cluster, have it do some work, then uninstall it, but you don't want to install it everywhere.Initially, I thought that the entry in KINI happened automagically, but looking at the KINI table on one of our dev instances, I can see not all modules are represented here, leading me to believe that this isn't so. So I guess my questions are 1) Is the KINI Module.VersionInfo created automagically or do you need to call it explicitly, and 2) are there best practices around this KINI entry? I would assume that you would want something like this if your module defined a custom node type so that all servers in the cluster could retrieve it.-Hugh
[To post a comment, use the normal reply function]
Forum: Content Server Development Forum
Content Server: Knowledge Center

Hans Stoop

As Appu wrote: It is the version number of the database schema of your module. Don’t use it when you don’t have a schema.

Hans

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Montag, 13. Juni 2016 21:29
To: eLink Recipient
Subject: Module development - Module.VersionInfo in KINI table

Module development - Module.VersionInfo in KINI table

Posted by Ferguson, Hugh On 06/13/2016 03:26 PM

Hi there,

-Hugh

[To post a comment, use the normal reply function]
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

Chris Meyer

1) Is the KINI Module.VersionInfo created automagically or do you need to call it explicitly

It's explicit if you're adding a database table using the standard CS approach. It's often in the form:

insert into %Prefix%KIni values('%IniSection%','%IniKeyword%','{2,0,1}')

I find it a bit strange since KIni has an API for CRUD operations.

are there best practices around this KINI entry?

It's debatable, but I think managing the schema outside of the standard approach is easier, less error prone, and doesn't require a KIni update.

I would assume that you would want something like this if your module defined a custom node type so that all servers in the cluster could retrieve it.

Custom node types are registered via the LLNode and Webnodes subsystems, which is part of the module and not anything explicit in the database.

Another thing that has been part of OT Bible .One shall not put your values into KINI which causes a reload of kini while it is running.

I've heard this before but don't take it seriously. If you look through Builder/OClipse you'll find many places where updates are made to KIni.

HFCDev

Thanks for the inputs, Appu, Hans, Chris. You've confirmed what I suspected and have given me ammunition to propose Oscript approaches to my client. The big worry about it was that one would need to install the module on every server in the cluster - i.e. in a PRD system, up to 9 different servers. Now, for operations that are more amenable to Oscript, I can propose loading a temp module on a single throwaway server that is connected to their PRD db which can be disconnected later.

I don't know why I didn't see this before as while I was at Suncor, we regularly had developers with their own DEV sandbox all connecting to the same development DB. Had it been otherwise, that sharing would have been impossible, but this was LL 971 back in the day.

And to the last point, I agree with Appu. I've seen instances (unfortunately, non-deterministic) where a field gets updated in SQL Server manager and doesn't get picked up by builder. Therefore, I generally restart, especially for KINI changes

-Hugh

Hans Stoop

<![if !supportLists]>Ø <![endif]>I've heard this before but don't take it seriously. If you look through Builder/OClipse you'll find many places where updates are made toKIni.

KIni should only be used to store configuration data. It should not be used for storing progress data.

Once we did an upgrade of data during the upgrade process. The number of items processed we stored in the KIni table. The performance of this was really really bad, so we removed it again.

Hans

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Dienstag, 14. Juni 2016 09:10
To: eLink Recipient
Subject: Module development - Module.VersionInfo in KINI table

Module development - Module.VersionInfo in KINI table

Posted by Meyer, Chris On 06/14/2016 03:04 AM

1) Is the KINI Module.VersionInfo created automagically or do you need to call it explicitly

It's explicit if you're adding a database table using the standard CS approach. It's often in the form:

insert into %Prefix%KIni values('%IniSection%','%IniKeyword%','{2,0,1}')

I find it a bit strange since KIni has an API for CRUD operations.

are there best practices around this KINI entry?

It's debatable, but I think managing the schema outside of the standard approach is easier, less error prone, and doesn't require a KIni update.

I would assume that you would want something like this if your module defined a custom node type so that all servers in the cluster could retrieve it.

Custom node types are registered via the LLNode and Webnodes subsystems, which is part of the module and not anything explicit in the database.

Another thing that has been part of OT Bible .One shall not put your values into KINI which causes a reload of kini while it is running.

I've heard this before but don't take it seriously. If you look through Builder/OClipse you'll find many places where updates are made toKIni.

[To post a comment, use the normal reply function]
Topic:	Module development - Module.VersionInfo in KINI table
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

Hans Stoop

Life was so much better with 9.7.1. ;-)

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Dienstag, 14. Juni 2016 14:11
To: eLink Recipient
Subject: Module development - Module.VersionInfo in KINI table

Module development - Module.VersionInfo in KINI table

Posted by Ferguson, Hugh On 06/14/2016 08:06 AM

-Hugh

[To post a comment, use the normal reply function]
Topic:	Module development - Module.VersionInfo in KINI table
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

eLink User

If at all it helps we have a module that introduces a new node type in its own volume.This nodetype is useful in transporting configuration data stored in the extendeddata field. Since it is a node that we defined we could control the extended data manipulation.A lot of complicated configuration data if done correctly in one system like QA then could be XMLExported and XMLImported. We went bonkers and even made it work with the transport system

Mostly I believe for rapidly changing data LLsystemdata or your own table.I tend not to argue with OT gurus once I see something that they say explicitly should not be done,however I have also seen OT code do those things.

.....appu appnair appunair

Well, if I called the wrongnumber, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

On Tue, Jun 14, 2016 at 7:10 AM, eLink Entry: Content Server Development Forum <development@elinkkc.opentext.com> wrote:

Module development - Module.VersionInfo in KINI table Posted byFerguson, HughOn 06/14/2016 08:06 AM

Thanks for the inputs, Appu, Hans, Chris. You've confirmed what I suspected and have given me ammunition to propose Oscript approaches to my client. The big worry about it was that one would need to install the module on every server in the cluster - i.e. in a PRD system, up to 9 different servers. Now, for operations that are more amenable to Oscript, I can propose loading a temp module on a single throwaway server that is connected to their PRD db which can be disconnected later.I don't know why I didn't see this before as while I was at Suncor, we regularly had developers with their own DEV sandbox all connecting to the same development DB. Had it been otherwise, that sharing would have been impossible, but this was LL 971 back in the day. And to the last point, I agree with Appu. I've seen instances (unfortunately, non-deterministic) where a field gets updated in SQL Server manager and doesn't get picked up by builder. Therefore, I generally restart, especially for KINI changes -Hugh
[To post a comment, use the normal reply function]Topic:Module development - Module.VersionInfo in KINI tableForum:Content Server Development ForumContent Server:Knowledge Center

David Templeton

Morning

I find it a bit strange sinceKIni has an API for CRUD operations. are there best practices around this KINI entry?

We have discussed changing that part of the upgrade steps to have features on the script object that the db upgrade would pick up and use instead of the direct SQL in the upgrade step. This is left over from the dawn of time and KINI was not cached etc.

Another thing that has been part of OT Bible .One shall not put your values into KINI which causes a reload of kini while it is running.

I've heard this before but don't take it seriously. If you look through Builder/OClipse you'll find many places where updates are made toKIni.

Yes, there are many places that update KINI and retrieve BUT look at the context we strive and go and correct code that doesn’t follow the following general best practices:

<![if !supportLists]>- <![endif]>Only use KINI for configuration settings

<![if !supportLists]>- <![endif]>DO NOT write or read the KINI directly, period

<![if !supportLists]>- <![endif]>If you have system settings like progress etc then use the $LLIAPI.SystemDataUtil.* functions

<![if !supportLists]>- <![endif]>KINI settings are cached, should not change often

<![if !supportLists]>- <![endif]>It is a supported interface, protection from changes under the cover are guaranteed

Constantly changing KINI will cripple the system. We have lots of evidence of this from customers.

It's debatable, but I think managing the schema outside of the standard approach is easier, less error prone, and doesn't require a KIni update.

Seriously? There is no debate, the schema management framework has been built to make managing schema predictable, upgradable and allow for the module to play nice in the CS eco-system. As CS-suite moves forward into more cloud and automated deployments the concept of automated management and known operational paths the days of modules differently managing schema is NOT viable. To be honest I don’t care the developer needs to take 5 extra steps to make an upgrade in the schema management, for the customer there is one path to install and manage and not 20 different looking screens.

IF, there are issues with the framework and not meeting some need then register an issue and NOT work around it. It doesn’t help you, OpenText or the customer. We strive to make it better all the time and there are lots of improvements that have gone in. I am sorry to say they didn’t get back ported to 971 but that is also reality, we are making the product to upgrade with Cluster Management in 10.5 and System Center in CS16. Rogue modules don’t help anyone.

We have in the backlog the following investigations:

<![if !supportLists]>- <![endif]>Not require the dummy DB to set up a system

<![if !supportLists]>- <![endif]>Mandate the separation of installation and configuration of a module

<![if !supportLists]>- <![endif]>Modules will need to be deployed without admin intervention

Just as the heads up of what the future holds….making it better all the time

Regards

David Templeton

Content Suite Enterprise Architect

OpenText Corporation

Phone:	(519) 888 7111 x2301
Mobile:	(519) 581 7600
LinkedIn:	davidt50
Twitter:	@davidt_50
Website:	www.opentext.com

This email message is confidential, may be privileged, and is intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosing or reproducing it. If the addressee cannot be reached or is unknown to you, please inform the sender by return email and delete this email message and all copies immediately.

HFCDev

Hi David,

As the instiagtor of this thread, I figured I had better chime in again. The original question was about whether the act of installing a module on one server in a cluster would make the rest of the cluster unusable until said module is installed on every item. And I would always recommend with any module that the best practice is to install it across the board. However, there are times when you just want to install a utility on a back-end server to manage some admin or data cleanup task for which Web Services and/or REST are simply not options.

As for 'asks', I would start with make it possible to have a module install on every server in the cluster so I don't get the argument back from clients that they won't install a partner product because they don't want to repeat the installation 20 times. That would go a long way to getting partners to use a more centralized schema management. It would make it easier for partners to sell their products as that's one less excuse the client can use for not buying the product (and currently OpenText products also need to be installed multiple times - 1 per server in the cluster). Maybe this is on the list for CS20

-Hugh

David Templeton

Hugh

So the best/recommended practice is to install across the board and before others jump on meJ we have been looking into enhancing the cluster management/system center to handle the deployment of modules from a gold master. Now, this obviously becomes much, MUCH harder when the said module does its own thing in areas like schema management, configuration etc. If this makes sense for integrators please say so and that can be relayed to the PM’s to help them in the decision making process.

Now for the problem you want to solve, it ‘feels’ like you don’t want the weight of the module but want to have some “utility” code to run. I don’t have an answer for this. My gut wants to say an oll ( or something ) that is loaded on the instance with no schema but then questions on what can be exposed? Does this open the potential for an attack vector? What about UI components? Debugging concerns especially if the code hooks into node callbacks for instance. What does it mean to audit since that render code is only on one instance? Can object types be defined? How would you prevent that? What would be the scope of what can be executed versus not? Should it be just the external interface ( REST ) that can be accessed? And these are just a couple of questions I came up in 10mins. If there are suggestions then as always all ears.

Agreed, it is a pain, simplifying the deployment effort and run time costs do make it easier. The perfect example is the mentioned cluster mgmt, the feedback we get is once tried customers love it. You match it up with the Informant module to additionally help manage the cluster it is much better than before. Let’s face it the system are getting larger period and more servers and need the tools to make more seamless to deploy the cluster

David

eLink User

@Hugh

"clients that they won't install a partner product because they don't want to repeat the installation 20 times"

Those kind of problems are man made most of the time.In almost every conceivable module that gets shrink wrapped and thrown to admin.index for further installation most of the people who do not like installing it 20 times will just make a deployment master change a few logical parameters convert servers into FE's,Admins and agents.Something you hear as "Anchor Copy Cloning" or "Gold Copy".This was necessary because of the obvious cluster aware things like "You have Directory in the database but you don't have it in the binaries blah blah".The process we follow has its difficulties especially in certain modules like classifications/sap activator etc which actually registers dll's as well.I have sometimes had to register them manually.Many times if you look at the oScript inside you will see that on module startup it does it anyways. BTW this essentially is kind of what the cluster management does as well.The entire problems in a OT deployment stems from the fact that many things have to configured in a QA instance,then again in the Pre Prod and then again in Prod.I believe the SAP integrations forced OT's hand in a "Transport Mechanism" so it is getting there slowly.In the absence one resorts to GCI or other logically made checklists of sorts.

What nowadays I do is in the CSIDE I run an external script you could do that in builder as well,this is my equivalent to if I needed to quickly test things etc.People like Christopher Meyer have even written products that can quickly execute server side script,it may be tantamount to misuse if not used correctly.

@David and other great OT heroes,What may work for integrators or others like me who is occasionally debugging or writing things useful is some guidelines in oScript. It may be as trivial as a comment in oScript that says "OT reserves the right to change the feature set at some point please refrain from using similar code"

or perhaps like the old script "Make a module" a script that will create the necessary DB objects consistently like what OT wants.Perhaps this is part of Hans's customizationsRT , I have not looked at that recently . While rogue modules are not one's intention sometimes job pressures forces us to bypass or do things for which examples don't exist and the company just does not have the money to shell out to a OT PSO guys.I n many big databases like ours webreports sometimes run very slowly or we are used to old oscript speed so we just do it at the drop of a hat. Incidentally things like Gimmeaprgctx sometimes say s Deprecated in echo statements those kind help developers like us or oncoming developers as well.

.....appu appnair appunair

Well, if I called the wrongnumber, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

On Tue, Jun 14, 2016 at 12:19 PM, eLink Entry: Content Server Development Forum <development@elinkkc.opentext.com> wrote:

RE RE Module development - Module.VersionInfo in KINI table 2 Posted byTempleton, DavidOn 06/14/2016 01:18 PM

Hugh As the instiagtor of this thread, I figured I had better chime in again. The original question was about whether the act of installing a module on one server in a cluster would make the rest of the cluster unusable until said module is installed on every item. And I would always recommend with any module that the best practice is to install it across the board. However, there are times when you just want to install a utility on a back-end server to manage some admin or data cleanup task for which Web Services and/or REST are simply not options.So the best/recommended practice is to install across the board and before others jump on meJ we have been looking into enhancing the cluster management/system center to handle the deployment of modules from a gold master. Now, this obviously becomes much, MUCH harder when the said module does its own thing in areas like schema management, configuration etc. If this makes sense for integrators please say so and that can be relayed to the PM’s to help them in the decision making process.Now for the problem you want to solve, it ‘feels’ like you don’t want the weight of the module but want to have some “utility” code to run. I don’t have an answer for this. My gut wants to say an oll ( or something ) that is loaded on the instance with no schema but then questions on what can be exposed? Does this open the potential for an attack vector? What about UI components? Debugging concerns especially if the code hooks into node callbacks for instance. What does it mean to audit since that render code is only on one instance? Can object types be defined? How would you prevent that? What would be the scope of what can be executed versus not? Should it be just the external interface ( REST ) that can be accessed? And these are just a couple of questions I came up in 10mins. If there are suggestions then as always all ears. As for 'asks', I would start with make it possible to have a module install on every server in the cluster so I don't get the argument back from clients that they won't install a partner product because they don't want to repeat the installation 20 times. That would go a long way to getting partners to use a more centralized schema management. It would make it easier for partners to sell their products as that's one less excuse the client can use for not buying the product (and currently OpenText products also need to be installed multiple times - 1 per server in the cluster). Maybe this is on the list for CS20 Agreed, it is a pain, simplifying the deployment effort and run time costs do make it easier. The perfect example is the mentioned cluster mgmt, the feedback we get is once tried customers love it. You match it up with the Informant module to additionally help manage the cluster it is much better than before. Let’s face it the system are getting larger period and more servers and need the tools to make more seamless to deploy the cluster David
[To post a comment, use the normal reply function]
Topic: Module development - Module.VersionInfo in KINI table
Forum: Content Server Development Forum
Content Server: Knowledge Center

David Templeton

Hugh

Some additional comments

I have seen this and it makes me cringe to tell you the truth. Except for the licensing issue of course sharing such an environment would be a pain. Now, for straight up oScript module work it will be easier since Postgres ( which is free ) is supported and would be trivial for the developer to have one locally.

This is where I just shake my head. Fingers off the KINI tableJ If you feel you need to access/update it directly, please step back from the keyboard and get a coffee….. J Over the last 18-24mths we have strengthened the KINI interface & implementation significantly to perform and minimize the need to access the DB for these settings.

David

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Tuesday, June 14, 2016 8:11 AM
To: eLink Recipient
Subject: Module development - Module.VersionInfo in KINI table

Module development - Module.VersionInfo in KINI table

Posted by Ferguson, Hugh On 06/14/2016 08:06 AM

-Hugh

[To post a comment, use the normal reply function]
Topic:	Module development - Module.VersionInfo in KINI table
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

HFCDev

Quoted David Templeton on 06/14/2016 09:11 PM:

Hugh

Some additional comments

Back then, there was just Oracle and SQL Server, and for whatever reason, they didn't want to licence development dbs for 12 developers. I didn't exactly enjoy sharing the db.

Quoted David Templeton on 06/14/2016 09:11 PM:

This is where I just shake my head. Fingers off the KINI table J If you feel you need to access/update it directly, please step back from the keyboard and get a coffee….. J Over the last 18-24mths we have strengthened the KINI interface & implementation significantly to perform and minimize the need to access the DB for these settings.

Actually, I've observed this with non-KINI tables, in fact, with tables that are outside of the core schema, but could never get this to reproduce itself deterministically. I actually fully support and loudly encourage the use of CAPI.IniGet/IniPut as the way to set values not just for the reasons you cited, but also I've seen it where values going in by hand that need to later come out as Oscript non-string data types can come back corrupted despite the best crafted SQL statement. Once again, nothing I could ever determine a hard set of rules for, so I just used the CAPI dropin.

-Hugh

Module development - Module.VersionInfo in KINI table

Posted by Ferguson, Hugh On 06/14/2016 08:06 AM

-Hugh

[To post a comment, use the normal reply function]
Topic:	Module development - Module.VersionInfo in KINI table
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

Hans Stoop

I have seen problems related to databases values not being available due to not properly closing transactions. I think it was mainly/only on Oracle.

Hans

From: eLink Entry: Content Server Development Forum [mailto:development@elinkkc.opentext.com]
Sent: Mittwoch, 15. Juni 2016 03:13
To: eLink Recipient
Subject: RE Module development - Module.VersionInfo in KINI table 2

RE Module development - Module.VersionInfo in KINI table 2

Posted by Ferguson, Hugh On 06/14/2016 09:11 PM

Quoted David Templeton on 06/14/2016 09:11 PM:

Hugh

Some additional comments

Back then, there was just Oracle and SQL Server, and for whatever reason, they didn't want to licence development dbs for 12 developers. I didn't exactly enjoy sharing the db.

Quoted David Templeton on 06/14/2016 09:11 PM:

-Hugh

Module development - Module.VersionInfo in KINI table

Posted by Ferguson, Hugh On 06/14/2016 08:06 AM

-Hugh

[To post a comment, use the normal reply function]
Topic:	Module development - Module.VersionInfo in KINI table
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

[To post a comment, use the normal reply function]
Topic:	Module development - Module.VersionInfo in KINI table
Forum:	Content Server Development Forum
Content Server:	Knowledge Center

Chris Meyer

Hi David,

Yes, there are many places that update KINI and retrieve BUT look at the context we strive and go and correct code that doesn’t follow the following general best practices:

True. I was trying to point out that never using it is exaggerated.

Seriously?

Absolutely. I have no problem writing a framework when I see a better way of doing things. Schema management is just one example: I'm able to create and change table schemas more reliably in a fraction of the time and the only difference in the end result is how the schema version number is stored.

The framework also adopts the "don't repeat yourself" principle, which means the underlying APIs to query, update, and insert records into the table are automatically updated. In other words, updating the schema doesn't require any SQL statements to be changed in OScript. Forms that depend on the schema are also updated automatically (e.g., no need to edit HTML forms in Weblingo to support a new field).

I hope this provides some context. It's more efficient to work this way even if it requires an administrator to click an "install" or "upgrade" button to install or upgrade a table. But this could also be changed in the future to support automatic deployment scenarios.

IF, there are issues with the framework and not meeting some need then register an issue and NOT work around it.

The problem is that we work with existing versions of Content Server and need solutions now. It's far easier to build something than have a conversation about a feature that might get added in a future release.

I appreciate your skepticism, but understand we're coming at the problem from very different directions. But I'm sure solutions others or I have developed will find a way to integrate with whatever the future holds.

John Simon

Coffee?!? Make it a beer and you have a deal!

Seriously though, I just wanted to jump in and say what a great discussion this is/was. Thanks to all who posted.

Cheers...

David Templeton

Chris

Ok, I would be absolutely stupid if I were to ignore/dismiss such ideas. No, I would say instead this statement has appeal and how do we make some of ideas universal for all modules so that customers don’t have two implementations to deal with. In the end the customer loses out and the complaints of the overly complicated management of the system continue. I am going to state right here, there needs to one official schema management for the customer period. We need to make it easier for the customer and automation going forward. Chris, feed us the ideas to improve the system and that goes for anyone.

Sure, but let me clarify this, our next release is in September 2016 for 10.5 and 16. We are not talking about the next major release, if we as a community decide that a change is warranted then a case can be made for it now. Yes, a lot of this forward position support but that is really the way to work.

Please do not take push back as skepticismJ anyone that has worked with me knows that I ask questions like crazy, sometimes stupid ones to make sure we all can explain the ‘solution’ and understand it clearly. I want the product suite to be the best it can be, we have made many changes to improve the system overall and hopefully that is being seen by the community and the customer base. If I need to say it again I will, bring the ideas, suggestions, code suggestions to the table to make everyone’s life better.

David

Jeff Lang

I'd like to add a few comments as a technology partner that primarily creates new products for general use. I've recently watched OT services try to install modules on a new system using the "Golden Master" technique and it has failed every time. The reason being is that modules can do very different things at install time on the server where they are being installed. What if your modules adds files to the OTHOME/scripts or OTHOME/ojlib directories? What if the module creates directories outside of OTHOME/support and populates them with required files? I haven't seen that the "Golden Master" approach handles these situations. How can that approach know what is necessary for the installation of a module? There is specific code in the install system that allows for modules to do things like this.

For the past 11 years we've shipped a product where we explicitly recommended that it only be installed on a single backend server. The only UI is through the admin.index page for an administrator. The other reason it was recommended to be installed on only 1 backend server was because when the features of the product are used, the code makes a runtime replacement of about 150 different methods in core, and other modules, to make XMLExport and XMLImport work for all node types. We tell our customers that after you've finished migrating your data across instances, bounce that service and all the code will be back to normal. This is in case some module depends on the OOTB limited XMLNode interfaces that have been written. We've recently run into problems with the OT patch manager system that wants to force all servers in a cluster to be the same configuration. This is not always the case.