1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright (c) 2017-2018 VMware, Inc.
=================
Event/Alert/Metrics Federation
=================
As a cloud mediation layer, Multicloud could be invoked by many projects, through this feature, Multicloud will provide
VM status/events check and also can customize the type of event which user would like to receive. There are some
kinds of VM status can be chosen: DELETE, PAUSE, POWER_OFF, REBUILD，SHUT_DOWN, SOFT_DELETE, etc.. In VMware VIO Plugin,
once any change of VM status is detected of a given type, Multicloud will catch the event and throw it to DMaaP.
Other projects can try this way of getting VM status messages in the future. Also, for other Multicloud plugin providers,
due to some issues, there will be rest apis for them to grab the VM status messages.
The APP-C won't be impacted since APP-C can still call the existing API which implemented in Amsterdam Release
and the API is an existing API
Use Cases
===================
In VIO, one typical use case is to allow VIO users to fetch messages from DMaaP, this will provide a easier way for fetching status of
VMs, it may drastically reduce the time of close loop, for other Multicloud plugin providers, Multicloud will provide a set of
rest apis to get them
Proposed change
===================
In VIO plugin:
The proposed change will include two parts: * listener: to listen the events of the status change of VM, for others it
will have rest apis to get the messages * publisher: to throw the event to DMaaP.The message we try to send is something like this:
{
"state_description": "powering-off",
"availability_zone": "nova",
"terminated_at": "",
"ephemeral_gb": 0,
"instance_type_id": 5,
"deleted_at": "",
"reservation_id": "r-pvx3l6s2",
"memory_mb": 2048,
"display_name": "VM1",
"hostname": "vm1",
"state": "active",
"progress": "",
"launched_at": "2018-03-07T05:59:46.000000",
"metadata": {},
"node": "domain-c202.22bfc05c-da55-4ba6-ba93-08d9a067138e",
"ramdisk_id": "",
"access_ip_v6": null,
"disk_gb": 20,
"access_ip_v4": null,
"kernel_id": "",
"host": "compute01",
"user_id": "aa90efa5c84c4084b39094da952e0bd1",
"image_ref_url": "http://10.154.9.172:9292/images/207b9b7c-9450-4a95-852b-0d6d41f35d24",
"cell_name": "",
"root_gb": 20,
"tenant_id": "943ecb804cdf4103976b8a02cea12fdb",
"created_at": "2018-03-07 05:58:01+00:00",
"instance_id": "4f398943-7d39-4119-8058-74768d6dfa52",
"instance_type": "m1.small",
"vcpus": 1,
"image_meta": {
"is_copying": "1",
"container_format": "bare",
"min_ram": "0",
"vmware_disktype": "streamOptimized",
"disk_format": "vmdk",
"source_type": "url",
"image_url": "https://cloud-images.ubuntu.com/releases/14.04/release/ubuntu-14.04-server-cloudimg-amd64-disk1.img",
"vmware_adaptertype": "lsiLogic",
"min_disk": "20",
"base_image_ref": "207b9b7c-9450-4a95-852b-0d6d41f35d24"
},
"architecture": null,
"os_type": null,
"instance_flavor_id": "2"
}
The eventual work flow looks like as follows:
+------------------+
| |
| Multicloud |
| Broker |
| |
+---------+--------+
|
|
V
+-----------------------+ +------------------+
| Multicloud VIO Plugin |----------->| Dmaap |
| | Event | |
+--------|-----^--------+ +------------------+
Oslo | |
Listener | |
V |
+----------------------+
| VIO |
+----------------------+
In Other Plugins:
Since the security rules of VIMs and network connectivity issues, other multicloud plugins won't be suitable for the
oslo notification listener, so we will provide rest apis for them, the specific implementation will be dicided by them
Input of <vim_id>/check_vim_status will be
::
{
"states": array // the set of VIM status which user wants to get
}
Output of check_vim_status will be
::
{
"state_description": string // VIM's state
"launched_at": string // time of state change
}
The work flow looks like as follows:
+------------------+
| |
| Multicloud |
| Broker |
| |
+---------+--------+
|
|
V
+-----------------------+
| Multicloud Plugins |
| |
+--------|-----^--------+
polling | |
or other way | |
V |
+----------------------+
| Openstack |
+----------------------+
|
