Task #6875
closedTask #6869: Challenge OpenStack and OpenNebula with ucloud
Create ucloud-scheduler
50%
Description
Reads / watches keys below /v1/vm (later probably as well /v1/networks?)
The JSON of the VM should contain a "status" field. On submit, the status should be "REQUESTED_NEW" (-> need to update ucloud-api).
Creating VM¶
The scheduler watches for changes on the key prefix. If the status is REQUEST_NEW, find a suitable host for deploying the VM to.
Update the status field to "SCHEDULED_DEPLOY". Also add a new field "host" that contains the hostname of the host the VM should be running on.
Deleting VM¶
The scheduler watches for changes on the key prefix. If the status is REQUEST_DELETE, do nothing -> ucloud-vm needs to react and will update the field.
APIs¶
ucloud scheduler only reacts on etcd changes and does not have a direct accessible API.
Updated by Nico Schottelius over 5 years ago
To be solved / undefined at the moment:
- Which component writes information about hosts? Do we have a key prefix /v1/host/<id>?
- If yes, do we need ucloud-host?
- Or do we use (existing) consul?
- consul is indeed an alternative to etcd for us as well
For the start:
- Create /v1/host and fill it up manually -- Balazs might also have some ideas on this
Updated by Ahmed Bilal over 5 years ago
Now, using etcd3 instead of using coreos/etcd python binding because the latter does not have support to watch a prefix e.g /v1/vm
This has implication that we can't access etcd v2 data from v3 API and vice versa. So, instead of usual `etcdctl` we need to use `ETCDCTL_API=3 etcdctl`.
Updated by Ahmed Bilal over 5 years ago
v1 is ready. It can be found here
@william and @llnu is notified to verify its working.
Updated by Ahmed Bilal over 5 years ago
- Status changed from In Progress to Waiting
Updated by Ahmed Bilal over 5 years ago
- Status changed from Feedback to In Progress
Updated by Ahmed Bilal almost 5 years ago
- Status changed from In Progress to Closed