Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move docs from other places #2856

Merged
merged 3 commits into from
Nov 6, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
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 |
11 changes: 11 additions & 0 deletions docs/yagna/capabilities.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
# Yagna Capabilities List

# Protocol capabilities

Capabilities requiring Provider agent support are listed [here](../provider/capabilities.md).

## Yagna API

| Capability | Yagna package version | Backwards-compatible? | Description |
|-------------|-----------------------|-----------------------|----------------------------------------------------------------------------|
| Cors Policy | 0.12.0 | Yes | Yagna is able to respond with Cors headers. [Spec](./capabilities/cors.md) |
60 changes: 60 additions & 0 deletions docs/yagna/capabilities/cors.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,60 @@
# Cors headers

Why is it needed:

- local tests by developers.
- convenient connection of applications in public arenas with the local golem node.

### Examples

#### Erigon

**--http.corsdomain value**
Comma separated list of domains from which to accept cross origin requests (browser enforced)

**--http.vhosts value**
Comma separated list of virtual hostnames from which to accept requests (server enforced). Accepts '*' wildcard. (default: "localhost")

#### Lightouse

***--http-allow-origin**
`<ORIGIN>` this server (e.g., http://localhost:5052).

## Yagna Requirements

### Ability to define default cors rules

Add new commandline argument api-allow-origin (defined by env YAGNA_API_ALLOW_ORIGIN).


```
$ yagna service run --api-allow-origin='*'
```


### Rules per appkey

Adding new appkey

```
$ yagna app-key create --id 0x578349a0d1dd825162fe8579a51efa220a9f4b17 --allow-origin https://dapps.golem.network dapp-portal
4f1cf7c363e9403b9ce15823cec182ff
$ yagna app-key list
┌───────────────┬──────────────────────────────────────────────┬───────────┬─────────────────────────────────┐
│ name │ id │ role │ created │
├───────────────┼──────────────────────────────────────────────┼───────────┼─────────────────────────────────┤
│ dapp-portal │ 0x578349a0d1dd825162fe8579a51efa220a9f4b17 │ manager │ 2022-12-01T14:11:20.113596023 │
└───────────────┴──────────────────────────────────────────────┴───────────┴─────────────────────────────────┘
$ yagna app-key show dapp-portal
---
name: dapp-portal
key: 4f1cf7c363e9403b9ce15823cec182ff
id: "0x578349a0d1dd825162fe8579a51efa220a9f4b17"
role: manager
created: 2022-12-01T14:11:20.113596023
allowOrigin:
- https://dapps.golem.network
---



Loading