---
# System prepended metadata

title: C4

---

<style>
    h1, h2, h3, h4, h5, h6, h7, p, a {
        font-family: Arial, Helvetica, sans-serif;
    }
</style>

<center>
    <br/>
    <br/>
    <br/>
    <img src="https://raw.githubusercontent.com/Elemento-Modular-Cloud/graphic-assets/main/logos/horizontal/Logo%20horizontal%20lightbg%20transp.svg" width=50%/>
    <br/>
    <h4>
        ELEMENTO technical docs
    </h4>
</center>

<center>
    <br/>
    <h1>
        C4 Tech Specs
    </h1>
</center>


The C4 protocol is a protocl for creating machines via the Elemento API.

## Methods CRUD (Create, Read, Update and Delete)

### Cancreate
Cancreate methods tells the clients which resources are available.
 
Cancreate procedure verifies if the host can allocate the pledge and returns an error if it can't.

Cancreate fails both if the server is already esposing all of its resources (i.e. the hosts has 4 core and all of them are allocated to the VMs.) and if the requested resources are not available (i.e. the pledge requires a GPU not connected to the host).

### Create

Allocate resources for the customer client which is requireing it.

Create the VM on the host (using the local virtualisation API).

Calls the storage servers asking to esport volumes.

Attach the VM to the storages.

Take note of the association *client UUID* *resource*

replies with success


### List

Lists all the specification for the customer requiring them.


Host should search all the resources associated with the given *UUID*

### Destroy

Destroy a resource belonging to the requiring *UUID*.

Destroy should verify that that the resource belongs to the *UUID*.


## Persistence

Host should be persistence and resilient to reboots.

If the hosts reboots it should be able to recreate resources and to assign them to the correct *UUID*s.


## Network problems

Hosts should workeven if the internet connection fails.


### Licensing

Hosts should verify to be valid registered hosts sending their hmac to Elemento servers.

## Authentication

C4 protocol uses *UUIDs*s to  assign resources to a given customer.

*UUID*s are managed through Elemento portal.
Users register themselves into the Elemento portal, and Elemento creates a *UUID* specific for that customer.
All the requests should contain such an ID to allow the servers to reply only to the correct clients.


### Organisations and admins
Elemento portal implements logic of organisations. For instance a customer can be admin of a set of cuatomers belonging to their organisation. Each customer can be admin and/or member of an arbitrary number of organisations. 
Organisations can also be mebers and admins of other organisations, in this case all the members inherit all the properties of all the organisations they belong to.


This logic is **managed by the elemento portal** the servers implementing the protocol should not **deal with it**.

Servers implementing C4 protocol could assume that repling correclty to the *UUID* the  organisation logic is preserved.
(Under the hood clients will call all the *UUID* they are suppose to manage given the topology of permissions).