Crowd cloud / Kraut Computing (KC's)¶

Idea¶

Make something simple that "doesn't suck", which allows us to manage VMs at our will.
It should support basic concepts and therefore be as generic and portable as possible.

Use-cases¶

Create a VM:¶

1. Pick an image
2. Pick network(s)
3. Pick machine type
[4. Pick machine type parameters]
[X. Add nic to VM / mod VM]
[Y. Upload images to be used for 1]
[Z. Destroy a VM]

Note: this actually includes most of the life-cycle of a VM.

Components¶

Following components were identified and commented out, sorted out by subjective order of importance.

These components are thought as being some kind of key/value (JSON seems likely, a priori no NOSQL) with possibilities for opaque customer metadata.

• This key/value + metadata information should be usable for filtering / operations.
• It should be versioned.

VM
Defined as an instance of different settings and multiplicities of the other components¶

Machine types / Templates¶

General definition with fixed sets of settings and, in a future stage, parametrised options.

Examples of settings:

• CPU/RAM
• HW Type: arm64 / x86
• HW / VM
• ...

Network(s)¶

Layer2-based, allow common use-cases like: static, dhcp, slaac, dhcpv6, custom gateway.

Outside connections: VXLAN

Note: it is quite important that the gateway can be set to another VM / something customised. That way, we can see firewalls and VPNs as special cases to be considered.

Firewall / routing¶

Thought as: extra VM, that is potentially "invisible" to customers/users and that can:

• deal with basic sets of rules (e.g. allow TCP 80, 22 from $SUBNET, ...)
• ratelimit
• standard ACLs
• geek_mode: on --> "I know what I'm doing, gimme SSH"

Note: By treating this component as a special case of VMs, we simplify things and keep them simple.

Storage¶

Thought as being out-of-scope to begin with since it can vary so much. We shouldn't rely on a specific implementation.

Images¶

Basically a rw repository of prepared images. Uploads can be thought as being "raw" to begin with, and we can later add pre-processors that convert them as needed.

Auth¶

Thought as "not being our problem".
BUT: we should have provisions for checkers as follows:

Use some HTTP Auth Header, which should be treated as opaque.
This value of the header, along with the details of the request, should offload Auth to an implementation.
That implementation should reply with the result of such request.

To facilitate adoption / testing, we should implement a few such Authenticators:

• httpasswd file
• ldap
• god-like tokens
• OTP
• limited-scope tokens
  Note: by treating the header as something opaque, it can be e.g. base64(user:name) à la HTTP Basic Auth or a uuid or jwt or ...

Things to consider¶

• The whole thing should aim to be a set of integrated tools that work well together and build on top of standard technologies as much as possible.
• Language of implementation should be consistent, but is open for discussion
• For the JSON metadata, Azure has some interesting tools / Schemas that are worth taking a look into.
• Take a look at ETCD, consul and the like.