diff options
Diffstat (limited to 'docs/specs/multicloud_event_federation.rst')
| -rw-r--r-- | docs/specs/multicloud_event_federation.rst | 144 |
1 files changed, 78 insertions, 66 deletions
diff --git a/docs/specs/multicloud_event_federation.rst b/docs/specs/multicloud_event_federation.rst index 02de57e..433a2a8 100644 --- a/docs/specs/multicloud_event_federation.rst +++ b/docs/specs/multicloud_event_federation.rst @@ -2,25 +2,30 @@ .. 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. +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 +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 +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 @@ -29,57 +34,60 @@ 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: +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:: +------------------+ | | @@ -104,12 +112,15 @@ The eventual work flow looks like as follows: 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 +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 } @@ -117,12 +128,13 @@ Input of <vim_id>/check_vim_status will be 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: +The work flow looks like as follows:: +------------------+ | | |