PDB - Create Pluggable Database Workflow (Jira, DETAILED, ITIL-ALIGNED)
Spec: Jira issue: target host, container DB, and new PDB name fields
Jira-driven, 3-play structure matching the ServiceNow project's shape. Includes documented risk-mitigation and best-practice controls
|
|
Jira
Process
Decision
SQL/Execute
ITIL Alignment
Risk Mitigation
Best Practice
Close OK
Close Failed
Follow-up
|
| 1 |
PRE-FLIGHT: validate Jira API token via /rest/api/2/myself
|
| 2 |
0: shepherd PDB intake queue toward 'In Progress'
|
| → |
ITIL alignment: the shepherd's To Do → Pending Approval → In Progress walk is itself a real ITIL change-model gate — genuinely cannot proceed unapproved
|
| 3 |
1: search Jira for PDB issues ready to execute
|
| 4 |
1: collect issues found
|
| 5 |
1: intake summary
|
| 6 |
1: exit cleanly when there is nothing to do
|
| 7 |
1: WARN and skip issues with an unusable spec
|
| → |
Risk mitigation: validating host, container, and PDB-name fields before any database work begins prevents a doomed run from ever reaching the Oracle host
|
| 8 |
1: build the PDB creation job list
|
| 9 |
1: nothing valid to process
|
| 10 |
1: jobs queued
|
| 11 |
1: write job list for PLAY 2
|
| 12 |
1: remove stale outcomes file from any previous run
|
| 13 |
2: slurp + decode the job list from the controller
|
| 14 |
2: capture container state, OMF setting and seed datafile path
|
| 15 |
2: fold the pre-check results into each job
|
| 16 |
2: show what the pre-check found
|
| 17 |
3: generate a PDB admin password for each job
|
| → |
Best practice: a fresh generated admin password per job, never touching Ansible logs (no_log)
|
| 18 |
3: create the datafile directory when OMF is not in use
|
| 19 |
3: create, open and save the state of the pluggable database
|
| 20 |
4: capture v$pdbs after the operation
|
| 21 |
4: determine the outcome for each issue
|
| 22 |
4: per-issue outcome
|
| 23 |
5: ensure the log directory exists on controller
|
| 24 |
5: write the evidence log for each issue (admin password intentionally omitted)
|
| → |
Risk mitigation: the evidence log deliberately excludes the admin password — it's disclosed exactly once, in a dedicated Jira comment, never written to a log file
|
| 25 |
5: write outcomes + job data for PLAY 3
|
| 26 |
6: slurp + decode outcomes from PLAY 2
|
| 27 |
6: attach the evidence log to each issue
|
| 28 |
7: post the result comment (admin password goes ONLY here)
|
| 29 |
8: get available transitions for DONE issues
|
| 30 |
8: transition DONE issues to 'Done'
|
| 31 |
8: get available transitions for FAILED issues
|
| 32 |
8: transition FAILED issues to 'Failed'
|
| 33 |
9: create DBA follow-up task for FAILED issues
|
| 34 |
10: final summary
|