Description
This task lists all consequences of the Action rollback proposal, which was introduced in #83.
- Introduce new properties in OCF schema and Local Hub GraphQL API (1SP)
- new Implementation
rollback property - optional
- new TypeInstance properties:
standalone (required) and rollbackActionRef(optional),
- Modify Engine: Upload TypeInstances with
standalone: false
- Create Rollback Custom Resource Definition (1SP)
- Create Rollback-related queries, mutations and types for Engine GraphQL
API (3SP)
type Query {
rollback(name: String!): Rollback
rollbacks(filter: RollbackFilter!): [Rollback!]
}
type Mutation {
createRollback(in: RollbackDetailsInput): Rollback!
runRollback(name: String!): Rollback!
cancelRollback(name: String!): Rollback!
updateRollback(in: RollbackDetailsInput!): Rollback!
deleteRollback(name: String!): Rollback!
}
- create separate service, converter, resolver
- Implement rollback handling logic in Engine (8SP)
- After implementation, as a follow-up task: Prepare rollback manifests for Hub manifests (5SP)
- Support rollback Action for Helm runner
- Support Terraform runner
- Insert URL to source files in TypeInstance to be able to do rollback
- Support rollback for CloudSQL, AWS RDS, Bitnami PostgreSQL
create.db and Mattermost, RocketChat, MongoDB Implementations
Additional scope
What about the data that is created by the given runner, when and how this will be deleted? For example, ArgoWorkflow CR created during install/upgrade. Now it is connected with the Action CR, so the Rollback CR controller should remove the Action CR from the creation phase? Also, when the Rollback CR will be removed? Are we going to keep them with some retention policy as helm does with history?
Reason
Capact makes it easy to execute arbitrary Actions in a form of Argo workflows, which can modify cluster state, run
external workloads and output TypeInstances. However, a User should be able to rollback any run Action. For example, to have a complete application lifecycle implemented using Workflow, there should be an ability to uninstall or downgrade the app.
Rollback feature will be required for:
- Application uninstallation
- Application downgrade
- cancelling Action (rollback to previous state)
- retrying Action (rollback to previous state + run the same Action)
Description
This task lists all consequences of the Action rollback proposal, which was introduced in #83.
rollbackproperty - optionalstandalone(required) androllbackActionRef(optional),standalone: falseAPI (3SP)
- Insert URL to source files in TypeInstance to be able to do rollback
create.dband Mattermost, RocketChat, MongoDB ImplementationsAdditional scope
Reason
Capact makes it easy to execute arbitrary Actions in a form of Argo workflows, which can modify cluster state, run
external workloads and output TypeInstances. However, a User should be able to rollback any run Action. For example, to have a complete application lifecycle implemented using Workflow, there should be an ability to uninstall or downgrade the app.
Rollback feature will be required for: