There are multiple parties like
...
event-driven
...
workflows
...
systems,
...
monitoring
...
system,
...
usage
...
&
...
billing
...
system
...
would
...
be
...
interested
...
in
...
getting
...
notification
...
of
...
a
...
events
...
in
...
the
...
cloud
...
in
...
near
...
instantaneous
...
manner.
...
In
...
CloudStack
...
event
...
could
...
be
...
state
...
change
...
of
...
virtual
...
or
...
psychical
...
resources,
...
an
...
action
...
performed
...
by
...
user
...
(action
...
events),
...
policy
...
based
...
events
...
(alerts).
...
Currently
...
CloudStack
...
has
...
no
...
notification
...
mechanism
...
to
...
let
...
the
...
interested
...
parties
...
know
...
of
...
the
...
occurrence
...
of
...
an
...
event.
...
Polling
...
by
...
invoking
...
listEvents
...
and
...
listAlerts
...
is
...
the
...
only
...
way
...
to
...
know
...
occurrence
...
of
...
events.
...
Also
...
there
...
are
...
no
...
externsion
...
hooks
...
one
...
can
...
implement
...
to
...
get
...
the
...
event
...
notification.
...
Though
...
there
...
is
...
StateListener
...
interface
...
which
...
has
...
both
...
pre
...
and
...
post
...
state
...
transition
...
event
...
call
...
back
...
methods,
...
only
...
user
...
VM
...
resource
...
has
...
state
...
listener
...
implemented.
...
Most
...
of
...
the
...
resorces
...
volume,
...
network,
...
nic,
...
etc
...
has
...
states
...
but
...
does
...
not
...
have
...
state
...
machine
...
and
...
StateListener.
...
So
...
for
...
a
...
component
...
interested
...
getting
...
notification
...
need
...
to
...
get
...
tightly
...
coupled
...
into
...
orchestration
...
workflow.
...
For
...
e.g,
...
code
...
to
...
generate
...
usage
...
date
...
(usage
...
events)
...
is
...
spread
...
across
...
the
...
orchestration
...
components.
...
This proposal is to introduce an in-process
...
event
...
bus
...
in
...
the
...
management
...
server
...
and
...
by
...
which
...
achieve
...
event
...
notifications.
...
Scope
...
of
...
the
...
event
...
bus
...
is
...
only
...
with
...
in
...
the
...
management
...
server,
...
so
...
only
...
CloudStack
...
components
...
and
...
extension
...
plug-in's
...
can
...
be
...
subscribers
...
to
...
the
...
events.
...
Goal of
...
this
...
proposal
...
is
...
to
...
have
...
bare
...
minimum
...
mechanism
...
in
...
the
...
CloudStack
...
code,
...
using
...
which
...
more
...
powerful
...
notification
...
mechanism
...
(like
...
SMS,
...
...
etc)
...
can
...
be
...
built
...
as
...
CloudStack
...
extensions.
...
Ideal
...
requirements
...
for
...
such
...
event
...
bus
...
is
...
to
...
be
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
In order for CloudStack be able to generate rich set of events and have clean mechanism to generate events, its important to have state machine associated with every resource that is managed by CloudStack. So another goal of this proposal is to associate with every resource (User VM, Volume, Nic, Network, public IP, snapshot, template etc) with a state machine and generate events as part of the state change. So the publishers of events in CloudStack will become that StateListeners associated with the resource.
For e.g. UserVMStateListener which is listener for the state changes of user VM's would create event object and post on to the event bus as below.
public boolean postStateTransitionEvent(State oldState, Event event, State newState, VirtualMachine vo, boolean status, Object opaque) {
_eventBus.post(new UserVmStateChangeEventVO(....));
}
A subscriber interested in the user VM state change would register to the event and get the events as below
_eventBus.register(this)
@Subscribe
public void userVMStateChangetHandler(UserVmStateChangeEventVO event)
Following are some use cases demonstrated in the diagram below