Skip to content

Latest commit

 

History

History
302 lines (210 loc) · 8.43 KB

development.adoc

File metadata and controls

302 lines (210 loc) · 8.43 KB

1. How to develop in ansible-oracle?

Important
This is an example how most of the development in ansible-oracle is done.
A Pull-Request is only accepted, when github-Actions are valid.

1.1. Prepare a development environment

Important
This chapter shows, how the development envionment could look like.
You need an Ansible-Controller with an Editor or IDE of your own choice.

1.2. Create Fork on github and contribute to the project

github has some great documentation with details about creating a fork and branch to contribute to ansible-oracle.

Important
The github-Actions will automatically start, when the branchname starts with pr or in each Pull-Request.
Please use a branch with 'pr'--prefix, when ansible-lint should be checked for each commit.

1.3. pre-commit

Important
pre-commit is a nice tool for git.
Each commit is locally checked against multiple rules, to prevent failures in github-Actions after pushing commits to github.
This tool is recommended but not mandatory for contributing to ansible-oracle.
Installation (cd into repository before)
pip install --user pre-commit
pre-commit install
run outside git
pre-commit run

1.4. Ansible Navigator

Important
python3 should point to Python >=3.9, otherwise ansible-navigator and ansible-lint could not be used.
The activate script is used to change the Python environment in current shell.
configure venv for ansible-oracle
python3.10 -V

Python 3.10.6

python3.10 -m venv ~/venv/ansible-oracle
install Python modules
. ~/venv/ansible-oracle/bin/activate
pip --require-virtualenv -v install -r requirements_dev.txt
Start ansible-navigator
. ~/venv/ansible-oracle/bin/activate
ansible-navigator --version

ansible-navigator 3.3.0

1.5. Using ansible-doctor

Important
ansible-doctor has module dpendencies with conflicts between ansible-lint. We have to use a dedicated venv for `ansible-doctor'
configure venv for ansible-oracle
python3 -m venv ~/venv/ansible-doctor
install Python modules
. ~/venv/ansible-doctor/bin/activate
pip --require-virtualenv -v install -r requirements_doctor.txt
Start ansible-doctor
~/venv/ansible-doctor/bin/ansible-doctor --version

ansible-doctor 2.0.4
Important
Do not forget to place change files in stage area of git before starting pre-commit.
pre-commit works only on the data of the stage area!
pre-commit could be executed without an active venv.
Start ansible-doctor with pre-commit
pre-commit run ansible-doctor
Start ansible-doctor to create new README.md file
cd ansible-oracle
~/venv/ansible-doctor/bin/ansible-doctor -f -r roles

1.6. Start Ansible-Container

1.7. Start Playbook

Important
Don’t forget to set the working branch in requirements.yml.
Remove/Disable devsec.hardening for faster installation of Ansible collection, when devsec should not be tested.
Edit requirements.yml
---
collections:
  # - name: devsec.hardening
  #   version: 8.2.0
  - name: https://github.com/Rendanic/ansible-oracle.git
    type: git
    version: devbranch
Execute ansible-playbook
ansible-galaxy collection install --force -r requirements.yml && ansible-playbook -i inventory/hasfd -e hostgroup='all' playbooks/single-instance-asm.yml --limit '*19c*'

2. Pull-Requests

2.1. Important Information

The ansible-oracle project introduced antsibull-changelog for managing the CHANGELOG.rst based on fragments in changelogs/fragments.

The ID should point to the PR and the filename describe the PR in short form. The fragments are part of the PR. If multiple PRs are open, the upper rule makes sure that no duplicate files are created during merge.

Important
Each Pull-Requests needs a fragment from Release 3.0.0 onwards!

3. Create new Releases in ansible-oracle

Important
This is only needed for creating new Releases in ansible-oracle - not for development!

3.1. Install antsibull-changelog

cd ansible-oracle/docker
docker-compose run --rm -w /git/ansible-oracle/example/beginner/ansible ansible bash

pip3 install antsibull-changelog

3.3. Creating new releases

antsibull-changelog release reads galaxy.yml to get the release version automatically. The execution is aborted, when a release with the version is existing in CHANGELOG.rst.

Note
The whole release process should be done with a dedicated Pull-Request.
antsibull-changelog release

4. Update Vagrantbox on vagrantcloud for examples

Important
This is only an example how to do it, when custom images should be used.

4.1. Create new Box

git clone https://github.com/Rendanic/bento.git
cd bento
git checkout oc
cd packer_templates/oraclelinux/
./oc_oracle-7.x_vbox.sh oracle-7.9-x86_64.json

4.2. Upload new Version

Important
Change the boxname to an account with write priviledges.
Upload new version after build:
boxname="Rendanic/oraclelinux-7.x"
vagrantversion=$(date +%y%m%d)

vagrant cloud version create ${boxname} "$vagrantversion"
vagrant cloud provider create ${boxname} virtualbox "$vagrantversion"
vagrant cloud provider upload ${boxname} virtualbox "$vagrantversion" ../../builds/oracle-7.9.virtualbox.box
vagrant cloud publish --release ${boxname} "$vagrantversion" virtualbox

5. ansible molecule

Warning
The timeout for pulling docker Container in molecule is 15s at the moment.
There is no parameter to increase the timeout. Pull container manually before starting the szenario. The image url is defined in molecule.yml.

The following szenarios are existing in the `ansible-oracle profect.

Stage Description

dbfs

Full stage for installation of RDBMS 19c + Patching and create database. Requires installation media in /vagrant on local host.

dbfs-ol9

Full stage for installation of RDBMS 19c + Patching on OL9 and create database. Requires installation media in /vagrant on local host.

default

Stage for testing common and orahost roles with different Distributions.

download

Download Patches from support.oracle.com for dbfs stage.

golden

Create Golden-Image for installation from dbfs.

5.1. Test OS roles

Important
This szenario is used, when changes at OS roles should be tested against different OS Distribuitions.
Most of the tests are included in the dbfs szenario!

The execution time is ~10m for a full test.

The default szenario requires no parameter -s!

Start download
cd extensions
molecule test

5.2. Download Patches for dbfs stage

Important
Make sure that /vagrant has enough free space for installation media and patches.
set environment variables for support.oracle.com login
export MOS_LOGIN=Username
export MOS_PASSWORD=verySecret
Start download
cd extensions
molecule test -s download

molecule test does the full test of the szenario.

5.3. Test Single Instance in Filesystem with szenario dbfs

Important
Make sure that the installation media and patches are placed in /vagrant before starting molecule.
Use the szenario download for downloading the Patches from support.oracle.com.

The execution time is ~2h for a full test.

Start download
cd extensions
molecule test -s dbfs

5.4. Create Golden-Images from dbfs installation

Important
Make sure that all requirements for scenario dbfs are met.
Executing a full test with molicule test -s golden will destroy an existing installation from molecule converge -s dbfs!
Start Golden-Image creation
cd extensions
molecule test -s golden

5.5. Oracle XE (not used at the moment!)

Important
This chapter was designed for testing the oradb_managed_-Roles.
It is not clear if this will be added or not.
Docker pull Oracle XE

Normal SSO-Login from Oracle is needed for login to docker registry.

docker login container-registry.oracle.com
docker pull container-registry.oracle.com/database/express:21.3.0-xe
Start Oracle Container for test
docker run -d --name oracle-xe \
  -e ORACLE_PWD=Oracle_123 \
  -p 1521:1521 \
  container-registry.oracle.com/database/express:21.3.0-xe