Project

General

Profile

Crowd cloud » History » Revision 3

Revision 2 (Evil Ham, 06/01/2019 06:47 PM) → Revision 3/4 (Nico Schottelius, 06/01/2019 06:50 PM)

h1. Crown Cloud / Bird Cloud / Crowd cloud / Kraut Computing (KC's) 

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

 h2. Use-cases 

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

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

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

 h3. 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 
 * ... 

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

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

 h3. Storage 

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

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

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

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