the best way to update teiid standalone, keeping all custom settings/deployments?

[m.ardito]

Hi,

I'm following this project since years, but lately I'm struggling to understand it better, and to keep it "in shape" in order to be able to use it in production, soon.

But, as soon as a new version comes out, I wish to try how it works, if bugs have been solved, and so on, obvioulsy, perhaps.

Any "old" standalone install always has its:

- users/roles settings

- custom configs,deployments (driver & vdb .jars)

- custom(ized) resource adapters & connection definitions

- custom jdbc data sources,

and so on.

And for new teiid versions I usually like to try also new appserver (jumping from AS7 to EAPalphas to Wildfly...)

I try to deploy as much as I can by web interface, but sometimes guides, suggestions make me try jboss-cli commands, or else.

for users, roles, I can (for minor or compatible versions ugrade), simply copy .properties file under <basedir>/standalone/configuration, itjust works.

For all the rest, I know that standalone-teiid.xml has many of those settings, but I can't simply copy/past just them, as many XML settings rely on deployments and CLI-made settings

So, I usually end up re-doing by hand, in the order

- all driver jar deployments (web console)

- all resource adapter & connection definitions (CLI)

- all jdbc datasource definition (web console)

- all vbd jars (web console)

and I always fear to make mistakes here and there...

How can I "upgrade" my install (or a testing copy of it), in the easiest way, in order to make thesmottherst transition from a new teiid version?

Any suggestions, or experience to share, in order to keep, in the simplest/safetst way, my teiid framework up to date?

Thanks...

Marco

[rareddy]

I suggest using a CLI script for all the items, you can

-  deploy driver jar deployments

- deploy  resource adapter & connection definitions

- deploy jdbc datasource definition

- deploy vbd jars

Write yourself a CLI file that deploys all your artifacts then execute it in the new environment. That way you can effectively move from one environment to another easily. You can run this file as

./jboss-cli.sh --file=myscript.cli

[m.ardito]

Sorry to be late on this, now I'm starting to tackle this aspect, too. Meanwhile I've also reviewed the quickstarts, and I've learned more about this process.

- deploying jars and vdbs is easy, it should be just matter of putting them in a defined folder and make the script fin find and deploy them with that simple command

- for RA config, RA definitions and jdbc DS definitions I guess that, as in the quickstarts, this can be done just with a sequence of commands

but RA config, RA definitions and jdbc DS definitions have a ton of possible settings/parameters, and it seems that the quickstart scripts, apart the obvious class/connection details, issue just some of the other settings/parameters, maybe just everything that overrides defaults...

is it so?

is there any way to "dump" RA config, RA definitions and jdbc DS definitions that I already have now in my server (ideally, just what is needed, ie: what is not a default, and needs to be specified to override the standard behaviour) in order to get some help transferring definitions from one install to another?

I mean: is there a way to "dump" all those settings (maybe also jars/vdbs) from one server, that can be used (directly or with some adjustments) as a "setupscript.cli" to reinstall or transfer the same settings to another install? This would be a very good way to "backup" all this complex environment's settings, and also to document what is running, how, and where.

That could be useful because if I use other deploying methods (webconsole, vdbs/jars with .dodeploy files,  or other) on my server, I am never sure if my "setupscript.cli" is up-to-date and executing it will replciate exactly the configuration I have now, whatever method I uset to set it up.

Marco

[shawkins]

This was asked at http://stackoverflow.com/questions/24730540/export-jboss-configuration-as-cli-script without a good answer.  And I couldn't find anything on creating cli from the current configuration either.  CLI Recipes - JBoss AS 7.1 - Project Documentation Editor shows getting the configuration state as:

:read-resource(include-runtime=true, recursive=true, recursive-depth=10)

However that is in a display format and not as cli script.  It seems like a perfectly valid feature request against wildfly if it doesn't already exist.

[m.ardito]

CLI Recipes - JBoss AS 7.1 - Project Documentation Editor shows getting the configuration state as:

:read-resource(include-runtime=true, recursive=true, recursive-depth=10)

Interesting, for a start, do you know how can I dump that output to file?

[edit] that was easy: create a dumpall.cli script which contains only that line, then execute bin/jboss-cli.sh -c --file=dumpall.cli > dumpall.txt [/edit]

Meanwhile, I am building a script from bottom up. I've learned about if-else-endif and try-catch-finally and also about setting variables, which all help a lot.

Up to now, I followed this approach

- check the vdb state.

- If it's in the desired state (enabled, active), quit, nothing to do.

- If it's not in the desired state (enabled, active), then try to install all dependencies:

> if not already deployed, deploy needed jars

> if not already there, add all datasources and resource adapters/connection definitions

> deploy the vdb

- repeat for every needed vdb

It's quite fast even in the worst case, just a few seconds for a vdb which needs 2 jars and 10-15 datasources

And, in the end I'll have dozens datasources (several mysql databases each one needing its own datasource....)

but I'll manage to issue a feature request, if not already there, next week.

Any other suggestion is welcome though...

Thanks, Marco

[rareddy]

It would be beneficial if you can post the scripts once you are done, we might just have that included in the build

[m.ardito]

Ramesh Reddy ha scritto:

It would be beneficial if you can post the scripts once you are done, we might just have that included in the build

If you think so, I surely will, once I get a somewhat final/readable shape... but I'm quite a newbie here, so it will be quite a basic script, I think...

I tried to read a related doc page, but it seems someone removed the code CLI non-interactive mode

see last version changes: https://developer.jboss.org/wiki/CLINon-interactiveMode/diff?secondVersionNumber=3

I also wrote to [e-mail] to tell about this, a few days ago, but I had no answer... is there any better channel?

Marco

[rareddy]

IMO you should ask in WildFly forums. [e-mail] is for website and account related issues.

[shawkins]

A late follow-up.  There is the profilecloner - Reverse engineer your JBoss AS-WildFly configuration to CLI