What would you like to be added:
Allow a complete plan to be run at a specific point in another plan.
Why is this needed:
Upgrade processes are often identical to the deploy plan, with the exception of a pre-upgrade step and a post-upgrade step. It would be preferable not to duplicate the deploy plan phases in the upgrade plan.
(I would not expect parameters that trigger the included plan to have any effect on the plan it is included in)
Example:
This is a cut-down code snippet of our operator.yaml that hopefully demonstrates what I mean.
plans:
deploy:
phases:
- name: deploy-init
steps:
- name: deploy-database
tasks:
- database-migrate
strategy: serial
- name: deploy-configs
steps:
- name: deploy-config
tasks:
- apiserver-config
strategy: serial
- name: deploy-apiserver
steps:
- name: deploy-apiserver
tasks:
- apiserver
strategy: serial
- name: deploy-virtualservices
steps:
- name: deploy-virtualservices
tasks:
- virtualservices
strategy: serial
- name: cleanup
steps:
- name: cleanup
tasks:
- database-migrate-cleanup
strategy: serial
strategy: serial
upgrade:
phases:
- name: offline
steps:
- name: offline
tasks:
- take-app-offline
- name: backup
steps:
- name: backup
tasks:
- backup-db
- name: upgrade
includePlan: deploy # upgrade is identical to deploy except that we need to take the application offline, backup the database, and bring the app online afterwards.
- name: online
steps:
- name: online
tasks:
- bring-app-online
What would you like to be added: Allow a complete plan to be run at a specific point in another plan.
Why is this needed: Upgrade processes are often identical to the deploy plan, with the exception of a pre-upgrade step and a post-upgrade step. It would be preferable not to duplicate the deploy plan phases in the upgrade plan.
(I would not expect parameters that trigger the included plan to have any effect on the plan it is included in)
Example: This is a cut-down code snippet of our operator.yaml that hopefully demonstrates what I mean.