The events notification framework is a key component of Apache CloudStack, facilitating traceability of operations, and enabling cloud operators to automate tasks which may otherwise require admin intervention at regular intervals.
Though quite useful, events in CloudStack had a major inconsistency regarding information of the resource (ie. Instances, Templates, Volumes, Networks, Accounts, etc.). To identify the resource in question, one had to refer to the Event description which may contain resource UUID or internal database ID. This made tracking resource operations difficult and also made automation difficult as the administrator would have to parse event description strings (which are not consistent across different event types).
This feature changes this behaviour by adding resource information to each event. Database schema changes have been made to store the required information for each event along with the API changes to facilitate querying and listing these details. With resource details added to events, the UI related to them has improved a lot and below are some of the noticeable changes.
Easy location of a target resource when viewing an event
A new column “Resource” was added to the event page in the UI, where all details about the Event is shown.
When using CloudMonkey or API, the new response parameters resourceid, resourcetype and resourcename have been added to the listEvents API call.
Similar resource details in UI will also be shown in the detail view of an event and on the dashboard for the events shown in the recent notification card.
Ability to query events based on Resource Type
When viewing the Event page in the UI, users can filter the Events based on the Resource Type selected.
Also, when using CloudMonkey or API, the new response parameter resourcetype has been added to the listEvents API call.
Events timeline for a resource
When accessing a particular CloudStack Resource through the UI, a new Events tab will be shown where all the Resource related Events will be listed.
Also, when using CloudMonkey or API, the new response parameters resourceid and resourcetype have been added to the listEvents API call.
Another important aspect of CloudStack’s event framework is the publishing of messages on the event bus. These messages already contain resource details and this will continue as it is with the UUID of the resource being shown as entityuuid and the type of the resource as entity. Below is an example event bus message for VM.REBOOT event:
{“eventDateTime”:”2022-05-12 08:20:50 +0000″,”entityuuid”:”d186b95c-1e58-41bd-9e7c-e3b6d7d9c3cf”,”description”:”rebooting user vm: d186b95c-1e58-41bd-9e7c-e3b6d7d9c3cf”,”event”:”VM.REBOOT”,”user”:”bde866ba-c600-11ec-af19-1e00320001f3″,”account”:”bde712c9-c600-11ec-af19-1e00320001f3″,”entity”:”VirtualMachine”,”status”:”Scheduled”,”VirtualMachine”:”d186b95c-1e58-41bd-9e7c-e3b6d7d9c3cf”}
Conclusion
Structured system events have made CloudStack events framework more meaningful. They help the operators track resource operations easily and automate tasks using event bus or API calls without needing to parse inconsistent event description strings. With added UI enhancements, they also provide a timeline view for a resource which would help in understanding the lifecycle of the resource and in troubleshooting in case of any issues with the resource. This enhancement is a part of the Apache CloudStack 4.17.0 release.
Abhishek Kumar is a software engineer by profession. His personal interests and hobbies are technology, politics and sports. Abhishek is experienced in development and management of a variety of desktop and mobile applications. He has a particular interest in mobile application development, designing and developing highly interactive and intuitive mobile, desktop applications GUI.
Abhishek became part of ShapeBlue in 2019 and is currently an active Apache CloudStack Committer.
You can learn more about Abhishek and his background by reading his Meet The Team blog.
