A CLI tool and library for interacting with Thoth
Project description
A CLI tool and library for communicating with Thoth backend.
Using Thamos as a CLI tool
Thamos is released on PyPI. See installation instructions bellow to setup Thoth/Thamos for your repository:
# Install Thamos CLI tool:
$ pip3 install thamos # keep in mind: requires Python 3.6+!!
# Go to repository that should be managed by Thoth which already has Pipfile present:
$ cd ~/git/repo/
# Setup Thamos configuration:
$ thamos config
# Ask Thoth for software stack recommendations:
$ thamos advise
# Retrieve logs of the last analysis:
$ thamos logAs Thamos notes analysis ids for better UX of thamos log, it’s recommended to add .thoth_last_analysis_id file to .gitignore.
Adjusting configuration based on environment variables
You can adjust content of configuration file each time Thamos CLI or Thamos library loads it by expanding entries with environment variables. This can be handy if you would like to parameterize some of the options at runtime (e.g. in deployment).
This behaviour is (due to security reasons) explicitly turned off by default. However you can turn it on by setting THAMOS_CONFIG_EXPAND_ENV environment variable to 1 (0 explicitly turns this behaviour off, default value):
THOTH_HOST=test.thoth-station.ninja THAMOS_CONFIG_EXPAND_ENV=1 thamos advise
2019-03-13 11:22:59,562 [18639] INFO thamos.config: Expanding configuration file based on environment variablesEntries which should be expanded have environment variables in curly braces like the following example:
host: {THOTH_HOST}Note the expansion is done by replacing these values directly with values of environment variable, this means types need to be taken into account (environment variable with value "true" is put into configuration file as true).
Using custom configuration file template
You can use your own custom configuration file as a template. This is especially useful if you want to have some configuration entries constant and let expand only some of the configuration options. In other words, you can parametrize configuration file.
An example of configuration file template can be:
host: {THOTH_SERVICE_HOST}
tls_verify: true
requirements_format: {requirements_format}
runtime_environments:
- name: '{os_name}:{os_version}'
operating_system:
name: {os_name}
version: '{os_version}'
hardware:
cpu_family: {cpu_family}
cpu_model: {cpu_model}
python_version: '{python_version}'
cuda_version: {cuda_version}
recommendation_type: stable
limit_latest_versions: null
platform: '{platform}'Then, you need to supply this configuration file to the following command:
thamos config --template template.yamlListing of automatically expanded configuration options which are supplied the config sub-command (these options are optional and will be expanded based on HW or SW discovery):
Configuration option |
Explanation |
Example |
|---|---|---|
os_name |
name of operating system |
fedora |
os_version |
version of operating system |
30 |
cpu_family |
CPU family identifier |
6 |
cpu_model |
CPU model identifier |
94 |
python_version |
Python version (major.minor) |
3.6 |
cuda_version |
CUDA version (major.minor) |
9.0 |
platform |
Platform used. |
linux-x86_64 |
requirements_format |
Requirements format. |
pipenv |
Platform corresponds to sysconfig.get_platform() call.
These configuration options are optional and can be mixed with adjustment based on environment variables (see THOTH_SERVICE_HOST example above). Note the environment variables are not expanded on thamos config call but rather on other sub-commands issued (e.g. thamos advise or others).
The output format coming out of recommendations can be compatible with Pipenv, raw pip or similar to the one provided by pip-tools (actually same as for pip as these formats are interchangeable). The format is configured using requirements_format configuration option, available options are:
Using Thoth and thamos in OpenShift’s s2i
Using configuration templates is especially useful for OpenShift builds where you can specify your template in an s2i repository (omit Pipfile.lock to enable call to thamos advise as shown in this repository).
Then, you need to provide following environment variables:
THAMOS_CONFIG_TEMPLATE - holds path to template - use /tmp/src prefix to point to root of s2i repository (e.g. /tmp/src/template.yaml if template.yaml is the configuration template and is stored in root of your Git repository).
THAMOS_NO_INTERACTIVE - set to 1 if you don’t want to omit interactive thamos (suitable for automated s2i builds happening in the cluster).
THAMOS_NO_PROGRESSBAR - set to 1 to disable progressbar while waiting for response from Thoth backend - it can cause annoying too verbose output printed to OpenShift console during the build.
THAMOS_CONFIG_EXPAND_ENV - set to 1 to enable expansion based on environment variables when generating .thoth.yaml file - this needs to be explicitly turned on due to possible security implications.
THAMOS_FORCE - set to 1 not use cached results, always force analysis on Thoth’s side (note this option can be ignored by a Thoth operator based on deployment configuration).
THAMOS_VERBOSE - set to 1 to run thamos in verbose mode to show what’s going on (verbosity on client side).
THAMOS_DEBUG - set to 1 to run analyzes (adviser, provenance checker, …) on Thoth’s backend side in debug mode, you can obtain logs by running thamos logs or directly on Thoth’s user API; the analysis id gets printed into the console during the build process in OpenShift (verbosity on server side).
THAMOS_DEV - set to 1 to consider also development dependencies, this flag defaults to 0 - by enabling development dependencies, adviser will need to browse larger space of software stacks possibly ending with a worse software stack advised (development dependencies are usually not used during application deployment)
THAMOS_DISABLE_CUDA - set to 1 to disable CUDA detection
THAMOS_NO_EMOJI - set to 1 to disable UTF-8 emojis (useful for dummy terminals)
THAMOS_RETRY_ON_ERROR_COUNT - number of retries performed if the API server is responding with an error HTTP status (defaults to 3), this option is not usually needed to be adjusted
THAMOS_RETRY_ON_ERROR_SLEEP - sleep time when an error on the API server is spotted (see THAMOS_RETRY_ON_ERROR_COUNT), defaults to 3 seconds
THAMOS_NO_PROGRESSBAR - disable progress bar visualization, useful for dummy terminals
THAMOS_TIMEOUT - timeout period in seconds after which Thamos stops trying to fetch results
THAMOS_DISABLE_LAST_ANALYSIS_ID_FILE - set to 1 if you do not want to create a file that states last analysis id (used not to memorize the last analysis id across commands)
THAMOS_REQUIREMENTS_FORMAT - style of requirements used for managing dependencies - one of pip, pip-tools, pipenv, defaults to pipenv if not specified
See OpenShift s2i documentation on how to pin build to a specific node in the cluster. This is needed if you would like to perform automatic hardware discovery to get optimized stacks on your hardware.
Using Thamos as a library
from thamos.lib import image_analysis
from thamos.config import config
# Set global context.
# Host to Thoth's User API. API discovery will be done
# transparently and the most appropriate API version will be used.
config.explicit_host = "thoth-user-api.redhat.com"
# TLS verification when communicating with Thoth API.
config.tls_verify = True
image_analysis(
image="registry.redhat.com/fedora:29",
registry_user="fridex",
registry_password="secret!",
# TLS verification when communicating with registry.
verify_tls=True,
nowait=False
)Autogenerated client from OpenAPI
Most parts of Thamos consist of automatic generated code. You can update Thamos by running the following command:
$ ./swagger-codegen.shThe command above will download and run automatic code generation tool against the most recent OpenAPI specification of User API. Results of the tool are automatically placed into this repository in thamos/swagger_client/ and Documentation/. They consist of automatically generated code as well as documentation on how to use the code. Thamos itself provides routines built on top of this automated generated code to simplify usage in thamos/lib.
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
File details
Details for the file thamos-0.10.2.tar.gz.
File metadata
- Download URL: thamos-0.10.2.tar.gz
- Upload date:
- Size: 60.2 kB
- Tags: Source
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/1.13.0 pkginfo/1.5.0.1 requests/2.22.0 setuptools/36.5.0 requests-toolbelt/0.9.1 tqdm/4.32.2 CPython/3.6.9
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 | fcd3f97050bf3e12ee22c8c425e53ec6f9bf76a2267a7eff12059f834f3dc6a0 |
|
| MD5 | a40c0e5c0e046df645ed9e7c8361b597 |
|
| BLAKE2b-256 | 1cdbde15b5909e1f4017e5a5a700b75915b3d79f809dfae35e537abc3222c79f |
File details
Details for the file thamos-0.10.2-py3-none-any.whl.
File metadata
- Download URL: thamos-0.10.2-py3-none-any.whl
- Upload date:
- Size: 132.6 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/1.13.0 pkginfo/1.5.0.1 requests/2.22.0 setuptools/36.5.0 requests-toolbelt/0.9.1 tqdm/4.32.2 CPython/3.6.9
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 | 2195f73095f29270f3697a784b2a5d3da039a74b5b458d768303a69df2658c80 |
|
| MD5 | f1026fd54ca380b3ff858331e2a1488d |
|
| BLAKE2b-256 | 8e76f5e2f16820b890103dfe0a257d3146265dff53489d26d1b6c3a133e87763 |
