summaryrefslogtreecommitdiffstats
path: root/docs/specs/multicloud_event_federation.rst
diff options
context:
space:
mode:
Diffstat (limited to 'docs/specs/multicloud_event_federation.rst')
-rw-r--r--docs/specs/multicloud_event_federation.rst145
1 files changed, 145 insertions, 0 deletions
diff --git a/docs/specs/multicloud_event_federation.rst b/docs/specs/multicloud_event_federation.rst
new file mode 100644
index 0000000..02de57e
--- /dev/null
+++ b/docs/specs/multicloud_event_federation.rst
@@ -0,0 +1,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 |
+ +----------------------+