mirror of
https://github.com/ClusterCockpit/cc-backend
synced 2024-09-20 03:17:26 +02:00
Transfer docs to dedicated doc webpage
This commit is contained in:
parent
476caebe7f
commit
bcd7f47409
@ -1,93 +0,0 @@
|
|||||||
## Intro
|
|
||||||
|
|
||||||
cc-backend requires a configuration file that specifies the cluster systems to be used.
|
|
||||||
To override the default, specify the location of a json configuration file with the `-config <file path>` command line option.
|
|
||||||
All security-related configurations, e.g. keys and passwords, are set using
|
|
||||||
environment variables.
|
|
||||||
It is supported to set these by means of a `.env` file in the project root.
|
|
||||||
|
|
||||||
## Configuration Options
|
|
||||||
|
|
||||||
* `addr`: Type string. Address where the http (or https) server will listen on (for example: 'localhost:80'). Default `:8080`.
|
|
||||||
* `apiAllowedIPs`: Type string array. Addresses from which the secured API endpoints (/users and other auth related endpoints) can be reached
|
|
||||||
* `user`: Type string. Drop root permissions once .env was read and the port was taken. Only applicable if using privileged port.
|
|
||||||
* `group`: Type string. Drop root permissions once .env was read and the port was taken. Only applicable if using privileged port.
|
|
||||||
* `disable-authentication`: Type bool. Disable authentication (for everything: API, Web-UI, ...). Default `false`.
|
|
||||||
* `embed-static-files`: Type bool. If all files in `web/frontend/public` should be served from within the binary itself (they are embedded) or not. Default `true`.
|
|
||||||
* `static-files`: Type string. Folder where static assets can be found, if `embed-static-files` is `false`. No default.
|
|
||||||
* `db-driver`: Type string. 'sqlite3' or 'mysql' (mysql will work for mariadb as well). Default `sqlite3`.
|
|
||||||
* `db`: Type string. For sqlite3 a filename, for mysql a DSN in this format: https://github.com/go-sql-driver/mysql#dsn-data-source-name (Without query parameters!). Default: `./var/job.db`.
|
|
||||||
* `job-archive`: Type object.
|
|
||||||
- `kind`: Type string. At them moment only file is supported as value.
|
|
||||||
- `path`: Type string. Path to the job-archive. Default: `./var/job-archive`.
|
|
||||||
- `compression`: Type integer. Setup automatic compression for jobs older than number of days.
|
|
||||||
- `retention`: Type object.
|
|
||||||
- `policy`: Type string (required). Retention policy. Possible values none, delete,
|
|
||||||
move.
|
|
||||||
- `includeDB`: Type boolean. Also remove jobs from database.
|
|
||||||
- `age`: Type integer. Act on jobs with startTime older than age (in days).
|
|
||||||
- `location`: Type string. The target directory for retention. Only applicable for retention policy move.
|
|
||||||
* `disable-archive`: Type bool. Keep all metric data in the metric data repositories, do not write to the job-archive. Default `false`.
|
|
||||||
* `validate`: Type bool. Validate all input json documents against json schema.
|
|
||||||
* `session-max-age`: Type string. Specifies for how long a session shall be valid as a string parsable by time.ParseDuration(). If 0 or empty, the session/token does not expire! Default `168h`.
|
|
||||||
* `https-cert-file` and `https-key-file`: Type string. If both those options are not empty, use HTTPS using those certificates.
|
|
||||||
* `redirect-http-to`: Type string. If not the empty string and `addr` does not end in ":80", redirect every request incoming at port 80 to that url.
|
|
||||||
* `machine-state-dir`: Type string. Where to store MachineState files. TODO: Explain in more detail!
|
|
||||||
* `stop-jobs-exceeding-walltime`: Type int. If not zero, automatically mark jobs as stopped running X seconds longer than their walltime. Only applies if walltime is set for job. Default `0`.
|
|
||||||
* `short-running-jobs-duration`: Type int. Do not show running jobs shorter than X seconds. Default `300`.
|
|
||||||
* `jwts`: Type object (required). For JWT Authentication.
|
|
||||||
- `max-age`: Type string (required). Configure how long a token is valid. As string parsable by time.ParseDuration().
|
|
||||||
- `cookieName`: Type string. Cookie that should be checked for a JWT token.
|
|
||||||
- `vaidateUser`: Type boolean. Deny login for users not in database (but defined in JWT). Overwrite roles in JWT with database roles.
|
|
||||||
- `trustedIssuer`: Type string. Issuer that should be accepted when validating external JWTs.
|
|
||||||
- `syncUserOnLogin`: Type boolean. Add non-existent user to DB at login attempt with values provided in JWT.
|
|
||||||
* `ldap`: Type object. For LDAP Authentication and user synchronisation. Default `nil`.
|
|
||||||
- `url`: Type string (required). URL of LDAP directory server.
|
|
||||||
- `user_base`: Type string (required). Base DN of user tree root.
|
|
||||||
- `search_dn`: Type string (required). DN for authenticating LDAP admin account with general read rights.
|
|
||||||
- `user_bind`: Type string (required). Expression used to authenticate users via LDAP bind. Must contain `uid={username}`.
|
|
||||||
- `user_filter`: Type string (required). Filter to extract users for syncing.
|
|
||||||
- `username_attr`: Type string. Attribute with full user name. Defaults to `gecos` if not provided.
|
|
||||||
- `sync_interval`: Type string. Interval used for syncing local user table with LDAP directory. Parsed using time.ParseDuration.
|
|
||||||
- `sync_del_old_users`: Type boolean. Delete obsolete users in database.
|
|
||||||
- `syncUserOnLogin`: Type boolean. Add non-existent user to DB at login attempt if user exists in Ldap directory.
|
|
||||||
* `clusters`: Type array of objects (required)
|
|
||||||
- `name`: Type string. The name of the cluster.
|
|
||||||
- `metricDataRepository`: Type object with properties: `kind` (Type string, can be one of `cc-metric-store`, `influxdb` ), `url` (Type string), `token` (Type string)
|
|
||||||
- `filterRanges` Type object. This option controls the slider ranges for the UI controls of numNodes, duration, and startTime. Example:
|
|
||||||
```
|
|
||||||
"filterRanges": {
|
|
||||||
"numNodes": { "from": 1, "to": 64 },
|
|
||||||
"duration": { "from": 0, "to": 86400 },
|
|
||||||
"startTime": { "from": "2022-01-01T00:00:00Z", "to": null }
|
|
||||||
}
|
|
||||||
```
|
|
||||||
* `ui-defaults`: Type object. Default configuration for ui views. If overwritten, all options must be provided! Most options can be overwritten by the user via the web interface.
|
|
||||||
- `analysis_view_histogramMetrics`: Type string array. Metrics to show as job count histograms in analysis view. Default `["flops_any", "mem_bw", "mem_used"]`.
|
|
||||||
- `analysis_view_scatterPlotMetrics`: Type array of string array. Initial
|
|
||||||
scatter plot configuration in analysis view. Default `[["flops_any", "mem_bw"], ["flops_any", "cpu_load"], ["cpu_load", "mem_bw"]]`.
|
|
||||||
- `job_view_nodestats_selectedMetrics`: Type string array. Initial metrics shown in node statistics table of single job view. Default `["flops_any", "mem_bw", "mem_used"]`.
|
|
||||||
- `job_view_polarPlotMetrics`: Type string array. Metrics shown in polar plot of single job view. Default `["flops_any", "mem_bw", "mem_used", "net_bw", "file_bw"]`.
|
|
||||||
- `job_view_selectedMetrics`: Type string array. Default `["flops_any", "mem_bw", "mem_used"]`.
|
|
||||||
- `plot_general_colorBackground`: Type bool. Color plot background according to job average threshold limits. Default `true`.
|
|
||||||
- `plot_general_colorscheme`: Type string array. Initial color scheme. Default `"#00bfff", "#0000ff", "#ff00ff", "#ff0000", "#ff8000", "#ffff00", "#80ff00"`.
|
|
||||||
- `plot_general_lineWidth`: Type int. Initial linewidth. Default `3`.
|
|
||||||
- `plot_list_jobsPerPage`: Type int. Jobs shown per page in job lists. Default `50`.
|
|
||||||
- `plot_list_selectedMetrics`: Type string array. Initial metric plots shown in jobs lists. Default `"cpu_load", "ipc", "mem_used", "flops_any", "mem_bw"`.
|
|
||||||
- `plot_view_plotsPerRow`: Type int. Number of plots per row in single job view. Default `3`.
|
|
||||||
- `plot_view_showPolarplot`: Type bool. Option to toggle polar plot in single job view. Default `true`.
|
|
||||||
- `plot_view_showRoofline`: Type bool. Option to toggle roofline plot in single job view. Default `true`.
|
|
||||||
- `plot_view_showStatTable`: Type bool. Option to toggle the node statistic table in single job view. Default `true`.
|
|
||||||
- `system_view_selectedMetric`: Type string. Initial metric shown in system view. Default `cpu_load`.
|
|
||||||
|
|
||||||
Some of the `ui-defaults` values can be appended by `:<clustername>` in order to have different settings depending on the current cluster. Those are notably `job_view_nodestats_selectedMetrics`, `job_view_polarPlotMetrics`, `job_view_selectedMetrics` and `plot_list_selectedMetrics`.
|
|
||||||
|
|
||||||
## Environment Variables
|
|
||||||
|
|
||||||
An example env file is found in this directory. Copy it to `.env` in the project root and adapt it for your needs.
|
|
||||||
|
|
||||||
* `JWT_PUBLIC_KEY` and `JWT_PRIVATE_KEY`: Base64 encoded Ed25519 keys used for JSON Web Token (JWT) authentication. You can generate your own keypair using `go run ./cmd/gen-keypair/gen-keypair.go`. More information in [README_TOKENS.md](./README_TOKENS.md).
|
|
||||||
* `SESSION_KEY`: Some random bytes used as secret for cookie-based sessions.
|
|
||||||
* `LDAP_ADMIN_PASSWORD`: The LDAP admin user password (optional).
|
|
||||||
* `CROSS_LOGIN_JWT_HS512_KEY`: Used for token based logins via another authentication service.
|
|
||||||
* `LOGLEVEL`: Can be `err`, `warn`, `info` or `debug` (optional, `warn` by default). Can be used to reduce logging.
|
|
||||||
@ -1,51 +0,0 @@
|
|||||||
## Introduction
|
|
||||||
|
|
||||||
ClusterCockpit uses JSON Web Tokens (JWT) for authorization of its APIs.
|
|
||||||
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.
|
|
||||||
This information can be verified and trusted because it is digitally signed.
|
|
||||||
In ClusterCockpit JWTs are signed using a public/private key pair using ECDSA.
|
|
||||||
Because tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.
|
|
||||||
Expiration of the generated tokens as well as the max. length of a browser session can be configured in the `config.json` file described [here](./README.md).
|
|
||||||
|
|
||||||
The [Ed25519](https://ed25519.cr.yp.to/) algorithm for signatures was used because it is compatible with other tools that require authentication, such as NATS.io, and because these elliptic-curve methods provide simillar security with smaller keys compared to something like RSA. They are sligthly more expensive to validate, but that effect is negligible.
|
|
||||||
|
|
||||||
## JWT Payload
|
|
||||||
|
|
||||||
You may view the payload of a JWT token at [https://jwt.io/#debugger-io](https://jwt.io/#debugger-io).
|
|
||||||
Currently ClusterCockpit sets the following claims:
|
|
||||||
* `iat`: Issued at claim. The “iat” claim is used to identify the the time at which the JWT was issued. This claim can be used to determine the age of the JWT.
|
|
||||||
* `sub`: Subject claim. Identifies the subject of the JWT, in our case this is the username.
|
|
||||||
* `roles`: An array of strings specifying the roles set for the subject.
|
|
||||||
* `exp`: Expiration date of the token (only if explicitly configured)
|
|
||||||
|
|
||||||
It is important to know that JWTs are not encrypted, only signed. This means that outsiders cannot create new JWTs or modify existing ones, but they are able to read out the username.
|
|
||||||
|
|
||||||
## Workflow
|
|
||||||
|
|
||||||
1. Create a new ECDSA Public/private keypair:
|
|
||||||
```
|
|
||||||
$ go build ./cmd/gen-keypair/
|
|
||||||
$ ./gen-keypair
|
|
||||||
```
|
|
||||||
2. Add keypair in your `.env` file. A template can be found in `./configs`.
|
|
||||||
|
|
||||||
When a user logs in via the `/login` page using a browser, a session cookie (secured using the random bytes in the `SESSION_KEY` env. variable you shoud change as well) is used for all requests after the successfull login. The JWTs make it easier to use the APIs of ClusterCockpit using scripts or other external programs. The token is specified n the `Authorization` HTTP header using the [Bearer schema](https://datatracker.ietf.org/doc/html/rfc6750) (there is an example below). Tokens can be issued to users from the configuration view in the Web-UI or the command line. In order to use the token for API endpoints such as `/api/jobs/start_job/`, the user that executes it needs to have the `api` role. Regular users can only perform read-only queries and only look at data connected to jobs they started themselves.
|
|
||||||
|
|
||||||
## cc-metric-store
|
|
||||||
|
|
||||||
The [cc-metric-store](https://github.com/ClusterCockpit/cc-metric-store) also uses JWTs for authentication. As it does not issue new tokens, it does not need to kown the private key. The public key of the keypair that is used to generate the JWTs that grant access to the `cc-metric-store` can be specified in its `config.json`. When configuring the `metricDataRepository` object in the `cluster.json` file, you can put a token issued by ClusterCockpit itself.
|
|
||||||
|
|
||||||
## Setup user and JWT token for REST API authorization
|
|
||||||
|
|
||||||
1. Create user:
|
|
||||||
```
|
|
||||||
$ ./cc-backend --add-user <username>:api:<password> --no-server
|
|
||||||
```
|
|
||||||
2. Issue token for user:
|
|
||||||
```
|
|
||||||
$ ./cc-backend --jwt <username> --no-server
|
|
||||||
```
|
|
||||||
3. Use issued token token on client side:
|
|
||||||
```
|
|
||||||
$ curl -X GET "<API ENDPOINT>" -H "accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer <JWT TOKEN>"
|
|
||||||
```
|
|
||||||
@ -1,38 +0,0 @@
|
|||||||
# Release versions
|
|
||||||
|
|
||||||
Versions are marked according to [semantic versioning] (https://semver.org).
|
|
||||||
Each version embeds the following static assets in the binary:
|
|
||||||
* Web frontend with javascript files and all static assets.
|
|
||||||
* Golang template files for server-side rendering.
|
|
||||||
* JSON schema files for validation.
|
|
||||||
* Database migration files.
|
|
||||||
|
|
||||||
The remaining external assets are:
|
|
||||||
* The SQL database used.
|
|
||||||
* The job archive
|
|
||||||
* The configuration files `config.json` and `.env`.
|
|
||||||
|
|
||||||
The external assets are versioned with integer IDs.
|
|
||||||
This means that each release binary is bound to specific versions of the SQL
|
|
||||||
database and the job archive.
|
|
||||||
The configuration file is checked against the current schema at startup.
|
|
||||||
The `-migrate-db` command line switch can be used to upgrade the SQL database
|
|
||||||
to migrate from a previous version to the latest one.
|
|
||||||
We offer a separate tool `archive-migration` to migrate an existing job archive
|
|
||||||
archive from the previous to the latest version.
|
|
||||||
|
|
||||||
# Versioning of APIs
|
|
||||||
|
|
||||||
cc-backend provides two API backends:
|
|
||||||
* A REST API for querying jobs.
|
|
||||||
* A GraphQL API for data exchange between web frontend and cc-backend.
|
|
||||||
|
|
||||||
The REST API will also be versioned. We still have to decide whether we will also
|
|
||||||
support older REST API versions by versioning the endpoint URLs.
|
|
||||||
The GraphQL API is for internal use and will not be versioned.
|
|
||||||
|
|
||||||
# How to build
|
|
||||||
|
|
||||||
In general it is recommended to use the provided release binary.
|
|
||||||
In case you want to build build `cc-backend` please always use the provided makefile. This will ensure
|
|
||||||
that the frontend is also built correctly and that the version in the binary is encoded in the binary.
|
|
||||||
234
docs/Hands-on.md
234
docs/Hands-on.md
@ -1,234 +0,0 @@
|
|||||||
# Hands-on setup ClusterCockpit from scratch (w/o docker)
|
|
||||||
|
|
||||||
## Prerequisites
|
|
||||||
* perl
|
|
||||||
* go
|
|
||||||
* npm
|
|
||||||
* Optional: curl
|
|
||||||
* Script migrateTimestamp.pl
|
|
||||||
|
|
||||||
## Documentation
|
|
||||||
You find READMEs or api docs in
|
|
||||||
* ./cc-backend/configs
|
|
||||||
* ./cc-backend/init
|
|
||||||
* ./cc-backend/api
|
|
||||||
|
|
||||||
## ClusterCockpit configuration files
|
|
||||||
### cc-backend
|
|
||||||
* `./.env` Passwords and Tokens set in the environment
|
|
||||||
* `./config.json` Configuration options for cc-backend
|
|
||||||
|
|
||||||
### cc-metric-store
|
|
||||||
* `./config.json` Optional to overwrite configuration options
|
|
||||||
|
|
||||||
### cc-metric-collector
|
|
||||||
Not yet included in the hands-on setup.
|
|
||||||
|
|
||||||
## Setup Components
|
|
||||||
Start by creating a base folder for all of the following steps.
|
|
||||||
* `mkdir clustercockpit`
|
|
||||||
* `cd clustercockpit`
|
|
||||||
|
|
||||||
### Setup cc-backend
|
|
||||||
* Clone Repository
|
|
||||||
- `git clone https://github.com/ClusterCockpit/cc-backend.git`
|
|
||||||
- `cd cc-backend`
|
|
||||||
* Build
|
|
||||||
- `make`
|
|
||||||
* Activate & configure environment for cc-backend
|
|
||||||
- `cp configs/env-template.txt .env`
|
|
||||||
- Optional: Have a look via `vim .env`
|
|
||||||
- Copy the `config.json` file included in this tarball into the root directory of cc-backend: `cp ../../config.json ./`
|
|
||||||
* Back to toplevel `clustercockpit`
|
|
||||||
- `cd ..`
|
|
||||||
* Prepare Datafolder and Database file
|
|
||||||
- `mkdir var`
|
|
||||||
- `./cc-backend -migrate-db`
|
|
||||||
|
|
||||||
### Setup cc-metric-store
|
|
||||||
* Clone Repository
|
|
||||||
- `git clone https://github.com/ClusterCockpit/cc-metric-store.git`
|
|
||||||
- `cd cc-metric-store`
|
|
||||||
* Build Go Executable
|
|
||||||
- `go get`
|
|
||||||
- `go build`
|
|
||||||
* Prepare Datafolders
|
|
||||||
- `mkdir -p var/checkpoints`
|
|
||||||
- `mkdir -p var/archive`
|
|
||||||
* Update Config
|
|
||||||
- `vim config.json`
|
|
||||||
- Exchange existing setting in `metrics` with the following:
|
|
||||||
```
|
|
||||||
"clock": { "frequency": 60, "aggregation": null },
|
|
||||||
"cpi": { "frequency": 60, "aggregation": null },
|
|
||||||
"cpu_load": { "frequency": 60, "aggregation": null },
|
|
||||||
"flops_any": { "frequency": 60, "aggregation": null },
|
|
||||||
"flops_dp": { "frequency": 60, "aggregation": null },
|
|
||||||
"flops_sp": { "frequency": 60, "aggregation": null },
|
|
||||||
"ib_bw": { "frequency": 60, "aggregation": null },
|
|
||||||
"lustre_bw": { "frequency": 60, "aggregation": null },
|
|
||||||
"mem_bw": { "frequency": 60, "aggregation": null },
|
|
||||||
"mem_used": { "frequency": 60, "aggregation": null },
|
|
||||||
"rapl_power": { "frequency": 60, "aggregation": null }
|
|
||||||
```
|
|
||||||
* Back to toplevel `clustercockpit`
|
|
||||||
- `cd ..`
|
|
||||||
|
|
||||||
### Setup Demo Data
|
|
||||||
* `mkdir source-data`
|
|
||||||
* `cd source-data`
|
|
||||||
* Download JobArchive-Source:
|
|
||||||
- `wget https://hpc-mover.rrze.uni-erlangen.de/HPC-Data/0x7b58aefb/eig7ahyo6fo2bais0ephuf2aitohv1ai/job-archive-dev.tar.xz`
|
|
||||||
- `tar xJf job-archive-dev.tar.xz`
|
|
||||||
- `mv ./job-archive ./job-archive-source`
|
|
||||||
- `rm ./job-archive-dev.tar.xz`
|
|
||||||
* Download CC-Metric-Store Checkpoints:
|
|
||||||
- `mkdir -p cc-metric-store-source/checkpoints`
|
|
||||||
- `cd cc-metric-store-source/checkpoints`
|
|
||||||
- `wget https://hpc-mover.rrze.uni-erlangen.de/HPC-Data/0x7b58aefb/eig7ahyo6fo2bais0ephuf2aitohv1ai/cc-metric-store-checkpoints.tar.xz`
|
|
||||||
- `tar xf cc-metric-store-checkpoints.tar.xz`
|
|
||||||
- `rm cc-metric-store-checkpoints.tar.xz`
|
|
||||||
* Back to `source-data`
|
|
||||||
- `cd ../..`
|
|
||||||
* Run timestamp migration script. This may take tens of minutes!
|
|
||||||
- `cp ../migrateTimestamps.pl .`
|
|
||||||
- `./migrateTimestamps.pl`
|
|
||||||
- Expected output:
|
|
||||||
```
|
|
||||||
Starting to update start- and stoptimes in job-archive for emmy
|
|
||||||
Starting to update start- and stoptimes in job-archive for woody
|
|
||||||
Done for job-archive
|
|
||||||
Starting to update checkpoint filenames and data starttimes for emmy
|
|
||||||
Starting to update checkpoint filenames and data starttimes for woody
|
|
||||||
Done for checkpoints
|
|
||||||
```
|
|
||||||
* Copy `cluster.json` files from source to migrated folders
|
|
||||||
- `cp source-data/job-archive-source/emmy/cluster.json cc-backend/var/job-archive/emmy/`
|
|
||||||
- `cp source-data/job-archive-source/woody/cluster.json cc-backend/var/job-archive/woody/`
|
|
||||||
* Initialize Job-Archive in SQLite3 job.db and add demo user
|
|
||||||
- `cd cc-backend`
|
|
||||||
- `./cc-backend -init-db -add-user demo:admin:demo`
|
|
||||||
- Expected output:
|
|
||||||
```
|
|
||||||
<6>[INFO] new user "demo" created (roles: ["admin"], auth-source: 0)
|
|
||||||
<6>[INFO] Building job table...
|
|
||||||
<6>[INFO] A total of 3936 jobs have been registered in 1.791 seconds.
|
|
||||||
```
|
|
||||||
* Back to toplevel `clustercockpit`
|
|
||||||
- `cd ..`
|
|
||||||
|
|
||||||
### Startup both Apps
|
|
||||||
* In cc-backend root: `$./cc-backend -server -dev`
|
|
||||||
- Starts Clustercockpit at `http:localhost:8080`
|
|
||||||
- Log: `<6>[INFO] HTTP server listening at :8080...`
|
|
||||||
- Use local internet browser to access interface
|
|
||||||
- You should see and be able to browse finished Jobs
|
|
||||||
- Metadata is read from SQLite3 database
|
|
||||||
- Metricdata is read from job-archive/JSON-Files
|
|
||||||
- Create User in settings (top-right corner)
|
|
||||||
- Name `apiuser`
|
|
||||||
- Username `apiuser`
|
|
||||||
- Role `API`
|
|
||||||
- Submit & Refresh Page
|
|
||||||
- Create JTW for `apiuser`
|
|
||||||
- In Userlist, press `Gen. JTW` for `apiuser`
|
|
||||||
- Save JWT for later use
|
|
||||||
* In cc-metric-store root: `$./cc-metric-store`
|
|
||||||
- Start the cc-metric-store on `http:localhost:8081`, Log:
|
|
||||||
```
|
|
||||||
2022/07/15 17:17:42 Loading checkpoints newer than 2022-07-13T17:17:42+02:00
|
|
||||||
2022/07/15 17:17:45 Checkpoints loaded (5621 files, 319 MB, that took 3.034652s)
|
|
||||||
2022/07/15 17:17:45 API http endpoint listening on '0.0.0.0:8081'
|
|
||||||
```
|
|
||||||
- Does *not* have a graphical interface
|
|
||||||
- Otpional: Test function by executing:
|
|
||||||
```
|
|
||||||
$ curl -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJFZERTQSJ9.eyJ1c2VyIjoiYWRtaW4iLCJyb2xlcyI6WyJST0xFX0FETUlOIiwiUk9MRV9BTkFMWVNUIiwiUk9MRV9VU0VSIl19.d-3_3FZTsadPjDEdsWrrQ7nS0edMAR4zjl-eK7rJU3HziNBfI9PDHDIpJVHTNN5E5SlLGLFXctWyKAkwhXL-Dw" -D - "http://localhost:8081/api/query" -d "{ \"cluster\": \"emmy\", \"from\": $(expr $(date +%s) - 60), \"to\": $(date +%s), \"queries\": [{
|
|
||||||
\"metric\": \"flops_any\",
|
|
||||||
\"host\": \"e1111\"
|
|
||||||
}] }"
|
|
||||||
|
|
||||||
HTTP/1.1 200 OK
|
|
||||||
Content-Type: application/json
|
|
||||||
Date: Fri, 15 Jul 2022 13:57:22 GMT
|
|
||||||
Content-Length: 119
|
|
||||||
{"results":[[JSON-DATA-ARRAY]]}
|
|
||||||
```
|
|
||||||
|
|
||||||
### Development API web interfaces
|
|
||||||
The `-dev` flag enables web interfaces to document and test the apis:
|
|
||||||
* http://localhost:8080/playground - A GraphQL playground. To use it you must have a authenticated session in the same browser.
|
|
||||||
* http://localhost:8080/swagger - A Swagger UI. To use it you have to be logged out, so no user session in the same browser. Use the JWT token with role Api generate previously to authenticate via http header.
|
|
||||||
|
|
||||||
### Use cc-backend API to start job
|
|
||||||
* Enter the URL `http://localhost:8080/swagger/index.html` in your browser.
|
|
||||||
* Enter your JWT token you generated for the API user by clicking the green Authorize button in the upper right part of the window.
|
|
||||||
* Click the `/job/start_job` endpoint and click the Try it out button.
|
|
||||||
* Enter the following json into the request body text area and fill in a recent start timestamp by executing `date +%s`.:
|
|
||||||
```
|
|
||||||
{
|
|
||||||
"jobId": 100000,
|
|
||||||
"arrayJobId": 0,
|
|
||||||
"user": "ccdemouser",
|
|
||||||
"subCluster": "main",
|
|
||||||
"cluster": "emmy",
|
|
||||||
"startTime": <date +%s>,
|
|
||||||
"project": "ccdemoproject",
|
|
||||||
"resources": [
|
|
||||||
{"hostname": "e0601"},
|
|
||||||
{"hostname": "e0823"},
|
|
||||||
{"hostname": "e0337"},
|
|
||||||
{"hostname": "e1111"}],
|
|
||||||
"numNodes": 4,
|
|
||||||
"numHwthreads": 80,
|
|
||||||
"walltime": 86400
|
|
||||||
}
|
|
||||||
```
|
|
||||||
* The response body should be the database id of the started job, for example:
|
|
||||||
```
|
|
||||||
{
|
|
||||||
"id": 3937
|
|
||||||
}
|
|
||||||
```
|
|
||||||
* Check in ClusterCockpit
|
|
||||||
- User `ccdemouser` should appear in Users-Tab with one running job
|
|
||||||
- It could take up to 5 Minutes until the Job is displayed with some current data (5 Min Short-Job Filter)
|
|
||||||
- Job then is marked with a green `running` tag
|
|
||||||
- Metricdata displayed is read from cc-metric-store!
|
|
||||||
|
|
||||||
|
|
||||||
### Use cc-backend API to stop job
|
|
||||||
* Enter the URL `http://localhost:8080/swagger/index.html` in your browser.
|
|
||||||
* Enter your JWT token you generated for the API user by clicking the green Authorize button in the upper right part of the window.
|
|
||||||
* Click the `/job/stop_job/{id}` endpoint and click the Try it out button.
|
|
||||||
* Enter the database id at id that was returned by `start_job` and copy the following into the request body. Replace the timestamp with a recent one:
|
|
||||||
```
|
|
||||||
{
|
|
||||||
"cluster": "emmy",
|
|
||||||
"jobState": "completed",
|
|
||||||
"stopTime": <RECENT TS>
|
|
||||||
}
|
|
||||||
```
|
|
||||||
* On success a json document with the job meta data is returned.
|
|
||||||
|
|
||||||
* Check in ClusterCockpit
|
|
||||||
- User `ccdemouser` should appear in Users-Tab with one completed job
|
|
||||||
- Job is no longer marked with a green `running` tag -> Completed!
|
|
||||||
- Metricdata displayed is now read from job-archive!
|
|
||||||
* Check in job-archive
|
|
||||||
- `cd ./cc-backend/var/job-archive/emmy/100/000`
|
|
||||||
- `cd $STARTTIME`
|
|
||||||
- Inspect `meta.json` and `data.json`
|
|
||||||
|
|
||||||
## Helper scripts
|
|
||||||
* In this tarball you can find the perl script `generate_subcluster.pl` that helps to generate the subcluster section for your system.
|
|
||||||
Usage:
|
|
||||||
* Log into an exclusive cluster node.
|
|
||||||
* The LIKWID tools likwid-topology and likwid-bench must be in the PATH!
|
|
||||||
* `$./generate_subcluster.pl` outputs the subcluster section on `stdout`
|
|
||||||
|
|
||||||
Please be aware that
|
|
||||||
* You have to enter the name and node list for the subCluster manually.
|
|
||||||
* GPU detection only works if LIKWID was build with Cuda avalable and you run likwid-topology also with Cuda loaded.
|
|
||||||
* Do not blindly trust the measured peakflops values.
|
|
||||||
* Because the script blindly relies on the CSV format output by likwid-topology this is a fragile undertaking!
|
|
||||||
@ -1,99 +0,0 @@
|
|||||||
## Introduction
|
|
||||||
|
|
||||||
ClusterCockpit uses JSON Web Tokens (JWT) for authorization of its APIs. JSON
|
|
||||||
Web Token (JWT) is an open standard (RFC 7519) that defines a compact and
|
|
||||||
self-contained way for securely transmitting information between parties as a
|
|
||||||
JSON object. This information can be verified and trusted because it is
|
|
||||||
digitally signed. In ClusterCockpit JWTs are signed using a public/private key
|
|
||||||
pair using ECDSA. Because tokens are signed using public/private key pairs, the
|
|
||||||
signature also certifies that only the party holding the private key is the one
|
|
||||||
that signed it. Token expiration is set to the configuration option MaxAge.
|
|
||||||
|
|
||||||
## JWT Payload
|
|
||||||
|
|
||||||
You may view the payload of a JWT token at [https://jwt.io/#debugger-io](https://jwt.io/#debugger-io).
|
|
||||||
Currently ClusterCockpit sets the following claims:
|
|
||||||
* `iat`: Issued at claim. The “iat” claim is used to identify the the time at which the JWT was issued. This claim can be used to determine the age of the JWT.
|
|
||||||
* `sub`: Subject claim. Identifies the subject of the JWT, in our case this is the username.
|
|
||||||
* `roles`: An array of strings specifying the roles set for the subject.
|
|
||||||
|
|
||||||
## Workflow
|
|
||||||
|
|
||||||
1. Create a new ECDSA Public/private keypair:
|
|
||||||
```
|
|
||||||
$ go build ./tools/gen-keypair.go
|
|
||||||
$ ./gen-keypair
|
|
||||||
```
|
|
||||||
2. Add keypair in your `.env` file. A template can be found in `./configs`.
|
|
||||||
|
|
||||||
There are two usage scenarios:
|
|
||||||
* The APIs are used during a browser session. API accesses are authorized with
|
|
||||||
the active session.
|
|
||||||
* The REST API is used outside a browser session, e.g. by scripts. In this case
|
|
||||||
you have to issue a token manually. This possible from within the
|
|
||||||
configuration view or on the command line. It is recommended to issue a JWT
|
|
||||||
token in this case for a special user that only has the `api` role. By using
|
|
||||||
different users for different purposes a fine grained access control and
|
|
||||||
access revocation management is possible.
|
|
||||||
|
|
||||||
The token is commonly specified in the Authorization HTTP header using the Bearer schema.
|
|
||||||
|
|
||||||
## Setup user and JWT token for REST API authorization
|
|
||||||
|
|
||||||
1. Create user:
|
|
||||||
```
|
|
||||||
$ ./cc-backend --add-user <username>:api:<Password> --no-server
|
|
||||||
```
|
|
||||||
2. Issue token for user:
|
|
||||||
```
|
|
||||||
$ ./cc-backend -jwt <username> -no-server
|
|
||||||
```
|
|
||||||
3. Use issued token token on client side:
|
|
||||||
```
|
|
||||||
$ curl -X GET "<API ENDPOINT>" -H "accept: application/json" -H "Content-Type: application/json" -H "Authorization: Bearer <JWT TOKEN>"
|
|
||||||
```
|
|
||||||
|
|
||||||
## Accept externally generated JWTs provided via cookie
|
|
||||||
If there is an external service like an AuthAPI that can generate JWTs and hand
|
|
||||||
them over to ClusterCockpit via cookies, CC can be configured to accept them:
|
|
||||||
|
|
||||||
1. `.env`: CC needs a public ed25519 key to verify foreign JWT signatures.
|
|
||||||
Public keys in PEM format can be converted with the instructions in
|
|
||||||
[/tools/convert-pem-pubkey-for-cc](../tools/convert-pem-pubkey-for-cc/Readme.md)
|
|
||||||
.
|
|
||||||
|
|
||||||
```
|
|
||||||
CROSS_LOGIN_JWT_PUBLIC_KEY="+51iXX8BdLFocrppRxIw52xCOf8xFSH/eNilN5IHVGc="
|
|
||||||
```
|
|
||||||
|
|
||||||
2. `config.json`: Insert a name for the cookie (set by the external service)
|
|
||||||
containing the JWT so that CC knows where to look at. Define a trusted issuer
|
|
||||||
(JWT claim 'iss'), otherwise it will be rejected. If you want usernames and
|
|
||||||
user roles from JWTs ('sub' and 'roles' claim) to be validated against CC's
|
|
||||||
internal database, you need to enable it here. Unknown users will then be
|
|
||||||
rejected and roles set via JWT will be ignored.
|
|
||||||
|
|
||||||
```json
|
|
||||||
"jwts": {
|
|
||||||
"cookieName": "access_cc",
|
|
||||||
"forceJWTValidationViaDatabase": true,
|
|
||||||
"trustedExternalIssuer": "auth.example.com"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
3. Make sure your external service includes the same issuer (`iss`) in its JWTs.
|
|
||||||
Example JWT payload:
|
|
||||||
|
|
||||||
```json
|
|
||||||
{
|
|
||||||
"iat": 1668161471,
|
|
||||||
"nbf": 1668161471,
|
|
||||||
"exp": 1668161531,
|
|
||||||
"sub": "alice",
|
|
||||||
"roles": [
|
|
||||||
"user"
|
|
||||||
],
|
|
||||||
"jti": "a1b2c3d4-1234-5678-abcd-a1b2c3d4e5f6",
|
|
||||||
"iss": "auth.example.com"
|
|
||||||
}
|
|
||||||
```
|
|
||||||
@ -1,78 +0,0 @@
|
|||||||
The job archive specifies an exchange format for job meta and performance metric
|
|
||||||
data. It consists of two parts:
|
|
||||||
* a [SQLite database schema](https://github.com/ClusterCockpit/cc-backend/wiki/Job-Archive#sqlite-database-schema) for job meta data and performance statistics
|
|
||||||
* a [Json file format](https://github.com/ClusterCockpit/cc-backend/wiki/Job-Archive#json-file-format) together with a [Directory hierarchy specification](https://github.com/ClusterCockpit/cc-backend/wiki/Job-Archive#directory-hierarchy-specification)
|
|
||||||
|
|
||||||
By using an open, portable and simple specification based on files it is
|
|
||||||
possible to exchange job performance data for research and analysis purposes as
|
|
||||||
well as use it as a robust way for archiving job performance data to disk.
|
|
||||||
|
|
||||||
# SQLite database schema
|
|
||||||
## Introduction
|
|
||||||
|
|
||||||
A SQLite 3 database schema is provided to standardize the job meta data
|
|
||||||
information in a portable way. The schema also includes optional columns for job
|
|
||||||
performance statistics (called a job performance footprint). The database acts
|
|
||||||
as a front end to filter and select subsets of job IDs, that are the keys to get
|
|
||||||
the full job performance data in the job performance tree hierarchy.
|
|
||||||
|
|
||||||
## Database schema
|
|
||||||
|
|
||||||
The schema includes 3 tables: the job table, a tag table and a jobtag table
|
|
||||||
representing the MANY-TO-MANY relation between jobs and tags. The SQL schema is
|
|
||||||
specified
|
|
||||||
[here](https://github.com/ClusterCockpit/cc-specifications/blob/master/schemas/jobs-sqlite.sql).
|
|
||||||
Explanation of the various columns including the JSON datatypes is documented
|
|
||||||
[here](https://github.com/ClusterCockpit/cc-specifications/blob/master/datastructures/job-meta.schema.json).
|
|
||||||
|
|
||||||
# Directory hierarchy specification
|
|
||||||
|
|
||||||
## Specification
|
|
||||||
|
|
||||||
To manage the number of directories within a single directory a tree approach is
|
|
||||||
used splitting the integer job ID. The job id is split in junks of 1000 each.
|
|
||||||
Usually 2 layers of directories is sufficient but the concept can be used for an
|
|
||||||
arbitrary number of layers.
|
|
||||||
|
|
||||||
For a 2 layer schema this can be achieved with (code example in Perl):
|
|
||||||
``` perl
|
|
||||||
$level1 = $jobID/1000;
|
|
||||||
$level2 = $jobID%1000;
|
|
||||||
$dstPath = sprintf("%s/%s/%d/%03d", $trunk, $destdir, $level1, $level2);
|
|
||||||
```
|
|
||||||
|
|
||||||
## Example
|
|
||||||
|
|
||||||
For the job ID 1034871 the directory path is `./1034/871/`.
|
|
||||||
|
|
||||||
# Json file format
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
Every cluster must be configured in a `cluster.json` file.
|
|
||||||
|
|
||||||
The job data consists of two files:
|
|
||||||
* `meta.json`: Contains job meta information and job statistics.
|
|
||||||
* `data.json`: Contains complete job data with time series
|
|
||||||
|
|
||||||
The description of the json format specification is available as [[json
|
|
||||||
schema|https://json-schema.org/]] format file. The latest version of the json
|
|
||||||
schema is part of the `cc-backend` source tree. For external reference it is
|
|
||||||
also available in a separate repository.
|
|
||||||
|
|
||||||
## Specification `cluster.json`
|
|
||||||
|
|
||||||
The json schema specification is available
|
|
||||||
[here](https://github.com/ClusterCockpit/cc-specifications/blob/master/datastructures/cluster.schema.json).
|
|
||||||
|
|
||||||
## Specification `meta.json`
|
|
||||||
|
|
||||||
The json schema specification is available
|
|
||||||
[here](https://github.com/RRZE-HPC/HPCJobDatabase/blob/master/json-schema/job-meta.schema.json).
|
|
||||||
|
|
||||||
## Specification `data.json`
|
|
||||||
|
|
||||||
The json schema specification is available
|
|
||||||
[here](https://github.com/RRZE-HPC/HPCJobDatabase/blob/master/json-schema/job-data.schema.json).
|
|
||||||
Metric time series data is stored for a fixed time step. The time step is set
|
|
||||||
per metric. If no value is available for a metric time series data timestamp
|
|
||||||
`null` is entered.
|
|
||||||
@ -1,29 +0,0 @@
|
|||||||
# Overview
|
|
||||||
|
|
||||||
Customizing `cc-backend` means changing the logo, legal texts, and the login
|
|
||||||
template instead of the placeholders. You can also place a text file in `./var`
|
|
||||||
to add dynamic status or notification messages to the clusterCockpit homepage.
|
|
||||||
|
|
||||||
# Replace legal texts
|
|
||||||
|
|
||||||
To replace the `imprint.tmpl` and `privacy.tmpl` legal texts, you can place your
|
|
||||||
version in `./var/`. At startup `cc-backend` will check if `./var/imprint.tmpl` and/or
|
|
||||||
`./var/privacy.tmpl` exist and use them instead of the built-in placeholders.
|
|
||||||
You can use the placeholders in `web/templates` as a blueprint.
|
|
||||||
|
|
||||||
# Replace login template
|
|
||||||
To replace the default login layout and styling, you can place your version in
|
|
||||||
`./var/`. At startup `cc-backend` will check if `./var/login.tmpl` exist and use
|
|
||||||
it instead of the built-in placeholder. You can use the default temaplte
|
|
||||||
`web/templates/login.tmpl` as a blueprint.
|
|
||||||
|
|
||||||
# Replace logo
|
|
||||||
To change the logo displayed in the navigation bar, you can provide the file
|
|
||||||
`logo.png` in the folder `./var/img/`. On startup `cc-backend` will check if the
|
|
||||||
folder exists and use the images provided there instead of the built-in images.
|
|
||||||
You may also place additional images there you use in a custom login template.
|
|
||||||
|
|
||||||
# Add notification banner on homepage
|
|
||||||
To add a notification banner you can add a file `notice.txt` to `./var`. As long
|
|
||||||
as this file is present all text in this file is shown in an info banner on the
|
|
||||||
homepage.
|
|
||||||
@ -1,78 +0,0 @@
|
|||||||
In general, an upgrade is nothing more than a replacement of the binary file.
|
|
||||||
All the necessary files, except the database file, the configuration file and
|
|
||||||
the job archive, are embedded in the binary file. It is recommended to use a
|
|
||||||
directory where the file names of the binary files are named with a version
|
|
||||||
indicator. This can be, for example, the date or the Unix epoch time. A symbolic
|
|
||||||
link points to the version to be used. This makes it easier to switch to earlier
|
|
||||||
versions.
|
|
||||||
|
|
||||||
The database and the job archive are versioned. Each release binary supports
|
|
||||||
specific versions of the database and job archive. If a version mismatch is
|
|
||||||
detected, the application is terminated and migration is required.
|
|
||||||
|
|
||||||
**IMPORTANT NOTE**
|
|
||||||
|
|
||||||
It is recommended to make a backup copy of the database before each update. This
|
|
||||||
is mandatory in case the database needs to be migrated. In the case of sqlite,
|
|
||||||
this means to stopping `cc-backend` and copying the sqlite database file
|
|
||||||
somewhere.
|
|
||||||
|
|
||||||
# Migrating the database
|
|
||||||
|
|
||||||
After you have backed up the database, run the following command to migrate the
|
|
||||||
database to the latest version:
|
|
||||||
```
|
|
||||||
$ ./cc-backend -migrate-db
|
|
||||||
```
|
|
||||||
|
|
||||||
The migration files are embedded in the binary and can also be viewed in the cc
|
|
||||||
backend [source tree](https://github.com/ClusterCockpit/cc-backend/tree/master/internal/repository/migrations).
|
|
||||||
There are separate migration files for both supported
|
|
||||||
database backends.
|
|
||||||
We use the [migrate library](https://github.com/golang-migrate/migrate).
|
|
||||||
|
|
||||||
If something goes wrong, you can check the status and get the current schema
|
|
||||||
(here for sqlite):
|
|
||||||
```
|
|
||||||
$ sqlite3 var/job.db
|
|
||||||
```
|
|
||||||
In the sqlite console execute:
|
|
||||||
```
|
|
||||||
.schema
|
|
||||||
```
|
|
||||||
to get the current databse schema.
|
|
||||||
You can query the current version and whether the migration failed with:
|
|
||||||
```
|
|
||||||
SELECT * FROM schema_migrations;
|
|
||||||
```
|
|
||||||
The first column indicates the current database version and the second column is
|
|
||||||
a dirty flag indicating whether the migration was successful.
|
|
||||||
|
|
||||||
# Migrating the job archive
|
|
||||||
|
|
||||||
Job archive migration requires a separate tool (`archive-migration`), which is
|
|
||||||
part of the cc-backend source tree (build with `go build ./tools/archive-migration`)
|
|
||||||
and is also provided as part of the releases.
|
|
||||||
|
|
||||||
Migration is supported only between two successive releases. The migration tool
|
|
||||||
migrates the existing job archive to a new job archive. This means that there
|
|
||||||
must be enough disk space for two complete job archives. If the tool is called
|
|
||||||
without options:
|
|
||||||
```
|
|
||||||
$ ./archive-migration
|
|
||||||
```
|
|
||||||
|
|
||||||
it is assumed that a job archive exists in `./var/job-archive`. The new job
|
|
||||||
archive is written to `./var/job-archive-new`. Since execution is threaded in case
|
|
||||||
of a fatal error, it is impossible to determine in which job the error occurred.
|
|
||||||
In this case, you can run the tool in debug mode (with the `-debug` flag). In
|
|
||||||
debug mode, threading is disabled and the job ID of each migrated job is output.
|
|
||||||
Jobs with empty files will be skipped. Between multiple runs of the tools, the
|
|
||||||
`job-archive-new` directory must be moved or deleted.
|
|
||||||
|
|
||||||
The `cluster.json` files in `job-archive-new` must be checked for errors, especially
|
|
||||||
whether the aggregation attribute is set correctly for all metrics.
|
|
||||||
|
|
||||||
Migration takes several hours for relatively large job archives (several hundred
|
|
||||||
GB). A versioned job archive contains a version.txt file in the root directory
|
|
||||||
of the job archive. This file contains the version as an unsigned integer.
|
|
||||||
@ -1,180 +0,0 @@
|
|||||||
# Overview
|
|
||||||
|
|
||||||
The authentication is implemented in `internal/auth/`. In `auth.go`
|
|
||||||
an interface is defined that any authentication provider must fulfill. It also
|
|
||||||
acts as a dispatcher to delegate the calls to the available authentication
|
|
||||||
providers.
|
|
||||||
|
|
||||||
Two authentication types are available:
|
|
||||||
* JWT authentication for the REST API that does not create a session cookie
|
|
||||||
* Session based authentication using a session cookie
|
|
||||||
|
|
||||||
The most important routines in auth are:
|
|
||||||
* `Login()` Handle POST request to login user and start a new session
|
|
||||||
* `Auth()` Authenticate user and put User Object in context of the request
|
|
||||||
|
|
||||||
The http router calls auth in the following cases:
|
|
||||||
* `r.Handle("/login", authentication.Login( ... )).Methods(http.MethodPost)`:
|
|
||||||
The POST request on the `/login` route will call the Login callback.
|
|
||||||
* `r.Handle("/jwt-login", authentication.Login( ... ))`:
|
|
||||||
Any request on the `/jwt-login` route will call the Login callback. Intended
|
|
||||||
for use for the JWT token based authenticators.
|
|
||||||
* Any route in the secured subrouter will always call Auth(), on success it will
|
|
||||||
call the next handler in the chain, on failure it will render the login
|
|
||||||
template.
|
|
||||||
```
|
|
||||||
secured.Use(func(next http.Handler) http.Handler {
|
|
||||||
return authentication.Auth(
|
|
||||||
// On success;
|
|
||||||
next,
|
|
||||||
|
|
||||||
// On failure:
|
|
||||||
func(rw http.ResponseWriter, r *http.Request, err error) {
|
|
||||||
// Render login form
|
|
||||||
})
|
|
||||||
})
|
|
||||||
```
|
|
||||||
|
|
||||||
A JWT token can be used to initiate an authenticated user
|
|
||||||
session. This can either happen by calling the login route with a token
|
|
||||||
provided in a header or via a special cookie containing the JWT token.
|
|
||||||
For API routes the access is authenticated on every request using the JWT token
|
|
||||||
and no session is initiated.
|
|
||||||
|
|
||||||
# Login
|
|
||||||
|
|
||||||
The Login function (located in `auth.go`):
|
|
||||||
* Extracts the user name and gets the user from the user database table. In case the
|
|
||||||
user is not found the user object is set to nil.
|
|
||||||
* Iterates over all authenticators and:
|
|
||||||
- Calls its `CanLogin` function which checks if the authentication method is
|
|
||||||
supported for this user.
|
|
||||||
- Calls its `Login` function to authenticate the user. On success a valid user
|
|
||||||
object is returned.
|
|
||||||
- Creates a new session object, stores the user attributes in the session and
|
|
||||||
saves the session.
|
|
||||||
- Starts the `onSuccess` http handler
|
|
||||||
|
|
||||||
## Local authenticator
|
|
||||||
|
|
||||||
This authenticator is applied if
|
|
||||||
```
|
|
||||||
return user != nil && user.AuthSource == AuthViaLocalPassword
|
|
||||||
```
|
|
||||||
|
|
||||||
Compares the password provided by the login form to the password hash stored in
|
|
||||||
the user database table:
|
|
||||||
```
|
|
||||||
if e := bcrypt.CompareHashAndPassword([]byte(user.Password), []byte(r.FormValue("password"))); e != nil {
|
|
||||||
log.Errorf("AUTH/LOCAL > Authentication for user %s failed!", user.Username)
|
|
||||||
return nil, fmt.Errorf("Authentication failed")
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
## LDAP authenticator
|
|
||||||
|
|
||||||
This authenticator is applied if the user was found in the database and its
|
|
||||||
AuthSource is LDAP:
|
|
||||||
```
|
|
||||||
if user != nil {
|
|
||||||
if user.AuthSource == schema.AuthViaLDAP {
|
|
||||||
return user, true
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
If the option `SyncUserOnLogin` is set it tried to sync the user from the LDAP
|
|
||||||
directory. In case this succeeds the user is persisted to the database and can
|
|
||||||
login.
|
|
||||||
|
|
||||||
Gets the LDAP connection and tries a bind with the provided credentials:
|
|
||||||
```
|
|
||||||
if err := l.Bind(userDn, r.FormValue("password")); err != nil {
|
|
||||||
log.Errorf("AUTH/LDAP > Authentication for user %s failed: %v", user.Username, err)
|
|
||||||
return nil, fmt.Errorf("Authentication failed")
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
## JWT Session authenticator
|
|
||||||
|
|
||||||
Login via JWT token will create a session without password.
|
|
||||||
For login the `X-Auth-Token` header is not supported. This authenticator is
|
|
||||||
applied if the Authorization header or query parameter login-token is present:
|
|
||||||
```
|
|
||||||
return user, r.Header.Get("Authorization") != "" ||
|
|
||||||
r.URL.Query().Get("login-token") != ""
|
|
||||||
```
|
|
||||||
|
|
||||||
The Login function:
|
|
||||||
* Parses the token and checks if it is expired
|
|
||||||
* Check if the signing method is EdDSA or HS256 or HS512
|
|
||||||
* Check if claims are valid and extracts the claims
|
|
||||||
* The following claims have to be present:
|
|
||||||
- `sub`: The subject, in this case this is the username
|
|
||||||
- `exp`: Expiration in Unix epoch time
|
|
||||||
- `roles`: String array with roles of user
|
|
||||||
* In case user does not exist in the database and the option `SyncUserOnLogin`
|
|
||||||
is set add user to user database table with `AuthViaToken` AuthSource.
|
|
||||||
* Return valid user object
|
|
||||||
|
|
||||||
## JWT Cookie Session authenticator
|
|
||||||
|
|
||||||
Login via JWT cookie token will create a session without password.
|
|
||||||
It is first checked if the required configuration options are set:
|
|
||||||
* `trustedIssuer`
|
|
||||||
* `CookieName`
|
|
||||||
|
|
||||||
and optionally the environment variable `CROSS_LOGIN_JWT_PUBLIC_KEY` is set.
|
|
||||||
|
|
||||||
This authenticator is applied if the configured cookie is present:
|
|
||||||
```
|
|
||||||
jwtCookie, err := r.Cookie(cookieName)
|
|
||||||
|
|
||||||
if err == nil && jwtCookie.Value != "" {
|
|
||||||
return true
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
The Login function:
|
|
||||||
* Extracts and parses the token
|
|
||||||
* Checks if signing method is Ed25519/EdDSA
|
|
||||||
* In case publicKeyCrossLogin is configured:
|
|
||||||
- Check if `iss` issuer claim matched trusted issuer from configuration
|
|
||||||
- Return public cross login key
|
|
||||||
- Otherwise return standard public key
|
|
||||||
* Check if claims are valid
|
|
||||||
* Depending on the option `validateUser` the roles are
|
|
||||||
extracted from JWT token or taken from user object fetched from database
|
|
||||||
* Ask browser to delete the JWT cookie
|
|
||||||
* In case user does not exist in the database and the option `SyncUserOnLogin`
|
|
||||||
is set add user to user database table with `AuthViaToken` AuthSource.
|
|
||||||
* Return valid user object
|
|
||||||
|
|
||||||
# Auth
|
|
||||||
|
|
||||||
The Auth function (located in `auth.go`):
|
|
||||||
* Returns a new http handler function that is defined right away
|
|
||||||
* This handler tries two methods to authenticate a user:
|
|
||||||
- Via a JWT API token in `AuthViaJWT()`
|
|
||||||
- Via a valid session in `AuthViaSession()`
|
|
||||||
* If err is not nil and the user object is valid it puts the user object in the
|
|
||||||
request context and starts the onSuccess http handler
|
|
||||||
* Otherwise it calls the onFailure handler
|
|
||||||
|
|
||||||
## AuthViaJWT
|
|
||||||
|
|
||||||
Implemented in JWTAuthenticator:
|
|
||||||
* Extract token either from header `X-Auth-Token` or `Authorization` with Bearer
|
|
||||||
prefix
|
|
||||||
* Parse token and check if it is valid. The Parse routine will also check if the
|
|
||||||
token is expired.
|
|
||||||
* If the option `validateUser` is set it will ensure the
|
|
||||||
user object exists in the database and takes the roles from the database user
|
|
||||||
* Otherwise the roles are extracted from the roles claim
|
|
||||||
* Returns a valid user object with AuthType set to AuthToken
|
|
||||||
|
|
||||||
## AuthViaSession
|
|
||||||
|
|
||||||
* Extracts session
|
|
||||||
* Get values username, projects, and roles from session
|
|
||||||
* Returns a valid user object with AuthType set to AuthSession
|
|
||||||
@ -1,33 +0,0 @@
|
|||||||
## Tips for frontend development
|
|
||||||
|
|
||||||
The frontend assets including the Svelte js files are per default embedded in
|
|
||||||
the bgo binary. To enable a quick turnaround cycle for web development of the
|
|
||||||
frontend disable embedding of static assets in `config.json`:
|
|
||||||
```
|
|
||||||
"embed-static-files": false,
|
|
||||||
"static-files": "./web/frontend/public/",
|
|
||||||
|
|
||||||
```
|
|
||||||
|
|
||||||
Start the node build process (in directory `./web/frontend`) in development mode:
|
|
||||||
```
|
|
||||||
$ npm run dev
|
|
||||||
```
|
|
||||||
|
|
||||||
This will start the build process in listen mode. Whenever you change a source
|
|
||||||
files the depending javascript targets will be automatically rebuild.
|
|
||||||
In case the javascript files are minified you may need to set the production
|
|
||||||
flag by hand to false in `./web/frontend/rollup.config.mjs`:
|
|
||||||
```
|
|
||||||
const production = false
|
|
||||||
```
|
|
||||||
|
|
||||||
Usually this should work automatically.
|
|
||||||
|
|
||||||
Because the files are still served by ./cc-backend you have to reload the view
|
|
||||||
explicitly in your browser.
|
|
||||||
|
|
||||||
A common setup is to have three terminals open:
|
|
||||||
* One running cc-backend (working directory repository root): `./cc-backend -server -dev`
|
|
||||||
* Another running npm in developer mode (working directory `./web/frontend`): `npm run dev`
|
|
||||||
* And the last one editing the frontend source files
|
|
||||||
@ -1,13 +0,0 @@
|
|||||||
# Steps to prepare a release
|
|
||||||
|
|
||||||
1. On `hotfix` branch:
|
|
||||||
* Update ReleaseNotes.md
|
|
||||||
* Update version in Makefile
|
|
||||||
* Commit, push, and pull request
|
|
||||||
* Merge in master
|
|
||||||
|
|
||||||
2. On Linux host:
|
|
||||||
* Pull master
|
|
||||||
* Ensure that GitHub Token environment variable `GITHUB_TOKEN` is set
|
|
||||||
* Create release tag: `git tag v1.1.0 -m release`
|
|
||||||
* Execute `goreleaser release`
|
|
||||||
@ -1,34 +0,0 @@
|
|||||||
## Overview
|
|
||||||
|
|
||||||
We use the standard golang testing environment.
|
|
||||||
|
|
||||||
The following conventions are used:
|
|
||||||
|
|
||||||
* *White box unit tests*: Tests for internal functionality are placed in files
|
|
||||||
* *Black box unit tests*: Tests for public interfaces are placed in files
|
|
||||||
with `<package name>_test.go` and belong to the package `<package_name>_test`.
|
|
||||||
There only exists one package test file per package.
|
|
||||||
* *Integration tests*: Tests that use multiple componenents are placed in a
|
|
||||||
package test file. These are named `<package name>_test.go` and belong to the
|
|
||||||
package `<package_name>_test`.
|
|
||||||
* *Test assets*: Any required files are placed in a directory `./testdata`
|
|
||||||
within each package directory.
|
|
||||||
|
|
||||||
## Executing tests
|
|
||||||
|
|
||||||
Visual Studio Code has a very good golang test integration.
|
|
||||||
For debugging a test this is the recommended solution.
|
|
||||||
|
|
||||||
The Makefile provided by us has a `test` target that executes:
|
|
||||||
```
|
|
||||||
$ go clean -testcache
|
|
||||||
$ go build ./...
|
|
||||||
$ go vet ./...
|
|
||||||
$ go test ./...
|
|
||||||
```
|
|
||||||
|
|
||||||
Of course the commands can also be used on the command line.
|
|
||||||
For details about golang testing refer to the standard documentation:
|
|
||||||
|
|
||||||
* [Testing package](https://pkg.go.dev/testing)
|
|
||||||
* [go test command](https://pkg.go.dev/cmd/go#hdr-Test_packages)
|
|
||||||
@ -1,229 +0,0 @@
|
|||||||
#!/usr/bin/env perl
|
|
||||||
use strict;
|
|
||||||
use warnings;
|
|
||||||
use utf8;
|
|
||||||
|
|
||||||
use JSON::PP; # from Perl default install
|
|
||||||
use Time::Local qw( timelocal ); # from Perl default install
|
|
||||||
use Time::Piece; # from Perl default install
|
|
||||||
|
|
||||||
### JSON
|
|
||||||
my $json = JSON::PP->new->allow_nonref;
|
|
||||||
|
|
||||||
### TIME AND DATE
|
|
||||||
# now
|
|
||||||
my $localtime = localtime;
|
|
||||||
my $epochtime = $localtime->epoch;
|
|
||||||
# 5 days ago: Via epoch due to possible reverse month borders
|
|
||||||
my $epochlessfive = $epochtime - (86400 * 5);
|
|
||||||
my $locallessfive = localtime($epochlessfive);
|
|
||||||
# Calc like `date --date 'TZ="Europe/Berlin" 0:00 5 days ago' +%s`)
|
|
||||||
my ($day, $month, $year) = ($locallessfive->mday, $locallessfive->_mon, $locallessfive->year);
|
|
||||||
my $checkpointStart = timelocal(0, 0, 0, $day, $month, $year);
|
|
||||||
# for checkpoints
|
|
||||||
my $halfday = 43200;
|
|
||||||
|
|
||||||
### JOB-ARCHIVE
|
|
||||||
my $archiveTarget = './cc-backend/var/job-archive';
|
|
||||||
my $archiveSrc = './source-data/job-archive-source';
|
|
||||||
my @ArchiveClusters;
|
|
||||||
|
|
||||||
# Gen folder
|
|
||||||
if ( not -d $archiveTarget ){
|
|
||||||
mkdir( $archiveTarget ) or die "Couldn't create $archiveTarget directory, $!";
|
|
||||||
}
|
|
||||||
|
|
||||||
# Get clusters by job-archive/$subfolder
|
|
||||||
opendir my $dh, $archiveSrc or die "can't open directory: $!";
|
|
||||||
while ( readdir $dh ) {
|
|
||||||
chomp; next if $_ eq '.' or $_ eq '..' or $_ eq 'job-archive';
|
|
||||||
my $cluster = $_;
|
|
||||||
push @ArchiveClusters, $cluster;
|
|
||||||
}
|
|
||||||
|
|
||||||
# start for jobarchive
|
|
||||||
foreach my $cluster ( @ArchiveClusters ) {
|
|
||||||
print "Starting to update start- and stoptimes in job-archive for $cluster\n";
|
|
||||||
|
|
||||||
my $clusterTarget = "$archiveTarget/$cluster";
|
|
||||||
|
|
||||||
if ( not -d $clusterTarget ){
|
|
||||||
mkdir( $clusterTarget ) or die "Couldn't create $clusterTarget directory, $!";
|
|
||||||
}
|
|
||||||
|
|
||||||
opendir my $dhLevel1, "$archiveSrc/$cluster" or die "can't open directory: $!";
|
|
||||||
while ( readdir $dhLevel1 ) {
|
|
||||||
chomp; next if $_ eq '.' or $_ eq '..';
|
|
||||||
my $level1 = $_;
|
|
||||||
|
|
||||||
if ( -d "$archiveSrc/$cluster/$level1" ) {
|
|
||||||
opendir my $dhLevel2, "$archiveSrc/$cluster/$level1" or die "can't open directory: $!";
|
|
||||||
while ( readdir $dhLevel2 ) {
|
|
||||||
chomp; next if $_ eq '.' or $_ eq '..';
|
|
||||||
my $level2 = $_;
|
|
||||||
my $jobSource = "$archiveSrc/$cluster/$level1/$level2";
|
|
||||||
my $jobOrigin = "$jobSource";
|
|
||||||
my $jobTargetL1 = "$clusterTarget/$level1";
|
|
||||||
my $jobTargetL2 = "$jobTargetL1/$level2";
|
|
||||||
|
|
||||||
# check if files are directly accessible (old format) else get subfolders as file and update path
|
|
||||||
if ( ! -e "$jobSource/meta.json") {
|
|
||||||
opendir(D, "$jobSource") || die "Can't open directory $jobSource: $!\n";
|
|
||||||
my @folders = readdir(D);
|
|
||||||
closedir(D);
|
|
||||||
if (!@folders) {
|
|
||||||
next;
|
|
||||||
}
|
|
||||||
|
|
||||||
foreach my $folder ( @folders ) {
|
|
||||||
next if $folder eq '.' or $folder eq '..';
|
|
||||||
$jobSource = "$jobSource/".$folder;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
# check if subfolder contains file, else skip
|
|
||||||
if ( ! -e "$jobSource/meta.json") {
|
|
||||||
print "$jobSource skipped\n";
|
|
||||||
next;
|
|
||||||
}
|
|
||||||
|
|
||||||
open my $metafh, '<', "$jobSource/meta.json" or die "Can't open file $!";
|
|
||||||
my $rawstr = do { local $/; <$metafh> };
|
|
||||||
close($metafh);
|
|
||||||
my $metadata = $json->decode($rawstr);
|
|
||||||
|
|
||||||
# NOTE Start meta.json iteration here
|
|
||||||
# my $random_number = int(rand(UPPERLIMIT)) + LOWERLIMIT;
|
|
||||||
# Set new startTime: Between 5 days and 1 day before now
|
|
||||||
|
|
||||||
# Remove id from attributes
|
|
||||||
$metadata->{startTime} = $epochtime - (int(rand(432000)) + 86400);
|
|
||||||
$metadata->{stopTime} = $metadata->{startTime} + $metadata->{duration};
|
|
||||||
|
|
||||||
# Add starttime subfolder to target path
|
|
||||||
my $jobTargetL3 = "$jobTargetL2/".$metadata->{startTime};
|
|
||||||
|
|
||||||
if ( not -d $jobTargetL1 ){
|
|
||||||
mkdir( $jobTargetL1 ) or die "Couldn't create $jobTargetL1 directory, $!";
|
|
||||||
}
|
|
||||||
|
|
||||||
if ( not -d $jobTargetL2 ){
|
|
||||||
mkdir( $jobTargetL2 ) or die "Couldn't create $jobTargetL2 directory, $!";
|
|
||||||
}
|
|
||||||
|
|
||||||
# target is not directory
|
|
||||||
if ( not -d $jobTargetL3 ){
|
|
||||||
mkdir( $jobTargetL3 ) or die "Couldn't create $jobTargetL3 directory, $!";
|
|
||||||
|
|
||||||
my $outstr = $json->encode($metadata);
|
|
||||||
open my $metaout, '>', "$jobTargetL3/meta.json" or die "Can't write to file $!";
|
|
||||||
print $metaout $outstr;
|
|
||||||
close($metaout);
|
|
||||||
|
|
||||||
open my $datafh, '<', "$jobSource/data.json" or die "Can't open file $!";
|
|
||||||
my $datastr = do { local $/; <$datafh> };
|
|
||||||
close($datafh);
|
|
||||||
|
|
||||||
open my $dataout, '>', "$jobTargetL3/data.json" or die "Can't write to file $!";
|
|
||||||
print $dataout $datastr;
|
|
||||||
close($dataout);
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
print "Done for job-archive\n";
|
|
||||||
sleep(1);
|
|
||||||
exit;
|
|
||||||
|
|
||||||
## CHECKPOINTS
|
|
||||||
my $checkpTarget = './cc-metric-store/var/checkpoints';
|
|
||||||
my $checkpSource = './source-data/cc-metric-store-source/checkpoints';
|
|
||||||
my @CheckpClusters;
|
|
||||||
|
|
||||||
# Gen folder
|
|
||||||
if ( not -d $checkpTarget ){
|
|
||||||
mkdir( $checkpTarget ) or die "Couldn't create $checkpTarget directory, $!";
|
|
||||||
}
|
|
||||||
|
|
||||||
# Get clusters by cc-metric-store/$subfolder
|
|
||||||
opendir my $dhc, $checkpSource or die "can't open directory: $!";
|
|
||||||
while ( readdir $dhc ) {
|
|
||||||
chomp; next if $_ eq '.' or $_ eq '..' or $_ eq 'job-archive';
|
|
||||||
my $cluster = $_;
|
|
||||||
push @CheckpClusters, $cluster;
|
|
||||||
}
|
|
||||||
closedir($dhc);
|
|
||||||
|
|
||||||
# start for checkpoints
|
|
||||||
foreach my $cluster ( @CheckpClusters ) {
|
|
||||||
print "Starting to update checkpoint filenames and data starttimes for $cluster\n";
|
|
||||||
|
|
||||||
my $clusterTarget = "$checkpTarget/$cluster";
|
|
||||||
|
|
||||||
if ( not -d $clusterTarget ){
|
|
||||||
mkdir( $clusterTarget ) or die "Couldn't create $clusterTarget directory, $!";
|
|
||||||
}
|
|
||||||
|
|
||||||
opendir my $dhLevel1, "$checkpSource/$cluster" or die "can't open directory: $!";
|
|
||||||
while ( readdir $dhLevel1 ) {
|
|
||||||
chomp; next if $_ eq '.' or $_ eq '..';
|
|
||||||
# Nodename as level1-folder
|
|
||||||
my $level1 = $_;
|
|
||||||
|
|
||||||
if ( -d "$checkpSource/$cluster/$level1" ) {
|
|
||||||
|
|
||||||
my $nodeSource = "$checkpSource/$cluster/$level1/";
|
|
||||||
my $nodeOrigin = "$nodeSource";
|
|
||||||
my $nodeTarget = "$clusterTarget/$level1";
|
|
||||||
my @files;
|
|
||||||
|
|
||||||
if ( -e "$nodeSource/1609459200.json") { # 1609459200 == First Checkpoint time in latest dump
|
|
||||||
opendir(D, "$nodeSource") || die "Can't open directory $nodeSource: $!\n";
|
|
||||||
while ( readdir D ) {
|
|
||||||
chomp; next if $_ eq '.' or $_ eq '..';
|
|
||||||
my $nodeFile = $_;
|
|
||||||
push @files, $nodeFile;
|
|
||||||
}
|
|
||||||
closedir(D);
|
|
||||||
my $length = @files;
|
|
||||||
if (!@files || $length != 14) { # needs 14 files == 7 days worth of data
|
|
||||||
next;
|
|
||||||
}
|
|
||||||
} else {
|
|
||||||
next;
|
|
||||||
}
|
|
||||||
|
|
||||||
# sort for integer timestamp-filename-part (moduleless): Guarantees start with index == 0 == 1609459200.json
|
|
||||||
my @sortedFiles = sort { ($a =~ /^([0-9]{10}).json$/)[0] <=> ($b =~ /^([0-9]{10}).json$/)[0] } @files;
|
|
||||||
|
|
||||||
if ( not -d $nodeTarget ){
|
|
||||||
mkdir( $nodeTarget ) or die "Couldn't create $nodeTarget directory, $!";
|
|
||||||
|
|
||||||
while (my ($index, $file) = each(@sortedFiles)) {
|
|
||||||
open my $checkfh, '<', "$nodeSource/$file" or die "Can't open file $!";
|
|
||||||
my $rawstr = do { local $/; <$checkfh> };
|
|
||||||
close($checkfh);
|
|
||||||
my $checkpdata = $json->decode($rawstr);
|
|
||||||
|
|
||||||
my $newTimestamp = $checkpointStart + ($index * $halfday);
|
|
||||||
# Get Diff from old Timestamp
|
|
||||||
my $timeDiff = $newTimestamp - $checkpdata->{from};
|
|
||||||
# Set new timestamp
|
|
||||||
$checkpdata->{from} = $newTimestamp;
|
|
||||||
|
|
||||||
foreach my $metric (keys %{$checkpdata->{metrics}}) {
|
|
||||||
$checkpdata->{metrics}->{$metric}->{start} += $timeDiff;
|
|
||||||
}
|
|
||||||
|
|
||||||
my $outstr = $json->encode($checkpdata);
|
|
||||||
|
|
||||||
open my $checkout, '>', "$nodeTarget/$newTimestamp.json" or die "Can't write to file $!";
|
|
||||||
print $checkout $outstr;
|
|
||||||
close($checkout);
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
closedir($dhLevel1);
|
|
||||||
}
|
|
||||||
print "Done for checkpoints\n";
|
|
||||||
@ -1,36 +0,0 @@
|
|||||||
# Docs for ClusterCockpit Searchbar
|
|
||||||
|
|
||||||
## Usage
|
|
||||||
|
|
||||||
* Searchtags are implemented as `type:<query>` search-string
|
|
||||||
* Types `jobId, jobName, projectId, username, name, arrayJobId` for roles `admin` and `support`
|
|
||||||
* `jobName` is jobName as persisted in `job.meta_data` table-column
|
|
||||||
* `username` is actual account identifier as persisted in `job.user` table-column
|
|
||||||
* `name` is account owners name as persisted in `user.name` table-column
|
|
||||||
* Types `jobId, jobName, projectId, arrayJobId` for role `user`
|
|
||||||
* Examples:
|
|
||||||
* `jobName:myJob12`
|
|
||||||
* `jobId:123456`
|
|
||||||
* `username:abcd100`
|
|
||||||
* `name:Paul`
|
|
||||||
* If no searchTag used: Best guess search with the following hierarchy
|
|
||||||
* `jobId -> username -> name -> projectId -> jobName`
|
|
||||||
* Destinations:
|
|
||||||
* JobId: Job-Table (Allows multiple identical matches, e.g. JobIds from different clusters)
|
|
||||||
* JobName: Job-Table (Allows multiple identical matches, e.g. JobNames from different clusters)
|
|
||||||
* ProjectId: Job-Table
|
|
||||||
* Username: Users-Table
|
|
||||||
* **Please Note**: Only users with jobs will be shown in table! I.e., Users without jobs will be missing in table. Also, a `Last 30 Days` is active by default and might filter out expected users.
|
|
||||||
* Name: Users-Table
|
|
||||||
* **Please Note**: Only users with jobs will be shown in table! I.e., Users without jobs will be missing in table. Also, a `Last 30 Days` is active by default and might filter out expected users.
|
|
||||||
* ArrayJobId: Job-Table (Lists all Jobs of Queried ArrayJobId)
|
|
||||||
* Best guess search always redirects to Job-Table or `/monitoring/user/$USER` (first username match)
|
|
||||||
* Unprocessable queries will display messages detailing the cause (Info, Warning, Error)
|
|
||||||
* Spaces trimmed (both for searchTag and queryString)
|
|
||||||
* ` job12` == `job12`
|
|
||||||
* `projectID : abcd ` == `projectId:abcd`
|
|
||||||
* `jobName`- and `name-`queries work with a part of the target-string
|
|
||||||
* `jobName:myjob` for jobName "myjob_cluster1"
|
|
||||||
* `name:Paul` for name "Paul Atreides"
|
|
||||||
|
|
||||||
* JobName GQL Query is resolved as matching the query as a part of the whole metaData-JSON in the SQL DB.
|
|
||||||
Loading…
Reference in New Issue
Block a user