Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

What are the URL Endpoints of the Regional Controller?

URLPurpose
https://<RC IP address>/api/v1/This is the base URL for all of the API calls to the Regional Controller.
https://<RC IP address>/docs/This is the address of an online copy of the documentation for the Regional Controller. Note that because this documentation is built along with the codebase, it is likely to be more up to date than this wiki.
http://<RC IP address>:8080/admin/This is the console for the embedded copy of Apache® Airflow that is used as the workflow engine within the Regional Controller.

Where is the full API documented?

As it is still being modified and in a state of flux, the full API is documented only in the online copy under https://<RC IP address>/docs/

Alternately, you can clone the gerrit repository for the Regional Controller, and look at the markup files under /src/site/docs/.

What are the Predefined Users in the Regional Controller database?

The regional controller will be installed with the following pre-defined users.  You are not required to use these usernames and can remove/replace them as you wish; however, the workflow user is used internally to log workflow events, so you would be well advised to leave that user alone.

UsernamePasswordRolesPurpose
adminadmin123create/read/update/delete allThis is the "super user" for RC; e.g. it has all roles and capabilities.
readonlyadmin123read allThis user has read only access; e.g. it can issue GET requests, but cannot change objects or make new objects.
workflowadmin123read all, create podeventsThis user is used internally in order to create POD events from within the workflows.
noaccessadmin123
This user has no access at all.

How are Workflows initiated?

All workflows are started as a result of operations on PODs:

  • POST - creates a  POD and causes the create workflow to run
  • PUT - updates a POD and cause one of several update workflows to run
  • DELETE - deletes the POD and causes the delete workflow to run

The details of the workflow are described in the Blueprint for the POD.

How do I look at the Workflow Logs?

The workflow logs are stored within Airflow.  As such, you need to access them via Airflow.  There are two ways to do this:

  1. Use the Airflow console (see above for the URL).
    1. Click on DAGs
    2. Click on the individual DAG you are interested in.  The name should contain both the workflow name and the UUID of the associated POD.
    3. Click on Graph View
    4. Click on the box for maintask
    5. In the popup sub-window, click on View Log
  2. Look at the logfile directly by following these steps:
    1. Login to the host where the regional controller is running
    2. Search within the arc-airflow-worker container for the log, and then cat it.
    3. $ UUID=<UUID of the POD>
$ docker exec arc-airflow-worker find /usr/local/airflow/logs -type f | grep $UUID/maintask

How can I determine the current state of a POD?

The current state of any POD can be determined by using the rc_cli command to look at the current POD state.  For example:

$ ./rc_cli -H rc -p admin123 pod show 18c3e63e-8847-4d97-a172-3a48b0ffa069 
---
blueprint: 690450c0-776a-11e9-ae9b-f3cee2e49e42
description: CD of blueprint on OE
edgesite: 60ab1298-7769-11e9-92b3-373d9b2f2476
events:
- level: INFO
  message: Pod created.
  time: '2019-06-12 16:56:22.0'
- level: INFO
  message: 'Starting workflow: create'
  time: '2019-06-12 16:56:22.0'
- level: INFO
  message: 'Workflow directory created: $DROOT/workflow/create-0-18c3e63e-8847-4d97-a172-3a48b0ffa069'
  time: '2019-06-12 16:56:22.0'
- level: INFO
  message: 'Workflow fetched: http://www.example.org/blueprints/work-flow-v0.1.sh'
  time: '2019-06-12 16:56:22.0'
- level: INFO
  message: Workflow template created.
  time: '2019-06-12 16:56:22.0'
- level: INFO
  message: Starting create workflow for POD 18c3e63e-8847-4d97-a172-3a48b0ffa069
  time: '2019-06-12 17:00:18.0'
name: pod_on_oe1
state: WORKFLOW
url: /api/v1/pod/18c3e63e-8847-4d97-a172-3a48b0ffa069
uuid: 18c3e63e-8847-4d97-a172-3a48b0ffa069
workflows:
- create
yaml:
  input_yaml: http://www.example.org/mtlab/aknode201-user_config.yaml
  iso_primary: http://www.example.org/iso/latest/install.iso
  iso_secondary: http://www.example.org/iso/latest/bootcd.iso

The status filed in the output shows the current status of the POD; WORKFLOW means that a workflow is currently running, and ACTIVE means the POD is active with no current workflow.

  • No labels