When you look at OS packages, they have can run things at a pre and post
stages, and maybe a rollback procedure. So maybe there should be a preExecute()
method that would run some checks to ensure that what it would execute() would
work?
if I was going to migrate from JRobin v1 to RR4J v2 formatted RRDs, I'd want to
know that I had enough disk space around before doing a conversion. Then, as an
option a postExecute() could remove all the JRobin v1 files. (Imagine if RRD
data moved into Cassandra or some other backend...)
Or another case might be having the a step do a database backup for us before
running the installer for database components. We'd want to have enough space
around for the database backup before doing the upgrade.
So then upgrade would run all the preExecutes(), and if they all succeeded, run
all the executes(), and if they all succeeded, run all the postExecutes(). If
any of the executes() failed, attempt to rollback executing a rollback() method?
Ron
From: Alejandro Galue [mailto:aga...@opennms.org]
Sent: Tuesday, October 08, 2013 2:56 PM
To: OpenNMS Code Development and Bugs
Subject: Re: [opennms-devel] install/upgrade non-database components?
Hi,
On Oct 1, 2013, at 10:40 AM, Benjamin Reed
<ran...@opennms.org<mailto:ran...@opennms.org>> wrote:
On 9/30/13 10:48 PM, Ronald Roskens wrote:
Is there a framework for handling the non-database components of OpenNMS when
running install?
There is not, and this has been something we've needed to do for quite a
while. We need "liquibase-for-filesystem".
Here is what I've been thinking about as a possible solution for this:
1) Define a Java Interface where all the custom upgrade scripts must implement.
2) Create a helper class that is going to find all the implementations of that
interface under a package reference supplied ("org/opennms" will be used by
default).
3) The list of implementations will be ordered somehow.
4) For each class, check if it was executed before or not (and store the
execution states somewhere).
5) For each class that was not executed before, execute it (*)
For the last step, I'm considering two possibilities:
a) OpenNMS must be running
b) OpenNMS must be stopped
The implementation of each class must inform if OpenNMS must be running or not
in order to execute the upgrade, so the helper class should be able to check
the status of OpenNMS somehow.
I'm attaching a prototype of that idea. Of course, it is a work in progress and
I though that it is a good idea to place it in core/upgrade. If you want to try
it, uncompress it on the core folder on your 1.12 branch.
Finally, the idea is to create an upgrade.sh script, to basically execute
install.sh plus the helper class that I've mentioned. Of course, we can modify
the current install script to perform both operations: the liquibase and the
post-upgrade processes.
Thoughts ?
Alejandro.
This e-mail message is being sent solely for use by the intended recipient(s)
and may contain confidential information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by phone or reply by e-mail, delete the
original message and destroy all copies. Thank you.------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ
opennms-devel mailing list
To *unsubscribe* or change your subscription options, see the bottom of this
page:
https://lists.sourceforge.net/lists/listinfo/opennms-devel
