Compare commits
78 Commits
v0.2.4
...
4d74c38618
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
4d74c38618 | ||
|
|
8a1b204179 | ||
|
|
b19f5a3518 | ||
|
|
38dc36e846 | ||
|
|
4fe6931b5f | ||
|
|
b8e8a83e49 | ||
|
|
3d6914974d | ||
|
|
9aff2ec154 | ||
|
|
ecd4525a7f | ||
|
|
7a3e5278b9 | ||
|
|
8dcf269b42 | ||
|
|
cb16f35265 | ||
|
|
b9d340b4b4 | ||
|
|
dd07e536f0 | ||
|
|
9af481a022 | ||
|
|
529a30a6e1 | ||
|
|
7d842529b1 | ||
|
|
c731c18360 | ||
|
|
5498eb6cbb | ||
|
|
43f0aebf54 | ||
|
|
6413f0238f | ||
|
|
6b0394586e | ||
|
|
108094b06a | ||
|
|
d7c974792d | ||
|
|
1987eb57a0 | ||
|
|
12ca87415c | ||
|
|
a0e52faa44 | ||
|
|
f910cd8c61 | ||
|
|
91dc7579bc | ||
|
|
90c9a7e4fa | ||
|
|
1216e016c2 | ||
|
|
d85cab4bc0 | ||
|
|
4fef8824e1 | ||
|
|
009bf492c8 | ||
|
|
f7e0e8dff8 | ||
|
|
eb57ee7b92 | ||
|
|
84d13153ed | ||
|
|
8beac57b50 | ||
|
|
44067efdb6 | ||
|
|
5528be1812 | ||
|
|
f4cf4c73b9 | ||
|
|
e19852a509 | ||
|
|
6de0df365e | ||
|
|
28f620f901 | ||
|
|
3497f66db7 | ||
|
|
1c7362c9b0 | ||
|
|
9983c80ef1 | ||
|
|
fc1fb33d5e | ||
|
|
3bee8e8020 | ||
|
|
f8ea5ed76e | ||
|
|
6c7c2d6dd3 | ||
|
|
c179b4ab7e | ||
|
|
a8c4af0975 | ||
|
|
e3fdb91ac5 | ||
|
|
9925079729 | ||
|
|
6031737f83 | ||
|
|
b6a8fa2671 | ||
|
|
0dc53dba1c | ||
|
|
857afbe111 | ||
|
|
84b78eb9c6 | ||
|
|
4f18377a3b | ||
|
|
7f5bb45138 | ||
| 973d7a69c7 | |||
| aebc64e76e | |||
| 48c832c61b | |||
| 8435bd32a9 | |||
| ece41dd622 | |||
| c7f3b0d79f | |||
| 8905b50f41 | |||
| 43b0612004 | |||
| 599ac2d2d9 | |||
| d1975bd55c | |||
| 24a8139d3e | |||
| 21aac49a52 | |||
| 8a5f1b753c | |||
| 1b0b5eb198 | |||
| 44c8a189b6 | |||
| 1a58324689 |
3
.gitignore
vendored
@@ -37,3 +37,6 @@ Cargo.lock
|
||||
|
||||
# Ajonaikaiset tietokannat
|
||||
*.db
|
||||
|
||||
# Wanha versio
|
||||
temp/
|
||||
215
network-poc/AGENTBUILDER.md
Normal file
@@ -0,0 +1,215 @@
|
||||
# Kipinä Agent Builder — Suunnitelma
|
||||
|
||||
Käyttäjä voi rakentaa omia agentteja "hahmolomakkeella": valitsee avatarin, roolin, kielimallin ja muokkaa prompteja. Agentit tallentuvat localStorageen ja ovat käytettävissä pipelineissa.
|
||||
|
||||
## Nykytila
|
||||
|
||||
```js
|
||||
// Kovakoodattu agentPrompts-objekti
|
||||
const agentPrompts = {
|
||||
manager: { name: 'Manageri', model: 'qwen2.5-coder:7b', default: '...' },
|
||||
coder: { name: 'Koodari', model: 'qwen2.5-coder:7b', default: '...' },
|
||||
tofuist: { name: 'Tofuist', model: 'qwen2.5-coder:7b', docs: '/docs/tofu-cheatsheet.md', default: '...' },
|
||||
// ...
|
||||
};
|
||||
```
|
||||
|
||||
**Ongelma:** Uuden agentin lisääminen vaatii koodimuutoksen index.html:ään.
|
||||
|
||||
## Tavoite
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ Agent Builder -lomake │
|
||||
│ │
|
||||
│ ┌─────────┐ Nimi: [Tofuist ] │
|
||||
│ │ 🦎 │ Rooli: [IaC / Infra ▼] │
|
||||
│ │ avatar │ Malli: [qwen2.5-coder:7b ▼] │
|
||||
│ └─────────┘ Docs: [/docs/tofu-cheatsheet.md] │
|
||||
│ │
|
||||
│ System Prompt: │
|
||||
│ ┌─────────────────────────────────────────────┐ │
|
||||
│ │ You are an OpenTofu/Terraform IaC specialist│ │
|
||||
│ │ ... │ │
|
||||
│ └─────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ LLM-parametrit: │
|
||||
│ Temperature: [0.7] Top-k: [40] Max tokens: [512]│
|
||||
│ │
|
||||
│ [💾 Tallenna] [🗑️ Poista] [📤 Export JSON] │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Building Blocks
|
||||
|
||||
### 1. Agenttiskeema
|
||||
|
||||
```js
|
||||
{
|
||||
id: 'tofuist', // uniikki tunniste
|
||||
name: 'Tofuist', // näyttönimi
|
||||
avatar: '/avatars/gecko_notext.png', // avatar-kuvan polku
|
||||
role: 'iac', // rooli-template
|
||||
model: 'qwen2.5-coder:7b', // eksakti Ollama-mallinimi
|
||||
color: '#e3a336', // teemaväri UI:ssa
|
||||
docs: '/docs/tofu-cheatsheet.md', // valinnainen referenssidokumentti
|
||||
prompt: 'You are an OpenTofu...', // system prompt
|
||||
params: { // LLM-parametrit
|
||||
temperature: 0.7,
|
||||
top_k: 40,
|
||||
max_tokens: 512,
|
||||
repetition_penalty: 1.15
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Rooli-templatet (alasvetovalikko)
|
||||
|
||||
Valmiit pohjat jotka tuovat oletuspromptit ja parametrit:
|
||||
|
||||
| Rooli | Oletusprompt | Parametrit |
|
||||
|-------|-------------|------------|
|
||||
| Koodari | "Kirjoita selkeää, testattavaa koodia" | temp 0.7, max 512 |
|
||||
| QA / Testaus | "Kirjoita testejä, etsi virheitä" | temp 0.4, max 512 |
|
||||
| DevOps | "Dockerfile, Compose, CI/CD" | temp 0.5, max 512 |
|
||||
| DevSecOps | "Tietoturva-auditointi, OWASP" | temp 0.3, max 512 |
|
||||
| Arkkitehti | "Järjestelmäsuunnittelu, rajapinnat" | temp 0.6, max 512 |
|
||||
| IaC / Infra | "OpenTofu/Terraform HCL-koodi" | temp 0.5, max 512 |
|
||||
| Data | "Tietokannat, SQL, datamallit" | temp 0.5, max 512 |
|
||||
| Manageri | "Tehtävien jako ja koordinointi" | temp 0.8, max 200 |
|
||||
| Kirjoittaja | "Dokumentaatio, README, ohjeet" | temp 0.8, max 512 |
|
||||
| Vapaa | (tyhjä, käyttäjä kirjoittaa) | temp 0.7, max 512 |
|
||||
|
||||
### 3. Malli-valitsin
|
||||
|
||||
Lista saatavilla olevista malleista — haetaan dynaamisesti:
|
||||
|
||||
```
|
||||
Hub-kysely: GET /api/models → palauttaa yhdistettyjen solmujen mallit
|
||||
|
||||
Tai staattinen lista:
|
||||
- qwen2.5-coder:7b (oletus, natiivi GPU)
|
||||
- qwen2.5-coder:1.5b (kevyt)
|
||||
- qwen2.5-coder:0.5b (selain Wasm)
|
||||
- deepseek-r1 (reasoning)
|
||||
- llama3.2:3b (yleiskäyttö)
|
||||
```
|
||||
|
||||
Pitkän aikavälin tavoite: hub ilmoittaa WebSocketin kautta mitkä mallit ovat saatavilla.
|
||||
|
||||
### 4. Avatar-valitsin
|
||||
|
||||
Valmiit avatarit + mahdollisuus ladata oma:
|
||||
|
||||
| Hahmo | Tiedosto | Eläin |
|
||||
|-------|----------|-------|
|
||||
| Asiakas | kettu_notext.png | Kettu |
|
||||
| Manageri | karhunpentu.png | Karhunpentu |
|
||||
| Koodari | kipina_notext.png | Salamanteri |
|
||||
| Data | pesukarhu_notext.png | Pesukarhu |
|
||||
| QA | susi_notext.png | Pikkususi |
|
||||
| DevOps | laiskiainen_notext.png | Laiskiainen |
|
||||
| Tarkkailija | aikuinen_susi.png | Aikuinen susi |
|
||||
| Tofuist | gecko_notext.png | Gecko/Lisko |
|
||||
| Arkkitehti | ??? | (tulossa) |
|
||||
| DevSecOps | ??? | (tulossa) |
|
||||
|
||||
### 5. Docs-kenttä (referenssidokumentti)
|
||||
|
||||
Agentti voi viitata ulkoiseen dokumenttiin joka ladataan promptiin:
|
||||
|
||||
```
|
||||
docs: '/docs/tofu-cheatsheet.md' → haetaan fetch():llä, cachetetaan _docsCache-kenttään
|
||||
```
|
||||
|
||||
**Toiminta:**
|
||||
1. Ensimmäisellä `kpnRun`-kutsulla ladataan docs-URL
|
||||
2. Sisältö cachetetaan `agent._docsCache`-kenttään
|
||||
3. Liitetään promptiin: `"Reference:\n" + docsContent`
|
||||
4. Ei ladata uudelleen saman session aikana
|
||||
|
||||
**Rajoitukset:**
|
||||
- Max ~3000 tokenia (~10 KB) — pidempi docs tiivistetään
|
||||
- Vain tekstitiedostot (.md, .txt)
|
||||
|
||||
### 6. Tallennus (localStorage)
|
||||
|
||||
```js
|
||||
// Tallennusavain
|
||||
'kpn-custom-agents' → JSON.stringify([ agentSkeema1, agentSkeema2, ... ])
|
||||
|
||||
// Ladattaessa
|
||||
const customAgents = JSON.parse(localStorage.getItem('kpn-custom-agents') || '[]');
|
||||
const defaultAgents = { manager: {...}, coder: {...}, ... };
|
||||
const agentPrompts = { ...defaultAgents };
|
||||
for (const agent of customAgents) {
|
||||
agentPrompts[agent.id] = agent;
|
||||
}
|
||||
```
|
||||
|
||||
**Oletusagentit** (manager, coder, tester, qa, data) ovat aina mukana — niitä ei voi poistaa, mutta prompteja voi muokata.
|
||||
|
||||
**Käyttäjäagentit** (tofuist, arkkitehti, devsecops, ...) tallentuvat localStorageen ja latautuvat käynnistyksessä.
|
||||
|
||||
### 7. Export / Import
|
||||
|
||||
```js
|
||||
// Export — JSON-tiedosto
|
||||
const blob = new Blob([JSON.stringify(agent, null, 2)], { type: 'application/json' });
|
||||
// → agent-tofuist.json
|
||||
|
||||
// Import — tiedoston valinta tai drag & drop
|
||||
// Validoidaan skeema, lisätään agentPrompts-objektiin
|
||||
```
|
||||
|
||||
Mahdollistaa agenttien jakamisen tiimin kesken.
|
||||
|
||||
## Toteutusvaiheet
|
||||
|
||||
### Vaihe 1: Hahmolomake UI
|
||||
- Avatar-grid valitsin
|
||||
- Rooli-template alasvetovalikko (täyttää oletuspromptit)
|
||||
- Malli-valitsin
|
||||
- System prompt -tekstikenttä
|
||||
- LLM-parametrit (temperature, top-k, max_tokens)
|
||||
- Tallenna/Poista-napit
|
||||
|
||||
### Vaihe 2: Dynaaminen agenttirekisteri
|
||||
- `agentPrompts` ladataan localStoragesta
|
||||
- Oletusagentit + käyttäjän agentit yhdistetään
|
||||
- Avatar-kortit renderöidään dynaamisesti (ei HTML:ssä)
|
||||
- Värimapit generoidaan agenttiskeemasta
|
||||
|
||||
### Vaihe 3: Pipeline käyttää dynaamisia agentteja
|
||||
- Pipeline-vaiheet viittaavat agentin id:hen (ei kovakoodattuun nimeen)
|
||||
- Käyttäjä voi valita mitkä agentit osallistuvat pipelineen
|
||||
- Tofuist voi korvata DevOpsin IaC-projekteissa
|
||||
|
||||
### Vaihe 4: Mallirekisteri (hub-integraatio)
|
||||
- Hub tarjoaa `/api/models`-endpointin
|
||||
- Saatavilla olevat mallit näkyvät valitsimessa reaaliajassa
|
||||
- Solmun liittyessä/poistuessa mallit päivittyvät
|
||||
|
||||
## Arkkitehtuurikaavio
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────┐
|
||||
│ Agent Builder UI │
|
||||
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
|
||||
│ │ Avatar │ │ Rooli │ │ Malli-valitsin │ │
|
||||
│ │ Grid │ │ Template │ │ (hub/staattinen) │ │
|
||||
│ └────┬─────┘ └────┬─────┘ └────────┬─────────┘ │
|
||||
│ └─────────────┼───────────────┘ │
|
||||
│ ▼ │
|
||||
│ ┌──────────────────────────────────────────────┐ │
|
||||
│ │ Agent Schema { id, name, avatar, model, │ │
|
||||
│ │ role, color, docs, prompt, │ │
|
||||
│ │ params } │ │
|
||||
│ └──────────────────┬───────────────────────────┘ │
|
||||
│ │ │
|
||||
│ ┌─────────────┼─────────────┐ │
|
||||
│ ▼ ▼ ▼ │
|
||||
│ localStorage Org Chart Pipeline │
|
||||
│ (persist) (render) (execute) │
|
||||
└──────────────────────────────────────────────────┘
|
||||
```
|
||||
@@ -1,47 +1,63 @@
|
||||
# syntax=docker/dockerfile:1
|
||||
FROM rust:slim AS builder
|
||||
|
||||
RUN apt-get update && apt-get install -y \
|
||||
curl pkg-config libssl-dev g++ \
|
||||
&& rm -rf /var/lib/apt/lists/*
|
||||
# --- Vaihe 1: Frontend (Astro) ---
|
||||
FROM node:22-slim AS frontend
|
||||
WORKDIR /app/frontend
|
||||
# Riippuvuudet ensin → cache-kerros (muuttuu harvoin)
|
||||
COPY frontend/package.json frontend/package-lock.json* ./
|
||||
RUN npm install --silent
|
||||
# Lähdekoodi → muuttuu usein, mutta npm install on cachessa
|
||||
COPY frontend/ .
|
||||
RUN npm run build
|
||||
|
||||
# --- Vaihe 2: Wasm (wasm-pack) ---
|
||||
FROM rust:slim AS wasm-builder
|
||||
RUN apt-get update && apt-get install -y curl pkg-config libssl-dev g++ && rm -rf /var/lib/apt/lists/*
|
||||
RUN curl https://rustwasm.github.io/wasm-pack/installer/init.sh -sSf | sh
|
||||
|
||||
WORKDIR /app
|
||||
|
||||
# Kopioi kaikki Cargo-tiedostot
|
||||
COPY Cargo.toml ./
|
||||
COPY Cargo.lock* ./
|
||||
COPY Cargo.toml Cargo.lock* ./
|
||||
COPY node/Cargo.toml node/Cargo.toml
|
||||
COPY node/src node/src
|
||||
# Dummy-cratet jotta workspace Cargo.toml on tyytyväinen
|
||||
COPY hub/Cargo.toml hub/Cargo.toml
|
||||
COPY native-node/Cargo.toml native-node/Cargo.toml
|
||||
COPY cli/Cargo.toml cli/Cargo.toml
|
||||
RUN mkdir -p hub/src native-node/src cli/src && touch hub/src/main.rs native-node/src/main.rs cli/src/main.rs
|
||||
RUN --mount=type=cache,target=/usr/local/cargo/registry \
|
||||
--mount=type=cache,target=/app/target \
|
||||
cd node && wasm-pack build --target web --out-dir /app/wasm-pkg
|
||||
|
||||
# --- Vaihe 3: Hub (Rust) ---
|
||||
FROM rust:slim AS hub-builder
|
||||
RUN apt-get update && apt-get install -y pkg-config libssl-dev && rm -rf /var/lib/apt/lists/*
|
||||
WORKDIR /app
|
||||
COPY Cargo.toml Cargo.lock* ./
|
||||
COPY hub/Cargo.toml hub/Cargo.toml
|
||||
COPY hub/src hub/src
|
||||
# Tarvitaan dummy-cratet jotta workspace kompiloi
|
||||
COPY node/Cargo.toml node/Cargo.toml
|
||||
COPY native-node/Cargo.toml native-node/Cargo.toml
|
||||
COPY cli/Cargo.toml cli/Cargo.toml
|
||||
|
||||
# Kopioi lähdekoodi
|
||||
COPY hub/src hub/src
|
||||
COPY node/src node/src
|
||||
COPY native-node/src native-node/src
|
||||
COPY cli/src cli/src
|
||||
COPY static static
|
||||
|
||||
# Rakenna Wasm — cache mount pitää Cargo-rekisterin ja target-kansion buildien välillä
|
||||
RUN --mount=type=cache,target=/usr/local/cargo/registry \
|
||||
--mount=type=cache,target=/app/target \
|
||||
cd node && wasm-pack build --target web --out-dir ../static/pkg
|
||||
|
||||
# Rakenna Hub
|
||||
RUN mkdir -p node/src native-node/src cli/src && touch node/src/lib.rs native-node/src/main.rs cli/src/main.rs
|
||||
RUN --mount=type=cache,target=/usr/local/cargo/registry \
|
||||
--mount=type=cache,target=/app/target \
|
||||
cargo build --release -p hub \
|
||||
&& cp /app/target/release/hub /usr/local/bin/hub
|
||||
|
||||
# --- Vaihe 4: Tuotantoimage ---
|
||||
FROM debian:bookworm-slim
|
||||
RUN apt-get update && apt-get install -y ca-certificates && rm -rf /var/lib/apt/lists/*
|
||||
|
||||
COPY --from=builder /usr/local/bin/hub /usr/local/bin/hub
|
||||
COPY --from=builder /app/static /app/static
|
||||
COPY --from=hub-builder /usr/local/bin/hub /usr/local/bin/hub
|
||||
COPY --from=frontend /app/frontend/dist /app/frontend/dist
|
||||
COPY --from=wasm-builder /app/wasm-pkg /app/frontend/dist/pkg
|
||||
|
||||
# Kopioidaan GUIDE.md ja templates
|
||||
COPY frontend/public/GUIDE.md /app/frontend/dist/GUIDE.md
|
||||
COPY frontend/public/templates /app/frontend/dist/templates
|
||||
COPY frontend/public/avatars /app/frontend/dist/avatars
|
||||
|
||||
WORKDIR /app
|
||||
ENV STATIC_DIR=/app/static
|
||||
ENV STATIC_DIR=/app/frontend/dist
|
||||
EXPOSE 3000
|
||||
CMD ["hub"]
|
||||
|
||||
33
network-poc/deploy-light.sh
Executable file
@@ -0,0 +1,33 @@
|
||||
#!/bin/bash
|
||||
# Kevyt deploy: lähetetään vain koodi, palvelin buildaa itse
|
||||
set -e
|
||||
|
||||
SERVER="ubuntu@86.50.252.98"
|
||||
REMOTE_DIR="~/code/agentic-studio/network-poc"
|
||||
SSH_OPTS="-o StrictHostKeyChecking=no"
|
||||
|
||||
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
|
||||
|
||||
echo "=== Kipinä Studio Deploy (remote build) ==="
|
||||
|
||||
# 1. Synkataan koodi palvelimelle (vain muuttuneet tiedostot)
|
||||
echo "[1/3] Synkataan koodi..."
|
||||
rsync -az --delete \
|
||||
--exclude 'target/' \
|
||||
--exclude 'node_modules/' \
|
||||
--exclude 'dist/' \
|
||||
--exclude '.astro/' \
|
||||
--exclude 'temp/' \
|
||||
--exclude '*.db' \
|
||||
--exclude '.git/' \
|
||||
"$SCRIPT_DIR/" "$SERVER:$REMOTE_DIR/"
|
||||
|
||||
# 2. Rakennetaan image palvelimella
|
||||
echo "[2/3] Rakennetaan image palvelimella..."
|
||||
ssh $SSH_OPTS $SERVER "cd $REMOTE_DIR && docker build -f Dockerfile.prod -t kipina-agentic:latest ."
|
||||
|
||||
# 3. Käynnistetään
|
||||
echo "[3/3] Käynnistetään..."
|
||||
ssh $SSH_OPTS $SERVER "cd $REMOTE_DIR && docker compose -f docker-compose.prod.yml down && docker compose -f docker-compose.prod.yml up -d"
|
||||
|
||||
echo "=== Valmis! https://kipina.studio ==="
|
||||
3
network-poc/frontend/.gitignore
vendored
Normal file
@@ -0,0 +1,3 @@
|
||||
node_modules/
|
||||
dist/
|
||||
.astro/
|
||||
2
network-poc/frontend/astro.config.mjs
Normal file
@@ -0,0 +1,2 @@
|
||||
import { defineConfig } from 'astro/config';
|
||||
export default defineConfig({});
|
||||
4721
network-poc/frontend/package-lock.json
generated
Normal file
13
network-poc/frontend/package.json
Normal file
@@ -0,0 +1,13 @@
|
||||
{
|
||||
"name": "kipina-frontend",
|
||||
"type": "module",
|
||||
"version": "0.1.0",
|
||||
"scripts": {
|
||||
"dev": "astro dev",
|
||||
"build": "astro build",
|
||||
"preview": "astro preview"
|
||||
},
|
||||
"dependencies": {
|
||||
"astro": "^6.1.5"
|
||||
}
|
||||
}
|
||||
BIN
network-poc/frontend/public/avatars/aikuinen_susi.webp
Normal file
|
After Width: | Height: | Size: 9.1 KiB |
BIN
network-poc/frontend/public/avatars/bear.webp
Normal file
|
After Width: | Height: | Size: 10 KiB |
BIN
network-poc/frontend/public/avatars/beaver.webp
Normal file
|
After Width: | Height: | Size: 8.5 KiB |
BIN
network-poc/frontend/public/avatars/chameleon.webp
Normal file
|
After Width: | Height: | Size: 9.1 KiB |
BIN
network-poc/frontend/public/avatars/elephant.webp
Normal file
|
After Width: | Height: | Size: 8.8 KiB |
BIN
network-poc/frontend/public/avatars/gecko.webp
Normal file
|
After Width: | Height: | Size: 8.2 KiB |
BIN
network-poc/frontend/public/avatars/gecko_notext.webp
Normal file
|
After Width: | Height: | Size: 14 KiB |
BIN
network-poc/frontend/public/avatars/karhunpentu.webp
Normal file
|
After Width: | Height: | Size: 5.0 KiB |
BIN
network-poc/frontend/public/avatars/kettu_notext.webp
Normal file
|
After Width: | Height: | Size: 8.3 KiB |
BIN
network-poc/frontend/public/avatars/kipina_notext.webp
Normal file
|
After Width: | Height: | Size: 3.7 KiB |
BIN
network-poc/frontend/public/avatars/laiskiainen.webp
Normal file
|
After Width: | Height: | Size: 6.9 KiB |
BIN
network-poc/frontend/public/avatars/laiskiainen_notext.webp
Normal file
|
After Width: | Height: | Size: 6.0 KiB |
BIN
network-poc/frontend/public/avatars/lion.webp
Normal file
|
After Width: | Height: | Size: 13 KiB |
BIN
network-poc/frontend/public/avatars/mantis.webp
Normal file
|
After Width: | Height: | Size: 10 KiB |
BIN
network-poc/frontend/public/avatars/owl.webp
Normal file
|
After Width: | Height: | Size: 12 KiB |
BIN
network-poc/frontend/public/avatars/penguin.webp
Normal file
|
After Width: | Height: | Size: 8.7 KiB |
BIN
network-poc/frontend/public/avatars/pesukarhu.webp
Normal file
|
After Width: | Height: | Size: 7.6 KiB |
BIN
network-poc/frontend/public/avatars/pesukarhu_notext.webp
Normal file
|
After Width: | Height: | Size: 6.7 KiB |
BIN
network-poc/frontend/public/avatars/serpent.webp
Normal file
|
After Width: | Height: | Size: 9.2 KiB |
BIN
network-poc/frontend/public/avatars/spider.webp
Normal file
|
After Width: | Height: | Size: 9.3 KiB |
BIN
network-poc/frontend/public/avatars/susi_notext.webp
Normal file
|
After Width: | Height: | Size: 6.2 KiB |
BIN
network-poc/frontend/public/avatars/tortoise.webp
Normal file
|
After Width: | Height: | Size: 11 KiB |
BIN
network-poc/frontend/public/avatars/walrus.webp
Normal file
|
After Width: | Height: | Size: 12 KiB |
63
network-poc/frontend/public/pkg/node.d.ts
vendored
Normal file
@@ -0,0 +1,63 @@
|
||||
/* tslint:disable */
|
||||
/* eslint-disable */
|
||||
|
||||
export function set_auto_tasks(enabled: boolean): void;
|
||||
|
||||
export function set_gpu_load(load: number): void;
|
||||
|
||||
export function start_agent_node(hub_url: string, has_webgpu: boolean, device_info_json: string, task_id: number): Promise<void>;
|
||||
|
||||
/**
|
||||
* JS-exportti: tokenisoi tekstin ja palauttaa JSON-merkkijonon
|
||||
* Tokenizer ladataan IndexedDB:stä (täytyy olla ladattu aiemmin)
|
||||
*/
|
||||
export function tokenize_js(text: string): Promise<string>;
|
||||
|
||||
export type InitInput = RequestInfo | URL | Response | BufferSource | WebAssembly.Module;
|
||||
|
||||
export interface InitOutput {
|
||||
readonly memory: WebAssembly.Memory;
|
||||
readonly set_auto_tasks: (a: number) => void;
|
||||
readonly set_gpu_load: (a: number) => void;
|
||||
readonly start_agent_node: (a: number, b: number, c: number, d: number, e: number, f: number) => any;
|
||||
readonly tokenize_js: (a: number, b: number) => any;
|
||||
readonly wasm_bindgen__convert__closures_____invoke__h6ec112f0342d232e: (a: number, b: number, c: any) => [number, number];
|
||||
readonly wasm_bindgen__convert__closures_____invoke__h737e63bacb96714d: (a: number, b: number, c: any, d: any) => void;
|
||||
readonly wasm_bindgen__convert__closures_____invoke__ha390eb51fa5285b4: (a: number, b: number, c: any) => void;
|
||||
readonly wasm_bindgen__convert__closures_____invoke__h9cacd8a9a6ca46c2: (a: number, b: number, c: any) => void;
|
||||
readonly wasm_bindgen__convert__closures_____invoke__ha390eb51fa5285b4_3: (a: number, b: number, c: any) => void;
|
||||
readonly wasm_bindgen__convert__closures_____invoke__h0afc19def95e993a: (a: number, b: number, c: any) => void;
|
||||
readonly wasm_bindgen__convert__closures_____invoke__h0afc19def95e993a_5: (a: number, b: number, c: any) => void;
|
||||
readonly wasm_bindgen__convert__closures_____invoke__h698aa4c8c2e7db1b: (a: number, b: number) => void;
|
||||
readonly __wbindgen_malloc: (a: number, b: number) => number;
|
||||
readonly __wbindgen_realloc: (a: number, b: number, c: number, d: number) => number;
|
||||
readonly __wbindgen_exn_store: (a: number) => void;
|
||||
readonly __externref_table_alloc: () => number;
|
||||
readonly __wbindgen_externrefs: WebAssembly.Table;
|
||||
readonly __wbindgen_free: (a: number, b: number, c: number) => void;
|
||||
readonly __wbindgen_destroy_closure: (a: number, b: number) => void;
|
||||
readonly __externref_table_dealloc: (a: number) => void;
|
||||
readonly __wbindgen_start: () => void;
|
||||
}
|
||||
|
||||
export type SyncInitInput = BufferSource | WebAssembly.Module;
|
||||
|
||||
/**
|
||||
* Instantiates the given `module`, which can either be bytes or
|
||||
* a precompiled `WebAssembly.Module`.
|
||||
*
|
||||
* @param {{ module: SyncInitInput }} module - Passing `SyncInitInput` directly is deprecated.
|
||||
*
|
||||
* @returns {InitOutput}
|
||||
*/
|
||||
export function initSync(module: { module: SyncInitInput } | SyncInitInput): InitOutput;
|
||||
|
||||
/**
|
||||
* If `module_or_path` is {RequestInfo} or {URL}, makes a request and
|
||||
* for everything else, calls `WebAssembly.instantiate` directly.
|
||||
*
|
||||
* @param {{ module_or_path: InitInput | Promise<InitInput> }} module_or_path - Passing `InitInput` directly is deprecated.
|
||||
*
|
||||
* @returns {Promise<InitOutput>}
|
||||
*/
|
||||
export default function __wbg_init (module_or_path?: { module_or_path: InitInput | Promise<InitInput> } | InitInput | Promise<InitInput>): Promise<InitOutput>;
|
||||
1741
network-poc/frontend/public/pkg/node.js
Normal file
BIN
network-poc/frontend/public/pkg/node_bg.wasm
Normal file
24
network-poc/frontend/public/pkg/node_bg.wasm.d.ts
vendored
Normal file
@@ -0,0 +1,24 @@
|
||||
/* tslint:disable */
|
||||
/* eslint-disable */
|
||||
export const memory: WebAssembly.Memory;
|
||||
export const set_auto_tasks: (a: number) => void;
|
||||
export const set_gpu_load: (a: number) => void;
|
||||
export const start_agent_node: (a: number, b: number, c: number, d: number, e: number, f: number) => any;
|
||||
export const tokenize_js: (a: number, b: number) => any;
|
||||
export const wasm_bindgen__convert__closures_____invoke__h6ec112f0342d232e: (a: number, b: number, c: any) => [number, number];
|
||||
export const wasm_bindgen__convert__closures_____invoke__h737e63bacb96714d: (a: number, b: number, c: any, d: any) => void;
|
||||
export const wasm_bindgen__convert__closures_____invoke__ha390eb51fa5285b4: (a: number, b: number, c: any) => void;
|
||||
export const wasm_bindgen__convert__closures_____invoke__h9cacd8a9a6ca46c2: (a: number, b: number, c: any) => void;
|
||||
export const wasm_bindgen__convert__closures_____invoke__ha390eb51fa5285b4_3: (a: number, b: number, c: any) => void;
|
||||
export const wasm_bindgen__convert__closures_____invoke__h0afc19def95e993a: (a: number, b: number, c: any) => void;
|
||||
export const wasm_bindgen__convert__closures_____invoke__h0afc19def95e993a_5: (a: number, b: number, c: any) => void;
|
||||
export const wasm_bindgen__convert__closures_____invoke__h698aa4c8c2e7db1b: (a: number, b: number) => void;
|
||||
export const __wbindgen_malloc: (a: number, b: number) => number;
|
||||
export const __wbindgen_realloc: (a: number, b: number, c: number, d: number) => number;
|
||||
export const __wbindgen_exn_store: (a: number) => void;
|
||||
export const __externref_table_alloc: () => number;
|
||||
export const __wbindgen_externrefs: WebAssembly.Table;
|
||||
export const __wbindgen_free: (a: number, b: number, c: number) => void;
|
||||
export const __wbindgen_destroy_closure: (a: number, b: number) => void;
|
||||
export const __externref_table_dealloc: (a: number) => void;
|
||||
export const __wbindgen_start: () => void;
|
||||
15
network-poc/frontend/public/pkg/package.json
Normal file
@@ -0,0 +1,15 @@
|
||||
{
|
||||
"name": "node",
|
||||
"type": "module",
|
||||
"version": "0.1.0",
|
||||
"files": [
|
||||
"node_bg.wasm",
|
||||
"node.js",
|
||||
"node.d.ts"
|
||||
],
|
||||
"main": "node.js",
|
||||
"types": "node.d.ts",
|
||||
"sideEffects": [
|
||||
"./snippets/*"
|
||||
]
|
||||
}
|
||||
27
network-poc/frontend/public/templates/fastapi-crud.json
Normal file
@@ -0,0 +1,27 @@
|
||||
{
|
||||
"name": "FastAPI CRUD",
|
||||
"description": "REST API with SQLite database",
|
||||
"files": {
|
||||
"models.py": {
|
||||
"description": "SQLAlchemy models, engine, and session",
|
||||
"example": "from sqlalchemy import create_engine, Column, Integer, String\nfrom sqlalchemy.ext.declarative import declarative_base\nfrom sqlalchemy.orm import sessionmaker\n\nDATABASE_URL = \"sqlite:///./app.db\"\nengine = create_engine(DATABASE_URL, connect_args={\"check_same_thread\": False})\nSessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)\nBase = declarative_base()\n\nclass Item(Base):\n __tablename__ = \"items\"\n id = Column(Integer, primary_key=True, index=True)\n name = Column(String(100), nullable=False)\n description = Column(String(500))",
|
||||
"instructions": "Define the SQLAlchemy model based on the project description. Always include:\n- engine with check_same_thread=False for SQLite\n- SessionLocal with autocommit=False\n- Base = declarative_base()\n- Model class with __tablename__, primary key, and fields"
|
||||
},
|
||||
"schemas.py": {
|
||||
"description": "Pydantic request/response schemas",
|
||||
"example": "from pydantic import BaseModel\n\nclass ItemCreate(BaseModel):\n name: str\n description: str | None = None\n\nclass ItemResponse(ItemCreate):\n id: int\n\n class Config:\n from_attributes = True",
|
||||
"instructions": "Create Pydantic schemas that match the SQLAlchemy model:\n- Create schema: fields without id (user provides these)\n- Response schema: inherits from Create, adds id\n- Add class Config with from_attributes = True (required for SQLAlchemy ORM)"
|
||||
},
|
||||
"main.py": {
|
||||
"description": "FastAPI app with CRUD endpoints",
|
||||
"example": "from fastapi import FastAPI, Depends, HTTPException\nfrom sqlalchemy.orm import Session\nfrom models import Base, engine, SessionLocal, Item\nfrom schemas import ItemCreate, ItemResponse\n\nBase.metadata.create_all(bind=engine)\napp = FastAPI()\n\ndef get_db():\n db = SessionLocal()\n try:\n yield db\n finally:\n db.close()\n\n@app.post(\"/items/\", response_model=ItemResponse, status_code=201)\ndef create_item(item: ItemCreate, db: Session = Depends(get_db)):\n db_item = Item(**item.model_dump())\n db.add(db_item)\n db.commit()\n db.refresh(db_item)\n return db_item\n\n@app.get(\"/items/\", response_model=list[ItemResponse])\ndef list_items(db: Session = Depends(get_db)):\n return db.query(Item).all()\n\n@app.get(\"/items/{item_id}\", response_model=ItemResponse)\ndef get_item(item_id: int, db: Session = Depends(get_db)):\n item = db.query(Item).filter(Item.id == item_id).first()\n if not item:\n raise HTTPException(status_code=404, detail=\"Not found\")\n return item\n\n@app.put(\"/items/{item_id}\", response_model=ItemResponse)\ndef update_item(item_id: int, item: ItemCreate, db: Session = Depends(get_db)):\n db_item = db.query(Item).filter(Item.id == item_id).first()\n if not db_item:\n raise HTTPException(status_code=404, detail=\"Not found\")\n for key, value in item.model_dump().items():\n setattr(db_item, key, value)\n db.commit()\n db.refresh(db_item)\n return db_item\n\n@app.delete(\"/items/{item_id}\", status_code=204)\ndef delete_item(item_id: int, db: Session = Depends(get_db)):\n db_item = db.query(Item).filter(Item.id == item_id).first()\n if not db_item:\n raise HTTPException(status_code=404, detail=\"Not found\")\n db.delete(db_item)\n db.commit()",
|
||||
"instructions": "Create the FastAPI app with all CRUD endpoints:\n- Import from models.py and schemas.py (use exact class names)\n- create_all(bind=engine) at module level\n- get_db dependency with yield pattern\n- POST (201), GET list, GET by id, PUT, DELETE (204)\n- Use response_model for type safety\n- Use model_dump() not dict() (Pydantic v2)"
|
||||
},
|
||||
"pyproject.toml": {
|
||||
"description": "Project dependencies",
|
||||
"example": "[project]\nname = \"myapp\"\nversion = \"0.1.0\"\nrequires-python = \">=3.11\"\ndependencies = [\n \"fastapi\",\n \"uvicorn[standard]\",\n \"sqlalchemy\",\n]\n\n[project.scripts]\ndev = \"uvicorn main:app --reload\"",
|
||||
"instructions": "Use [project] format (PEP 621, compatible with uv). List dependencies under [project.dependencies]. Add [project.scripts] with dev command. Never use requirements.txt or Poetry format. Run with: uv run uvicorn main:app --reload"
|
||||
}
|
||||
},
|
||||
"order": ["models.py", "schemas.py", "main.py", "pyproject.toml"]
|
||||
}
|
||||
79
network-poc/frontend/src/components/AgentBar.astro
Normal file
@@ -0,0 +1,79 @@
|
||||
<!-- Agenttigalleria + konfigurointipaneeli -->
|
||||
<div style="display:flex;gap:16px;padding:10px 0;align-items:flex-start">
|
||||
<!-- Agenttilista (drag & drop) -->
|
||||
<div id="agent-bar" style="display:flex;gap:6px;align-items:flex-end;flex-wrap:wrap">
|
||||
<!-- Renderöidään JS:stä -->
|
||||
</div>
|
||||
<!-- + Lisää agentti -->
|
||||
<div id="add-agent-btn" class="agent-avatar" onclick="addCustomAgent()" title="Lisää oma agentti" style="opacity:0.4">
|
||||
<div style="width:48px;height:48px;border-radius:50%;border:2px dashed var(--border);display:flex;align-items:center;justify-content:center;font-size:24px;color:var(--border)">+</div>
|
||||
<span style="font-size:10px;color:#8b949e;text-align:center;display:block">Lisää</span>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- Agentin konfigurointipaneeli (avautuu klikkaamalla avataria) -->
|
||||
<div id="agent-config" style="display:none;background:var(--panel);border:1px solid var(--border);border-radius:6px;padding:16px;margin-bottom:10px">
|
||||
<div style="display:flex;justify-content:space-between;align-items:center;margin-bottom:12px">
|
||||
<div style="display:flex;align-items:center;gap:10px">
|
||||
<img id="config-avatar" src="" style="width:40px;height:40px;border-radius:50%">
|
||||
<div>
|
||||
<input id="config-name" style="background:transparent;border:none;color:var(--text);font-size:16px;font-weight:600;outline:none;width:200px" placeholder="Agentin nimi">
|
||||
<div id="config-role" style="font-size:11px;color:#8b949e"></div>
|
||||
</div>
|
||||
</div>
|
||||
<div style="display:flex;gap:6px">
|
||||
<button class="btn btn-red" onclick="deleteAgent()" title="Poista agentti">Poista</button>
|
||||
<button class="btn btn-muted" onclick="closeAgentConfig()">Sulje</button>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- Malli -->
|
||||
<div style="margin-bottom:10px">
|
||||
<label style="font-size:12px;color:#8b949e;display:block;margin-bottom:4px">Kielimalli</label>
|
||||
<select id="config-model" style="background:var(--bg);color:var(--text);border:1px solid var(--border);border-radius:4px;padding:6px 10px;font-size:13px;width:100%">
|
||||
<option value="qwen-coder">Qwen2.5-Coder:0.5B (selain)</option>
|
||||
<option value="qwen-coder-3b">Qwen2.5-Coder:3B (Ollama)</option>
|
||||
<option value="qwen2.5-coder:7b">Qwen2.5-Coder:7B (Ollama)</option>
|
||||
<option value="qwen2.5-coder:1.5b">Qwen2.5-Coder:1.5B (Ollama)</option>
|
||||
</select>
|
||||
</div>
|
||||
|
||||
<!-- System prompt -->
|
||||
<div style="margin-bottom:10px" title="Agentin perusohje joka lähetetään kielimallille jokaisessa pyynnössä. Hyvän promptin rakenne: 1. Rooli: 'You are an expert...' 2. Säännöt: RULES/CRITICAL RULES listana 3. Esimerkit: EXAMPLE OUTPUT 4. Kiellot: NEVER-lista Vinkki: käytä englantia — malli ymmärtää sen paremmin ja se kuluttaa vähemmän tokeneita.">
|
||||
<label style="font-size:12px;color:#8b949e;display:block;margin-bottom:4px;cursor:help">System prompt 💡</label>
|
||||
<textarea id="config-prompt" style="width:100%;background:var(--bg);color:var(--text);border:1px solid var(--border);border-radius:4px;padding:8px;font-size:13px;font-family:'Courier New',monospace;resize:vertical;overflow:hidden;min-height:60px" placeholder="Kuvaa agentin rooli ja käyttäytyminen..."></textarea>
|
||||
</div>
|
||||
|
||||
<!-- Sampling-parametrit -->
|
||||
<div style="margin-bottom:10px">
|
||||
<label style="font-size:12px;color:#8b949e;display:block;margin-bottom:8px">Sampling-parametrit</label>
|
||||
<div style="display:grid;grid-template-columns:1fr 1fr;gap:10px">
|
||||
<div title="Kontrolloi 'luovuutta'. Matala arvo (0.2-0.4) tuottaa ennustettavaa, toistettavaa koodia — hyvä testaajille ja reviewereille. Keskiarvo (0.6-0.8) on paras koodin generointiin. Korkea arvo (1.0+) lisää vaihtelua mutta myös virheitä. Suositus: • Manageri: 0.5 (tarkat tiedostolistat) • Koodari: 0.7 (toimiva koodi + vaihtelu) • Testaaja: 0.3 (deterministinen arviointi)">
|
||||
<label style="font-size:11px;color:#8b949e;cursor:help">Temperature 💡 <span id="config-temp-val" style="color:var(--accent);float:right">0.7</span></label>
|
||||
<input type="range" id="config-temperature" min="0" max="1.5" step="0.1" value="0.7" style="width:100%;accent-color:var(--accent)">
|
||||
<div style="font-size:10px;color:#30363d">0=tarkka · 0.7=oletus · 1.5=luova</div>
|
||||
</div>
|
||||
<div title="Vastauksen maksimipituus tokeneina (~1 token ≈ 4 merkkiä). Suositus: • Manageri: 256-512 (lyhyet tiedostolistat) • Koodari: 1024-2048 (täydet tiedostot, CRUD-endpointit) • Testaaja: 256-512 (lyhyet arvioinnit) Jos koodi katkeaa kesken, nosta tätä. Jos malli tuottaa turhaa toistoa, laske.">
|
||||
<label style="font-size:11px;color:#8b949e;cursor:help">Max tokens 💡 <span id="config-maxtok-val" style="color:var(--accent);float:right">1024</span></label>
|
||||
<input type="range" id="config-maxtokens" min="64" max="4096" step="64" value="1024" style="width:100%;accent-color:var(--accent)">
|
||||
<div style="font-size:10px;color:#30363d">Vastauksen maksimipituus</div>
|
||||
</div>
|
||||
<div title="Montako todennäköisintä tokenia huomioidaan valinnassa. Pieni arvo (1-10) tekee vastauksesta deterministisen. Suuri arvo (50-100) sallii harvinaisempia sanoja. Suositus: • Boilerplate-koodi: 20-30 (tutut patternit) • Yleiskoodi: 40 (hyvä oletus) • Luova teksti: 60-80 Yleensä ei tarvitse muuttaa oletuksesta.">
|
||||
<label style="font-size:11px;color:#8b949e;cursor:help">Top-K 💡 <span id="config-topk-val" style="color:var(--accent);float:right">40</span></label>
|
||||
<input type="range" id="config-topk" min="1" max="100" step="1" value="40" style="width:100%;accent-color:var(--accent)">
|
||||
<div style="font-size:10px;color:#30363d">1=greedy · 40=oletus · 100=laaja</div>
|
||||
</div>
|
||||
<div title="Vähentää jo tuotettujen sanojen todennäköisyyttä. Estää mallia toistamasta samaa lausetta. Liian korkea arvo (>1.5) voi rikkoa koodin koska samat avainsanat (return, if, def) ovat tarpeellisia. Suositus: • Koodi: 1.1-1.2 (lievä, sallii toiston) • Teksti: 1.15-1.3 (vahvempi) • Review: 1.0-1.1 (ei rangaistusta, lyhyet vastaukset)">
|
||||
<label style="font-size:11px;color:#8b949e;cursor:help">Repetition penalty 💡 <span id="config-rep-val" style="color:var(--accent);float:right">1.15</span></label>
|
||||
<input type="range" id="config-repeat" min="1.0" max="2.0" step="0.05" value="1.15" style="width:100%;accent-color:var(--accent)">
|
||||
<div style="font-size:10px;color:#30363d">1.0=ei · 1.15=oletus · 2.0=vahva</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- Pipeline-järjestys -->
|
||||
<div>
|
||||
<label style="font-size:12px;color:#8b949e;display:block;margin-bottom:4px">Pipeline-järjestys <span style="color:var(--border)">(vedä järjestääksesi)</span></label>
|
||||
<div id="config-pipeline" style="display:flex;gap:4px;flex-wrap:wrap"></div>
|
||||
</div>
|
||||
</div>
|
||||
15
network-poc/frontend/src/components/Editor.astro
Normal file
@@ -0,0 +1,15 @@
|
||||
<!-- Monaco Editor paneeli -->
|
||||
<div id="panel-editor" class="panel">
|
||||
<div style="display:flex;height:calc(100vh - 200px);gap:0;border:1px solid var(--border);border-radius:6px;overflow:hidden">
|
||||
<div id="editor-filetree" style="width:200px;min-width:150px;background:var(--bg);border-right:1px solid var(--border);overflow-y:auto;font-family:'Courier New',monospace;font-size:13px">
|
||||
<div style="padding:10px 12px;color:#8b949e;font-size:11px;text-transform:uppercase;letter-spacing:0.5px;border-bottom:1px solid var(--border)">Tiedostot</div>
|
||||
<div id="editor-file-list" style="padding:4px 0">
|
||||
<div style="padding:8px 16px;color:#8b949e;font-size:12px">Generoi projekti:<br><code style="color:var(--accent)">kpn project "..."</code></div>
|
||||
</div>
|
||||
</div>
|
||||
<div style="flex:1;display:flex;flex-direction:column">
|
||||
<div id="editor-tabs" style="display:flex;background:var(--bg);border-bottom:1px solid var(--border);min-height:35px;align-items:flex-end;padding:0 8px;gap:2px;overflow-x:auto"></div>
|
||||
<div id="monaco-container" style="flex:1"></div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
6
network-poc/frontend/src/components/Guide.astro
Normal file
@@ -0,0 +1,6 @@
|
||||
<!-- Opas-paneeli: ladataan GUIDE.md fetchillä -->
|
||||
<div id="panel-guide" class="panel">
|
||||
<div id="guide-content" style="max-width:800px;margin:0 auto;padding:20px;line-height:1.7;font-size:15px">
|
||||
<p style="color:#8b949e">Ladataan opasta...</p>
|
||||
</div>
|
||||
</div>
|
||||
67
network-poc/frontend/src/components/Settings.astro
Normal file
@@ -0,0 +1,67 @@
|
||||
<!-- Asetukset-paneeli: kaikki LLM-parametrit muokattavissa -->
|
||||
<div id="panel-settings" class="panel">
|
||||
<div style="max-width:800px;margin:0 auto;padding:20px">
|
||||
<h2 style="color:#e6edf3;margin-bottom:16px">Asetukset</h2>
|
||||
<p style="color:#8b949e;margin-bottom:20px;font-size:14px">Kaikki kielimallin toimintaan vaikuttavat parametrit. Muutokset tallentuvat automaattisesti.</p>
|
||||
|
||||
<!-- System prompt -->
|
||||
<div class="settings-section">
|
||||
<h3 class="settings-title">System Prompt</h3>
|
||||
<p class="settings-desc">Kielimallin perusohje joka lähetetään jokaisessa pyynnössä. Määrittää mallin käyttäytymisen.</p>
|
||||
<textarea id="set-system-prompt" class="settings-textarea" rows="4"></textarea>
|
||||
</div>
|
||||
|
||||
<!-- Sampling -->
|
||||
<div class="settings-section">
|
||||
<h3 class="settings-title">Sampling-parametrit</h3>
|
||||
<p class="settings-desc">Kontrolloi miten malli valitsee seuraavan tokenin. <a href="#guide" onclick="switchTab('guide')" style="color:var(--accent)">Lue lisää oppaasta.</a></p>
|
||||
<div class="settings-grid">
|
||||
<div>
|
||||
<label class="settings-label">Temperature <span id="set-temp-val" class="settings-val">0.7</span></label>
|
||||
<input type="range" id="set-temperature" min="0" max="1.5" step="0.1" value="0.7" class="settings-slider">
|
||||
<div class="settings-hint">0 = deterministic, 0.7 = balanced, 1.5 = creative</div>
|
||||
</div>
|
||||
<div>
|
||||
<label class="settings-label">Top-K <span id="set-topk-val" class="settings-val">40</span></label>
|
||||
<input type="range" id="set-topk" min="1" max="100" step="1" value="40" class="settings-slider">
|
||||
<div class="settings-hint">Montako tokenia huomioidaan. 1 = greedy, 40 = oletus</div>
|
||||
</div>
|
||||
<div>
|
||||
<label class="settings-label">Repetition Penalty <span id="set-rep-val" class="settings-val">1.15</span></label>
|
||||
<input type="range" id="set-repeat" min="1.0" max="2.0" step="0.05" value="1.15" class="settings-slider">
|
||||
<div class="settings-hint">Estää toistoa. 1.0 = ei rangaistusta, 1.15 = oletus</div>
|
||||
</div>
|
||||
<div>
|
||||
<label class="settings-label">Max Tokens <span id="set-maxtok-val" class="settings-val">1024</span></label>
|
||||
<input type="range" id="set-maxtokens" min="64" max="4096" step="64" value="1024" class="settings-slider">
|
||||
<div class="settings-hint">Vastauksen maksimipituus tokeneina</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- Stop-sekvenssit -->
|
||||
<div class="settings-section">
|
||||
<h3 class="settings-title">Stop-sekvenssit</h3>
|
||||
<p class="settings-desc">Generointi katkeaa kun malli tuottaa jonkin näistä. Yksi per rivi.</p>
|
||||
<textarea id="set-stop-sequences" class="settings-textarea" rows="4"></textarea>
|
||||
</div>
|
||||
|
||||
<!-- Malli -->
|
||||
<div class="settings-section">
|
||||
<h3 class="settings-title">Malli (Ollama)</h3>
|
||||
<p class="settings-desc">Natiivisolmun käyttämä kielimalli. Muutos vaatii native-noden uudelleenkäynnistyksen.</p>
|
||||
<select id="set-model" class="settings-select">
|
||||
<option value="qwen2.5-coder:1.5b">Qwen2.5-Coder:1.5B (~80 tok/s, ~1GB)</option>
|
||||
<option value="qwen2.5-coder:3b">Qwen2.5-Coder:3B (~50 tok/s, ~2GB)</option>
|
||||
<option value="qwen2.5-coder:7b-instruct-q4_K_M">Qwen2.5-Coder:7B Q4 (~30 tok/s, ~4GB)</option>
|
||||
<option value="qwen2.5-coder:7b">Qwen2.5-Coder:7B (~20 tok/s, ~7GB)</option>
|
||||
</select>
|
||||
</div>
|
||||
|
||||
<!-- Reset -->
|
||||
<div style="margin-top:24px;padding-top:16px;border-top:1px solid var(--border)">
|
||||
<button class="btn btn-red" onclick="resetSettings()" style="padding:6px 16px">Palauta oletukset</button>
|
||||
<span style="color:#8b949e;font-size:12px;margin-left:8px">Palauttaa kaikki parametrit oletusarvoihin</span>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
15
network-poc/frontend/src/components/StatusBar.astro
Normal file
@@ -0,0 +1,15 @@
|
||||
<!-- Hub-yhteys + laskentasolmun tila -->
|
||||
<div class="status-bar">
|
||||
<span class="status-group" title="Hub-yhteyden tila">
|
||||
<span id="hub-dot" class="status-dot" style="background:#d29922"></span>
|
||||
<span style="color:#8b949e">Hub:</span>
|
||||
<span id="hub-label" style="color:#d29922">Yhdistetään...</span>
|
||||
</span>
|
||||
<span class="status-separator">│</span>
|
||||
<span class="status-group">
|
||||
<span id="compute-dot" class="status-dot" style="background:#30363d"></span>
|
||||
<span style="color:#8b949e">Laskenta:</span>
|
||||
<span id="compute-label" style="color:#8b949e">—</span>
|
||||
<button id="compute-btn" class="btn btn-accent" title="Käynnistä kielimalli">Alusta</button>
|
||||
</span>
|
||||
</div>
|
||||
10
network-poc/frontend/src/components/Terminal.astro
Normal file
@@ -0,0 +1,10 @@
|
||||
<!-- Pipeline-palkki + Terminaali + Input -->
|
||||
<div id="pipeline-bar" class="pipeline-bar"></div>
|
||||
<div id="terminal" class="terminal"></div>
|
||||
<div class="terminal-input-row">
|
||||
<span class="terminal-prompt">$</span>
|
||||
<input id="term-input" class="terminal-input" type="text"
|
||||
placeholder='kpn run coder "hello world in python"'
|
||||
spellcheck="false" autocomplete="off">
|
||||
<div id="term-dropdown" class="terminal-dropdown"></div>
|
||||
</div>
|
||||
1219
network-poc/frontend/src/pages/index.astro
Normal file
198
network-poc/frontend/src/styles/global.css
Normal file
@@ -0,0 +1,198 @@
|
||||
:root {
|
||||
--bg: #0d1117;
|
||||
--panel: #161b22;
|
||||
--text: #c9d1d9;
|
||||
--accent: #58a6ff;
|
||||
--green: #3fb950;
|
||||
--yellow: #d29922;
|
||||
--red: #f85149;
|
||||
--purple: #a371f7;
|
||||
--border: #30363d;
|
||||
}
|
||||
|
||||
* { box-sizing: border-box; margin: 0; padding: 0; }
|
||||
|
||||
body {
|
||||
font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
|
||||
background: var(--bg);
|
||||
color: var(--text);
|
||||
min-height: 100vh;
|
||||
}
|
||||
|
||||
.container { max-width: 1200px; margin: 0 auto; padding: 20px; }
|
||||
|
||||
/* Tabs */
|
||||
.tabs { display: flex; gap: 4px; margin-bottom: 16px; }
|
||||
.tab {
|
||||
padding: 8px 16px; border-radius: 6px 6px 0 0; cursor: pointer;
|
||||
border: 1px solid var(--border); border-bottom: none;
|
||||
background: var(--bg); color: #8b949e; font-size: 14px;
|
||||
}
|
||||
.tab.active { background: var(--panel); color: var(--accent); border-color: var(--border); }
|
||||
|
||||
/* Panels */
|
||||
.panel { display: none; }
|
||||
.panel.active { display: block; }
|
||||
|
||||
/* Status bar */
|
||||
.status-bar {
|
||||
display: flex; align-items: center; gap: 12px;
|
||||
padding: 8px 14px; background: var(--bg);
|
||||
border: 1px solid var(--border); border-radius: 6px 6px 0 0;
|
||||
font-family: 'Courier New', monospace; font-size: 13px;
|
||||
}
|
||||
.status-dot {
|
||||
width: 8px; height: 8px; border-radius: 50%; display: inline-block;
|
||||
}
|
||||
.status-group { display: flex; align-items: center; gap: 6px; }
|
||||
.status-separator { color: var(--border); }
|
||||
|
||||
/* Terminal */
|
||||
.terminal {
|
||||
background: #010409; border: 1px solid var(--border); border-top: none;
|
||||
font-family: 'Courier New', monospace; font-size: 14px;
|
||||
min-height: 300px; max-height: 60vh; overflow-y: auto;
|
||||
padding: 8px 12px;
|
||||
}
|
||||
.terminal-line { padding: 1px 0; white-space: pre-wrap; word-break: break-word; }
|
||||
.terminal-prompt { color: var(--yellow); margin-right: 8px; }
|
||||
.terminal-input-row {
|
||||
display: flex; align-items: center; position: relative;
|
||||
background: #010409; border: 1px solid var(--border); border-top: none;
|
||||
border-radius: 0 0 6px 6px; padding: 8px 12px;
|
||||
font-family: 'Courier New', monospace; font-size: 14px;
|
||||
}
|
||||
.terminal-input {
|
||||
flex: 1; background: transparent; border: none; outline: none;
|
||||
color: var(--green); font-family: inherit; font-size: inherit;
|
||||
}
|
||||
.terminal-dropdown {
|
||||
display: none; position: absolute; bottom: 100%; left: 30px;
|
||||
background: var(--panel); border: 1px solid var(--border);
|
||||
border-radius: 6px; max-height: 200px; overflow-y: auto;
|
||||
font-size: 13px; min-width: 200px; z-index: 100;
|
||||
box-shadow: 0 4px 12px rgba(0,0,0,0.4);
|
||||
}
|
||||
.dd-item {
|
||||
padding: 6px 12px; cursor: pointer; color: var(--text);
|
||||
white-space: nowrap; border-bottom: 1px solid #21262d;
|
||||
}
|
||||
.dd-item:hover, .dd-item.active { background: var(--border); color: var(--accent); }
|
||||
|
||||
/* Pipeline progress */
|
||||
.pipeline-bar {
|
||||
display: none; padding: 8px 14px; background: var(--bg);
|
||||
border: 1px solid var(--border); border-top: none;
|
||||
font-family: 'Courier New', monospace; font-size: 12px;
|
||||
overflow-x: auto; white-space: nowrap;
|
||||
}
|
||||
|
||||
/* Project card */
|
||||
.project-card {
|
||||
margin: 8px 0; border: 1px solid var(--border);
|
||||
border-radius: 6px; background: var(--panel); overflow: hidden;
|
||||
}
|
||||
.project-header {
|
||||
display: flex; align-items: center; justify-content: space-between;
|
||||
padding: 8px 12px; background: var(--bg); border-bottom: 1px solid var(--border);
|
||||
}
|
||||
.project-tabs { display: flex; gap: 2px; padding: 6px 8px 0; background: var(--bg); }
|
||||
.project-tab {
|
||||
padding: 4px 10px; cursor: pointer; border-radius: 4px 4px 0 0;
|
||||
font-size: 12px; color: #8b949e;
|
||||
}
|
||||
.project-tab.active { background: var(--panel); color: var(--accent); border: 1px solid var(--border); border-bottom: none; }
|
||||
|
||||
/* Buttons */
|
||||
.btn {
|
||||
padding: 2px 10px; border-radius: 4px;
|
||||
border: 1px solid var(--border); background: var(--panel);
|
||||
font-size: 12px; font-family: inherit; cursor: pointer;
|
||||
}
|
||||
.btn-accent { color: var(--accent); }
|
||||
.btn-green { color: var(--green); border-color: var(--green); }
|
||||
.btn-red { color: var(--red); border-color: var(--red); }
|
||||
.btn-muted { color: #8b949e; background: none; }
|
||||
|
||||
/* Code display */
|
||||
.code-block {
|
||||
font-family: 'Courier New', monospace; background: #010409;
|
||||
border: 1px solid var(--border); border-radius: 6px;
|
||||
padding: 14px; font-size: 13px; line-height: 1.6;
|
||||
white-space: pre-wrap; overflow-x: auto; max-height: 400px; overflow-y: auto;
|
||||
}
|
||||
.code-block .hljs { background: transparent; padding: 0; }
|
||||
|
||||
/* Agent avatars */
|
||||
.agent-avatar {
|
||||
background: linear-gradient(145deg, rgba(33,38,45,0.4) 0%, rgba(13,17,23,0.8) 100%);
|
||||
backdrop-filter: blur(12px);
|
||||
border: 1px solid rgba(240,246,252,0.1);
|
||||
border-radius: 12px;
|
||||
padding: 6px 6px 4px;
|
||||
text-align: center;
|
||||
width: 72px;
|
||||
opacity: 0.8;
|
||||
cursor: pointer;
|
||||
transition: all 0.4s cubic-bezier(0.175, 0.885, 0.32, 1.275);
|
||||
box-shadow: 0 4px 8px rgba(0,0,0,0.3);
|
||||
}
|
||||
.agent-avatar:hover {
|
||||
opacity: 0.85;
|
||||
transform: translateY(-2px) scale(1.02);
|
||||
border-color: rgba(240,246,252,0.3);
|
||||
box-shadow: 0 8px 14px rgba(0,0,0,0.4);
|
||||
}
|
||||
.agent-avatar img {
|
||||
width: 50px; height: 50px; border-radius: 12px;
|
||||
margin-bottom: 4px; border: 2px solid rgba(240,246,252,0.1);
|
||||
transition: all 0.4s ease; object-fit: cover;
|
||||
}
|
||||
.agent-avatar .avatar-name {
|
||||
font-size: 10px; color: #8b949e; white-space: nowrap;
|
||||
overflow: hidden; text-overflow: ellipsis;
|
||||
}
|
||||
.agent-avatar.active {
|
||||
opacity: 1;
|
||||
transform: translateY(-8px) scale(1.05);
|
||||
border-color: var(--accent);
|
||||
background: linear-gradient(145deg, rgba(88,166,255,0.15) 0%, rgba(13,17,23,0.9) 100%);
|
||||
box-shadow: 0 16px 24px rgba(0,0,0,0.5), 0 0 20px rgba(88,166,255,0.3);
|
||||
z-index: 2;
|
||||
}
|
||||
.agent-avatar.active img {
|
||||
border-color: var(--accent);
|
||||
box-shadow: 0 0 25px rgba(88,166,255,0.8);
|
||||
}
|
||||
|
||||
/* Settings */
|
||||
.settings-section {
|
||||
margin-bottom: 24px; padding: 16px; background: var(--panel);
|
||||
border: 1px solid var(--border); border-radius: 6px;
|
||||
}
|
||||
.settings-title { color: #e6edf3; font-size: 15px; margin-bottom: 4px; }
|
||||
.settings-desc { color: #8b949e; font-size: 13px; margin-bottom: 12px; }
|
||||
.settings-label { color: var(--text); font-size: 13px; display: block; margin-bottom: 4px; }
|
||||
.settings-val { color: var(--accent); font-weight: 600; float: right; }
|
||||
.settings-hint { color: #8b949e; font-size: 11px; margin-top: 2px; }
|
||||
.settings-textarea {
|
||||
width: 100%; background: var(--bg); color: var(--text);
|
||||
border: 1px solid var(--border); border-radius: 4px;
|
||||
padding: 8px; font-size: 13px; font-family: 'Courier New', monospace;
|
||||
resize: vertical;
|
||||
}
|
||||
.settings-select {
|
||||
width: 100%; background: var(--bg); color: var(--text);
|
||||
border: 1px solid var(--border); border-radius: 4px;
|
||||
padding: 8px; font-size: 13px;
|
||||
}
|
||||
.settings-slider {
|
||||
width: 100%; accent-color: var(--accent);
|
||||
}
|
||||
.settings-grid {
|
||||
display: grid; grid-template-columns: 1fr 1fr; gap: 16px;
|
||||
}
|
||||
|
||||
/* Animations */
|
||||
@keyframes blink { 0%,100% { opacity:1 } 50% { opacity:0 } }
|
||||
@keyframes spin { to { transform: rotate(360deg) } }
|
||||
1
network-poc/frontend/tsconfig.json
Normal file
@@ -0,0 +1 @@
|
||||
{ "extends": "astro/tsconfigs/strict" }
|
||||
@@ -1,6 +1,6 @@
|
||||
[package]
|
||||
name = "hub"
|
||||
version = "0.2.4"
|
||||
version = "0.3.1"
|
||||
edition = "2024"
|
||||
|
||||
[dependencies]
|
||||
|
||||
@@ -26,6 +26,29 @@ impl NodeDb {
|
||||
INSERT INTO _schema_version VALUES (2);
|
||||
");
|
||||
}
|
||||
if version < 3 {
|
||||
let _ = conn.execute_batch("
|
||||
CREATE TABLE IF NOT EXISTS agents (
|
||||
id TEXT PRIMARY KEY,
|
||||
name TEXT NOT NULL,
|
||||
avatar TEXT NOT NULL DEFAULT '/avatars/kipina_notext.png',
|
||||
role TEXT NOT NULL DEFAULT 'coder',
|
||||
model TEXT NOT NULL DEFAULT 'qwen2.5-coder:7b',
|
||||
color TEXT NOT NULL DEFAULT '#3fb950',
|
||||
docs TEXT,
|
||||
prompt TEXT NOT NULL DEFAULT '',
|
||||
temperature REAL DEFAULT 0.7,
|
||||
top_k INTEGER DEFAULT 40,
|
||||
max_tokens INTEGER DEFAULT 512,
|
||||
repetition_penalty REAL DEFAULT 1.15,
|
||||
is_default BOOLEAN DEFAULT 0,
|
||||
created_at TEXT NOT NULL,
|
||||
updated_at TEXT NOT NULL
|
||||
);
|
||||
DELETE FROM _schema_version;
|
||||
INSERT INTO _schema_version VALUES (3);
|
||||
");
|
||||
}
|
||||
|
||||
conn.execute_batch("
|
||||
CREATE TABLE IF NOT EXISTS node_sessions (
|
||||
@@ -279,6 +302,82 @@ impl NodeDb {
|
||||
})
|
||||
}
|
||||
|
||||
// ── Agents CRUD ──
|
||||
|
||||
pub fn upsert_agent(&self, agent: &serde_json::Value) -> Result<(), String> {
|
||||
let conn = self.conn.lock().unwrap_or_else(|e| e.into_inner());
|
||||
let now = chrono::Utc::now().to_rfc3339();
|
||||
let id = agent.get("id").and_then(|v| v.as_str()).ok_or("id puuttuu")?;
|
||||
let name = agent.get("name").and_then(|v| v.as_str()).ok_or("name puuttuu")?;
|
||||
conn.execute(
|
||||
"INSERT INTO agents (id, name, avatar, role, model, color, docs, prompt,
|
||||
temperature, top_k, max_tokens, repetition_penalty, is_default, created_at, updated_at)
|
||||
VALUES (?1,?2,?3,?4,?5,?6,?7,?8,?9,?10,?11,?12,?13,?14,?14)
|
||||
ON CONFLICT(id) DO UPDATE SET
|
||||
name=?2, avatar=?3, role=?4, model=?5, color=?6, docs=?7, prompt=?8,
|
||||
temperature=?9, top_k=?10, max_tokens=?11, repetition_penalty=?12, updated_at=?14",
|
||||
params![
|
||||
id, name,
|
||||
agent.get("avatar").and_then(|v| v.as_str()).unwrap_or("/avatars/kipina_notext.png"),
|
||||
agent.get("role").and_then(|v| v.as_str()).unwrap_or("coder"),
|
||||
agent.get("model").and_then(|v| v.as_str()).unwrap_or("qwen2.5-coder:7b"),
|
||||
agent.get("color").and_then(|v| v.as_str()).unwrap_or("#3fb950"),
|
||||
agent.get("docs").and_then(|v| v.as_str()),
|
||||
agent.get("prompt").and_then(|v| v.as_str()).unwrap_or(""),
|
||||
agent.get("temperature").and_then(|v| v.as_f64()).unwrap_or(0.7),
|
||||
agent.get("top_k").and_then(|v| v.as_u64()).unwrap_or(40) as i64,
|
||||
agent.get("max_tokens").and_then(|v| v.as_u64()).unwrap_or(512) as i64,
|
||||
agent.get("repetition_penalty").and_then(|v| v.as_f64()).unwrap_or(1.15),
|
||||
agent.get("is_default").and_then(|v| v.as_bool()).unwrap_or(false),
|
||||
now,
|
||||
],
|
||||
).map_err(|e| format!("Agent upsert: {}", e))?;
|
||||
Ok(())
|
||||
}
|
||||
|
||||
pub fn get_agents(&self) -> Vec<serde_json::Value> {
|
||||
let conn = self.conn.lock().unwrap_or_else(|e| e.into_inner());
|
||||
let mut stmt = conn.prepare(
|
||||
"SELECT id, name, avatar, role, model, color, docs, prompt,
|
||||
temperature, top_k, max_tokens, repetition_penalty, is_default,
|
||||
created_at, updated_at
|
||||
FROM agents ORDER BY is_default DESC, name"
|
||||
).unwrap();
|
||||
|
||||
stmt.query_map([], |row| {
|
||||
Ok(serde_json::json!({
|
||||
"id": row.get::<_, String>(0)?,
|
||||
"name": row.get::<_, String>(1)?,
|
||||
"avatar": row.get::<_, String>(2)?,
|
||||
"role": row.get::<_, String>(3)?,
|
||||
"model": row.get::<_, String>(4)?,
|
||||
"color": row.get::<_, String>(5)?,
|
||||
"docs": row.get::<_, Option<String>>(6)?,
|
||||
"prompt": row.get::<_, String>(7)?,
|
||||
"temperature": row.get::<_, f64>(8)?,
|
||||
"top_k": row.get::<_, i64>(9)?,
|
||||
"max_tokens": row.get::<_, i64>(10)?,
|
||||
"repetition_penalty": row.get::<_, f64>(11)?,
|
||||
"is_default": row.get::<_, bool>(12)?,
|
||||
"created_at": row.get::<_, String>(13)?,
|
||||
"updated_at": row.get::<_, String>(14)?,
|
||||
}))
|
||||
}).unwrap().filter_map(|r| r.ok()).collect()
|
||||
}
|
||||
|
||||
pub fn delete_agent(&self, id: &str) -> Result<(), String> {
|
||||
let conn = self.conn.lock().unwrap_or_else(|e| e.into_inner());
|
||||
let deleted = conn.execute(
|
||||
"DELETE FROM agents WHERE id = ?1 AND is_default = 0",
|
||||
params![id],
|
||||
).map_err(|e| format!("Agent delete: {}", e))?;
|
||||
if deleted == 0 {
|
||||
Err("Agenttia ei löydy tai se on oletusagentti".to_string())
|
||||
} else {
|
||||
Ok(())
|
||||
}
|
||||
}
|
||||
|
||||
pub fn insert_pair_result(
|
||||
&self,
|
||||
node_id: u64,
|
||||
|
||||
@@ -34,7 +34,7 @@ struct AppState {
|
||||
total_tasks: Mutex<u64>,
|
||||
stats_tx: broadcast::Sender<String>,
|
||||
node_channels: tokio::sync::RwLock<HashMap<u64, tokio::sync::mpsc::UnboundedSender<String>>>, // Kohdennettu reititys
|
||||
pending_consensus: tokio::sync::RwLock<HashMap<String, Vec<serde_json::Value>>>, // Proof of Compute -konsensus
|
||||
_pending_consensus: tokio::sync::RwLock<HashMap<String, Vec<serde_json::Value>>>, // Proof of Compute -konsensus
|
||||
feature_flags: tokio::sync::RwLock<HashMap<String, bool>>, // Tuntee TODO.md:n ruksit lennosta
|
||||
ip_connections: Mutex<HashMap<IpAddr, u32>>,
|
||||
node_ips: Mutex<HashMap<u64, IpAddr>>,
|
||||
@@ -256,7 +256,7 @@ async fn main() {
|
||||
total_tasks: Mutex::new(0),
|
||||
stats_tx: stats_tx.clone(),
|
||||
node_channels: tokio::sync::RwLock::new(HashMap::new()),
|
||||
pending_consensus: tokio::sync::RwLock::new(HashMap::new()),
|
||||
_pending_consensus: tokio::sync::RwLock::new(HashMap::new()),
|
||||
feature_flags: tokio::sync::RwLock::new(HashMap::new()),
|
||||
ip_connections: Mutex::new(HashMap::new()),
|
||||
node_ips: Mutex::new(HashMap::new()),
|
||||
@@ -330,15 +330,6 @@ async fn main() {
|
||||
let idx = (rng_state as usize) % pairs.len();
|
||||
let (en, fi) = pairs[idx];
|
||||
|
||||
// Tokenisointiparit
|
||||
let pair_msg = serde_json::json!({
|
||||
"type": "pair_task",
|
||||
"en": en,
|
||||
"fi": fi,
|
||||
});
|
||||
let _ = state_for_task.stats_tx.send(pair_msg.to_string());
|
||||
|
||||
// LLM-promptit
|
||||
let llm_prompts = vec![
|
||||
"Tell me a short joke.",
|
||||
"What is WebGPU in one sentence?",
|
||||
@@ -348,33 +339,39 @@ async fn main() {
|
||||
];
|
||||
let llm_idx = (rng_state as usize / 7) % llm_prompts.len();
|
||||
|
||||
// SmolLM-prompt
|
||||
let smollm_msg = serde_json::json!({
|
||||
"type": "llm_prompt",
|
||||
"prompt": llm_prompts[llm_idx],
|
||||
"model": "smollm-135m",
|
||||
});
|
||||
let _ = state_for_task.stats_tx.send(smollm_msg.to_string());
|
||||
// Smart Routing: Lähetetään vain niille, jotka valittuna ja idle
|
||||
let mut sends = Vec::new();
|
||||
{
|
||||
let channels = state_for_task.node_channels.read().await;
|
||||
let tasks = state_for_task.node_tasks.lock().unwrap();
|
||||
let mut busy = state_for_task.node_busy.lock().unwrap();
|
||||
|
||||
// Qwen-prompt (sama prompti, eri malli-tagi)
|
||||
let qwen_msg = serde_json::json!({
|
||||
"type": "llm_prompt",
|
||||
"prompt": llm_prompts[llm_idx],
|
||||
"model": "qwen-05b",
|
||||
});
|
||||
let _ = state_for_task.stats_tx.send(qwen_msg.to_string());
|
||||
for (node_id, task) in tasks.iter() {
|
||||
if !busy.contains(node_id) {
|
||||
// Vapaa node -> lähetetään oikea tehtävä
|
||||
let msg = match task.as_str() {
|
||||
"tokenize" => Some(serde_json::json!({ "type": "pair_task", "en": en, "fi": fi })),
|
||||
"smollm-135m" => Some(serde_json::json!({ "type": "llm_prompt", "prompt": llm_prompts[llm_idx], "model": "smollm-135m" })),
|
||||
"qwen-05b" => Some(serde_json::json!({ "type": "llm_prompt", "prompt": llm_prompts[llm_idx], "model": "qwen-05b" })),
|
||||
"phi3-mini" => Some(serde_json::json!({ "type": "llm_prompt", "prompt": llm_prompts[llm_idx], "model": "phi3-mini" })),
|
||||
_ => None, // Coder ja viewer ei saa auto-tehtäviä
|
||||
};
|
||||
|
||||
// Phi-3 prompt
|
||||
let phi3_msg = serde_json::json!({
|
||||
"type": "llm_prompt",
|
||||
"prompt": llm_prompts[llm_idx],
|
||||
"model": "phi3-mini",
|
||||
});
|
||||
let _ = state_for_task.stats_tx.send(phi3_msg.to_string());
|
||||
if let Some(payload) = msg {
|
||||
if let Some(ch) = channels.get(node_id) {
|
||||
sends.push((ch.clone(), payload.to_string()));
|
||||
busy.insert(*node_id);
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Coder ei saa automaattisia tehtäviä — vain käyttäjän user_text
|
||||
for (ch, msg_str) in sends {
|
||||
let _ = ch.send(msg_str);
|
||||
}
|
||||
|
||||
tracing::debug!("Tehtävät lähetetty: pair + smollm + qwen + phi3");
|
||||
// tracing::debug!("Tehtävät lähetetty reititetysti idle-nodeille");
|
||||
}
|
||||
});
|
||||
|
||||
@@ -387,9 +384,11 @@ async fn main() {
|
||||
.route("/api/v1/model", axum::routing::post(api_change_model))
|
||||
.route("/api/v1/hardware", get(api_hardware))
|
||||
.route("/api/v1/ollama/tags", get(api_ollama_tags))
|
||||
.route("/api/v1/agents", get(api_get_agents).post(api_upsert_agent))
|
||||
.route("/api/v1/agents/:id", axum::routing::delete(api_delete_agent))
|
||||
.route("/admin", get(admin_page))
|
||||
.nest_service("/", {
|
||||
let static_dir = std::env::var("STATIC_DIR").unwrap_or_else(|_| "../static".to_string());
|
||||
let static_dir = std::env::var("STATIC_DIR").unwrap_or_else(|_| "../frontend/dist".to_string());
|
||||
ServeDir::new(&static_dir).fallback(ServeFile::new(format!("{}/index.html", static_dir)))
|
||||
})
|
||||
.with_state(state);
|
||||
@@ -462,6 +461,34 @@ fn admin_unauthorized() -> axum::response::Response {
|
||||
.unwrap()
|
||||
}
|
||||
|
||||
// ── Agents API ──
|
||||
|
||||
async fn api_get_agents(
|
||||
axum::extract::State(state): axum::extract::State<Arc<AppState>>,
|
||||
) -> axum::response::Response {
|
||||
axum::Json(state.db.get_agents()).into_response()
|
||||
}
|
||||
|
||||
async fn api_upsert_agent(
|
||||
axum::extract::State(state): axum::extract::State<Arc<AppState>>,
|
||||
axum::Json(payload): axum::Json<serde_json::Value>,
|
||||
) -> axum::response::Response {
|
||||
match state.db.upsert_agent(&payload) {
|
||||
Ok(()) => axum::Json(serde_json::json!({"ok": true})).into_response(),
|
||||
Err(e) => (axum::http::StatusCode::BAD_REQUEST, e).into_response(),
|
||||
}
|
||||
}
|
||||
|
||||
async fn api_delete_agent(
|
||||
axum::extract::State(state): axum::extract::State<Arc<AppState>>,
|
||||
axum::extract::Path(id): axum::extract::Path<String>,
|
||||
) -> axum::response::Response {
|
||||
match state.db.delete_agent(&id) {
|
||||
Ok(()) => axum::Json(serde_json::json!({"ok": true})).into_response(),
|
||||
Err(e) => (axum::http::StatusCode::BAD_REQUEST, e).into_response(),
|
||||
}
|
||||
}
|
||||
|
||||
async fn admin_page(headers: axum::http::HeaderMap) -> axum::response::Response {
|
||||
if !check_admin_auth(&headers) { return admin_unauthorized(); }
|
||||
axum::response::Html(ADMIN_HTML).into_response()
|
||||
@@ -475,7 +502,12 @@ async fn ws_handler(
|
||||
) -> impl IntoResponse {
|
||||
// Origin-tarkistus — estää cross-site WebSocket hijackingin
|
||||
if let Some(origin) = headers.get("origin").and_then(|v| v.to_str().ok()) {
|
||||
if !ALLOWED_ORIGINS.iter().any(|&allowed| origin == allowed) {
|
||||
let is_allowed = ALLOWED_ORIGINS.iter().any(|&allowed| origin == allowed)
|
||||
|| origin.starts_with("http://192.168.")
|
||||
|| origin.starts_with("http://10.")
|
||||
|| origin.starts_with("http://172."); // LAN-avaruudet
|
||||
|
||||
if !is_allowed {
|
||||
tracing::warn!("Estetty yhteys väärällä originilla: {}", origin);
|
||||
return (
|
||||
axum::http::StatusCode::FORBIDDEN,
|
||||
@@ -491,16 +523,19 @@ async fn ws_handler(
|
||||
.and_then(|s| s.trim().parse::<IpAddr>().ok())
|
||||
.unwrap_or_else(|| addr.ip());
|
||||
|
||||
// Max yhteyttä per IP: jokainen selain tarvitsee 2 (UI + coder-node)
|
||||
// Max yhteyttä per IP (ei rajoiteta localhost/127.0.0.1)
|
||||
{
|
||||
let conns = state.ip_connections.lock().unwrap();
|
||||
let count = conns.get(&ip).copied().unwrap_or(0);
|
||||
if count >= 10 {
|
||||
tracing::warn!("IP {} ylitti yhteysrajan ({}/10) — estetty", ip, count);
|
||||
return (
|
||||
axum::http::StatusCode::TOO_MANY_REQUESTS,
|
||||
"Max 10 yhteyttä per IP",
|
||||
).into_response();
|
||||
let is_local = ip.is_loopback();
|
||||
if !is_local {
|
||||
let conns = state.ip_connections.lock().unwrap();
|
||||
let count = conns.get(&ip).copied().unwrap_or(0);
|
||||
if count >= 20 {
|
||||
tracing::warn!("IP {} ylitti yhteysrajan ({}/20) — estetty", ip, count);
|
||||
return (
|
||||
axum::http::StatusCode::TOO_MANY_REQUESTS,
|
||||
"Max 20 yhteyttä per IP",
|
||||
).into_response();
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -661,6 +696,18 @@ async fn handle_socket(socket: WebSocket, state: Arc<AppState>, ip: IpAddr) {
|
||||
let allocated = json.get("allocated_gb").and_then(|v| v.as_u64()).unwrap_or(4) as u32;
|
||||
let node_type = json.get("node_type").and_then(|v| v.as_str()).unwrap_or("browser");
|
||||
|
||||
// API-avain vaaditaan natiivisolmuilta (ei selaimilta)
|
||||
if node_type == "native" {
|
||||
let required_key = std::env::var("NODE_API_KEY").unwrap_or_default();
|
||||
if !required_key.is_empty() {
|
||||
let provided_key = json.get("api_key").and_then(|v| v.as_str()).unwrap_or("");
|
||||
if provided_key != required_key {
|
||||
tracing::warn!("Solmu {} ({}) hylätty: virheellinen API-avain", node_id, ip);
|
||||
break; // Suljetaan WebSocket
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
{
|
||||
let mut map = state.nodes_vram.lock().unwrap();
|
||||
map.insert(node_id, allocated);
|
||||
@@ -741,6 +788,7 @@ async fn handle_socket(socket: WebSocket, state: Arc<AppState>, ip: IpAddr) {
|
||||
}
|
||||
broadcast_stats(&state).await;
|
||||
} else if msg_type == "pair_done" {
|
||||
state.node_busy.lock().unwrap().remove(&node_id);
|
||||
{
|
||||
let mut json = json; // Siirretään omistajuus muokkausta varten
|
||||
if let Some(obj) = json.as_object_mut() {
|
||||
@@ -1054,93 +1102,50 @@ async fn api_chat_completions(
|
||||
}
|
||||
|
||||
// Etsitään vapaa solmu — priorisoidaan natiivisolmut (GPU) selaimen edelle
|
||||
let (target_node_free, target_node_any, total_matching) = {
|
||||
let (target_node, _total_matching) = {
|
||||
let tasks = state.node_tasks.lock().unwrap();
|
||||
let busy = state.node_busy.lock().unwrap();
|
||||
let _busy = state.node_busy.lock().unwrap();
|
||||
let node_types = state.node_types.lock().unwrap();
|
||||
let matching: Vec<u64> = tasks.iter().filter(|(_, task)| {
|
||||
if payload.model == "qwen-coder" {
|
||||
task.starts_with("qwen-coder")
|
||||
// Eksakti match tai qwen-perheen yhteensopivuus (selain: qwen-coder-05b, natiivi: qwen2.5-coder:7b)
|
||||
let req_model = payload.model.to_lowercase();
|
||||
let node_task = task.to_lowercase();
|
||||
if req_model.starts_with("qwen") {
|
||||
node_task.starts_with("qwen")
|
||||
} else if req_model.starts_with("phi") {
|
||||
node_task.starts_with("phi")
|
||||
} else {
|
||||
**task == payload.model
|
||||
}
|
||||
}).map(|(k, _)| *k).collect();
|
||||
// Vapaat solmut: natiivi ensin, sitten selain
|
||||
let free_native = matching.iter().find(|id| {
|
||||
!busy.contains(id) && node_types.get(id).map(|t| t == "native").unwrap_or(false)
|
||||
// Etsitään mikä tahansa matchaava solmu (natiivi priorisoidaan)
|
||||
let native = matching.iter().find(|id| {
|
||||
node_types.get(id).map(|t| t == "native").unwrap_or(false)
|
||||
}).copied();
|
||||
let free_any = matching.iter().find(|id| !busy.contains(id)).copied();
|
||||
let free = free_native.or(free_any);
|
||||
let any = matching.first().copied();
|
||||
(free, any, matching.len())
|
||||
let any = native.or_else(|| matching.first().copied());
|
||||
(any, matching.len())
|
||||
};
|
||||
|
||||
// Broadcastataan reititystila UI:lle
|
||||
let task_id = payload.task_id.clone();
|
||||
|
||||
if target_node_any.is_none() {
|
||||
// Ei yhtään solmua tälle mallille
|
||||
return (axum::http::StatusCode::SERVICE_UNAVAILABLE, "Ei solmua tälle mallille (käynnistä malli selaimessa)").into_response();
|
||||
}
|
||||
let target_node_id = match target_node {
|
||||
Some(id) => id,
|
||||
None => {
|
||||
return (axum::http::StatusCode::SERVICE_UNAVAILABLE, "Ei solmua tälle mallille (käynnistä malli selaimessa)").into_response();
|
||||
}
|
||||
};
|
||||
|
||||
let target_node_id;
|
||||
if let Some(free_id) = target_node_free {
|
||||
// Vapaa solmu löytyi — reititetään suoraan
|
||||
target_node_id = free_id;
|
||||
let node_type = if state.node_tasks.lock().unwrap().get(&free_id).map(|t| t.contains("native")).unwrap_or(false) { "natiivi" } else { "selain" };
|
||||
// Reititystila UI:lle
|
||||
{
|
||||
let routing_msg = serde_json::json!({
|
||||
"type": "task_routed",
|
||||
"task_id": task_id,
|
||||
"node_id": free_id,
|
||||
"node_type": node_type,
|
||||
"node_id": target_node_id,
|
||||
"status": "routed",
|
||||
"message": format!("Reititetty solmulle #{}", free_id),
|
||||
"message": format!("Reititetty solmulle #{}", target_node_id),
|
||||
});
|
||||
let _ = state.stats_tx.send(routing_msg.to_string());
|
||||
} else {
|
||||
// Kaikki solmut varattuja — odotetaan vapautumista (max 30s)
|
||||
let queue_msg = serde_json::json!({
|
||||
"type": "task_routed",
|
||||
"task_id": task_id,
|
||||
"status": "queued",
|
||||
"message": format!("Kaikki {} solmua varattuja — odotetaan vapautumista...", total_matching),
|
||||
});
|
||||
let _ = state.stats_tx.send(queue_msg.to_string());
|
||||
|
||||
// Pollaa busy-tilaa 500ms välein, max 30s
|
||||
let mut waited = 0u32;
|
||||
loop {
|
||||
tokio::time::sleep(std::time::Duration::from_millis(500)).await;
|
||||
waited += 500;
|
||||
let free = {
|
||||
let tasks = state.node_tasks.lock().unwrap();
|
||||
let busy = state.node_busy.lock().unwrap();
|
||||
tasks.iter().find(|(node_id, task)| {
|
||||
let model_match = if payload.model == "qwen-coder" {
|
||||
*task == "qwen-coder-05b" || *task == "qwen-coder"
|
||||
} else {
|
||||
**task == payload.model
|
||||
};
|
||||
model_match && !busy.contains(node_id)
|
||||
}).map(|(k, _)| *k)
|
||||
};
|
||||
if let Some(id) = free {
|
||||
target_node_id = id;
|
||||
let routing_msg = serde_json::json!({
|
||||
"type": "task_routed",
|
||||
"task_id": task_id,
|
||||
"node_id": id,
|
||||
"status": "routed",
|
||||
"message": format!("Solmu #{} vapautui — reititetään ({:.1}s jonossa)", id, waited as f64 / 1000.0),
|
||||
});
|
||||
let _ = state.stats_tx.send(routing_msg.to_string());
|
||||
break;
|
||||
}
|
||||
if waited >= 30000 {
|
||||
return (axum::http::StatusCode::SERVICE_UNAVAILABLE, "Aikakatkaisu: kaikki solmut varattuja 30s ajan").into_response();
|
||||
}
|
||||
}
|
||||
};
|
||||
}
|
||||
|
||||
// Merkitään solmu varatuksi ja task_id jaetuksi
|
||||
state.node_busy.lock().unwrap().insert(target_node_id);
|
||||
|
||||
59
network-poc/install.sh
Executable file
@@ -0,0 +1,59 @@
|
||||
#!/bin/bash
|
||||
# Kipinä Agentic Studio — asennusskripti (Debian/Ubuntu)
|
||||
set -e
|
||||
|
||||
echo "=== Kipinä Agentic Studio — Asennus ==="
|
||||
echo ""
|
||||
|
||||
# Tarkistetaan käyttöjärjestelmä
|
||||
if [ ! -f /etc/debian_version ]; then
|
||||
echo "⚠ Tämä skripti on suunniteltu Debian/Ubuntu-järjestelmille."
|
||||
echo " Muilla jakeluilla voit asentaa riippuvuudet manuaalisesti."
|
||||
read -p " Jatketaanko? (k/e) " -n 1 -r; echo
|
||||
[[ $REPLY =~ ^[Kk]$ ]] || exit 1
|
||||
fi
|
||||
|
||||
echo "[1/6] Päivitetään pakettilistaus..."
|
||||
sudo apt-get update -qq
|
||||
|
||||
echo "[2/6] Asennetaan peruspaketteja..."
|
||||
sudo apt-get install -y -qq curl git build-essential pkg-config libssl-dev
|
||||
|
||||
# Rust
|
||||
if command -v rustc &>/dev/null; then
|
||||
echo "[3/6] Rust löytyi: $(rustc --version)"
|
||||
else
|
||||
echo "[3/6] Asennetaan Rust..."
|
||||
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
|
||||
source "$HOME/.cargo/env"
|
||||
fi
|
||||
|
||||
# Node.js (Astro-frontend vaatii)
|
||||
if command -v node &>/dev/null; then
|
||||
echo "[4/6] Node.js löytyi: $(node --version)"
|
||||
else
|
||||
echo "[4/6] Asennetaan Node.js 22..."
|
||||
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
|
||||
sudo apt-get install -y -qq nodejs
|
||||
fi
|
||||
|
||||
# Ollama
|
||||
if command -v ollama &>/dev/null; then
|
||||
echo "[5/6] Ollama löytyi"
|
||||
else
|
||||
echo "[5/6] Asennetaan Ollama..."
|
||||
curl -fsSL https://ollama.ai/install.sh | sh
|
||||
fi
|
||||
|
||||
# Malli
|
||||
echo "[6/6] Ladataan kielimalli (qwen2.5-coder:3b)..."
|
||||
ollama pull qwen2.5-coder:3b
|
||||
|
||||
echo ""
|
||||
echo "=== Asennus valmis! ==="
|
||||
echo ""
|
||||
echo "Käynnistä:"
|
||||
echo " cd $(pwd)"
|
||||
echo " ./network-poc/local.sh"
|
||||
echo ""
|
||||
echo "Avaa selaimessa: http://localhost:3000"
|
||||
37
network-poc/local.sh
Executable file
@@ -0,0 +1,37 @@
|
||||
#!/bin/bash
|
||||
set -e
|
||||
|
||||
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
|
||||
echo "=== Kipinä Studio Local Development ==="
|
||||
|
||||
# Frontend
|
||||
echo "[1/3] Rakennetaan frontend..."
|
||||
cd "$SCRIPT_DIR/frontend"
|
||||
[ -d node_modules ] || npm install --silent
|
||||
npm run build --silent 2>&1 | tail -1
|
||||
|
||||
# Hub
|
||||
echo "[2/3] Käynnistetään hub..."
|
||||
cd "$SCRIPT_DIR/hub"
|
||||
cargo run &
|
||||
HUB_PID=$!
|
||||
sleep 3
|
||||
|
||||
# Native-node (jos Ollama on käynnissä)
|
||||
if curl -s http://localhost:11434/api/tags >/dev/null 2>&1; then
|
||||
echo "[3/3] Ollama löytyi — käynnistetään native-node..."
|
||||
cd "$SCRIPT_DIR/native-node"
|
||||
HUB_URL=ws://localhost:3000/ws cargo run --no-default-features &
|
||||
NODE_PID=$!
|
||||
echo " Native-node PID: $NODE_PID"
|
||||
else
|
||||
echo "[3/3] Ollama ei käynnissä — käytetään selaimen Wasm-laskentaa"
|
||||
echo " Nopeampi: ollama serve & ollama pull qwen2.5-coder:7b && ./local.sh"
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "=== http://localhost:3000 ==="
|
||||
echo " Ctrl+C pysäyttää"
|
||||
|
||||
# Odotetaan hub-prosessia
|
||||
wait $HUB_PID
|
||||
@@ -3,6 +3,10 @@ name = "native-node"
|
||||
version = "0.2.2"
|
||||
edition = "2024"
|
||||
|
||||
[features]
|
||||
default = ["gpu-detect"]
|
||||
gpu-detect = ["nvml-wrapper", "wgpu"]
|
||||
|
||||
[dependencies]
|
||||
tokio = { version = "1.36", features = ["full"] }
|
||||
tokio-tungstenite = { version = "0.21", features = ["native-tls"] }
|
||||
@@ -10,8 +14,8 @@ futures-util = "0.3"
|
||||
serde = { version = "1.0", features = ["derive"] }
|
||||
serde_json = "1.0"
|
||||
sysinfo = "0.30"
|
||||
nvml-wrapper = "0.10"
|
||||
wgpu = "24"
|
||||
nvml-wrapper = { version = "0.10", optional = true }
|
||||
wgpu = { version = "24", optional = true }
|
||||
reqwest = { version = "0.12", features = ["json"] }
|
||||
tracing = "0.1"
|
||||
tracing-subscriber = { version = "0.3", features = ["env-filter"] }
|
||||
|
||||
@@ -9,7 +9,7 @@ pub struct LlmEngine {
|
||||
|
||||
impl LlmEngine {
|
||||
pub async fn load() -> Result<Self, String> {
|
||||
let model = std::env::var("OLLAMA_MODEL").unwrap_or_else(|_| "qwen2.5-coder:7b".to_string());
|
||||
let model = std::env::var("OLLAMA_MODEL").unwrap_or_else(|_| "qwen2.5-coder:3b".to_string());
|
||||
|
||||
let client = reqwest::Client::builder()
|
||||
.timeout(std::time::Duration::from_secs(600))
|
||||
@@ -79,7 +79,8 @@ impl LlmEngine {
|
||||
}
|
||||
|
||||
pub async fn generate(&self, prompt: &str, max_tokens: usize) -> Result<GenerateResult, String> {
|
||||
let system = "You are a coding assistant. Respond with ONLY code. Use proper newlines and indentation. No explanations, no markdown fences, no comments unless asked.";
|
||||
// System prompt tulee agentin konfiguraatiosta (frontend lähettää sen osana promptia).
|
||||
// Tässä ei yliajeta sitä — Ollama saa vain prompt-kentän.
|
||||
let model = self.model.borrow().clone();
|
||||
|
||||
let start = Instant::now();
|
||||
@@ -87,14 +88,13 @@ impl LlmEngine {
|
||||
.json(&serde_json::json!({
|
||||
"model": model,
|
||||
"prompt": prompt,
|
||||
"system": system,
|
||||
"stream": false,
|
||||
"options": {
|
||||
"num_predict": max_tokens,
|
||||
"temperature": 0.7,
|
||||
"top_k": 40,
|
||||
"repeat_penalty": 1.15,
|
||||
"stop": ["<|im_end|>", "\n###", "\nExplanation", "\nNote:"]
|
||||
"stop": ["<|im_end|>", "\n###", "\nExplanation", "\nNote:", "\nPlease note", "\nThis is", "\n```\n\n", "\n// Example", "\n# Example"]
|
||||
}
|
||||
}))
|
||||
.send()
|
||||
@@ -109,7 +109,7 @@ impl LlmEngine {
|
||||
.map_err(|e| format!("Ollama JSON: {}", e))?;
|
||||
|
||||
let text = body["response"].as_str().unwrap_or("").to_string();
|
||||
let total_duration_ns = body["total_duration"].as_u64().unwrap_or(0);
|
||||
let _total_duration_ns = body["total_duration"].as_u64().unwrap_or(0);
|
||||
let eval_count = body["eval_count"].as_u64().unwrap_or(0) as usize;
|
||||
let eval_duration_ns = body["eval_duration"].as_u64().unwrap_or(1);
|
||||
|
||||
@@ -127,27 +127,40 @@ impl LlmEngine {
|
||||
}
|
||||
}
|
||||
|
||||
/// Siivoa mahdolliset markdown-koodiblokki-merkit
|
||||
/// Siivoa markdown-koodiblokki-merkit ja selitystekstit
|
||||
fn strip_code_fences(text: &str) -> String {
|
||||
let mut result = text.trim().to_string();
|
||||
// Poistetaan kaikki ```-rivit ja kielitunnisteet (```python, ```rust jne.)
|
||||
let lines: Vec<&str> = text.lines().collect();
|
||||
let filtered: Vec<&str> = lines.into_iter().filter(|line| {
|
||||
let trimmed = line.trim();
|
||||
// Poista rivit jotka ovat pelkkiä ``` tai ```kielitunniste
|
||||
if trimmed.starts_with("```") {
|
||||
return false;
|
||||
}
|
||||
true
|
||||
}).collect();
|
||||
let mut result = filtered.join("\n").trim().to_string();
|
||||
|
||||
// Poista aloittava ```lang
|
||||
if result.starts_with("```") {
|
||||
if let Some(nl) = result.find('\n') {
|
||||
result = result[nl + 1..].to_string();
|
||||
// Poista selitysteksti lopusta (kaikki rivin "\nPlease note" jälkeen jne.)
|
||||
let lower = result.to_lowercase();
|
||||
for stop in &["\nplease note", "\nthis is a basic", "\nthis code", "\nnote that", "\nremember to", "\nyou can", "\nto run"] {
|
||||
if let Some(pos) = lower.find(stop) {
|
||||
result = result[..pos].trim_end().to_string();
|
||||
}
|
||||
}
|
||||
|
||||
// Poista sulkeva ```
|
||||
let trimmed = result.trim_end();
|
||||
if trimmed.ends_with("```") {
|
||||
let before = &trimmed[..trimmed.len() - 3];
|
||||
if before.is_empty() || before.ends_with('\n') {
|
||||
result = before.trim_end().to_string();
|
||||
// Poista johdantolauseet alusta
|
||||
let lower = result.to_lowercase();
|
||||
for prefix in &["sure!", "here is", "here's", "certainly!", "below is"] {
|
||||
if lower.starts_with(prefix) {
|
||||
if let Some(nl) = result.find('\n') {
|
||||
result = result[nl + 1..].to_string();
|
||||
}
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
result
|
||||
result.trim().to_string()
|
||||
}
|
||||
|
||||
pub struct GenerateResult {
|
||||
|
||||
@@ -33,6 +33,7 @@ impl GpuInfo {
|
||||
}
|
||||
}
|
||||
|
||||
#[cfg(feature = "gpu-detect")]
|
||||
/// Tunnistaa kaikki GPU:t wgpu:lla (NVIDIA/AMD/Apple/Intel)
|
||||
fn collect_gpus_wgpu() -> Vec<GpuInfo> {
|
||||
let instance = wgpu::Instance::new(&wgpu::InstanceDescriptor {
|
||||
@@ -84,6 +85,7 @@ fn collect_gpus_wgpu() -> Vec<GpuInfo> {
|
||||
gpus
|
||||
}
|
||||
|
||||
#[cfg(feature = "gpu-detect")]
|
||||
/// Täydentää NVIDIA-GPU:iden tiedot NVML:llä (VRAM, lämpötila, kuormitus)
|
||||
fn enrich_nvidia_gpus(gpus: &mut [GpuInfo]) {
|
||||
let Ok(nvml) = nvml_wrapper::Nvml::init() else { return };
|
||||
@@ -109,6 +111,7 @@ fn enrich_nvidia_gpus(gpus: &mut [GpuInfo]) {
|
||||
}
|
||||
}
|
||||
|
||||
#[cfg(feature = "gpu-detect")]
|
||||
/// AMD GPU-tiedot Linuxin sysfs:stä (/sys/class/drm/)
|
||||
fn enrich_amd_gpus(gpus: &mut [GpuInfo]) {
|
||||
let Ok(entries) = std::fs::read_dir("/sys/class/drm") else { return };
|
||||
@@ -150,10 +153,12 @@ fn enrich_amd_gpus(gpus: &mut [GpuInfo]) {
|
||||
}
|
||||
}
|
||||
|
||||
#[cfg(feature = "gpu-detect")]
|
||||
fn read_sysfs_u64(path: &std::path::Path) -> Option<u64> {
|
||||
std::fs::read_to_string(path).ok()?.trim().parse().ok()
|
||||
}
|
||||
|
||||
#[cfg(feature = "gpu-detect")]
|
||||
fn find_hwmon_temp(device_path: &std::path::Path) -> Option<u64> {
|
||||
let hwmon_dir = device_path.join("hwmon");
|
||||
let entries = std::fs::read_dir(&hwmon_dir).ok()?;
|
||||
@@ -166,8 +171,8 @@ fn find_hwmon_temp(device_path: &std::path::Path) -> Option<u64> {
|
||||
None
|
||||
}
|
||||
|
||||
#[cfg(feature = "gpu-detect")]
|
||||
/// Apple GPU-tiedot — wgpu/Metal antaa nimen, tarkempaa dataa ei saa ilman IOKit:ia
|
||||
/// mutta Metal adapter_info sisältää jo olennaiset tiedot
|
||||
fn enrich_apple_gpus(gpus: &mut [GpuInfo]) {
|
||||
// Apple Silicon -koneiden unified memory: koko RAM on GPU:n käytettävissä
|
||||
// Arvioidaan system RAM:sta
|
||||
@@ -187,13 +192,18 @@ fn enrich_apple_gpus(gpus: &mut [GpuInfo]) {
|
||||
|
||||
/// Kerää kaikki GPU:t ja täydentää valmistajakohtaiset tiedot
|
||||
fn collect_all_gpus() -> Vec<GpuInfo> {
|
||||
let mut gpus = collect_gpus_wgpu();
|
||||
|
||||
enrich_nvidia_gpus(&mut gpus);
|
||||
enrich_amd_gpus(&mut gpus);
|
||||
enrich_apple_gpus(&mut gpus);
|
||||
|
||||
gpus
|
||||
#[cfg(feature = "gpu-detect")]
|
||||
{
|
||||
let mut gpus = collect_gpus_wgpu();
|
||||
enrich_nvidia_gpus(&mut gpus);
|
||||
enrich_amd_gpus(&mut gpus);
|
||||
enrich_apple_gpus(&mut gpus);
|
||||
return gpus;
|
||||
}
|
||||
#[cfg(not(feature = "gpu-detect"))]
|
||||
{
|
||||
Vec::new()
|
||||
}
|
||||
}
|
||||
|
||||
/// Kerää järjestelmätiedot (CPU, RAM, OS)
|
||||
@@ -222,15 +232,21 @@ fn build_auth_message(allocated_gb: u32) -> String {
|
||||
v
|
||||
}).collect();
|
||||
|
||||
let api_key = std::env::var("NODE_API_KEY").unwrap_or_default();
|
||||
|
||||
let mut msg = json!({
|
||||
"type": "auth",
|
||||
"status": "agent_ready",
|
||||
"node_type": "native",
|
||||
"allocated_gb": allocated_gb,
|
||||
"selected_task": "qwen-coder-05b",
|
||||
"selected_task": "qwen2.5-coder:7b",
|
||||
"system": sys,
|
||||
});
|
||||
|
||||
if !api_key.is_empty() {
|
||||
msg.as_object_mut().unwrap().insert("api_key".to_string(), json!(api_key));
|
||||
}
|
||||
|
||||
if !gpu_json.is_empty() {
|
||||
msg.as_object_mut().unwrap().insert("gpus".to_string(), json!(gpu_json));
|
||||
}
|
||||
@@ -269,6 +285,9 @@ async fn main() {
|
||||
|
||||
let gpus = collect_all_gpus();
|
||||
if gpus.is_empty() {
|
||||
#[cfg(not(feature = "gpu-detect"))]
|
||||
tracing::info!("GPU-tunnistus ei käytössä (--no-default-features). Ollama käyttää GPU:ta automaattisesti jos saatavilla.");
|
||||
#[cfg(feature = "gpu-detect")]
|
||||
tracing::info!("GPU:ta ei havaittu — toimitaan CPU-moodissa");
|
||||
} else {
|
||||
for (i, gpu) in gpus.iter().enumerate() {
|
||||
@@ -315,22 +334,19 @@ async fn main() {
|
||||
continue;
|
||||
}
|
||||
|
||||
let mut busy = false;
|
||||
|
||||
while let Some(Ok(msg)) = read.next().await {
|
||||
if let Message::Text(text) = msg {
|
||||
// LLM-promptit
|
||||
if text.contains("llm_prompt") && !busy {
|
||||
if text.contains("llm_prompt") {
|
||||
if let Ok(task) = serde_json::from_str::<serde_json::Value>(&text) {
|
||||
let prompt = task.get("prompt").and_then(|v| v.as_str()).unwrap_or("");
|
||||
let task_id = task.get("task_id").and_then(|v| v.as_str()).unwrap_or("?");
|
||||
let msg_model = task.get("model").and_then(|v| v.as_str()).unwrap_or("");
|
||||
|
||||
if !prompt.is_empty() && msg_model.starts_with("qwen-coder") {
|
||||
if !prompt.is_empty() && (msg_model.starts_with("qwen-coder") || msg_model.starts_with("qwen2.5-coder")) {
|
||||
|
||||
if let Some(ref engine) = llm {
|
||||
busy = true;
|
||||
let max_tokens = task.get("max_tokens").and_then(|v| v.as_u64()).unwrap_or(512) as usize;
|
||||
let max_tokens = task.get("max_tokens").and_then(|v| v.as_u64()).unwrap_or(1024) as usize;
|
||||
tracing::info!("Generoidaan (task_id: {}, max_tokens: {}): \"{}\"", task_id, max_tokens, &prompt[..prompt.len().min(100)]);
|
||||
|
||||
let model_name = engine.model_name();
|
||||
@@ -361,7 +377,6 @@ async fn main() {
|
||||
tracing::error!("Inferenssivirhe: {}", e);
|
||||
}
|
||||
}
|
||||
busy = false;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -348,7 +348,9 @@ pub async fn start_agent_node(hub_url: String, has_webgpu: bool, device_info_jso
|
||||
});
|
||||
}
|
||||
}
|
||||
} else if msg.contains("llm_prompt") && (current_task == 4 || current_task == 5) {
|
||||
} else if msg.contains("llm_prompt") {
|
||||
console_log!("[DEBUG] llm_prompt vastaanotettu! current_task={}, busy={}", current_task, LLM_BUSY.load(Ordering::SeqCst));
|
||||
if current_task == 4 || current_task == 5 {
|
||||
// Qwen2.5-Coder: 4 = 0.5B, 5 = 3B
|
||||
if let Ok(task) = serde_json::from_str::<serde_json::Value>(&msg) {
|
||||
let prompt = task.get("prompt").and_then(|v| v.as_str()).unwrap_or("").to_string();
|
||||
@@ -376,6 +378,7 @@ pub async fn start_agent_node(hub_url: String, has_webgpu: bool, device_info_jso
|
||||
}
|
||||
}
|
||||
}
|
||||
} // current_task == 4 || 5
|
||||
} else if msg.contains("ai_task") {
|
||||
console_log!("Hub task vastaanotettu, ajetaan GPU:lla...");
|
||||
let ws_for_async = ws_clone.clone();
|
||||
|
||||
@@ -248,14 +248,17 @@ async fn get_or_build_model(use_3b: bool, ws: &Rc<RefCell<WebSocket>>) -> Result
|
||||
|
||||
/// use_3b: false = 0.5B (nopea), true = 3B (laadukas)
|
||||
pub async fn run_coder_inference(prompt: String, ws: Rc<RefCell<WebSocket>>, use_3b: bool, task_id: Option<String>) {
|
||||
console_log!("[Coder] run_coder_inference alkaa! prompt={}", &prompt[..prompt.len().min(50)]);
|
||||
let size_label = if use_3b { "3B" } else { "0.5B" };
|
||||
|
||||
let start_load = crate::perf_now();
|
||||
|
||||
console_log!("[Coder] Kutsutaan get_or_build_model...");
|
||||
if let Err(e) = get_or_build_model(use_3b, &ws).await {
|
||||
console_log!("[Coder] Mallin lataus: {}", e);
|
||||
console_log!("[Coder] Mallin lataus epäonnistui: {}", e);
|
||||
return;
|
||||
}
|
||||
console_log!("[Coder] Malli valmis, aloitetaan inferenssi");
|
||||
|
||||
let load_time = crate::perf_now() - start_load;
|
||||
if load_time > 100.0 {
|
||||
@@ -320,7 +323,11 @@ pub async fn run_coder_inference(prompt: String, ws: Rc<RefCell<WebSocket>>, use
|
||||
if let Ok(text) = cached.tokenizer.decode(&[next_token], true) {
|
||||
generated_text.push_str(&text);
|
||||
let mut chunk = serde_json::json!({ "type": "llm_chunk", "token": text, "prompt": prompt, "model": "Qwen2.5-Coder" });
|
||||
if let Some(ref tid) = task_id { chunk.as_object_mut().unwrap().insert("task_id".to_string(), serde_json::json!(tid)); }
|
||||
if let Some(ref tid) = task_id {
|
||||
if let Some(obj) = chunk.as_object_mut() {
|
||||
obj.insert("task_id".to_string(), serde_json::json!(tid));
|
||||
}
|
||||
}
|
||||
let _ = ws.borrow().send_with_str(&chunk.to_string());
|
||||
}
|
||||
all_generated.push(next_token);
|
||||
@@ -362,7 +369,11 @@ pub async fn run_coder_inference(prompt: String, ws: Rc<RefCell<WebSocket>>, use
|
||||
}
|
||||
|
||||
let mut chunk = serde_json::json!({ "type": "llm_chunk", "token": text, "prompt": prompt, "model": "Qwen2.5-Coder" });
|
||||
if let Some(ref tid) = task_id { chunk.as_object_mut().unwrap().insert("task_id".to_string(), serde_json::json!(tid)); }
|
||||
if let Some(ref tid) = task_id {
|
||||
if let Some(obj) = chunk.as_object_mut() {
|
||||
obj.insert("task_id".to_string(), serde_json::json!(tid));
|
||||
}
|
||||
}
|
||||
let _ = ws.borrow().send_with_str(&chunk.to_string());
|
||||
}
|
||||
all_generated.push(next_token);
|
||||
@@ -391,7 +402,9 @@ pub async fn run_coder_inference(prompt: String, ws: Rc<RefCell<WebSocket>>, use
|
||||
"load_time_ms": (load_time * 100.0).round() / 100.0,
|
||||
});
|
||||
if let Some(tid) = task_id {
|
||||
done.as_object_mut().unwrap().insert("task_id".to_string(), serde_json::json!(tid));
|
||||
if let Some(obj) = done.as_object_mut() {
|
||||
obj.insert("task_id".to_string(), serde_json::json!(tid));
|
||||
}
|
||||
}
|
||||
let _ = ws.borrow().send_with_str(&done.to_string());
|
||||
}
|
||||
|
||||
1
network-poc/target-check/.rustc_info.json
Normal file
@@ -0,0 +1 @@
|
||||
{"rustc_fingerprint":15841952146704291179,"outputs":{"17747080675513052775":{"success":true,"status":"","code":0,"stdout":"rustc 1.94.1 (e408947bf 2026-03-25)\nbinary: rustc\ncommit-hash: e408947bfd200af42db322daf0fadfe7e26d3bd1\ncommit-date: 2026-03-25\nhost: x86_64-unknown-linux-gnu\nrelease: 1.94.1\nLLVM version: 21.1.8\n","stderr":""},"7971740275564407648":{"success":true,"status":"","code":0,"stdout":"___\nlib___.rlib\nlib___.so\nlib___.so\nlib___.a\nlib___.so\n/home/jaakko/.rustup/toolchains/stable-x86_64-unknown-linux-gnu\noff\npacked\nunpacked\n___\ndebug_assertions\npanic=\"unwind\"\nproc_macro\ntarget_abi=\"\"\ntarget_arch=\"x86_64\"\ntarget_endian=\"little\"\ntarget_env=\"gnu\"\ntarget_family=\"unix\"\ntarget_feature=\"fxsr\"\ntarget_feature=\"sse\"\ntarget_feature=\"sse2\"\ntarget_has_atomic=\"16\"\ntarget_has_atomic=\"32\"\ntarget_has_atomic=\"64\"\ntarget_has_atomic=\"8\"\ntarget_has_atomic=\"ptr\"\ntarget_os=\"linux\"\ntarget_pointer_width=\"64\"\ntarget_vendor=\"unknown\"\nunix\n","stderr":""}},"successes":{}}
|
||||
3
network-poc/target-check/CACHEDIR.TAG
Normal file
@@ -0,0 +1,3 @@
|
||||
Signature: 8a477f597d28d172789f06886806bc55
|
||||
# This file is a cache directory tag created by cargo.
|
||||
# For information about cache directory tags see https://bford.info/cachedir/
|
||||
24
network-poc/temp/frontend-old/.gitignore
vendored
Normal file
@@ -0,0 +1,24 @@
|
||||
# build output
|
||||
dist/
|
||||
# generated types
|
||||
.astro/
|
||||
|
||||
# dependencies
|
||||
node_modules/
|
||||
|
||||
# logs
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
pnpm-debug.log*
|
||||
|
||||
|
||||
# environment variables
|
||||
.env
|
||||
.env.production
|
||||
|
||||
# macOS-specific files
|
||||
.DS_Store
|
||||
|
||||
# jetbrains setting folder
|
||||
.idea/
|
||||
4
network-poc/temp/frontend-old/.vscode/extensions.json
vendored
Normal file
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"recommendations": ["astro-build.astro-vscode"],
|
||||
"unwantedRecommendations": []
|
||||
}
|
||||
11
network-poc/temp/frontend-old/.vscode/launch.json
vendored
Normal file
@@ -0,0 +1,11 @@
|
||||
{
|
||||
"version": "0.2.0",
|
||||
"configurations": [
|
||||
{
|
||||
"command": "./node_modules/.bin/astro dev",
|
||||
"name": "Development server",
|
||||
"request": "launch",
|
||||
"type": "node-terminal"
|
||||
}
|
||||
]
|
||||
}
|
||||
43
network-poc/temp/frontend-old/README.md
Normal file
@@ -0,0 +1,43 @@
|
||||
# Astro Starter Kit: Minimal
|
||||
|
||||
```sh
|
||||
npm create astro@latest -- --template minimal
|
||||
```
|
||||
|
||||
> 🧑🚀 **Seasoned astronaut?** Delete this file. Have fun!
|
||||
|
||||
## 🚀 Project Structure
|
||||
|
||||
Inside of your Astro project, you'll see the following folders and files:
|
||||
|
||||
```text
|
||||
/
|
||||
├── public/
|
||||
├── src/
|
||||
│ └── pages/
|
||||
│ └── index.astro
|
||||
└── package.json
|
||||
```
|
||||
|
||||
Astro looks for `.astro` or `.md` files in the `src/pages/` directory. Each page is exposed as a route based on its file name.
|
||||
|
||||
There's nothing special about `src/components/`, but that's where we like to put any Astro/React/Vue/Svelte/Preact components.
|
||||
|
||||
Any static assets, like images, can be placed in the `public/` directory.
|
||||
|
||||
## 🧞 Commands
|
||||
|
||||
All commands are run from the root of the project, from a terminal:
|
||||
|
||||
| Command | Action |
|
||||
| :------------------------ | :----------------------------------------------- |
|
||||
| `npm install` | Installs dependencies |
|
||||
| `npm run dev` | Starts local dev server at `localhost:4321` |
|
||||
| `npm run build` | Build your production site to `./dist/` |
|
||||
| `npm run preview` | Preview your build locally, before deploying |
|
||||
| `npm run astro ...` | Run CLI commands like `astro add`, `astro check` |
|
||||
| `npm run astro -- --help` | Get help using the Astro CLI |
|
||||
|
||||
## 👀 Want to learn more?
|
||||
|
||||
Feel free to check [our documentation](https://docs.astro.build) or jump into our [Discord server](https://astro.build/chat).
|
||||
5
network-poc/temp/frontend-old/astro.config.mjs
Normal file
@@ -0,0 +1,5 @@
|
||||
// @ts-check
|
||||
import { defineConfig } from 'astro/config';
|
||||
|
||||
// https://astro.build/config
|
||||
export default defineConfig({});
|
||||
4731
network-poc/temp/frontend-old/package-lock.json
generated
Normal file
18
network-poc/temp/frontend-old/package.json
Normal file
@@ -0,0 +1,18 @@
|
||||
{
|
||||
"name": "frontend",
|
||||
"type": "module",
|
||||
"version": "0.0.1",
|
||||
"engines": {
|
||||
"node": ">=22.12.0"
|
||||
},
|
||||
"scripts": {
|
||||
"dev": "astro dev",
|
||||
"build": "astro build",
|
||||
"preview": "astro preview",
|
||||
"astro": "astro"
|
||||
},
|
||||
"dependencies": {
|
||||
"astro": "^6.1.5",
|
||||
"three": "^0.183.2"
|
||||
}
|
||||
}
|
||||
34
network-poc/temp/frontend-old/public/avatars/README.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Kipinä Agentic Playground - Animaatioiden käyttöönotto
|
||||
|
||||
Koska Kipinä-verkon agenttien avatarit tällä erää ovat staattisia PNG-kuvatiedostoja, käyttöliittymä hyödyntää CSS-pohjaista pomppimisilmiötä (sekä pulppuavaa 💬 puhekuplaa) "puhumisen" merkkinä. Olemme kuitenkin koodanneet taustalle piilotetun tuen aivioiduille videoloopeille myöhempää käyttöä varten!
|
||||
|
||||
Näin saat UI:n tukemaan oikeasti animoituja kasvoja/videoita.
|
||||
|
||||
## 1. Luo Animoidut GIF-tiedostot
|
||||
Valitse mikä tahansa ulkoinen AI-työkalu (kuten HeyGen, Pika v1.0, tai Midjourney+Runway yhdistelmä) ja muunna avatar-kuvat (esim. `kettu_notext.png`) 3-5 sekunnin kestäviksi GIF-loopeiksi. Hahmon leuka tulisi pyöriä tai naama vääntyillä puhuessaan.
|
||||
|
||||
## 2. Nimeä Tiedostot Oikein ja Lisää Ne Kansioon
|
||||
Siirrä uudet GIF-animaatiot samaan kansioon alkuperäisten kuvien kanssa. Muuta niiden nimi siten, että se päättyy tunnisteeseen `_puhuva.gif`.
|
||||
|
||||
Esimerkkejä:
|
||||
- Koodari `kipina_notext.png` → `kipina_notext_puhuva.gif`
|
||||
- Manageri `karhunpentu.png` → `karhunpentu_puhuva.gif`
|
||||
- Asiakas `kettu_notext.png` → `kettu_notext_puhuva.gif`
|
||||
|
||||
## 3. Aktivoi Koodi
|
||||
Käännä Kipinä Playground -ohjaimen JavaScript-koodista piilotettu ominaisuus päälle.
|
||||
|
||||
Etsi tiedostosta `../index.html` (noin riviltä 1084, `updatePromptEditor`-funktiosta):
|
||||
```javascript
|
||||
// Piilotettu ominaisuus: Puhuvien videoiden / gif-animaatioiden kytkentä
|
||||
window.USE_ANIMATED_GIFS = false;
|
||||
```
|
||||
Muuta tuo `false` arvoon `true`:
|
||||
```javascript
|
||||
window.USE_ANIMATED_GIFS = true;
|
||||
```
|
||||
|
||||
**Mitä logiikka tekee?**
|
||||
Aina kun valitset agentin kaaviosta, koodi korvaa aktiivisen kuvakkeen lopussa olevan `.png` -päätteen sanalla `_puhuva.gif` – lennosta! Jos poistut agentin valinnasta tai valitset jonkun toisen, koodi vaihtaa kuvan välittömästi takaisin staattiseen `.png`-versioon ja sulkee ilmentymän suun.
|
||||
|
||||
Näin saat kaikkien asiantuntijoiden face-track looppeja hallittua yhdellä kädenkäänteellä.
|
||||
|
Before Width: | Height: | Size: 696 KiB After Width: | Height: | Size: 696 KiB |
BIN
network-poc/temp/frontend-old/public/avatars/bear.png
Normal file
|
After Width: | Height: | Size: 757 KiB |
BIN
network-poc/temp/frontend-old/public/avatars/beaver.png
Normal file
|
After Width: | Height: | Size: 700 KiB |
BIN
network-poc/temp/frontend-old/public/avatars/chameleon.png
Normal file
|
After Width: | Height: | Size: 731 KiB |
BIN
network-poc/temp/frontend-old/public/avatars/elephant.png
Normal file
|
After Width: | Height: | Size: 711 KiB |
BIN
network-poc/temp/frontend-old/public/avatars/gecko.png
Normal file
|
After Width: | Height: | Size: 695 KiB |
|
Before Width: | Height: | Size: 130 KiB After Width: | Height: | Size: 130 KiB |
|
Before Width: | Height: | Size: 432 KiB After Width: | Height: | Size: 432 KiB |
|
Before Width: | Height: | Size: 650 KiB After Width: | Height: | Size: 650 KiB |
|
Before Width: | Height: | Size: 389 KiB After Width: | Height: | Size: 389 KiB |
|
Before Width: | Height: | Size: 596 KiB After Width: | Height: | Size: 596 KiB |
|
Before Width: | Height: | Size: 496 KiB After Width: | Height: | Size: 496 KiB |
BIN
network-poc/temp/frontend-old/public/avatars/lion.png
Normal file
|
After Width: | Height: | Size: 872 KiB |
BIN
network-poc/temp/frontend-old/public/avatars/mantis.png
Normal file
|
After Width: | Height: | Size: 738 KiB |
|
Before Width: | Height: | Size: 109 KiB After Width: | Height: | Size: 109 KiB |
BIN
network-poc/temp/frontend-old/public/avatars/old/gecko_hero.png
Normal file
|
After Width: | Height: | Size: 130 KiB |
|
Before Width: | Height: | Size: 3.4 MiB After Width: | Height: | Size: 3.4 MiB |
|
Before Width: | Height: | Size: 98 KiB After Width: | Height: | Size: 98 KiB |
BIN
network-poc/temp/frontend-old/public/avatars/owl.png
Normal file
|
After Width: | Height: | Size: 813 KiB |
BIN
network-poc/temp/frontend-old/public/avatars/penguin.png
Normal file
|
After Width: | Height: | Size: 658 KiB |
|
Before Width: | Height: | Size: 593 KiB After Width: | Height: | Size: 593 KiB |
|
Before Width: | Height: | Size: 563 KiB After Width: | Height: | Size: 563 KiB |
BIN
network-poc/temp/frontend-old/public/avatars/serpent.png
Normal file
|
After Width: | Height: | Size: 696 KiB |
BIN
network-poc/temp/frontend-old/public/avatars/spider.png
Normal file
|
After Width: | Height: | Size: 718 KiB |
|
Before Width: | Height: | Size: 513 KiB After Width: | Height: | Size: 513 KiB |
BIN
network-poc/temp/frontend-old/public/avatars/tortoise.png
Normal file
|
After Width: | Height: | Size: 780 KiB |
BIN
network-poc/temp/frontend-old/public/avatars/walrus.png
Normal file
|
After Width: | Height: | Size: 826 KiB |
43
network-poc/temp/frontend-old/public/docs/README.md
Normal file
@@ -0,0 +1,43 @@
|
||||
# OpenTofu Core Codebase Documentation
|
||||
|
||||
This directory contains some documentation about the OpenTofu Core codebase,
|
||||
aimed at readers who are interested in making code contributions.
|
||||
|
||||
If you're looking for information on _using_ OpenTofu, please instead refer
|
||||
to [the main OpenTofu CLI documentation](https://opentofu.org/docs/cli/index.html).
|
||||
|
||||
## OpenTofu Core Architecture Documents
|
||||
|
||||
* [OpenTofu Core Architecture Summary](./architecture.md): an overview of the
|
||||
main components of OpenTofu Core and how they interact. This is the best
|
||||
starting point if you are diving in to this codebase for the first time.
|
||||
|
||||
* [Resource Instance Change Lifecycle](./resource-instance-change-lifecycle.md):
|
||||
a description of the steps in validating, planning, and applying a change
|
||||
to a resource instance, from the perspective of the provider plugin RPC
|
||||
operations. This may be useful for understanding the various expectations
|
||||
OpenTofu enforces about provider behavior, either if you intend to make
|
||||
changes to those behaviors or if you are implementing a new OpenTofu plugin
|
||||
SDK and so wish to conform to them.
|
||||
|
||||
(If you are planning to write a new provider using the _official_ SDK then
|
||||
please refer to [the Extend documentation](https://github.com/hashicorp/terraform-docs-common)
|
||||
instead; it presents similar information from the perspective of the SDK
|
||||
API, rather than the plugin wire protocol.)
|
||||
|
||||
* [Diagnostics](./diagnostics): how we report errors and warnings to end-users
|
||||
in OpenTofu.
|
||||
|
||||
* [Plugin Protocol](./plugin-protocol/): gRPC/protobuf definitions for the
|
||||
plugin wire protocol and information about its versioning strategy.
|
||||
|
||||
This documentation is for SDK developers, and is not necessary reading for
|
||||
those implementing a provider using the official SDK.
|
||||
|
||||
* [How OpenTofu Uses Unicode](./unicode.md): an overview of the various
|
||||
features of OpenTofu that rely on Unicode and how to change those features
|
||||
to adopt new versions of Unicode.
|
||||
|
||||
## Contribution Guides
|
||||
|
||||
* [Contributing to OpenTofu](../CONTRIBUTING.md): a complete guideline for those who want to contribute to this project.
|
||||
374
network-poc/temp/frontend-old/public/docs/architecture.md
Normal file
@@ -0,0 +1,374 @@
|
||||
# OpenTofu Core Architecture Summary
|
||||
|
||||
This document is a summary of the main components of OpenTofu Core and how
|
||||
data and requests flow between these components. It's intended as a primer
|
||||
to help navigate the codebase to dig into more details.
|
||||
|
||||
We assume some familiarity with user-facing OpenTofu concepts like
|
||||
configuration, state, CLI workflow, etc. The OpenTofu website has
|
||||
documentation on these ideas.
|
||||
|
||||
## OpenTofu Request Flow
|
||||
|
||||
The following diagram shows an approximation of how a user command is
|
||||
executed in OpenTofu:
|
||||
|
||||

|
||||
|
||||
Each of the different subsystems (solid boxes) in this diagram is described
|
||||
in more detail in a corresponding section below.
|
||||
|
||||
## CLI (`command` package)
|
||||
|
||||
Each time a user runs the `tofu` program, aside from some initial
|
||||
bootstrapping in the root package (not shown in the diagram) execution
|
||||
transfers immediately into one of the "command" implementations in
|
||||
[the `command` package](https://pkg.go.dev/github.com/opentofu/opentofu/internal/command).
|
||||
The mapping between the user-facing command names and
|
||||
their corresponding `command` package types can be found in the `commands.go`
|
||||
file under the `cmd/tofu` directory (package `main`).
|
||||
|
||||
The full flow illustrated above does not actually apply to _all_ commands,
|
||||
but it applies to the main OpenTofu workflow commands `tofu plan` and
|
||||
`tofu apply`, along with a few others.
|
||||
|
||||
For these commands, the role of the command implementation is to read and parse
|
||||
any command line arguments, command line options, and environment variables
|
||||
that are needed for the given command and use them to produce a
|
||||
[`backend.Operation`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/backend#Operation)
|
||||
object that describes an action to be taken.
|
||||
|
||||
An _operation_ consists of:
|
||||
|
||||
* The action to be taken (e.g. "plan", "apply").
|
||||
* The name of the [workspace](https://opentofu.org/docs/language/state/workspaces)
|
||||
where the action will be taken.
|
||||
* Root module input variables to use for the action.
|
||||
* For the "plan" operation, a path to the directory containing the configuration's root module.
|
||||
* For the "apply" operation, the plan to apply.
|
||||
* Various other less-common options/settings such as `-target` addresses, the
|
||||
"force" flag, etc.
|
||||
|
||||
The operation is then passed to the currently-selected
|
||||
[backend](https://opentofu.org/docs/language/settings/backends/configuration). Each backend name
|
||||
corresponds to an implementation of
|
||||
[`backend.Backend`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/backend#Backend), using a
|
||||
mapping table in
|
||||
[the `backend/init` package](https://pkg.go.dev/github.com/opentofu/opentofu/internal/backend/init).
|
||||
|
||||
Backends that are able to execute operations additionally implement
|
||||
[`backend.Enhanced`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/backend#Enhanced);
|
||||
the command-handling code calls `Operation` with the operation it has
|
||||
constructed, and then the backend is responsible for executing that action.
|
||||
|
||||
Backends that execute operations, however, do so as an architectural implementation detail and not a
|
||||
general feature of backends. That is, the term 'backend' as a OpenTofu feature is used to refer to
|
||||
a plugin that determines where OpenTofu stores its state snapshots - only the default `local`, `remote` and `cloud` backends perform operations.
|
||||
|
||||
Thus, most backends do _not_ implement this interface, and so the `command` package wraps these
|
||||
backends in an instance of
|
||||
[`local.Local`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/backend/local#Local),
|
||||
causing the operation to be executed locally within the `tofu` process itself.
|
||||
|
||||
## Backends
|
||||
|
||||
A _backend_ determines where OpenTofu should store its state snapshots.
|
||||
|
||||
As described above, the `local` backend also executes operations on behalf of most other
|
||||
backends. It uses a _state manager_
|
||||
(either
|
||||
[`statemgr.Filesystem`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/states/statemgr#Filesystem) if the
|
||||
local backend is being used directly, or an implementation provided by whatever
|
||||
backend is being wrapped) to retrieve the current state for the workspace
|
||||
specified in the operation, then uses the _config loader_ to load and do
|
||||
initial processing/validation of the configuration specified in the
|
||||
operation. It then uses these, along with the other settings given in the
|
||||
operation, to construct a
|
||||
[`tofu.Context`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#Context),
|
||||
which is the main object that actually performs OpenTofu operations.
|
||||
|
||||
The `local` backend finally calls an appropriate method on that context to
|
||||
begin execution of the relevant command, such as
|
||||
[`Plan`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#Context.Plan)
|
||||
or
|
||||
[`Apply`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#Context.Apply), which in turn constructs a graph using a _graph builder_,
|
||||
described in a later section.
|
||||
|
||||
## Configuration Loader
|
||||
|
||||
The top-level configuration structure is represented by model types in
|
||||
[package `configs`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/configs).
|
||||
A whole configuration (the root module plus all of its descendent modules)
|
||||
is represented by
|
||||
[`configs.Config`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/configs#Config).
|
||||
|
||||
The `configs` package contains some low-level functionality for constructing
|
||||
configuration objects, but the main entry point is in the sub-package
|
||||
[`configload`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/configs/configload]),
|
||||
via
|
||||
[`configload.Loader`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/configs/configload#Loader).
|
||||
A loader deals with all of the details of installing child modules
|
||||
(during `tofu init`) and then locating those modules again when a
|
||||
configuration is loaded by a backend. It takes the path to a root module
|
||||
and recursively loads all of the child modules to produce a single
|
||||
[`configs.Config`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/configs#Config)
|
||||
representing the entire configuration.
|
||||
|
||||
OpenTofu expects configuration files written in the OpenTofu language, which
|
||||
is a DSL built on top of
|
||||
[HCL](https://github.com/hashicorp/hcl). Some parts of the configuration
|
||||
cannot be interpreted until we build and walk the graph, since they depend
|
||||
on the outcome of other parts of the configuration, and so these parts of
|
||||
the configuration remain represented as the low-level HCL types
|
||||
[`hcl.Body`](https://pkg.go.dev/github.com/hashicorp/hcl/v2/#Body)
|
||||
and
|
||||
[`hcl.Expression`](https://pkg.go.dev/github.com/hashicorp/hcl/v2/#Expression),
|
||||
allowing OpenTofu to interpret them at a more appropriate time.
|
||||
|
||||
## State Manager
|
||||
|
||||
A _state manager_ is responsible for storing and retrieving snapshots of the
|
||||
[OpenTofu state](https://opentofu.org/docs/language/state/index.html)
|
||||
for a particular workspace. Each manager is an implementation of
|
||||
some combination of interfaces in
|
||||
[the `statemgr` package](https://pkg.go.dev/github.com/opentofu/opentofu/internal/states/statemgr),
|
||||
with most practical managers implementing the full set of operations
|
||||
described by
|
||||
[`statemgr.Full`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/states/statemgr#Full)
|
||||
provided by a _backend_. The smaller interfaces exist primarily for use in
|
||||
other function signatures to be explicit about what actions the function might
|
||||
take on the state manager; there is little reason to write a state manager
|
||||
that does not implement all of `statemgr.Full`.
|
||||
|
||||
The implementation
|
||||
[`statemgr.Filesystem`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/states/statemgr#Filesystem) is used
|
||||
by default (by the `local` backend) and is responsible for the familiar
|
||||
`terraform.tfstate` local file that most OpenTofu users start with, before
|
||||
they switch to [remote state](https://opentofu.org/docs/language/state/remote).
|
||||
Other implementations of `statemgr.Full` are used to implement remote state.
|
||||
Each of these saves and retrieves state via a remote network service
|
||||
appropriate to the backend that creates it.
|
||||
|
||||
A state manager accepts and returns a state snapshot as a
|
||||
[`states.State`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/states#State)
|
||||
object. The state manager is responsible for exactly how that object is
|
||||
serialized and stored, but all state managers at the time of writing use
|
||||
the same JSON serialization format, storing the resulting JSON bytes in some
|
||||
kind of arbitrary blob store.
|
||||
|
||||
## Graph Builder
|
||||
|
||||
A _graph builder_ is called by a
|
||||
[`tofu.Context`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#Context)
|
||||
method (e.g. `Plan` or `Apply`) to produce the graph that will be used
|
||||
to represent the necessary steps for that operation and the dependency
|
||||
relationships between them.
|
||||
|
||||
In most cases, the
|
||||
[vertices](https://en.wikipedia.org/wiki/Vertex_(graph_theory)) of OpenTofu's
|
||||
graphs each represent a specific object in the configuration, or something
|
||||
derived from those configuration objects. For example, each `resource` block
|
||||
in the configuration has one corresponding
|
||||
[`GraphNodeConfigResource`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#GraphNodeConfigResource)
|
||||
vertex representing it in the "plan" graph. (OpenTofu Core uses terminology
|
||||
inconsistently, describing graph _vertices_ also as graph _nodes_ in various
|
||||
places. These both describe the same concept.)
|
||||
|
||||
The [edges](https://en.wikipedia.org/wiki/Glossary_of_graph_theory_terms#edge)
|
||||
in the graph represent "must happen after" relationships. These define the
|
||||
order in which the vertices are evaluated, ensuring that e.g. one resource is
|
||||
created before another resource that depends on it.
|
||||
|
||||
Each operation has its own graph builder, because the graph building process
|
||||
is different for each. For example, a "plan" operation needs a graph built
|
||||
directly from the configuration, but an "apply" operation instead builds its
|
||||
graph from the set of changes described in the plan that is being applied.
|
||||
|
||||
The graph builders all work in terms of a sequence of _transforms_, which
|
||||
are implementations of
|
||||
[`tofu.GraphTransformer`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#GraphTransformer).
|
||||
Implementations of this interface just take a graph and mutate it in any
|
||||
way needed, and so the set of available transforms is quite varied. Some
|
||||
important examples include:
|
||||
|
||||
* [`ConfigTransformer`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#ConfigTransformer),
|
||||
which creates a graph vertex for each `resource` block in the configuration.
|
||||
|
||||
* [`StateTransformer`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#StateTransformer),
|
||||
which creates a graph vertex for each resource instance currently tracked
|
||||
in the state.
|
||||
|
||||
* [`ReferenceTransformer`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#ReferenceTransformer),
|
||||
which analyses the configuration to find dependencies between resources and
|
||||
other objects and creates any necessary "happens after" edges for these.
|
||||
|
||||
* [`ProviderTransformer`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#ProviderTransformer),
|
||||
which associates each resource or resource instance with exactly one
|
||||
provider configuration (implementing
|
||||
[the inheritance rules](https://opentofu.org/docs/language/providers/))
|
||||
and then creates "happens after" edges to ensure that the providers are
|
||||
initialized before taking any actions with the resources that belong to
|
||||
them.
|
||||
|
||||
There are many more different graph transforms, which can be discovered
|
||||
by reading the source code for the different graph builders. Each graph
|
||||
builder uses a different subset of these depending on the needs of the
|
||||
operation that is being performed.
|
||||
|
||||
The result of graph building is a
|
||||
[`tofu.Graph`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#Graph), which
|
||||
can then be processed using a _graph walker_.
|
||||
|
||||
## Graph Walk
|
||||
|
||||
The process of walking the graph visits each vertex of that graph in a way
|
||||
which respects the "happens after" edges in the graph. The walk algorithm
|
||||
itself is implemented in
|
||||
[the low-level `dag` package](https://pkg.go.dev/github.com/opentofu/opentofu/internal/dag#AcyclicGraph.Walk)
|
||||
(where "DAG" is short for [_Directed Acyclic Graph_](https://en.wikipedia.org/wiki/Directed_acyclic_graph)), in
|
||||
[`AcyclicGraph.Walk`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/dag#AcyclicGraph.Walk).
|
||||
However, the "interesting" OpenTofu walk functionality is implemented in
|
||||
[`tofu.ContextGraphWalker`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#ContextGraphWalker),
|
||||
which implements a small set of higher-level operations that are performed
|
||||
during the graph walk:
|
||||
|
||||
* `EnterPath` is called once for each module in the configuration, taking a
|
||||
module address and returning a
|
||||
[`tofu.EvalContext`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#EvalContext)
|
||||
that tracks objects within that module. `tofu.Context` is the _global_
|
||||
context for the entire operation, while `tofu.EvalContext` is a
|
||||
context for processing within a single module, and is the primary means
|
||||
by which the namespaces in each module are kept separate.
|
||||
|
||||
Each vertex in the graph is evaluated, in an order that guarantees that the
|
||||
"happens after" edges will be respected. If possible, the graph walk algorithm
|
||||
will evaluate multiple vertices concurrently. Vertex evaluation code must
|
||||
therefore make careful use of concurrency primitives such as mutexes in order
|
||||
to coordinate access to shared objects such as the `states.State` object.
|
||||
In most cases, we use the helper wrapper
|
||||
[`states.SyncState`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/states#SyncState)
|
||||
to safely implement concurrent reads and writes from the shared state.
|
||||
|
||||
## Vertex Evaluation
|
||||
|
||||
The action taken for each vertex during the graph walk is called
|
||||
_execution_. Execution runs a sequence of arbitrary actions that make sense
|
||||
for a particular vertex type.
|
||||
|
||||
For example, evaluation of a vertex representing a resource instance during
|
||||
a plan operation would include the following high-level steps:
|
||||
|
||||
* Retrieve the resource's associated provider from the `EvalContext`. This
|
||||
should already be initialized earlier by the provider's own graph vertex,
|
||||
due to the "happens after" edge between the resource node and the provider
|
||||
node.
|
||||
|
||||
* Retrieve from the state the portion relevant to the specific resource
|
||||
instance being evaluated.
|
||||
|
||||
* Evaluate the attribute expressions given for the resource in configuration.
|
||||
This often involves retrieving the state of _other_ resource instances so
|
||||
that their values can be copied or transformed into the current instance's
|
||||
attributes, which is coordinated by the `EvalContext`.
|
||||
|
||||
* Pass the current instance state and the resource configuration to the
|
||||
provider, asking the provider to produce an _instance diff_ representing the
|
||||
differences between the state and the configuration.
|
||||
|
||||
* Save the instance diff as part of the plan that is being constructed by
|
||||
this operation.
|
||||
|
||||
Each execution step for a vertex is an implementation of
|
||||
[`tofu.Execute`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#GraphNodeExecutable.Execute).
|
||||
As with graph transforms, the behavior of these implementations varies widely:
|
||||
whereas graph transforms can take any action against the graph, an `Execute`
|
||||
implementation can take any action against the `EvalContext`.
|
||||
|
||||
The implementation of `tofu.EvalContext` used in real processing
|
||||
(as opposed to testing) is
|
||||
[`tofu.BuiltinEvalContext`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#BuiltinEvalContext).
|
||||
It provides coordinated access to plugins, the current state, and the current
|
||||
plan via the `EvalContext` interface methods.
|
||||
|
||||
In order to be executed, a vertex must implement
|
||||
[`tofu.GraphNodeExecutable`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#GraphNodeExecutable),
|
||||
which has a single `Execute` method that handles. There are numerous `Execute`
|
||||
implementations with different behaviors, but some prominent examples are:
|
||||
|
||||
* [NodePlannableResource.Execute](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#NodePlannableResourceInstance.Execute), which handles the `plan` operation.
|
||||
|
||||
* [`NodeApplyableResourceInstance.Execute`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#NodeApplyableResourceInstance.Execute), which handles the main `apply` operation.
|
||||
|
||||
* [`NodeDestroyResourceInstance.Execute`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#EvalWriteState), which handles the main `destroy` operation.
|
||||
|
||||
A vertex must complete successfully before the graph walk will begin evaluation
|
||||
for other vertices that have "happens after" edges. Evaluation can fail with one
|
||||
or more errors, in which case the graph walk is halted and the errors are
|
||||
returned to the user.
|
||||
|
||||
### Expression Evaluation
|
||||
|
||||
An important part of vertex evaluation for most vertex types is evaluating
|
||||
any expressions in the configuration block associated with the vertex. This
|
||||
completes the processing of the portions of the configuration that were not
|
||||
processed by the configuration loader.
|
||||
|
||||
The high-level process for expression evaluation is:
|
||||
|
||||
1. Analyze the configuration expressions to see which other objects they refer
|
||||
to. For example, the expression `aws_instance.example[1]` refers to one of
|
||||
the instances created by a `resource "aws_instance" "example"` block in
|
||||
configuration. This analysis is performed by
|
||||
[`lang.References`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/lang#References),
|
||||
or more often one of the helper wrappers around it:
|
||||
[`lang.ReferencesInBlock`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/lang#ReferencesInBlock)
|
||||
or
|
||||
[`lang.ReferencesInExpr`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/lang#ReferencesInExpr)
|
||||
|
||||
1. Retrieve from the state the data for the objects that are referred to and
|
||||
create a lookup table of the values from these objects that the
|
||||
HCL evaluation code can refer to.
|
||||
|
||||
1. Prepare the table of built-in functions so that HCL evaluation can refer to
|
||||
them.
|
||||
|
||||
1. Ask HCL to evaluate each attribute's expression (a
|
||||
[`hcl.Expression`](https://pkg.go.dev/github.com/hashicorp/hcl/v2/#Expression)
|
||||
object) against the data and function lookup tables.
|
||||
|
||||
In practice, steps 2 through 4 are usually run all together using one
|
||||
of the methods on [`lang.Scope`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/lang#Scope);
|
||||
most commonly,
|
||||
[`lang.EvalBlock`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/lang#Scope.EvalBlock)
|
||||
or
|
||||
[`lang.EvalExpr`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/lang#Scope.EvalExpr).
|
||||
|
||||
Expression evaluation produces a dynamic value represented as a
|
||||
[`cty.Value`](https://pkg.go.dev/github.com/zclconf/go-cty/cty#Value).
|
||||
This Go type represents values from the OpenTofu language and such values
|
||||
are eventually passed to provider plugins.
|
||||
|
||||
### Sub-graphs
|
||||
|
||||
Some vertices have a special additional behavior that happens after their
|
||||
evaluation steps are complete, where the vertex implementation is given
|
||||
the opportunity to build another separate graph which will be walked as part
|
||||
of the evaluation of the vertex.
|
||||
|
||||
The main example of this is when a `resource` block has the `count` argument
|
||||
set. In that case, the plan graph initially contains one vertex for each
|
||||
`resource` block, but that graph then _dynamically expands_ to have a sub-graph
|
||||
containing one vertex for each instance requested by the count. That is, the
|
||||
sub-graph of `aws_instance.example` might contain vertices for
|
||||
`aws_instance.example[0]`, `aws_instance.example[1]`, etc. This is necessary
|
||||
because the `count` argument may refer to other objects whose values are not
|
||||
known when the main graph is constructed, but become known while evaluating
|
||||
other vertices in the main graph.
|
||||
|
||||
This special behavior applies to vertex objects that implement
|
||||
[`tofu.GraphNodeDynamicExpandable`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tofu#GraphNodeDynamicExpandable).
|
||||
Such vertices have their own nested _graph builder_, _graph walk_,
|
||||
and _vertex evaluation_ steps, with the same behaviors as described in these
|
||||
sections for the main graph. The difference is in which graph transforms
|
||||
are used to construct the graph and in which evaluation steps apply to the
|
||||
nodes in that sub-graph.
|
||||
361
network-poc/temp/frontend-old/public/docs/destroying.md
Normal file
@@ -0,0 +1,361 @@
|
||||
# OpenTofu Core Resource Destruction Notes
|
||||
|
||||
This document intends to describe some of the details and complications
|
||||
involved in the destruction of resources. It covers the ordering defined for
|
||||
related create and destroy operations, as well as changes to the lifecycle
|
||||
ordering imposed by `create_before_destroy`. It is not intended to enumerate
|
||||
all possible combinations of dependency ordering, only to outline the basics
|
||||
and document some of the more complicated aspects of resource destruction.
|
||||
|
||||
The graph diagrams here will continue to use the inverted graph structure used
|
||||
internally by OpenTofu, where edges represent dependencies rather than order
|
||||
of operations.
|
||||
|
||||
## Simple Resource Creation
|
||||
|
||||
In order to describe resource destruction, we first need to create the
|
||||
resources and define their order. The order of creation is that which fulfills
|
||||
the dependencies for each resource. In this example, `A` has no dependencies,
|
||||
`B` depends on `A`, and `C` depends on `B`, and transitively depends on `A`.
|
||||
|
||||

|
||||
<!--
|
||||
digraph create {
|
||||
subgraph nodes {
|
||||
rank=same;
|
||||
a [label="A create"];
|
||||
b [label="B create"];
|
||||
c [label="C create"];
|
||||
b -> c [dir=back];
|
||||
a -> b [dir=back];
|
||||
}
|
||||
}
|
||||
-->
|
||||
|
||||
Order of operations:
|
||||
1. `A` is created
|
||||
1. `B` is created
|
||||
1. `C` is created
|
||||
|
||||
## Resource Updates
|
||||
|
||||
An existing resource may be updated with references to a newly created
|
||||
resource. The ordering here is exactly the same as one would expect for
|
||||
creation.
|
||||
|
||||

|
||||
<!--
|
||||
digraph update {
|
||||
subgraph nodes {
|
||||
rank=same;
|
||||
a [label="A create"];
|
||||
b [label="B update"];
|
||||
c [label="C update"];
|
||||
b -> c [dir=back];
|
||||
a -> b [dir=back];
|
||||
}
|
||||
}
|
||||
-->
|
||||
|
||||
Order of operations:
|
||||
1. `A` is created
|
||||
1. `B` is created
|
||||
1. `C` is created
|
||||
|
||||
## Simple Resource Destruction
|
||||
|
||||
The order for destroying resource is exactly the inverse used to create them.
|
||||
This example shows the graph for the destruction of the same nodes defined
|
||||
above. While destroy nodes will not contain attribute references, we will
|
||||
continue to use the inverted edges showing dependencies for destroy, so the
|
||||
operational ordering is still opposite the flow of the arrows.
|
||||
|
||||

|
||||
<!--
|
||||
digraph destroy {
|
||||
subgraph nodes {
|
||||
rank=same;
|
||||
a [label="A destroy"];
|
||||
b [label="B destroy"];
|
||||
c [label="C destroy"];
|
||||
a -> b;
|
||||
b -> c;
|
||||
}
|
||||
}
|
||||
-->
|
||||
|
||||
Order of operations:
|
||||
1. `C` is destroyed
|
||||
1. `B` is destroyed
|
||||
1. `A` is Destroyed
|
||||
|
||||
## Resource Replacement
|
||||
|
||||
Resource replacement is the logical combination of the above scenarios. Here we
|
||||
will show the replacement steps involved when `B` depends on `A`.
|
||||
|
||||
In this first example, we simultaneously replace both `A` and `B`. Here `B` is
|
||||
destroyed before `A`, then `A` is recreated before `B`.
|
||||
|
||||

|
||||
<!--
|
||||
digraph replacement {
|
||||
subgraph create {
|
||||
rank=same;
|
||||
a [label="A create"];
|
||||
b [label="B create"];
|
||||
a -> b [dir=back];
|
||||
}
|
||||
subgraph destroy {
|
||||
rank=same;
|
||||
a_d [label="A destroy"];
|
||||
b_d [label="B destroy"];
|
||||
a_d -> b_d;
|
||||
}
|
||||
|
||||
a -> a_d;
|
||||
a -> b_d [style=dotted];
|
||||
b -> a_d [style=dotted];
|
||||
b -> b_d;
|
||||
}
|
||||
-->
|
||||
|
||||
Order of operations:
|
||||
1. `B` is destroyed
|
||||
1. `A` is destroyed
|
||||
1. `A` is created
|
||||
1. `B` is created
|
||||
|
||||
|
||||
This second example replaces only `A`, while updating `B`. Resource `B` is only
|
||||
updated once `A` has been destroyed and recreated.
|
||||
|
||||

|
||||
<!--
|
||||
digraph replacement {
|
||||
subgraph create {
|
||||
rank=same;
|
||||
a [label="A create"];
|
||||
b [label="B update"];
|
||||
a -> b [dir=back];
|
||||
}
|
||||
subgraph destroy {
|
||||
rank=same;
|
||||
a_d [label="A destroy"];
|
||||
}
|
||||
|
||||
a -> a_d;
|
||||
b -> a_d [style=dotted];
|
||||
}
|
||||
-->
|
||||
|
||||
Order of operations:
|
||||
1. `A` is destroyed
|
||||
1. `A` is created
|
||||
1. `B` is updated
|
||||
|
||||
|
||||
While the dependency edge from `B update` to `A destroy` isn't necessary in
|
||||
these examples, it is shown here as an implementation detail which will be
|
||||
mentioned later on.
|
||||
|
||||
A final example based on the replacement graph; starting with the above
|
||||
configuration where `B` depends on `A`. The graph is reduced to an update of
|
||||
`A` while only destroying `B`. The interesting feature here is the remaining
|
||||
dependency of `A update` on `B destroy`. We can derive this ordering of
|
||||
operations from the full replacement example above, by replacing `A create`
|
||||
with `A update` and removing the unused nodes.
|
||||
|
||||

|
||||
<!--
|
||||
digraph destroy_then_update {
|
||||
subgraph update {
|
||||
rank=same;
|
||||
a [label="A update"];
|
||||
}
|
||||
subgraph destroy {
|
||||
rank=same;
|
||||
b_d [label="B destroy"];
|
||||
}
|
||||
|
||||
a -> b_d;
|
||||
}
|
||||
-->
|
||||
## Create Before Destroy
|
||||
|
||||
Currently, the only user-controllable method for changing the ordering of
|
||||
create and destroy operations is with the `create_before_destroy` resource
|
||||
`lifecycle` attribute. This has the obvious effect of causing a resource to be
|
||||
created before it is destroyed when replacement is required, but has a couple
|
||||
of other effects we will detail here.
|
||||
|
||||
Taking the previous replacement examples, we can change the behavior of `A` to
|
||||
be that of `create_before_destroy`.
|
||||
|
||||

|
||||
<!--
|
||||
digraph replacement {
|
||||
subgraph create {
|
||||
rank=same;
|
||||
a [label="A create"];
|
||||
b [label="B create"];
|
||||
a -> b [dir=back];
|
||||
}
|
||||
subgraph destroy {
|
||||
rank=same;
|
||||
a_d [label="A destroy"];
|
||||
b_d [label="B destroy"];
|
||||
a_d -> b_d;
|
||||
}
|
||||
|
||||
a -> a_d [dir=back];
|
||||
a -> b_d;
|
||||
b -> a_d [dir=back];
|
||||
b -> b_d;
|
||||
}
|
||||
-->
|
||||
|
||||
|
||||
Order of operations:
|
||||
1. `B` is destroyed
|
||||
2. `A` is created
|
||||
1. `B` is created
|
||||
1. `A` is destroyed
|
||||
|
||||
Note that in this first example, the creation of `B` is inserted in between the
|
||||
creation of `A` and the destruction of `A`. This becomes more important in the
|
||||
update example below.
|
||||
|
||||
|
||||

|
||||
<!--
|
||||
digraph replacement {
|
||||
subgraph create {
|
||||
rank=same;
|
||||
a [label="A create"];
|
||||
b [label="B update"];
|
||||
a -> b [dir=back];
|
||||
}
|
||||
subgraph destroy {
|
||||
rank=same;
|
||||
a_d [label="A destroy"];
|
||||
}
|
||||
|
||||
a -> a_d [dir=back, style=dotted];
|
||||
b -> a_d [dir=back];
|
||||
}
|
||||
-->
|
||||
|
||||
Order of operations:
|
||||
1. `A` is created
|
||||
1. `B` is updated
|
||||
1. `A` is destroyed
|
||||
|
||||
Here we can see clearly how `B` is updated after the creation of `A` and before
|
||||
the destruction of the _deposed_ resource `A`. (The prior resource `A` is
|
||||
sometimes referred to as "deposed" before it is destroyed, to disambiguate it
|
||||
from the newly created `A`.) This ordering is important for resource that
|
||||
"register" other resources, and require updating before the dependent resource
|
||||
can be destroyed.
|
||||
|
||||
The transformation used to create these graphs is also where we use the extra
|
||||
edges mentioned above connecting `B` to `A destroy`. The algorithm to change a
|
||||
resource from the default ordering to `create_before_destroy` simply inverts
|
||||
any incoming edges from other resources, which automatically creates the
|
||||
necessary dependency ordering for dependent updates. This also ensures that
|
||||
reduced versions of this example still adhere to the same ordering rules, such
|
||||
as when the dependency is only being removed:
|
||||
|
||||

|
||||
<!--
|
||||
digraph update {
|
||||
subgraph create {
|
||||
rank=same;
|
||||
b [label="B update"];
|
||||
}
|
||||
subgraph destroy {
|
||||
rank=same;
|
||||
a_d [label="A destroy"];
|
||||
}
|
||||
|
||||
b -> a_d [dir=back];
|
||||
}
|
||||
-->
|
||||
|
||||
Order of operations:
|
||||
1. `B` is updated
|
||||
1. `A` is destroyed
|
||||
|
||||
### Forced Create Before Destroy
|
||||
|
||||
In the previous examples, only resource `A` was being used as is it were
|
||||
`create_before_destroy`. The minimal graphs used show that it works in
|
||||
isolation, but that is only when the `create_before_destroy` resource has no
|
||||
dependencies of it own. When a `create_before_resource` depends on another
|
||||
resource, that dependency is "infected" by the `create_before_destroy`
|
||||
lifecycle attribute.
|
||||
|
||||
This example demonstrates why forcing `create_before_destroy` is necessary. `B`
|
||||
has `create_before_destroy` while `A` does not. If we only invert the ordering
|
||||
for `B`, we can see that results in a cycle.
|
||||
|
||||

|
||||
<!--
|
||||
digraph replacement {
|
||||
subgraph create {
|
||||
rank=same;
|
||||
a [label="A create"];
|
||||
b [label="B create"];
|
||||
a -> b [dir=back];
|
||||
}
|
||||
subgraph destroy {
|
||||
rank=same;
|
||||
a_d [label="A destroy"];
|
||||
b_d [label="B destroy"];
|
||||
a_d -> b_d;
|
||||
}
|
||||
|
||||
a -> a_d;
|
||||
a -> b_d [style=dotted];
|
||||
b -> a_d [style=dotted];
|
||||
b -> b_d [dir=back];
|
||||
}
|
||||
-->
|
||||
|
||||
In order to resolve these cycles, all resources that precede a resource
|
||||
with `create_before_destroy` must in turn be handled in the same manner.
|
||||
Reversing the incoming edges to `A destroy` resolves the problem:
|
||||
|
||||

|
||||
<!--
|
||||
digraph replacement {
|
||||
subgraph create {
|
||||
rank=same;
|
||||
a [label="A create"];
|
||||
b [label="B create"];
|
||||
a -> b [dir=back];
|
||||
}
|
||||
subgraph destroy {
|
||||
rank=same;
|
||||
a_d [label="A destroy"];
|
||||
b_d [label="B destroy"];
|
||||
a_d -> b_d;
|
||||
}
|
||||
|
||||
a -> a_d [dir=back];
|
||||
a -> b_d [dir=back, style=dotted];
|
||||
b -> a_d [dir=back, style=dotted];
|
||||
b -> b_d [dir=back];
|
||||
}
|
||||
-->
|
||||
|
||||
Order of operations:
|
||||
1. `A` is created
|
||||
1. `B` is created
|
||||
1. `B` is destroyed
|
||||
1. `A` is destroyed
|
||||
|
||||
This also demonstrates why `create_before_destroy` cannot be overridden when
|
||||
it is inherited; changing the behavior here isn't possible without removing
|
||||
the initial reason for `create_before_destroy`; otherwise cycles are always
|
||||
introduced into the graph.
|
||||
495
network-poc/temp/frontend-old/public/docs/diagnostics.md
Normal file
@@ -0,0 +1,495 @@
|
||||
# OpenTofu Diagnostics Guide
|
||||
|
||||
"Diagnostics" is the general term we use to describe the error and warning
|
||||
messages that OpenTofu returns when there are problems with the configuration,
|
||||
or when interactions with external systems fail.
|
||||
|
||||
This document is an overview of how we typically use diagnostics in OpenTofu.
|
||||
It includes both some technical information about how we represent diagnostics
|
||||
in code, and some more subjective information about the writing style we most
|
||||
often use in diagnostic messages.
|
||||
|
||||
## Diagnostics in Code
|
||||
|
||||
Diagnostics are modelled using the types from
|
||||
[the `tfdiags` package](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags).
|
||||
|
||||
In particular:
|
||||
- [`tfdiags.Diagnostics`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags#Diagnostics)
|
||||
represents a set of zero or more diagnostics.
|
||||
|
||||
A total lack of diagnostics is usually represented by a `nil` value of this
|
||||
type.
|
||||
|
||||
When constructing sets of diagnostics to return we typically don't worry
|
||||
about the order they are returned in, even though we return them using a
|
||||
slice type. The UI-layer code uses
|
||||
[`tfdiags.Diagnostics.Sort`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags#Diagnostics.Sort)
|
||||
to place all of the collected diagnostics into a predictable order before
|
||||
rendering them, and so that function effectively turns the set of
|
||||
diagnostics into an ordered list of diagnostics _just in time_.
|
||||
|
||||
- [`tfdiags.Diagnostic`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags#Diagnostic)
|
||||
is an interface type that all diagnostic values implement.
|
||||
|
||||
In practice values of this type are often created automatically as an
|
||||
implementation detail of [`Diagnostics.Append`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags#Diagnostics.Append),
|
||||
which accepts various types that _don't_ directly implement
|
||||
`Diagnostic` and then automatically wraps them in a type that does.
|
||||
In particular:
|
||||
|
||||
- We often use [`hcl.Diagnostic`](https://pkg.go.dev/github.com/hashicorp/hcl/v2#Diagnostic)
|
||||
to describe problems related to the configuration or operations that are
|
||||
strongly related to parts of the configuration, because it is the most
|
||||
fully-fledged type of diagnostic we allow including support for source
|
||||
ranges and relevant expressions as described later.
|
||||
|
||||
It's also acceptable to append a whole `hcl.Diagnostics` (the HCL
|
||||
equivalent of `tfdiags.Diagnostics`) in which case each diagnostic
|
||||
will be wrapped and appended in turn. This is common when calling
|
||||
HCL's own functions and passing on its diagnostics verbatim.
|
||||
- Normal `error` values can be appended to a `tfdiags.Diagnostics`, but
|
||||
that's mainly for historical reasons -- adapting code that was present
|
||||
before the diagnostic models were added -- and should not be used in new
|
||||
code because it typically results in low-quality diagnostics that don't
|
||||
meet the style guidelines later in this document.
|
||||
|
||||
One exception is for "should never happen" cases: we sometimes use
|
||||
`error` directly in that case to avoid overwhelming the surrounding
|
||||
code with the construction of a full diagnostic.
|
||||
|
||||
Package `tfdiags` also includes some functions for constructing other kinds
|
||||
of diagnostics, including:
|
||||
|
||||
- [`tfdiags.Sourceless`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags#Sourceless)
|
||||
is good for diagnostics that don't relate to any part of the configuration,
|
||||
such as when reporting incorrect usage of a command line argument.
|
||||
- [`tfdiags.AttributeValue`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags#AttributeValue) and
|
||||
[`tfdiags.WholeContainingBody`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags#WholeContainingBody)
|
||||
produce special "contextual diagnostics" that must be transformed by
|
||||
calling [`InConfigBody`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags#Diagnostics.InConfigBody)
|
||||
on the resulting `Diagnostics` value. This is a special mechanism used
|
||||
when the subsystem generating the diagnostic does not have direct access
|
||||
to the configuration itself, such as when a provider returns a diagnostic
|
||||
via the provider wire protocol.
|
||||
- [`tfdiags.Severity`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags#Severity)
|
||||
(and its HCL equivalent [`hcl.DiagnosticSeverity`](https://pkg.go.dev/github.com/hashicorp/hcl/v2#DiagnosticSeverity))
|
||||
are how we distinguish between "error" and "warning" diagnostics.
|
||||
|
||||
The `tfdiags.Diagnostics.HasErrors` method returns true if the diagnostics
|
||||
contains at least one with the severity `tfdiags.Error`.
|
||||
|
||||
The most common pattern for handling diagnostics in code is:
|
||||
1. Declare `var diags tfdiags.Diagnostics` at the very start of a function.
|
||||
2. During the function's body, whenever calling another function that might
|
||||
produce its own diagnostics, capture them into a separate variable
|
||||
(often called `moreDiags`, or `hclDiags` if the return type is
|
||||
`hcl.Diagnostics`) and then immediately append them to the main `diags`
|
||||
using `tfdiags.Diagnostics.Append`.
|
||||
|
||||
If subsequent code depends on the success of the call, check
|
||||
`moreDiags.HasErrors()` (or similar) and return early if it returns `true`.
|
||||
3. If the function generates any diagnostics of its own, append them directly
|
||||
to `diags`.
|
||||
4. At all exit points of the function, return `diags` regardless of whether
|
||||
it has been assigned to or whether it contains errors. This ensures that
|
||||
we always return any warnings that might have been produced and avoids
|
||||
the risk of missing certain return paths under future maintenance if we
|
||||
introduce additional diagnostics later.
|
||||
|
||||
Here's a code-example version of the above advice:
|
||||
|
||||
```go
|
||||
func Example() (anything, tfdiags.Diagnostics) {
|
||||
var diags tfdiags.Diagnostics
|
||||
|
||||
somethingElse, moreDiags := otherFunction()
|
||||
diags = diags.Append(moreDiags)
|
||||
if moreDiags.HasErrors() {
|
||||
// NOTE: it isn't _always_ necessary to return immediately when there
|
||||
// are errors, as long as the callee clearly documents what it
|
||||
// guarantees about an errored result and the caller is able to
|
||||
// work within those limitations. Collecting multiple errors to
|
||||
// return together is often desirable.
|
||||
//
|
||||
// If the caller cannot continue at all though, or if continuing is
|
||||
// likely to cause redundant errors that just restate the same problem
|
||||
// in more confusing terms, then...
|
||||
return nil, diags
|
||||
}
|
||||
if isProblematic(somethingElse) {
|
||||
// A function might need to generate its own diagnostics if it detects
|
||||
// a problem directly.
|
||||
diags = diags.Append(&hcl.Diagnostic{
|
||||
Severity: hcl.DiagError,
|
||||
// ...
|
||||
})
|
||||
return nil, diags
|
||||
}
|
||||
|
||||
// ...
|
||||
|
||||
// The final return statement should include diags even if no errors
|
||||
// were detected along the way, because it might contain warnings.
|
||||
return something, diags
|
||||
}
|
||||
```
|
||||
|
||||
Some functions diverge from this pattern for special reasons, such as capturing
|
||||
multiple sets of child function diagnostics and then using some logic to decide
|
||||
which ones to append, or processing multiple items in a loop and appending
|
||||
new diagnostics for each iteration. The above is just a general example of the
|
||||
most common case, not a fixed template to follow in all cases.
|
||||
|
||||
## Information in a Diagnostic
|
||||
|
||||
The general model of `tfdiags.Diagnostic` has the following parts, though not
|
||||
all implementations of the interface make use of all of them:
|
||||
|
||||
- Severity: either `tfdiags.Error` or `tfdiags.Warning`.
|
||||
- Description: the main human-readable text describing the problem. This
|
||||
has the following fields:
|
||||
|
||||
- Summary: A short, terse description of the general type of problem
|
||||
that has occurred.
|
||||
- Detail: A longer description of the problem, sometimes including multiple
|
||||
paragraphs of information.
|
||||
- Address: The address of some object that the error relates to, which
|
||||
is most often a resource instance address.
|
||||
|
||||
OpenTofu does not currently have a localized UI, so built-in diagnostics
|
||||
always have their summary and detail written in US English. There's more
|
||||
subjective guidance about the content of these fields in sections below.
|
||||
- Source location information: optional references to parts of the configuration
|
||||
that the problem relates to. This has the following fields:
|
||||
|
||||
- Subject: source range for the part of the configuration that caused the
|
||||
problem or that the problem is directly about.
|
||||
- Context: optional source range of a larger section of configuration that
|
||||
might make the cause of the problem easier to quickly understand if
|
||||
included in the diagnostic message. The Context source range must always
|
||||
contain the Subject source range within it.
|
||||
|
||||
The UI uses the context and subject together to display a source code
|
||||
snippet. The lines of code included in the snippet cover both the context
|
||||
and the subject, and then the subject itself is rendered with an underline
|
||||
if we're rendering into a terminal that supports that style.
|
||||
|
||||
We don't use "context" very often, but it can be useful if the problem
|
||||
we're describing is that just one part of a larger source element is
|
||||
problematic. For example, if one of the operands to the `+` operator
|
||||
isn't a number then that operand would be the "subject" but the entire
|
||||
addition operation could be returned as "context", so that both of the
|
||||
operands and the `+` symbol will definitely be included in the rendered
|
||||
diagnostic too.
|
||||
- Expression-related information: optional information about an expression whose
|
||||
evaluation cause the problem. This has the following fields:
|
||||
|
||||
- Expression: The `hcl.Expression` representing the expression itself.
|
||||
- EvalContext: The `hcl.EvalContext` that the expression was being evaluated
|
||||
in.
|
||||
|
||||
The diagnostic renderer for the UI uses this information, when available,
|
||||
to offer some extra hints about the values of any symbols that were used
|
||||
in the expression, because it's often the dynamic values that cause a
|
||||
problem, rather than the syntax used to obtain them.
|
||||
- Extra info: this is a rather underspecified collection of assorted other
|
||||
information that's only relevant in very specific contexts. Refer to the
|
||||
`tfdiags` package documentation for more information.
|
||||
|
||||
There's _some_ guidance on this later in this document, but it's focused
|
||||
only on a few main cases.
|
||||
|
||||
## Diagnostic Description Writing Style
|
||||
|
||||
Although there is some variation in diagnostic writing style, particularly in
|
||||
parts of the system like state storage backends which were originally written by
|
||||
third-parties, most of the _built-in_ diagnostics follow a relatively consistent
|
||||
writing style that is in turn based on the writing style used by HCL itself in
|
||||
its own diagnostics, because HCL and OpenTofu diagnostics often mix together
|
||||
in the same set of problems.
|
||||
|
||||
The "summary" should typically be a very short and concise description of
|
||||
what was wrong and what was wrong about it. Our summaries typically don't
|
||||
include any user-chosen information such as symbol names, because that means a
|
||||
particular kind of problem is always described using the same text and so
|
||||
readers can become familiar enough with the summaries of problems they see
|
||||
frequently to skip reading the rest of the diagnostic when skimming.
|
||||
|
||||
The following are some real examples of summaries currently used across both
|
||||
HCL and OpenTofu:
|
||||
|
||||
- Unsupported operator
|
||||
- Duplicate argument
|
||||
- Invalid index
|
||||
- Unexpected end of template
|
||||
- Invalid template interpolation value
|
||||
- Invalid default value for variable
|
||||
- Required variable not set
|
||||
- Invalid "count" attribute
|
||||
|
||||
The "detail" text is where we tend to put most of the information, and so
|
||||
there's a lot more variation here but ideally a good diagnostic detail
|
||||
should mention the following information, usually in the following order:
|
||||
|
||||
- What was wrong and what was wrong about it: similar to the summary but this
|
||||
time including information about specifically what was wrong, such as the
|
||||
name of the input variable whose default value was invalid.
|
||||
- Why the situation is problematic, if knowing that relies on some
|
||||
characteristic of OpenTofu's design that might not be obvious to a newcomer.
|
||||
- What should be done to fix it, or (if it's unclear what the author's intention
|
||||
was) a question-sentence that implies a _possible_ solution, often starting
|
||||
with the words "Did you mean" and ending with a question mark.
|
||||
|
||||
While the summary message is often terse and uses only minimal punctuation,
|
||||
the detail message should always be written in full sentences including
|
||||
end-of-sentence punctuation (`.`, `?`). If "what was wrong about it" is
|
||||
coming from the string representation of an `error` value, we typically
|
||||
present it with a prefix ending with a colon and then append a period `.`
|
||||
after the error string, and format the error itself using `tfdiags.FormatError`,
|
||||
like this:
|
||||
|
||||
```go
|
||||
Detail: fmt.Sprintf("Unsuitable value for thingy: %s.", tfdiags.FormatError(err))
|
||||
```
|
||||
|
||||
If the second and third items in the above take more than a few words, it's
|
||||
helpful to split them into their own paragraphs for easier scanning. When
|
||||
writing multiple paragraphs in a detail message they should be separated by
|
||||
`\n\n` -- two newline characters.
|
||||
|
||||
In many cases our diagnostics only include a subset of this information because
|
||||
either the reason why it's problematic is relatively clear or because we don't
|
||||
have any specific suggestion for how to solve the problem, but the following
|
||||
is an example of a real diagnostic message from OpenTofu at the time of writing
|
||||
this documentation which includes all of these parts:
|
||||
|
||||
```
|
||||
Error: Invalid for_each argument
|
||||
|
||||
The "for_each" map includes keys derived from resource attributes that cannot
|
||||
be determined until apply, and so OpenTofu cannot determine the full set of keys
|
||||
that will identify the instances of this resource.
|
||||
|
||||
When working with unknown values in for_each, it's better to define the map keys
|
||||
statically in your configuration and place apply-time results only in the map
|
||||
values.
|
||||
|
||||
Alternatively, you could use the planning option -exclude=aws_instance.example
|
||||
to first apply without this object, and then apply normally to converge.
|
||||
```
|
||||
|
||||
The text immediately after "Error:" above is the summary for this diagnostic.
|
||||
The paragraphs that follow are all a single "detail" string.
|
||||
|
||||
That was a particularly extreme diagnostic message with lots of information to
|
||||
communicate. Most diagnostics are not so complicated; the following is an
|
||||
example with less information to communicate:
|
||||
|
||||
```
|
||||
Error: Invalid value for input variable
|
||||
|
||||
The given value is not suitable for var.example declared
|
||||
at example.tf:12,1: a string is required.
|
||||
```
|
||||
|
||||
This example also illustrates a situation where there are two different source
|
||||
locations that could be relevant: the input variable's declaration or the
|
||||
expression that's used to define its value. Because this message is talking
|
||||
about a problem with the _value_, the diagnostic should have the source
|
||||
"Subject" set to the expression that defined it, but it also mentions the
|
||||
location of the declaration as part of the detail text as some additional
|
||||
context.
|
||||
|
||||
Some other notes about some other specific situations that arise sometimes:
|
||||
|
||||
- If a diagnostic message includes a suggestion for a shell command to run
|
||||
or a URL to visit for more information, use a paragraph that ends with a
|
||||
colon, followed by a single newline, four spaces for indentation, and then the
|
||||
command or URL:
|
||||
|
||||
```
|
||||
To view the root module output values, run:
|
||||
tofu output
|
||||
```
|
||||
|
||||
The goal of this formatting is to make it very clear what part of the
|
||||
message is intended to be copied and used elsewhere, by placing it on a
|
||||
line of its own without any surrounding punctuation. The indented text
|
||||
should ideally be formatted so that the user can copy it _verbatim_ into
|
||||
whatever place it will be used.
|
||||
|
||||
The diagnostic renderer also has a special case where it will not try to
|
||||
word-wrap a line that begins with spaces, and so this layout has the
|
||||
useful side-effect of avoiding introducing extra newline characters into
|
||||
a command line that is intended to be copied.
|
||||
|
||||
- There are some terminology choices we use to refer to some OpenTofu-specific
|
||||
ideas and concepts that disagree slightly with terminology used in the code.
|
||||
These differences are the result of learning from feedback from folks who
|
||||
had been confused by the original terminology, even though the code still
|
||||
often uses the original terminology:
|
||||
|
||||
- Instead of referring to "unknown values" or "computed values" we say that
|
||||
values are "known after apply" or "cannot be determined until apply".
|
||||
- In HCL the word "variable" means anything that's available to refer to
|
||||
in the current evaluation context, which is confusing because OpenTofu
|
||||
itself uses that word to refer only to input variables.
|
||||
|
||||
Sometimes messages are generated by HCL itself and so it's unavoidably
|
||||
confusing, but when we're generating messages _inside OpenTofu_ we
|
||||
use the two words "input variable" to refer to an input variable,
|
||||
and "symbol" or "object" (depending on whether we're talking about
|
||||
the name itself or what the name refers to) as the general word for
|
||||
something you can refer to in an expression.
|
||||
- For consistency with our use of "input variable" to distinguish from
|
||||
HCL's more general meaning of "variable", we also tend to write
|
||||
"local value" and "output value" when referring to those concepts, rather
|
||||
than using the shorthands "locals" and "outputs".
|
||||
- HCL distinguishes between "attributes" meaning the named keys inside an
|
||||
object type, and "arguments" meaning the names used for individual
|
||||
settings inside a configuration block.
|
||||
|
||||
OpenTofu itself uses those words a little more interchangeably because
|
||||
in _many_ cases the configuration arguments in a block directly
|
||||
correspond to the attributes of an object created by evaluating that
|
||||
block.
|
||||
|
||||
However, if a particular error message is talking about a configuration
|
||||
setting inside a block it's better to use "argument" rather than
|
||||
"attribute" because that's then consistent with error messages that
|
||||
HCL itself might generate.
|
||||
|
||||
Go uses the term "field" to describe an element of a struct type, and
|
||||
JavaScript and JSON use the word "property" to describe an element of
|
||||
an object type. We don't use either of those words in OpenTofu: the
|
||||
elements of an object are its _attributes_, and the settings available
|
||||
in a configuration block are its _arguments_. The string values that
|
||||
identify elements of a map are called "keys".
|
||||
- The `cty` terminology "marks" or "value marks" refers to an implementation
|
||||
detail that should never be mentioned directly in an error message.
|
||||
|
||||
Instead, we use specific terminology related to what each mark type
|
||||
is representing: "sensitive values", "ephemeral values", etc.
|
||||
- `aws_instance` is an example of a "resource _type_", not of a "resource",
|
||||
even though the provider protocol uses the single noun "resource" to refer
|
||||
to both ideas.
|
||||
|
||||
A "resource" is what's declared by a `resource`, `data`, or `ephemeral`
|
||||
block. A "resource _instance_" is what such a block can declare zero
|
||||
or more of, when using the `count`, `for_each`, or `enabled` arguments.
|
||||
- Although there are certainly some historical diagnostic messages that
|
||||
predate this adjustment of terminology, new error messages should use
|
||||
"managed resource" to refer to the kind of resource that's declared
|
||||
using a `resource` block, "data resource" for `data` blocks, and
|
||||
"ephemeral resource" for an `ephemeral` block.
|
||||
|
||||
In the code we refer to these three as "resource _modes_", but that is
|
||||
internal terminology that should never appear in a diagnostic message.
|
||||
- When a file or directory path appears as part of a diagnostic message, it
|
||||
should typically be presented relative to the current working directory and
|
||||
should use the syntax conventions of the platform where OpenTofu is running.
|
||||
|
||||
In particular, we return paths using backslashes as the separator when we
|
||||
are running on Windows, but normal slashes otherwise. Using the Go
|
||||
`filepath` package is a good way to get this right, though you might need
|
||||
to add some complexity to your tests to make them pass on all platforms.
|
||||
- If an error message is describing a "should never happen" case, we typically
|
||||
end the detail string with the sentence "This is a bug in OpenTofu.". This
|
||||
hopefully prompts the reader that this wasn't directly caused by something
|
||||
they did, and so they should probably open a bug report in the
|
||||
OpenTofu repository instead of just trying to solve it themselves.
|
||||
|
||||
For this kind of error message we often relax our preference against
|
||||
mentioning implementation details in the error message, because the most
|
||||
likely next step is for the user to copy-paste the entire message into their
|
||||
bug report text and so the final reader of the message is OpenTofu
|
||||
maintainers rather than OpenTofu users.
|
||||
|
||||
For example, it can be okay to use internal terminology like "cty marks" and
|
||||
use the `GoString` representations of values in a "This is a bug in
|
||||
OpenTofu" detail message, if that's the most concise way to capture the
|
||||
information the OpenTofu maintainers would need to debug the problem.
|
||||
|
||||
## Diagnostics caused by unknown or sensitive values
|
||||
|
||||
When a diagnostic has expression information associated with it, the diagnostic
|
||||
renderer for the UI includes some additional information about the values
|
||||
that were in scope, like this:
|
||||
|
||||
```
|
||||
var.greeting is "Hello"
|
||||
var.items is list of string with 5 elements
|
||||
```
|
||||
|
||||
By default, this renderer will not mention any symbol which refers to an unknown
|
||||
or sensitive value. That was not historically true: originally, this could
|
||||
say something like "var.example is a string, known only after apply".
|
||||
|
||||
Those who are less familiar with these concepts often misunderstood the
|
||||
"known only after apply" part of the message as being _the problem itself_,
|
||||
rather than just context to help diagnose the problem, and so the UI no longer
|
||||
mentions "unknown-ness" or "sensitive-ness" in most cases.
|
||||
|
||||
However, there are some diagnostics messages that _are_ directly caused by the
|
||||
presence of an unknown or sensitive value, in which case it's helpful to
|
||||
mention that in the summary of values that were in scope.
|
||||
|
||||
To allow for this, we set the "extra info" field of a diagnostic to contain
|
||||
an implementation of one of the following interfaces:
|
||||
|
||||
- [`tfdiags.DiagnosticExtraBecauseUnknown`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags#DiagnosticExtraBecauseUnknown)
|
||||
for a problem that's caused by an unknown value.
|
||||
|
||||
(Remember that the _text_ of the error message should refer to this as "known
|
||||
only after apply", or similar.)
|
||||
- [`tfdiags.DiagnosticExtraBecauseSensitive`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags#DiagnosticExtraBecauseSensitive)
|
||||
for situations where a sensitive value was used in a location that OpenTofu
|
||||
cannot permit it, such as in the instance key of a resource instance.
|
||||
|
||||
These extra markers should be used only when mentioning the unknown or sensitive
|
||||
values in the diagnostic message is likely to help with debugging a problem.
|
||||
If the problem is not directly caused by unknown or sensitive values then
|
||||
neither of these should be used, to avoid creating a distracting
|
||||
[red herring](https://en.wikipedia.org/wiki/Red_herring) for the reader.
|
||||
|
||||
## Consolidation of Diagnostics
|
||||
|
||||
The UI layer has some special rules for finding sets of similar diagnostics
|
||||
and showing them as just a single diagnostic referring to the first example
|
||||
of a problem, with a short extra note about how many other similar diagnostics
|
||||
there are.
|
||||
|
||||
```
|
||||
(and 2 similar warnings elsewhere)
|
||||
```
|
||||
|
||||
The main implementation of this behavior is in
|
||||
[`tfdiags.Diagnostics.Consolidate`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags#Diagnostics.Consolidate),
|
||||
but we allow end-users to customize (using command line options) whether this
|
||||
consolidation applies to errors or warnings separately. By default, we
|
||||
consolidate only warnings.
|
||||
|
||||
For a severity that is subject to consolidation, the main behavior is to group
|
||||
together diagnostics that have the same "summary" text, and this is part of
|
||||
why we tend to use terse, fixed strings in the summary field.
|
||||
|
||||
There are two extra mechanisms for customizing this behavior for specific
|
||||
diagnostic messages:
|
||||
|
||||
- If the "extra info" of a diagnostic contains an implementation of
|
||||
[`tfdiags.DiagnosticExtraDoNotConsolidate`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags#DiagnosticExtraDoNotConsolidate)
|
||||
then that diagnostic is not eligible for consolidation at all, regardless
|
||||
of how similar it might be to other diagnostics in the same set.
|
||||
- If the "extra info" of a diagnostic contains an implementation of
|
||||
[`tfdiags.Keyable`](https://pkg.go.dev/github.com/opentofu/opentofu/internal/tfdiags#Keyable)
|
||||
then the string returned by its `ExtraInfoKey` method is used _in addition to_
|
||||
the summary text for deciding what to consolidate.
|
||||
|
||||
For example, if there were three warnings with the same summary text but
|
||||
two of them have the same `ExtraInfoKey` and the third has a different
|
||||
one then only the first two would be able to consolidate.
|
||||
|
||||
The `ExtraInfoKey` is an internal key used for comparison only and is never
|
||||
exposed in the UI, so it can be set to whatever makes sense to define
|
||||
separate consolidation groups for diagnostics with a specific summary.
|
||||
78
network-poc/temp/frontend-old/public/docs/glossary.md
Normal file
@@ -0,0 +1,78 @@
|
||||
# OpenTofu glossary
|
||||
This document is intended for anyone who wants to gain more knowledge about the terms and vocabulary used to talk about different concepts in OpenTofu.
|
||||
|
||||
> [!NOTE]
|
||||
> This was created with the intent of gathering more knowledge over time.
|
||||
> The state that you find this in right now could be incomplete.
|
||||
> Once you discover and learn about a new concept that would benefit others,
|
||||
> feel free to open a PR to update this.
|
||||
|
||||
> [!NOTE]
|
||||
> When adding new content to this document, try to place it in such a way to match the alphabetical order of the already existing content.
|
||||
>
|
||||
> Optionally, also add a reference link if possible (GitHub conversation, issue, other docs, etc).
|
||||
|
||||
## OpenTofu
|
||||
### Attribute/argument/field
|
||||
* Attribute - a named key inside an object type.
|
||||
* Argument - a name used for an individual setting inside a configuration block.
|
||||
|
||||
It is recommended to avoid using popular programming language terms such as "field" or "property" to describe an element of an object in OpenTofu.
|
||||
|
||||
Reference: [link](./diagnostics.md#diagnostic-description-writing-style)
|
||||
|
||||
### Data sources/data resource
|
||||
* Data source - the remote thing that the data resource reads from.
|
||||
* Data resource - refers to a block of type `data`, and the associated object it declares.
|
||||
* Data resource type - is what is represented by the first label in a `data` block header, and the associated declarations and code for it in the provider plugin.
|
||||
|
||||
Reference: [link](https://github.com/opentofu/opentofu/pull/3389#discussion_r2440264786)
|
||||
|
||||
### Diagnostic
|
||||
"Diagnostic" is the general term we use to describe the error or warning
|
||||
message that OpenTofu returns when there are problems with the configuration,
|
||||
or when interactions with external systems fail.
|
||||
|
||||
Reference: [link](./diagnostics.md)
|
||||
|
||||
### Mark/value mark
|
||||
OpenTofu uses cty.Value to represent the result of expressions (and other data).
|
||||
Occasionally, we will want to annotate that data with additional properties, without actually modifying the underlying value.
|
||||
Marks are used for that purpose and are the preferred method of doing so with go-cty.
|
||||
|
||||
### Resource/resource instance/resource type
|
||||
* Resource - is what is declared by a `resource`, `data` or `ephemeral` block.
|
||||
* Resource instance - is what such a block can declare zero or more of, when using the `count`, `for_each`, or `enabled` arguments.
|
||||
* Resource type - the type of a "resource". E.g., `aws_instance` is a "resource type".
|
||||
|
||||
It is recommended to use the following terms when discussing about "resource" blocks:
|
||||
* managed resource - a block declared as `resource "type" "name" {}`
|
||||
* data resource - a block declared as `data "type" "name" {}`
|
||||
* ephemeral resource - a block declared as `ephemeral "type" "name" {}`
|
||||
|
||||
Reference: [link](./diagnostics.md#diagnostic-description-writing-style)
|
||||
|
||||
### Unknown value/Computed value
|
||||
* Unknown value - Unknown values are the result of expressions that have unknown inputs. E.g.: a value that will not be known until a resource is created.
|
||||
Right now the main source of this type of values is resources, but we are considering adding others like unknown inputs.
|
||||
Another place where an unknown value can be encountered is from using some of the built-in functions like `timestamp`, `bcrypt` and `uuid`.
|
||||
* Computed value - Computed is more of a resource specific concept that a provider can specify in its resource schema.
|
||||
When set to true, the provider does not expect a value and may instead produce one that may or may not be unknown.
|
||||
With other flags, the actual functionality is a bit more subtle.
|
||||
|
||||
References: [link](https://github.com/opentofu/opentofu/blob/490762343322eff42c0586f7a4c267b579fe80ef/internal/configs/configschema/schema.go#L65), [link](https://github.com/opentofu/opentofu/blob/490762343322eff42c0586f7a4c267b579fe80ef/internal/lang/functions.go#L22)
|
||||
## HCL
|
||||
### Evaluation context (HCL)
|
||||
A set of already known functions, input values, local values, resources, etc. that is used to evaluate an expression that can reference any of the concepts listed above.
|
||||
|
||||
The list of concepts above, in the context of HCL evaluation, are called [variables](#variable-hcl).
|
||||
|
||||
### Expression
|
||||
An expression is any right hand side of an assignment that will be evaluated to generate the value that will be associated with key on the left hand side of the assignment.
|
||||
The simplest expressions are just literal values, like "hello" or 5, but the OpenTofu language also allows more complex
|
||||
expressions such as references to data exported by resources, arithmetic, conditional evaluation, and a number of built-in and provider-defined functions.
|
||||
|
||||
Reference: [link](https://opentofu.org/docs/language/expressions/)
|
||||
|
||||
### Variable (HCL)
|
||||
Anything that's available to refer to in the current evaluation context.
|
||||