Advanced MyST usage – delete binaries

Usually, when you are using Rubicon Red MyST to provision Oracle Fusion Middleware domains, you choose your nodes, and go install the products on them. These will not change over time so there is no need to wipe the installed binaries. This is probably the reason why MyST does not do this when you tear down an environment.

Together with my colleague Robert Jan de Groot, we encountered a different situation at a client and have found a way to leverage standard MyST functionality to achieve our goal: wiping the nodes.

This post is part of a Series in which Robert Jan and I explore the inner and hidden parts of Rubicon Red MyST Studio which might come in handy at times.

In our case, we wanted to reuse certain nodes to provision to as part of a ‘regression test’, to check whether a new version of the product (or a Release Candidate) didn’t break our setup.
The basic flow of this test would be:
Provision domain type A. Upon success: tear down.
Provision domain type B. Upon success: tear down.
And so on.

We don’t have the capability to also provision/create full Linux nodes on demand, so in order for us to not have tens of nodes just idling we designated three Linux nodes to be our Product Test Nodes; but they’d need to be wiped clean after each successful provisioning by MyST.

For this to work properly, we would need to get rid of not only the domain, but also the binaries in the ORACLE_HOME.

To achieve this, three steps are required:

1. Create Custom Action in MyST to delete binaries from nodes.
2. Have MyST execute this áfter ‘Terminate’ Action.
3. Make this behaviour optional & safeguarded.

Custom Action in MyST

This Custom Action in MyST needs to be able to log on to each and every node in our FMW cluster and delete the binaries from that node.
Our domains ether consist of two nodes (MS + co-located AS, MS) or one node (2 MS and a co-located AS), so we cannot hard code this.

Name: remove-product-home
Type: Jython Action
Description: Remove product home from nodes
Content:

from com.rubiconred.myst.util import SSHUtil
def myst(cfg):
  if cfg['remove-product-home'] == 'true':
    nodes = cfg['nodes']
    for node in nodes.split(','):
      machineName = cfg.getProperty('core.node[' + node + '].host')
      LOG.info("Removing " + cfg['core.fmw.home'] + " from " + machineName)
      SSHUtil.removeRemoteDirectory(node, cfg['core.fmw.home'])

This piece of Jython/Python script leverages an internal class from MyST to do the majority of the hard work. The class is called SSHUtil, and the method we are using here is conveniently called removeRemoteDirectory; which just does that.
It logs on to the node you require, and proceeds to delete the location you request. Here, it takes the fmw.home location from the Platform Model and deletes it.
We do not have to worry about paths or inclusions as this SSHUtil is readily available on the classpath as MyST executes its own actions.
Please note there is little to no error handling going on here, both in our code or in the SSHUtil class. We are just assuming that the location which is to be deleted is available and has the correct set of rights. I’m pretty sure this can be improved upon!

Execute Custom Action after Termination

To have MyST execute an additional action we can leverage the not-so-hidden feature of pre and post tasks.
We just need to add an extra Global Variable:

action.destroy.post=remove-product-home

This will chain our Custom Action with the name remove-product-home to the destroy action.
There are actually two moments like this, a pre and a post. You are able to do things like this:

action.rcu.pre=really-do-drop-all-connections
action.create-resource.post=security

Please note, this added Custom Action shouldn’t be set on a Platform Blueprint, but just on the Platform Model as there is no need for it on all environments. Just this one.

Safeguard against mishaps

You actually never would need to delete the binaries from your hosts, except in this very specific situation.
Moreover, you REALLY do not want to delete the binaries from, let’s say, your PRODUCTION environment.

Also, simple mistakes are made easily, and even though ‘accidentally’ executing this custom action is not something you can do with just a single click the consequences are worth adding an extra safeguard for.
We added an extra Global Variable to our Platform Model, and have the Custom action check for the value of that variable.

remove-product-home=true

When the Custom Action reads the value to be “true”, only then the binaries will be deleted from the nodes. If this value is either “false”, something else altogether, or not set at all, it just ignores it and does nothing.

Extra information

With this safeguard in place, it’s also possible to Nuke & Destroy a running environment, without modifying the Platform Model.
To do this, you need to execute an Action on the Platform Instance (Actions -> Control)

Here, you need to select the Action to be ‘Custom’, type the Action to be destroy (TAB or ENTER away) and add the following Additional Properties:

-Daction.destroy.post=remove-product-home -Dremove-product-home=true

Click execute and watch your environment be deleted completely.

Future improvements

The script we created as our Custom Action in this post is far from complete, it only removes the binaries from your filesystem (ORACLE_HOME) and it still leaves a lot of stuff behind. The Oracle FMW installers not only place the binaries in a certain location, but also register the installed products in the Oracle Inventory. This Inventory is not touched by this Custom Action.

Also, any Filestores you might have created in your domain are not cleaned up.
Extending the script in the Custom Action might be a solution to this. We did not pursue this matter further, as the deletion of the binaries solved our issue.

If you’ve come up with a nice addition to remove more of the domain from your nodes, we’d love to hear about it!