
Incorporated feedback from reviews Added steps to the action commands document Added renderedconfigdocs resource for rendered representations of documents Updated POST configdocs to be collection based Added append and force parameter behaviors for POST configdocs Updated verbiage for the document staging API to be collection based Update GET behaviors for configdocs to clarify when collections are removed vs. not represented. Remove the secrets API, as it will be handled by the configdocs change to have document versions referenced by verion=rollback|staged instead of lastDeployed=true|false. Updated to make clearer when documents move from staged to rollback reformatted for 80 cols removed extraneous trailing whitespace Change-Id: I59ceb8643d7da5ef335b746ea98053a8338207be
2.6 KiB
Action API supported commands
Supported actions
These actions are currently supported using the Action API
None at this time.
Actions under development
These actions are under active development
-
deploy_site
Triggers the initial deployment of a site, using the latest committed configuration documents. Steps:- Concurrency check - to prevent concurrent site modifications by conflicting actions/workflows.
- Preflight checks - ensures all UCP components are in a responsive state.
- Get design version - uses Deckhand to discover the latest committed version of design for the site.
- Validate design - asks each involved UCP component to validate the design. This ensures that the design, which was previously committed is valid at the present time.
- Drydock build - orchestrates the Drydock component to configure hardware and the Kubernetes environment (Drydock -> Promenade)
- Check deployed node status - checks that the deployment of nodes is successful.
- Armada build - orchestrates Armada to configure software on the nodes as designed.
-
update_site
Triggers the initial deployment of a site, using the latest committed configuration documents. Steps: (same as deploy_site) -
redeploy_server
Using parameters to indicate which server(s), triggers a redeployment of server to the last known good design and secrets -
commit_configdocs This signals to shipyard that the documents in the shipyard buffer should be committed to the site as design. Steps:
- Blocks Shipyard from accepting any documents for the duration of the commit_configdocs action to prevent unexpected behavior of the buffer in the case of validation failures.
- Triggers validations by the various UCP components against the documents
in the Shipyard Buffer.
- If all validations pass, tags the revision in Deckhand as a committed version. This will effecively "empty" the Shipyard Buffer.
- If validations fail, the Shipyard Buffer will remain in the state it was before the commit_configdocs started.
Future actions
These actions are anticipated for development
-
test region
Invoke site validation testing - perhaps baseline is a invocation of all components regular "component" tests. This test would be used as a preflight-style test to ensure all components are in a working state. -
test component
Invoke a particular platform component to test it. This test would be used to interrogate a particular platform component to ensure it is in a working state, and that its own downstream dependencies are also operational