Skip to content

Commit

Permalink
Merge branch 'master' into update-js-sdk-reference
Browse files Browse the repository at this point in the history
  • Loading branch information
grisha87 authored Nov 15, 2023
2 parents c6b829b + df2b936 commit 4d64fab
Show file tree
Hide file tree
Showing 6 changed files with 194 additions and 9 deletions.
21 changes: 21 additions & 0 deletions docs/logging-guidelines.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
This page describes the logging mechanics and lists guidelines for clear logging.

## Goal
There are 2 main goals of the logging: providing support and tracing down errors in development

Logging with the support goal the is to inform semi-technical users about the state of the application.
This means all levels from INFO and up need to be clear to understand for everyone.

Logging with the development goal is to find where errors originate from. This means every log message needs sufficient information to trace the application its steps.

Use cases for the logs are:
- Support and development teams will receive an end-user log to investigate
- Run the application in DEBUG log-level to see what goes on in detail.

## Levels
These are the log levels available to the logger:
- **CRITICAL** = app is unable to continue, it should exit after this message
- **ERROR** = app is unable to perform the requested action and stops trying
- **WARNING** = app is unable to perform the requested action but will continue to run, for instance try again later
- **INFO** = app performs a requested action
- **DEBUG** = gives extra details over other messages, always a following message
11 changes: 11 additions & 0 deletions docs/provider/capabilities.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
# Provider agent capabilities List

## Protocol

| Capability | Yagna package version | Backwards-compatible? | Description |
|-------------------------------|-----------------------|-----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Multi-Activity Agreement | 0.5.0 | Yes | Negotiate ability to create multiple activities under single Agreement. Use (which?) property in Demand/Offer to indicate node's support for Multi-Activity. If counterparty does not support Multi-Activity, the node falls back to single Activity per Agreement behaviour. |
| Restart Proposal Negotiations | 0.7.0 | Yes | Agent is allowed to restart negotiations, by sending `Counter Proposal`, after he rejected Proposal at some point. Counter-party will receive regular `ProposalEvent` in this case. Only Agent rejecting Proposal has initiative in restarting negotiations, rejected Agent can only wait for this to happen. To indicate, that Proposal rejection isn't final and negotiations can be restarted later, Agent can set `golem.proposal.rejection.is-final` (bool) field in `Reason` structure. If this value is set to false, Agent can free any state related to this negotiation. The same field can be set in `Reason` sent in `Reject Agreement` operation. Requestor can send new counter Proposal after some period of time or propose the same Agreement for the second time. (No change to specification) |
| manifest-support | | | TODO |
| inet | | | TODO |
| start-entrypoint | | | TODO |
82 changes: 82 additions & 0 deletions docs/provider/exe-unit/exe-units.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,82 @@
# ExeUnits

## How Provider agent finds ExeUnits?

`ya-provider` lists available ExeUnits by listing descriptors placed in [directory](../overview.md#provider-directories).

Example directory content:
```commandline
nieznanysprawiciel@laptop:~$ tree ~/.local/lib/yagna/plugins
/home/nieznanysprawiciel/.local/lib/yagna/plugins
├── exe-unit
├── ya-runtime-vm
│   ├── runtime
│   │   ├── bios-256k.bin
│   │   ├── efi-virtio.rom
│   │   ├── initramfs.cpio.gz
│   │   ├── kvmvapic.bin
│   │   ├── linuxboot_dma.bin
│   │   ├── self-test.gvmi
│   │   ├── vmlinuz-virt
│   │   └── vmrt
│   └── ya-runtime-vm
├── ya-runtime-vm.json
├── ya-runtime-wasi
└── ya-runtime-wasi.json
```
ExeUnit descriptors (`ya-runtime-vm.json` and `ya-runtime-wasi.json`) must be placed directly in plugins directory (not in nested structure).
Other ExeUnits' files can be moved into subdirectories, because descriptor is pointing to specific files.

## Descriptor

Example ExeUnit descriptor:
```json
[
{
"name": "custom",
"version": "0.2.2",
"supervisor-path": "exe-unit",
"runtime-path": "custom-runtime/custom",
"description": "Custom runtime for documentation purposes.",
"extra-args": ["--runtime-managed-image"],
"properties": {
"golem.custom-runtime.enable" : false,
"golem.custom-runtime.config" : {
"value": 32
}
},
"config": {
"counters": {
"golem.usage.network.in-mib": {
"name": "in-network-traffic",
"description": "Incoming network traffic usage in MiB",
"price": true
},
"golem.usage.network.out-mib": {
"name": "out-network-traffic",
"description": "Outgoing network traffic usage in MiB",
"price": true
},
"golem.usage.duration_sec": {
"name": "duration",
"description": "Activity duration in seconds",
"price": true
}
}
}
}
]
```


| property | optional | description |
|-----------------|----------|---------------------------------------------------------------------------------------------------------------------------------|
| name | No | Runtime name which will be placed in offer as `"golem.runtime.name"` |
| version | No | Runtime version following semantic versioning. Placed in Offer as `golem.runtime.version` |
| supervisor-path | No | Path to supervisor binary relative to this descriptor. |
| runtime-path | Yes | Path to runtime binary relative to this descriptor. |
| description | Yes | Human readable runtime description. |
| extra-args | Yes | Runtime specific arguments that will be appended to ExeUnit binary when starting. |
| properties | Yes | Properties that will be attached to Offer. Dictionary with keys used as a path in Offer which value can be any legal json type. |
| config | Yes | Runtime configuration that can be used by Provider. |
| config/counters | Yes | Dictionary of supported usage counters. |
Loading

0 comments on commit 4d64fab

Please sign in to comment.