ahmedbilal/uncloud
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

[doc] cleanup

Browse source
This commit is contained in:
Nico Schottelius 2020-08-01 16:28:19 +02:00
parent 9b3493a661
commit 2771a7518a
5 changed files with 44 additions and 154 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

29
doc/README-identifiers.org
View file

@ -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

82
doc/README-object-relations.md
View file

@ -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

8
doc/README-postgresql.org
View file

@ -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

34
doc/README-products.md
View file

@ -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.

45
doc/uncloud-manual-2020-08-01.org
View file

@ -5,7 +5,6 @@
python manage.py bootstrap-user --username nicocustomer
#+END_SRC
* Testing / CLI Access
Access via the commandline (CLI) can be done using curl or
httpie. In our examples we will use httpie.
@ -17,6 +16,15 @@
#+BEGIN_SRC sh
http --auth nicocustomer:$(pass ldap/nicocustomer) localhost:8000/api/
#+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
- api/ - the rest API
@ -69,3 +77,38 @@
vpn_hostname=vpn-2a0ae5c1200.ungleich.ch wireguard_private_key=$(wg
genkey)
**** 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.