shipyard/docs/API_action_commands.md
Bryan Strassner 59fabf8cac Updated the API documentation for shipyard:
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
2017-08-24 09:55:47 -05:00

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:

    1. Concurrency check - to prevent concurrent site modifications by conflicting actions/workflows.
    2. Preflight checks - ensures all UCP components are in a responsive state.
    3. Get design version - uses Deckhand to discover the latest committed version of design for the site.
    4. 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.
    5. Drydock build - orchestrates the Drydock component to configure hardware and the Kubernetes environment (Drydock -> Promenade)
    6. Check deployed node status - checks that the deployment of nodes is successful.
    7. 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:

    1. 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.
    2. 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