[doc] cleanup
This commit is contained in:
Nico Schottelius
parent
9b3493a661
commit
2771a7518a
5 changed files with 44 additions and 154 deletions
|
|
@ -1,29 +0,0 @@
|
||||||
* Identifiers
|
|
||||||
** Problem description
|
|
||||||
Identifiers can be integers, strings or other objects. They should
|
|
||||||
be unique.
|
|
||||||
** Approach 1: integers
|
|
||||||
Integers are somewhat easy to remember, but also include
|
|
||||||
predictable growth, which might allow access to guessed hacking
|
|
||||||
(obivously proper permissions should prevent this).
|
|
||||||
** Approach 2: random uuids
|
|
||||||
UUIDs are 128 bit integers. Python supports uuid.uuid4() for random
|
|
||||||
uuids.
|
|
||||||
** Approach 3: IPv6 addresses
|
|
||||||
uncloud heavily depends on IPv6 in the first place. uncloud could
|
|
||||||
use a /48 to identify all objects. Objects that have IPv6 addresses
|
|
||||||
on their own, don't need to draw from the system /48.
|
|
||||||
*** Possible Subnetworks
|
|
||||||
Assuming uncloud uses a /48 to represent all resources.
|
|
||||||
|
|
||||||
| Network | Name | Description |
|
|
||||||
|-----------------+-----------------+----------------------------------------------|
|
|
||||||
| 2001:db8::/48 | uncloud network | All identifiers drawn from here |
|
|
||||||
| 2001:db8:1::/64 | VM network | Every VM has an IPv6 address in this network |
|
|
||||||
| 2001:db8:2::/64 | Bill network | Every bill has an IPv6 address |
|
|
||||||
| 2001:db8:3::/64 | Order network | Every order has an IPv6 address |
|
|
||||||
| 2001:db8:5::/64 | Product network | Every product (?) has an IPv6 address |
|
|
||||||
| 2001:db8:4::/64 | Disk network | Every disk is identified |
|
|
||||||
|
|
||||||
*** Tests
|
|
||||||
[15:47:37] black3.place6:~# rbd create -s 10G ssd/2a0a:e5c0:1::8
|
|
||||||
|
|
@ -1,82 +0,0 @@
|
||||||
## Introduction
|
|
||||||
|
|
||||||
This article describes how models relate to each other and what the
|
|
||||||
design ideas are. It is meant to prevent us from double implementing
|
|
||||||
something or changing something that is already solved.
|
|
||||||
|
|
||||||
|
|
||||||
## Products
|
|
||||||
|
|
||||||
A product is something someone can order. We might have "low level"
|
|
||||||
products that need to be composed (= higher degree of flexibility, but
|
|
||||||
more amount of details necessary) and "composed products" that present
|
|
||||||
some defaults or select other products automatically (f.i. a "dual
|
|
||||||
stack VM" can be a VM + a disk + an IPv4 address).
|
|
||||||
|
|
||||||
|
|
||||||
## Bills
|
|
||||||
|
|
||||||
Bills represent active orders of a month. Bills can be shown during a
|
|
||||||
month but only become definitive at the end of the month.
|
|
||||||
|
|
||||||
## Orders
|
|
||||||
|
|
||||||
When customer X order a (set) of product, it generates an order for billing
|
|
||||||
purposes. The ordered products point to that order and register an Order Record
|
|
||||||
at creation.
|
|
||||||
|
|
||||||
Orders and Order Records are assumed immutable => they are used to generate
|
|
||||||
bills and should not be mutated. If a product is updated (e.g. adding RAM to
|
|
||||||
VM), a new order should be generated.
|
|
||||||
|
|
||||||
The order MUST NOT be deleted when a product is deleted, as it is used for
|
|
||||||
billing (including past bills).
|
|
||||||
|
|
||||||
### Order record
|
|
||||||
|
|
||||||
Used to store billing details of a product at creation: will stay there even if
|
|
||||||
the product change (e.g. new pricing, updated) and act as some kind of archive.
|
|
||||||
Used to generate bills.
|
|
||||||
|
|
||||||
## Payment Methods
|
|
||||||
|
|
||||||
Users/customers can register payment methods.
|
|
||||||
|
|
||||||
## Sample flows / products
|
|
||||||
|
|
||||||
### A VM snapshot
|
|
||||||
|
|
||||||
A VM snapshot creates a snapshot of all disks attached to a VM to be
|
|
||||||
able to rollback the VM to a previous state.
|
|
||||||
|
|
||||||
Creating a VM snapshot (-product) creates a related order. Deleting a
|
|
||||||
VMSnapshotproduct sets the order to deleted.
|
|
||||||
|
|
||||||
### Object Storage
|
|
||||||
|
|
||||||
(tbd by Balazs)
|
|
||||||
|
|
||||||
### A "raw" VM
|
|
||||||
|
|
||||||
(tbd by Ahmed)
|
|
||||||
|
|
||||||
### An IPv6 only VM
|
|
||||||
|
|
||||||
(tbd by Ahmed)
|
|
||||||
|
|
||||||
### A dual stack VM
|
|
||||||
|
|
||||||
(tbd by Ahmed)
|
|
||||||
|
|
||||||
### A managed service (e.g. Matrix-as-a-Service)
|
|
||||||
|
|
||||||
Customer orders service with:
|
|
||||||
* Service-specific configuration: e.g. domain name for matrix
|
|
||||||
* VM configuration:
|
|
||||||
- CPU
|
|
||||||
- Memory
|
|
||||||
- Disk (soon)
|
|
||||||
|
|
||||||
It creates a new Order with two products/records:
|
|
||||||
* Service itself (= management)
|
|
||||||
* Underlying VM
|
|
||||||
|
|
@ -1,8 +0,0 @@
|
||||||
* uncloud clients access the data base from a variety of outside hosts
|
|
||||||
* So the postgresql data base needs to be remotely accessible
|
|
||||||
* Instead of exposing the tcp socket, we make postgresql bind to localhost via IPv6
|
|
||||||
** ::1, port 5432
|
|
||||||
* Then we remotely connect to the database server with ssh tunneling
|
|
||||||
** ssh -L5432:localhost:5432 uncloud-database-host
|
|
||||||
* Configuring your database for SSH based remote access
|
|
||||||
** host all all ::1/128 trust
|
|
||||||
|
|
@ -1,34 +0,0 @@
|
||||||
## Introduction
|
|
||||||
|
|
||||||
This document describes how to create, modify or
|
|
||||||
delete a product and use it.
|
|
||||||
|
|
||||||
A product (like a VMSnapshotproduct) creates an order when ordered.
|
|
||||||
The "order" is used to combine products together.
|
|
||||||
|
|
||||||
Sub-products or related products link to the same order.
|
|
||||||
Each product has one (?) orderrecord
|
|
||||||
|
|
||||||
|
|
||||||
## How to delete a product (logic 1)
|
|
||||||
|
|
||||||
If a user want so delete (=cancel) a product, the following steps
|
|
||||||
should be taken:
|
|
||||||
|
|
||||||
* the associated order is set to cancelled
|
|
||||||
* the product itself is deleted
|
|
||||||
|
|
||||||
[above steps to be reviewed]
|
|
||||||
|
|
||||||
## How to delete a product (rest api)
|
|
||||||
|
|
||||||
http -a nicoschottelius:$(pass
|
|
||||||
ungleich.ch/nico.schottelius@ungleich.ch)
|
|
||||||
http://localhost:8000/net/vpn/43c83088-f4d6-49b9-86c7-40251ac07ada/
|
|
||||||
|
|
||||||
-> does not delete the reservation.
|
|
||||||
|
|
||||||
|
|
||||||
### Deleting a VPN
|
|
||||||
|
|
||||||
When the product is deleted, the network must be marked as free.
|
|
||||||
|
|
@ -5,7 +5,6 @@
|
||||||
python manage.py bootstrap-user --username nicocustomer
|
python manage.py bootstrap-user --username nicocustomer
|
||||||
#+END_SRC
|
#+END_SRC
|
||||||
|
|
||||||
|
|
||||||
* Testing / CLI Access
|
* Testing / CLI Access
|
||||||
Access via the commandline (CLI) can be done using curl or
|
Access via the commandline (CLI) can be done using curl or
|
||||||
httpie. In our examples we will use httpie.
|
httpie. In our examples we will use httpie.
|
||||||
|
|
@ -17,6 +16,15 @@
|
||||||
#+BEGIN_SRC sh
|
#+BEGIN_SRC sh
|
||||||
http --auth nicocustomer:$(pass ldap/nicocustomer) localhost:8000/api/
|
http --auth nicocustomer:$(pass ldap/nicocustomer) localhost:8000/api/
|
||||||
#+END_SRC
|
#+END_SRC
|
||||||
|
* Database
|
||||||
|
** uncloud clients access the data base from a variety of outside hosts
|
||||||
|
** So the postgresql data base needs to be remotely accessible
|
||||||
|
** Instead of exposing the tcp socket, we make postgresql bind to localhost via IPv6
|
||||||
|
*** ::1, port 5432
|
||||||
|
** Then we remotely connect to the database server with ssh tunneling
|
||||||
|
*** ssh -L5432:localhost:5432 uncloud-database-host
|
||||||
|
** Configuring your database for SSH based remote access
|
||||||
|
*** host all all ::1/128 trust
|
||||||
|
|
||||||
* URLs
|
* URLs
|
||||||
- api/ - the rest API
|
- api/ - the rest API
|
||||||
|
|
@ -69,3 +77,38 @@
|
||||||
vpn_hostname=vpn-2a0ae5c1200.ungleich.ch wireguard_private_key=$(wg
|
vpn_hostname=vpn-2a0ae5c1200.ungleich.ch wireguard_private_key=$(wg
|
||||||
genkey)
|
genkey)
|
||||||
**** Creating a new vpn network
|
**** Creating a new vpn network
|
||||||
|
* Developer Handbook
|
||||||
|
The following section describe decisions / architecture of
|
||||||
|
uncloud. These chapters are intended to be read by developers.
|
||||||
|
** Identifiers
|
||||||
|
*** Problem description
|
||||||
|
Identifiers can be integers, strings or other objects. They should
|
||||||
|
be unique.
|
||||||
|
*** Approach 1: integers
|
||||||
|
Integers are somewhat easy to remember, but also include
|
||||||
|
predictable growth, which might allow access to guessed hacking
|
||||||
|
(obivously proper permissions should prevent this).
|
||||||
|
*** Approach 2: random uuids
|
||||||
|
UUIDs are 128 bit integers. Python supports uuid.uuid4() for random
|
||||||
|
uuids.
|
||||||
|
*** Approach 3: IPv6 addresses
|
||||||
|
uncloud heavily depends on IPv6 in the first place. uncloud could
|
||||||
|
use a /48 to identify all objects. Objects that have IPv6 addresses
|
||||||
|
on their own, don't need to draw from the system /48.
|
||||||
|
**** Possible Subnetworks
|
||||||
|
Assuming uncloud uses a /48 to represent all resources.
|
||||||
|
|
||||||
|
| Network | Name | Description |
|
||||||
|
|-----------------+-----------------+----------------------------------------------|
|
||||||
|
| 2001:db8::/48 | uncloud network | All identifiers drawn from here |
|
||||||
|
| 2001:db8:1::/64 | VM network | Every VM has an IPv6 address in this network |
|
||||||
|
| 2001:db8:2::/64 | Bill network | Every bill has an IPv6 address |
|
||||||
|
| 2001:db8:3::/64 | Order network | Every order has an IPv6 address |
|
||||||
|
| 2001:db8:5::/64 | Product network | Every product (?) has an IPv6 address |
|
||||||
|
| 2001:db8:4::/64 | Disk network | Every disk is identified |
|
||||||
|
|
||||||
|
**** Tests
|
||||||
|
[15:47:37] black3.place6:~# rbd create -s 10G ssd/2a0a:e5c0:1::8
|
||||||
|
|
||||||
|
*** Decision
|
||||||
|
We use integers, because they are easy.
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue