Hi,
Michael already made a great set of roles to install and configure Oracle databases. See https://github.com/oravirt/ansible-oracle.
It works but I wonder if this is the way to go or not. Considering the fact that there will be many Oracle installations and upgrades, I can imagine that the simplest declarative form would make an overview a lot easier that the way it is built now.
I imagine something like
- install the stuff
orainst src=pp:/hh/ff ORACLE_HOME=/some/loc ORACLE_BASE=/some ORA_INVENTORY=/also/somewhere type=rdbms/wls edition=EE/SE/… options=partitioning,rac etc.
I think this would mean writing an orainst module that does al the work, including defining the facts.
When writing such a module, there will be a lot of code that is already written, like copy and shell/command. It would be a pity to have to write that same functionality again. How should we tackle such a thing?
Maybe ansible-oracle is already when we should dream about?
The biggest goal of writing such a module would be to improve the declarative description of what it does. The actions will be the same as ansible-oracle already does. It works.
Would it be OK to re-use the modules that are already proven to build a new module?
Ideally an oracle installation would be written as smooth as it goes with yum.
Ronald - who is interested to hear about the way to go.
A few things, as I don’t have time to review this directly.
- Generally a “fact” module isn’t also a module that makes changes - a module should be something like oracle_db or oracle_user, etc. If it’s installing oracle, that feels like a role to me, and maybe it even packages an expect script, who knows.
I’m not sure what you mean about having to deal with copy shell/command, but I think this is probably better dealt with by keeping things a role for install purposes.
Hi Michael,
if you look at yum, it gets binaries and installs them, with a very simple recipe. That is the way I would like to install Oracle. Specify what type of software, the version, the edition and possibly the options that should be installed, in which location and who owns it. The steps that should be taken are very similar to those steps yum takes. It transfers the binaries to the host, unpacks and installs it.
Now this is written in roles and although they show a tremendous lot of power, the configuration is much more complex than that of yum. The way I see it, there is no need to have it that complex, just because it is Oracle. It is the size that is a bit larger than that of most yum packages. The software installation succeeds or fails. Maybe, because of the size, transferring to the staging area could be separated so it there is a network hick-up, the next steps can continue from the staging instead of having to copy it all to the staging again,
What I meant with handling the copy/shell/command things was: if we write a module that installs the Oracle software like yum installs it’s packages, there are actions to be coded that are already coded in the copy/shell and command modules. Can such work be re-used in a new module or should each module be self-supporting and copy all that code?
“if you look at yum, it gets binaries and installs them, with a very simple recipe.”
I’m aware of what yum is but I’m unclear on what “recipe” means here.
I gather you are trying to build a module to automatically install Oracle, where that feels like it should be a role to me.
Oracle is not a simple package, so letting this be managed by a role - downloading a tarball, working through an installer if needed, etc, is ok and makes sense.
Modules make sense when there are package managers to rely on, but it seems like this is a collection of using other ansible modules to me, maybe with a “script” directive.
Roles are not more complex than modules, they are less complex to work on, actually, so this should be a fine route to go.
As an example https://galaxy.ansible.com/list#/roles/628, my role to
install Oracle's java on ubuntu/debian.
It has similar requirements, though lot simpler than the DB install.