Bugzilla – Bug 7045
Make Nimbus services installation portable
Last modified: 2010-06-19 23:17:14
You need to
before you can comment on or make changes to this bug.
Currently the installation system will copy the absolute path of the target
directory into various configurations that the service uses to find files,
databases, etc. This means that when you move the directory, everything needs
to be changed "manually."
Instead, Nimbus could use a special token that meant "NIMBUS_HOME"
When Spring intakes the configuration, we could intercept and switch in the
right value. Administrators that went outside NIMBUS_HOME would be on their
This is more valuable than it might seem at first, it allows for easy "non
unit" testing via programmatic creation and teardown of databases etc. without
messing with configuration files.
Merged the work for this in 'relpath' branch to master.
$ ./bin/install /tmp/nimbus-relpath
$ /tmp/nimbus-relpath/bin/nimbusctl start
# start a VM here ...
$ /tmp/nimbus-relpath/bin/nimbusctl stop
$ mv /tmp/nimbus-relpath /tmp/nimbus-newpath
$ cd /tmp/nimbus-newpath
$ /tmp/nimbus-newpath/bin/nimbusctl start
# kill a VM here ...
We will need to discuss how this could work with cumulus installed.
Remember you do need to stop the services container first :-)
This resulted in a regression with something in the code expecting a String
rather than an instance of Resource and the testing so far did not catch it.
Thankyou Pierre for finding and fixing this!
Looked over the rest of the changes like that, I don't see this problem
cropping up. Something to be aware of.
I think the strategy of intaking a Resource instance and storing only the path
is probably the best strategy in most cases (always with a null check on the
String in case set was never called at all).
public void setSpringConfigResource(Resource springConfigResource) throws
this.springConfig = springConfigResource.getFile().getAbsolutePath();