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
146
147
148
149
150
151
152
153
154
155
156
157
|
.. 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 |
+----------------------+
|
