Project

General

Profile

Ucloud » History » Version 5

Ahmed Bilal, 07/02/2019 09:17 AM

1 1 Ahmed Bilal
h1. ucloud (To Be Continued)
2
3 4 Ahmed Bilal
h2. Requirements
4 5 Ahmed Bilal
5 4 Ahmed Bilal
1. Python 3.7, pip, pipenv
6
2. etcd
7
3. ceph
8
9 1 Ahmed Bilal
h2. ucloud-api
10
11
Outside world (indirect) communication with the internal systems.
12
13
Its responsibilities are
14
* Create VM *(Done)* POST _/vm/create_ 
15
<pre><code class="javascript">
16
{
17
	"name": "username",
18
	"realm": "user_realm",
19
	"seed": "user_seed",
20
	"specs": {
21
		"cpu": 16,
22
		"ram": 256,
23 2 Ahmed Bilal
		"hdd": 2000,
24
		"ssd": 256
25 1 Ahmed Bilal
	}
26
}
27
</code></pre>
28
29
* Delete VM *(Done)* POST _/vm/delete_
30
<pre><code class="javascript">
31
{
32
	"name": "username",
33
	"realm": "user_realm",
34
	"seed": "user_seed",
35
	"vmid": "id_of_virtual_machine"
36
}
37
</code></pre>
38
39
* Status VM *(Done)* GET _/vm/status_
40
<pre><code class="javascript">
41
{
42
	"id": "id_of_virtual_machine"
43
}
44
</code></pre>
45
46
* Create new network
47
* Attach network to VM
48
* Detach network from VM
49
* Delete network
50
51
h2. ucloud-scheduler
52
53
It schedules/reschedules VM that are created using ucloud-api. How does it schedules? It does by watching any changes under the _/v1/vm/_ prefix. Basically, it deals with two ETCD entries
54
55
1. Virtual Machines Entries that looks like
56
<pre><code class="javascript">
57
/v1/vm/1
58
{
59
  "owner": "ahmedbilal-admin",
60
  "specs": {
61
    "cpu": 20,
62
    "ram": 2,
63
    "hdd": 10,
64 3 Ahmed Bilal
    "ssd": 10
65 1 Ahmed Bilal
  },
66
  "hostname": "",
67
  "status": "REQUESTED_NEW" 
68
}
69
</code></pre>
70
2. Hosts Entries that look like
71
<pre><code class="javascript">
72
/v1/host/1
73
{
74
    "cpu": 32,
75
    "ram": 128,
76
    "hdd": 1024,
77 3 Ahmed Bilal
    "ssd": 0
78 1 Ahmed Bilal
    "status": "UP"
79
}
80
</code></pre>
81
82
It loop through list of host entries found under _/v1/host/_ and check whether we can run the incoming VM on that host. if we can, then it (ucloud-scheduler) sets the hostname key of incoming VM to that host. Suppose, our scheduler decides that we can run the earlier shown VM _/v1/vm/1_ on _/v1/host/1_. Then, our updated entry would look like
83
84
<pre><code class="javascript">
85
/v1/vm/1
86
{
87
  "owner": "ahmedbilal-admin",
88
  "specs": {
89
    "cpu": 20,
90
    "ram": 2,
91
    "hdd": 10,
92 3 Ahmed Bilal
    "ssd": 10
93 1 Ahmed Bilal
  },
94
  "hostname": "/v1/host/1",
95
  "status": "REQUESTED_NEW" 
96
}
97
</code></pre>
98
99
*Note* the hostname key/value pair.
100
101
h2. ucloud-vm
102
It is responsible for creating (running) / deleting (stopping) / monitoring virtual machines
103
104
It watches the _/v1/vm/_ prefix for any changes like (Virtual Machines with status like *SCHEDULED_DEPLOY* or *REQUEST_DELETE*.
105
106
On, *SCHEDULED_DEPLOY* it creates the VM and run it. On, *REQUEST_DELETE* it stops the VM. 
107
108
It is also responsible for monitoring VM statues i.e whether they are RUNNING or KILLED (in action). If a VM is killed we put that in log file, notify system administrator and restart it.