openinfra
/
refstack
Code Issues Proposed changes
refstack/tools/update-rs-db.rst

3.0 KiB
Raw Blame History

# update-rs-db.py #

This document contains some details that are necessary to know to be successful in the usage of the script update-rs-db.py.

The script can be run using the following formatting: "./update-rs-db.py --file /tmp/datasource.csv --endpoint http://example.com:8000/v1 --tokenfile <token file path>". In order to successfully update and verify results, you will need admin rights for the refstack server in question. Instructions on how to get these for your local install can be found at https://opendev.org/osf/refstack/src/master/doc/source/refstack.rst#optional-configure-foundation-organization-and-group

This script updates RefStack tests as verified given a specific spreadsheet. The columns in this spreadsheet are, in this order:

  • Company Name
  • Product Name
  • Type (Distribution, Public, or Private)
  • Region
  • Guideline
  • Component (Compute, Platform, or Object)
  • Reported Release
  • Passed Release
  • Federated identity (yes/no)
  • Refstack Link
  • Zendesk Link
  • Marketplace Link
  • License Date
  • Update Product (yes/no)
  • Contacts
  • Notes
  • License Link
  • Active (1 or 0)
  • Public (1 or 0)

The data is pulled from a csv file. The default csv name is toadd.csv, but using the -f flag, we can use csv of a different filename.

The refstack database that we are pushing updates to is set via the "-e", or "--endpoint flag. This flag specifies the refstack api endpoint to be used to update the database. This is a required flag.

Because editing arbitrary test results requires administrative privileges, an auth token must be used with the RefStack API. This token can be generated by entering the command "jwt --key="$( cat <path to private key> )" --alg=RS256 user_openid=<openstackid> exp=+100500". This generates a json web token, which we must link using the "--tokenfile" flag. Because we cannot auth without this token, the token is a required flag.

The script will go through each line of the CSV, grabbing the refstack link, the guideline, and the component. It also uses the refstack result to get a test result Id.

It then uses that test ID to update the internal db using refstack's built in RESTful api.

Lastly, if at least one of the links has proven to be valid, we will then use the same RESTful api and test ID to update the verification_status field associated with that test result.

The status of each of these steps will be output to "verification_status.csv" by default. A '1' will denote that the resource was successfully updated while a '0' will denote that the resource was not successfully updated. The order of fields of this file are as follows:

  • Date modified
  • API link
  • Shared update status
  • Guideline
  • Guideline update success status
  • Target
  • Target update success status
  • Verification update success status