You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Marcus Sorensen <sh...@gmail.com> on 2013/06/25 06:11:46 UTC
event bus details
Hi all,
I've been playing around with the new event bus, trying to see if
it could be useful, and I'm a bit confused about the output. If I
subscribe to all topics, and try to reboot a virtual machine, this is
all I see:
'management-server.ActionEvent.VM-REBOOT.VirtualMachine.*':'{"status":"Scheduled","event":"VM.REBOOT","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
I see the account info, but nothing about which VM is being rebooted.
If I try to stop/start a VM, I likewise see no details in the
ActionEvent, about the subject being acted upon:
'management-server.ActionEvent.VM-STOP.VirtualMachine.*':'{"status":"Scheduled","event":"VM.STOP","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
I do however see some details regarding a 'Network' resource, though
if I were to write something to parse this output I wouldn't
immediately know that it was related to a VM (note the 'id' here
actually matches the VM I'm stopping, but there's nothing in the event
to tell me it's a VM):
'management-server.ResourceStateEvent.StopRequested.Network.d287a0fa-6b3b-4e8b-8fb2-2677778ec32c':'{"id":"d287a0fa-6b3b-4e8b-8fb2-2677778ec32c","old-state":"Running","new-state":"Stopping","resource":"Network"}'
I'm just subscribing to "#", so I assume I'm getting everything, but
I'm just having trouble making sense of the output.
Re: event bus details
Posted by Marcus Sorensen <sh...@gmail.com>.
It's also perhaps worth mentioning that the event table (and
event_view) is also missing a column that describes the subject of the
event (the thing being acted upon). Some events contain the id of the
subject being acted upon in the 'description' column, for example
"Successfully completed rebooting Vm. Vm Id: 86", but the format is
inconsistent. Ultimately that's kind of useless for doing anything
programatically, and useless for an admin who doesn't know anything by
id, but by uuid.
On Mon, Jun 24, 2013 at 11:19 PM, Marcus Sorensen <sh...@gmail.com> wrote:
> ok, if they're just bugs then we can help fix them, it just seems like
> the ActionEvents in particular were missing them everywhere, and that
> something else might be going on.
>
> On Mon, Jun 24, 2013 at 11:03 PM, Sangeetha Hariharan
> <Sa...@citrix.com> wrote:
>> I had logged a similar bug where the UUID of the user that was disabled and the UUID of the domain that was deleted is not included:
>>
>> CLOUDSTACK-1673 - AWS Regions - Events - User disable / Domain Delete event does not include the UUID of the user/domain that was disabled.
>>
>> -Thanks
>> Sangeetha
>> -----Original Message-----
>> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
>> Sent: Monday, June 24, 2013 9:24 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: event bus details
>>
>> Here's another, when deleting a VPC. I see the details of all of the things it's doing (removing the router, networks, etc), but I can't tell which VPC was being deleted. I feel like that '*' under ActionEvent should be telling me the uuid, like that position does in the other events:
>>
>> [x] 'management-server.ActionEvent.VPC-DELETE.Vpc.*':'{"status":"Scheduled","event":"VPC.DELETE","account":"f668198a-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>> [x] 'management-server.ResourceStateEvent.StopRequested.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","old-state":"Running","new-state":"Stopping","resource":"Network"}'
>> [x] 'management-server.ResourceStateEvent.OperationSucceeded.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","old-state":"Stopping","new-state":"Stopped","resource":"Network"}'
>> [x] 'management-server.ResourceStateEvent.ExpungeOperation.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","old-state":"Stopped","new-state":"Expunging","resource":"Network"}'
>> [x] 'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Ready","new-state":"Destroy","resource":"Volume"}'
>> [x] 'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Ready","new-state":"Destroy","resource":"Volume"}'
>> [x] 'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
>> [x] 'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
>> ...
>>
>> On Mon, Jun 24, 2013 at 10:11 PM, Marcus Sorensen <sh...@gmail.com> wrote:
>>> Hi all,
>>> I've been playing around with the new event bus, trying to see if
>>> it could be useful, and I'm a bit confused about the output. If I
>>> subscribe to all topics, and try to reboot a virtual machine, this is
>>> all I see:
>>>
>>> 'management-server.ActionEvent.VM-REBOOT.VirtualMachine.*':'{"status":"Scheduled","event":"VM.REBOOT","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>>
>>> I see the account info, but nothing about which VM is being rebooted.
>>>
>>> If I try to stop/start a VM, I likewise see no details in the
>>> ActionEvent, about the subject being acted upon:
>>>
>>> 'management-server.ActionEvent.VM-STOP.VirtualMachine.*':'{"status":"Scheduled","event":"VM.STOP","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>>
>>> I do however see some details regarding a 'Network' resource, though
>>> if I were to write something to parse this output I wouldn't
>>> immediately know that it was related to a VM (note the 'id' here
>>> actually matches the VM I'm stopping, but there's nothing in the event
>>> to tell me it's a VM):
>>>
>>> 'management-server.ResourceStateEvent.StopRequested.Network.d287a0fa-6b3b-4e8b-8fb2-2677778ec32c':'{"id":"d287a0fa-6b3b-4e8b-8fb2-2677778ec32c","old-state":"Running","new-state":"Stopping","resource":"Network"}'
>>>
>>> I'm just subscribing to "#", so I assume I'm getting everything, but
>>> I'm just having trouble making sense of the output.
Re: event bus details
Posted by Marcus Sorensen <sh...@gmail.com>.
ok, if they're just bugs then we can help fix them, it just seems like
the ActionEvents in particular were missing them everywhere, and that
something else might be going on.
On Mon, Jun 24, 2013 at 11:03 PM, Sangeetha Hariharan
<Sa...@citrix.com> wrote:
> I had logged a similar bug where the UUID of the user that was disabled and the UUID of the domain that was deleted is not included:
>
> CLOUDSTACK-1673 - AWS Regions - Events - User disable / Domain Delete event does not include the UUID of the user/domain that was disabled.
>
> -Thanks
> Sangeetha
> -----Original Message-----
> From: Marcus Sorensen [mailto:shadowsor@gmail.com]
> Sent: Monday, June 24, 2013 9:24 PM
> To: dev@cloudstack.apache.org
> Subject: Re: event bus details
>
> Here's another, when deleting a VPC. I see the details of all of the things it's doing (removing the router, networks, etc), but I can't tell which VPC was being deleted. I feel like that '*' under ActionEvent should be telling me the uuid, like that position does in the other events:
>
> [x] 'management-server.ActionEvent.VPC-DELETE.Vpc.*':'{"status":"Scheduled","event":"VPC.DELETE","account":"f668198a-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
> [x] 'management-server.ResourceStateEvent.StopRequested.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","old-state":"Running","new-state":"Stopping","resource":"Network"}'
> [x] 'management-server.ResourceStateEvent.OperationSucceeded.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","old-state":"Stopping","new-state":"Stopped","resource":"Network"}'
> [x] 'management-server.ResourceStateEvent.ExpungeOperation.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","old-state":"Stopped","new-state":"Expunging","resource":"Network"}'
> [x] 'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Ready","new-state":"Destroy","resource":"Volume"}'
> [x] 'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Ready","new-state":"Destroy","resource":"Volume"}'
> [x] 'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
> [x] 'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
> ...
>
> On Mon, Jun 24, 2013 at 10:11 PM, Marcus Sorensen <sh...@gmail.com> wrote:
>> Hi all,
>> I've been playing around with the new event bus, trying to see if
>> it could be useful, and I'm a bit confused about the output. If I
>> subscribe to all topics, and try to reboot a virtual machine, this is
>> all I see:
>>
>> 'management-server.ActionEvent.VM-REBOOT.VirtualMachine.*':'{"status":"Scheduled","event":"VM.REBOOT","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>
>> I see the account info, but nothing about which VM is being rebooted.
>>
>> If I try to stop/start a VM, I likewise see no details in the
>> ActionEvent, about the subject being acted upon:
>>
>> 'management-server.ActionEvent.VM-STOP.VirtualMachine.*':'{"status":"Scheduled","event":"VM.STOP","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>
>> I do however see some details regarding a 'Network' resource, though
>> if I were to write something to parse this output I wouldn't
>> immediately know that it was related to a VM (note the 'id' here
>> actually matches the VM I'm stopping, but there's nothing in the event
>> to tell me it's a VM):
>>
>> 'management-server.ResourceStateEvent.StopRequested.Network.d287a0fa-6b3b-4e8b-8fb2-2677778ec32c':'{"id":"d287a0fa-6b3b-4e8b-8fb2-2677778ec32c","old-state":"Running","new-state":"Stopping","resource":"Network"}'
>>
>> I'm just subscribing to "#", so I assume I'm getting everything, but
>> I'm just having trouble making sense of the output.
RE: event bus details
Posted by Sangeetha Hariharan <Sa...@citrix.com>.
I had logged a similar bug where the UUID of the user that was disabled and the UUID of the domain that was deleted is not included:
CLOUDSTACK-1673 - AWS Regions - Events - User disable / Domain Delete event does not include the UUID of the user/domain that was disabled.
-Thanks
Sangeetha
-----Original Message-----
From: Marcus Sorensen [mailto:shadowsor@gmail.com]
Sent: Monday, June 24, 2013 9:24 PM
To: dev@cloudstack.apache.org
Subject: Re: event bus details
Here's another, when deleting a VPC. I see the details of all of the things it's doing (removing the router, networks, etc), but I can't tell which VPC was being deleted. I feel like that '*' under ActionEvent should be telling me the uuid, like that position does in the other events:
[x] 'management-server.ActionEvent.VPC-DELETE.Vpc.*':'{"status":"Scheduled","event":"VPC.DELETE","account":"f668198a-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
[x] 'management-server.ResourceStateEvent.StopRequested.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","old-state":"Running","new-state":"Stopping","resource":"Network"}'
[x] 'management-server.ResourceStateEvent.OperationSucceeded.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","old-state":"Stopping","new-state":"Stopped","resource":"Network"}'
[x] 'management-server.ResourceStateEvent.ExpungeOperation.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","old-state":"Stopped","new-state":"Expunging","resource":"Network"}'
[x] 'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Ready","new-state":"Destroy","resource":"Volume"}'
[x] 'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Ready","new-state":"Destroy","resource":"Volume"}'
[x] 'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
[x] 'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
...
On Mon, Jun 24, 2013 at 10:11 PM, Marcus Sorensen <sh...@gmail.com> wrote:
> Hi all,
> I've been playing around with the new event bus, trying to see if
> it could be useful, and I'm a bit confused about the output. If I
> subscribe to all topics, and try to reboot a virtual machine, this is
> all I see:
>
> 'management-server.ActionEvent.VM-REBOOT.VirtualMachine.*':'{"status":"Scheduled","event":"VM.REBOOT","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>
> I see the account info, but nothing about which VM is being rebooted.
>
> If I try to stop/start a VM, I likewise see no details in the
> ActionEvent, about the subject being acted upon:
>
> 'management-server.ActionEvent.VM-STOP.VirtualMachine.*':'{"status":"Scheduled","event":"VM.STOP","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>
> I do however see some details regarding a 'Network' resource, though
> if I were to write something to parse this output I wouldn't
> immediately know that it was related to a VM (note the 'id' here
> actually matches the VM I'm stopping, but there's nothing in the event
> to tell me it's a VM):
>
> 'management-server.ResourceStateEvent.StopRequested.Network.d287a0fa-6b3b-4e8b-8fb2-2677778ec32c':'{"id":"d287a0fa-6b3b-4e8b-8fb2-2677778ec32c","old-state":"Running","new-state":"Stopping","resource":"Network"}'
>
> I'm just subscribing to "#", so I assume I'm getting everything, but
> I'm just having trouble making sense of the output.
Re: event bus details
Posted by Chip Childers <ch...@sungard.com>.
On Wed, Jul 03, 2013 at 02:14:59PM +0000, Murali Reddy wrote:
> On 02/07/13 7:45 PM, "Ryan Dietrich" <ry...@betterservers.com> wrote:
>
> >Patch submitted.
> >
> >https://reviews.apache.org/r/12223/
>
> Thanks for the patch. Added some comments to the review. Cloudstack group
> is missing as reviewer, don't have permission to edit the review, so could
> you please add group to the reviewers?
Done
>
> >
> >Things that still need to be thought through:
> >
> >1. Should the async command event type be a column on async job (and be
> >an attribute of AsyncJobVO)?
> >2. Should getInstanceId and getInstanceType of AsyncCmd be abstract
> >instead of implemented with null values? (would require updating every
> >async command in the system, and would break everyones async plugin
> >commands)
> >
> >Oh, and after figuring out how the parameter annotation works (and
> >ApiDispatcher uses reflection to iterate over parameters, ugh), I saw
> >BaseCmd.java has a HashMap<String, String> of the arguments passed in
> >from the user.
> >I went with the APIDBUtils query function for UUID's because I saw no
> >precedent for accessing that HashMap after initial argument handling.
> >
> >-Ryan Dietrich
>
>
>
RE: Async Job / Event Bus issue
Posted by Alex Huang <Al...@citrix.com>.
Ryan,
There's explicit code to remove those two columns. IIRC, the reason is because asyncjob actually uses those two fields to sequence jobs on the same id and type. So when the job is done, then it removes those two fields so it doesn't block the next job.
--Alex
> -----Original Message-----
> From: Ryan Dietrich [mailto:ryan@betterservers.com]
> Sent: Tuesday, July 2, 2013 1:18 PM
> To: dev@cloudstack.apache.org
> Subject: Async Job / Event Bus issue
>
> I've found a bug that I am having trouble determining the cause. Basically,
> my instance_type and instance_id columns are showing up when the job is
> submitted, but they do not show up when the job is completed or updated.
> When I look in the database, those columns are null, however, they are
> published correctly to the event bus on submit.
>
> I went a step further and verified that SqlGenerator.java is actually using
> these columns on insertion and for querying the fields back out.
>
> INSERT INTO async_job (async_job.user_id, async_job.account_id,
> async_job.session_key, async_job.job_cmd, async_job.job_cmd_originator,
> async_job.job_cmd_ver, async_job.job_cmd_info, async_job.callback_type,
> async_job.callback_address, async_job.job_status,
> async_job.job_process_status, async_job.job_re sult_code,
> async_job.job_result, async_job.instance_type, async_job.instance_id,
> async_job.job_init_msid, async_job.job_complete_msid, async_job.created,
> async_job.last_updated, async_job.last_polled, async_job.uuid) VALUES
> (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
>
> I also verified that the column has a database @Column annotation.
> SqlGenerator appears to be using reflection to determine the "attributes"
> that get mapped into columns.
>
> (from AsyncJobVO.java)
> @Enumerated(value=EnumType.STRING)
> @Column(name="instance_type", length=64)
> private Type instanceType;
>
> @Column(name="instance_id", length=64)
> private Long instanceId;
>
> What could be causing the instance_id and instance_type to drop on the
> floor? I am literally logging the job right after it says it has been written to the
> database, I log it again right after it is retrieved from the dao via findById.
> Either the dao isn't populating the volumes when it queries the AsyncJobVO
> back out (and subsequently updates the columns with null values), or it's
> something that I'm simply not seeing.
>
> Help?
>
> On Jul 2, 2013, at 8:15 AM, Ryan Dietrich <ry...@betterservers.com> wrote:
>
> > Patch submitted.
> >
> > https://reviews.apache.org/r/12223/
> >
> > Things that still need to be thought through:
> >
> > 1. Should the async command event type be a column on async job (and be
> an attribute of AsyncJobVO)?
> > 2. Should getInstanceId and getInstanceType of AsyncCmd be abstract
> > instead of implemented with null values? (would require updating every
> > async command in the system, and would break everyones async plugin
> > commands)
> >
> > Oh, and after figuring out how the parameter annotation works (and
> ApiDispatcher uses reflection to iterate over parameters, ugh), I saw
> BaseCmd.java has a HashMap<String, String> of the arguments passed in
> from the user.
> > I went with the APIDBUtils query function for UUID's because I saw no
> precedent for accessing that HashMap after initial argument handling.
> >
> > -Ryan Dietrich
Re: Async Job / Event Bus issue
Posted by Marcus Sorensen <sh...@gmail.com>.
He has a point though, why go to the trouble of removing the data to
tell that a job is no longer active, when there's a field that tells
us if the job is active? Was there some other reason?
On Tue, Jul 2, 2013 at 4:42 PM, Kelven Yang <ke...@citrix.com> wrote:
> Fields in job record are tend to be used to reflect job status in job's
> life cycle instead of history.
>
> Kelven
>
> On 7/2/13 1:35 PM, "Ryan Dietrich" <ry...@betterservers.com> wrote:
>
>>Ok. I see the "reset attached object" calls now.
>>
>>I'm curious why those columns are being wiped out. If you wanted to see
>>outstanding calls for an ID or Type, wouldn't you just query where the
>>jobStatus is still equal to zero?
>>
>>Wiping out those columns seems to destroy history, no?
>>
>>On Jul 2, 2013, at 2:27 PM, Alena Prokharchyk
>><Al...@citrix.com> wrote:
>>
>>> Ryan,
>>>
>>> Those fields were added to indicate the instances (volumes, vms, etc)
>>> having pending/active async jobs. The customers' main use case was - by
>>> instance id, find out the jobs that are currently being executed for
>>>this
>>> instance. Once the job is completed, the field is offset to NULL.
>>>
>>> -Alena.
>>
>
Re: Async Job / Event Bus issue
Posted by Murali Reddy <Mu...@citrix.com>.
What do we break if we fix it now? Since instance id, instance type are
also part of the 'AsyncJobResponse' its appropriate to pass full details.
Clearly from the Ryan use case, details of job are needed by external
systems and since this is the only book-keeping of a job, we need to
retain the history.
On 03/07/13 4:12 AM, "Kelven Yang" <ke...@citrix.com> wrote:
>Fields in job record are tend to be used to reflect job status in job's
>life cycle instead of history.
>
>Kelven
>
>On 7/2/13 1:35 PM, "Ryan Dietrich" <ry...@betterservers.com> wrote:
>
>>Ok. I see the "reset attached object" calls now.
>>
>>I'm curious why those columns are being wiped out. If you wanted to see
>>outstanding calls for an ID or Type, wouldn't you just query where the
>>jobStatus is still equal to zero?
>>
>>Wiping out those columns seems to destroy history, no?
>>
>>On Jul 2, 2013, at 2:27 PM, Alena Prokharchyk
>><Al...@citrix.com> wrote:
>>
>>> Ryan,
>>>
>>> Those fields were added to indicate the instances (volumes, vms, etc)
>>> having pending/active async jobs. The customers' main use case was - by
>>> instance id, find out the jobs that are currently being executed for
>>>this
>>> instance. Once the job is completed, the field is offset to NULL.
>>>
>>> -Alena.
>>
>
>
Re: Async Job / Event Bus issue
Posted by Kelven Yang <ke...@citrix.com>.
Fields in job record are tend to be used to reflect job status in job's
life cycle instead of history.
Kelven
On 7/2/13 1:35 PM, "Ryan Dietrich" <ry...@betterservers.com> wrote:
>Ok. I see the "reset attached object" calls now.
>
>I'm curious why those columns are being wiped out. If you wanted to see
>outstanding calls for an ID or Type, wouldn't you just query where the
>jobStatus is still equal to zero?
>
>Wiping out those columns seems to destroy history, no?
>
>On Jul 2, 2013, at 2:27 PM, Alena Prokharchyk
><Al...@citrix.com> wrote:
>
>> Ryan,
>>
>> Those fields were added to indicate the instances (volumes, vms, etc)
>> having pending/active async jobs. The customers' main use case was - by
>> instance id, find out the jobs that are currently being executed for
>>this
>> instance. Once the job is completed, the field is offset to NULL.
>>
>> -Alena.
>
Re: Async Job / Event Bus issue
Posted by Ryan Dietrich <ry...@betterservers.com>.
Ok. I see the "reset attached object" calls now.
I'm curious why those columns are being wiped out. If you wanted to see outstanding calls for an ID or Type, wouldn't you just query where the jobStatus is still equal to zero?
Wiping out those columns seems to destroy history, no?
On Jul 2, 2013, at 2:27 PM, Alena Prokharchyk <Al...@citrix.com> wrote:
> Ryan,
>
> Those fields were added to indicate the instances (volumes, vms, etc)
> having pending/active async jobs. The customers' main use case was - by
> instance id, find out the jobs that are currently being executed for this
> instance. Once the job is completed, the field is offset to NULL.
>
> -Alena.
Re: Async Job / Event Bus issue
Posted by Alena Prokharchyk <Al...@citrix.com>.
Ryan,
Those fields were added to indicate the instances (volumes, vms, etc)
having pending/active async jobs. The customers' main use case was - by
instance id, find out the jobs that are currently being executed for this
instance. Once the job is completed, the field is offset to NULL.
-Alena.
On 7/2/13 1:17 PM, "Ryan Dietrich" <ry...@betterservers.com> wrote:
>I've found a bug that I am having trouble determining the cause.
>Basically, my instance_type and instance_id columns are showing up when
>the job is submitted, but they do not show up when the job is completed
>or updated.
>When I look in the database, those columns are null, however, they are
>published correctly to the event bus on submit.
>
>I went a step further and verified that SqlGenerator.java is actually
>using these columns on insertion and for querying the fields back out.
>
>INSERT INTO async_job (async_job.user_id, async_job.account_id,
>async_job.session_key, async_job.job_cmd, async_job.job_cmd_originator,
>async_job.job_cmd_ver, async_job.job_cmd_info, async_job.callback_type,
>async_job.callback_address, async_job.job_status,
>async_job.job_process_status, async_job.job_re
>sult_code, async_job.job_result, async_job.instance_type,
>async_job.instance_id, async_job.job_init_msid,
>async_job.job_complete_msid, async_job.created, async_job.last_updated,
>async_job.last_polled, async_job.uuid) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?,
>?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
>
>I also verified that the column has a database @Column annotation.
>SqlGenerator appears to be using reflection to determine the "attributes"
>that get mapped into columns.
>
>(from AsyncJobVO.java)
> @Enumerated(value=EnumType.STRING)
> @Column(name="instance_type", length=64)
> private Type instanceType;
>
> @Column(name="instance_id", length=64)
> private Long instanceId;
>
>What could be causing the instance_id and instance_type to drop on the
>floor? I am literally logging the job right after it says it has been
>written to the database, I log it again right after it is retrieved from
>the dao via findById. Either the dao isn't populating the volumes when
>it queries the AsyncJobVO back out (and subsequently updates the columns
>with null values), or it's something that I'm simply not seeing.
>
>Help?
>
>On Jul 2, 2013, at 8:15 AM, Ryan Dietrich <ry...@betterservers.com> wrote:
>
>> Patch submitted.
>>
>> https://reviews.apache.org/r/12223/
>>
>> Things that still need to be thought through:
>>
>> 1. Should the async command event type be a column on async job (and be
>>an attribute of AsyncJobVO)?
>> 2. Should getInstanceId and getInstanceType of AsyncCmd be abstract
>>instead of implemented with null values? (would require updating every
>>async command in the system, and would break everyones async plugin
>>commands)
>>
>> Oh, and after figuring out how the parameter annotation works (and
>>ApiDispatcher uses reflection to iterate over parameters, ugh), I saw
>>BaseCmd.java has a HashMap<String, String> of the arguments passed in
>>from the user.
>> I went with the APIDBUtils query function for UUID's because I saw no
>>precedent for accessing that HashMap after initial argument handling.
>>
>> -Ryan Dietrich
>
>
Async Job / Event Bus issue
Posted by Ryan Dietrich <ry...@betterservers.com>.
I've found a bug that I am having trouble determining the cause. Basically, my instance_type and instance_id columns are showing up when the job is submitted, but they do not show up when the job is completed or updated.
When I look in the database, those columns are null, however, they are published correctly to the event bus on submit.
I went a step further and verified that SqlGenerator.java is actually using these columns on insertion and for querying the fields back out.
INSERT INTO async_job (async_job.user_id, async_job.account_id, async_job.session_key, async_job.job_cmd, async_job.job_cmd_originator, async_job.job_cmd_ver, async_job.job_cmd_info, async_job.callback_type, async_job.callback_address, async_job.job_status, async_job.job_process_status, async_job.job_re
sult_code, async_job.job_result, async_job.instance_type, async_job.instance_id, async_job.job_init_msid, async_job.job_complete_msid, async_job.created, async_job.last_updated, async_job.last_polled, async_job.uuid) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
I also verified that the column has a database @Column annotation. SqlGenerator appears to be using reflection to determine the "attributes" that get mapped into columns.
(from AsyncJobVO.java)
@Enumerated(value=EnumType.STRING)
@Column(name="instance_type", length=64)
private Type instanceType;
@Column(name="instance_id", length=64)
private Long instanceId;
What could be causing the instance_id and instance_type to drop on the floor? I am literally logging the job right after it says it has been written to the database, I log it again right after it is retrieved from the dao via findById. Either the dao isn't populating the volumes when it queries the AsyncJobVO back out (and subsequently updates the columns with null values), or it's something that I'm simply not seeing.
Help?
On Jul 2, 2013, at 8:15 AM, Ryan Dietrich <ry...@betterservers.com> wrote:
> Patch submitted.
>
> https://reviews.apache.org/r/12223/
>
> Things that still need to be thought through:
>
> 1. Should the async command event type be a column on async job (and be an attribute of AsyncJobVO)?
> 2. Should getInstanceId and getInstanceType of AsyncCmd be abstract instead of implemented with null values? (would require updating every async command in the system, and would break everyones async plugin commands)
>
> Oh, and after figuring out how the parameter annotation works (and ApiDispatcher uses reflection to iterate over parameters, ugh), I saw BaseCmd.java has a HashMap<String, String> of the arguments passed in from the user.
> I went with the APIDBUtils query function for UUID's because I saw no precedent for accessing that HashMap after initial argument handling.
>
> -Ryan Dietrich
Re: event bus details
Posted by Murali Reddy <Mu...@citrix.com>.
On 02/07/13 7:45 PM, "Ryan Dietrich" <ry...@betterservers.com> wrote:
>Patch submitted.
>
>https://reviews.apache.org/r/12223/
Thanks for the patch. Added some comments to the review. Cloudstack group
is missing as reviewer, don't have permission to edit the review, so could
you please add group to the reviewers?
>
>Things that still need to be thought through:
>
>1. Should the async command event type be a column on async job (and be
>an attribute of AsyncJobVO)?
>2. Should getInstanceId and getInstanceType of AsyncCmd be abstract
>instead of implemented with null values? (would require updating every
>async command in the system, and would break everyones async plugin
>commands)
>
>Oh, and after figuring out how the parameter annotation works (and
>ApiDispatcher uses reflection to iterate over parameters, ugh), I saw
>BaseCmd.java has a HashMap<String, String> of the arguments passed in
>from the user.
>I went with the APIDBUtils query function for UUID's because I saw no
>precedent for accessing that HashMap after initial argument handling.
>
>-Ryan Dietrich
Re: event bus details
Posted by Ryan Dietrich <ry...@betterservers.com>.
Patch submitted.
https://reviews.apache.org/r/12223/
Things that still need to be thought through:
1. Should the async command event type be a column on async job (and be an attribute of AsyncJobVO)?
2. Should getInstanceId and getInstanceType of AsyncCmd be abstract instead of implemented with null values? (would require updating every async command in the system, and would break everyones async plugin commands)
Oh, and after figuring out how the parameter annotation works (and ApiDispatcher uses reflection to iterate over parameters, ugh), I saw BaseCmd.java has a HashMap<String, String> of the arguments passed in from the user.
I went with the APIDBUtils query function for UUID's because I saw no precedent for accessing that HashMap after initial argument handling.
-Ryan Dietrich
Re: event bus details
Posted by Murali Reddy <Mu...@citrix.com>.
On 28/06/13 4:28 AM, "Ryan Dietrich" <ry...@betterservers.com> wrote:
>> For every api command, pretty much there is an action event generated
>>that
>> gets published on to event bus as well. CLOUDSTACK-3190 is open bug that
>> needs to be fixed so that entity type being operated and UUID details of
>> entity are published. It just tedious job to fix all the places action
>> events are generated. Good pick for CloudStack newbie to fix it though.
>
>Yes, my assumption is you'd have to add another abstract method on
>BaseAsyncCmd to allow you to query for the UUID being modified.
>The problem with this is, many of the UUID's passed into commands are
>transformed into their internal ID (long) via the "Parameter" annotation.
>It would seem sort of ugly to have to re-query the UUID out of the
>database so it would be available when the job details needed to be
>published.
>
>Is there any way to get raw access to the parameters sent to a command?
>
>> This should be doable with a quick fix. I opened CLOUDSTACK-3233 for
>>this.
>> Would you mind take a look at this bug and see if you can fix it? I left
>> details on what needs to be done in the bug.
>
>Ok, I'm working on this now.
>
>> There is RESOURCE_STATE_CHANGE_EVENT's that get published on resource
>> state change of critical entities VM, network, volume, snapshot. But
>>there
>> is entity type and entity UUID details only. If you feel user/domain
>> details are needed as well please go ahead and fix message body.
>
>I will, I planned on using a configuration option to allow you to
>show/hide this extra information. I'll need it, but I understand that
>others might see this as bloat. (I'm making it default to "false").
>
>> Event message body is key-value pair in JSON format. Body format may
>> differ depending on the event category (action event, usage event,
>> resource state change, alert). Can you please check if for a event
>> category message are consistent? If its not please open bug.
>
>Sure, here's a couple quick examples.
>
>management-server.AlertEvent.ALERT-USAGE.*.* {"event":"ALERT.USAGE"}
>management-server.ResourceStateEvent.OperationSucceeded.Volume.bb213f8b-d7
>c8-4f7d-82bd-8e4ed230eb66
>{"id":"bb213f8b-d7c8-4f7d-82bd-8e4ed230eb66","old-state":"Snapshotting","n
>ew-state":"Ready","resource":"Volume"}
>management-server.ActionEvent.VM-CREATE.VirtualMachine.*
>{"status":"Scheduled","event":"VM.CREATE","account":"f66d4d60-bbdf-11e2-8b
>b5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}
>management-server.UsageEvent.VOLUME-DELETE.com-cloud-storage-Volume.dc802b
>ce-15f5-4694-be44-096d6aefca80
>{"id":"dc802bce-15f5-4694-be44-096d6aefca80","event":"VOLUME.DELETE","reso
>urce":"com.cloud.storage.Volume","account":"f66d4d60-bbdf-11e2-8bb5-525400
>14c04d","zone":"5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4"}
>
>So, within each EventCategory, things are consistent, but between them
>they are totally different. When using say, GSON as the parsing routine
>you're force to do one of two things when receiving messages.
>
>1. Look at the routing key with a regex or "indexOf" call to figure out
>what kind of message you're receiving.
>2. Create a superset object that has all of the possible keys that
>compose all of the messages, and then use GSON to slurp everything in.
>Then you'd have to just check which fields were NULL to figure out what
>type of message you're dealing with.
>
>Both of these solutions seem poor.
Okay. When I designed I did not think of somebody consuming the message
directly. Since it was framework to both publish and subscribe, I sort of
added the necessary details in the payload
(framework/events/src/org/apache/cloudstack/framework/events/Event.java)
that a callback ( registered through subscribe in
framework/events/src/org/apache/cloudstack/framework/events/EventBus.java).
Please go ahead and add the details to message body.
> Obviously a resource event is different than a usage event, but if they
>were at least consistent at some level I wouldn't have to have super
>explicit code paths for every type of message being sent. If I had to
>choose from any of the existing formats, I like the ResourceStateEvent
>the best. It clearly shows you what the type of the UUID (volume in the
>example) as well as the state change. ActionEvent, AlertEvent need some
>help.
You are right, since ResourceStateEvent is newly added its built up on
EventBus, but legacy events definitely need help.
>
>Lastly, UsageEvent. I'm almost confused what this means. Here's an
>example from my logs.
>
>management-server.ResourceStateEvent.DestroyRequested.Volume.ed51b63b-a63b
>-4e6a-8c36-45f32c29988d
>{"id":"ed51b63b-a63b-4e6a-8c36-45f32c29988d","old-state":"Ready","new-stat
>e":"Destroy","resource":"Volume"}
>management-server.UsageEvent.VOLUME-DELETE.com-cloud-storage-Volume.ed51b6
>3b-a63b-4e6a-8c36-45f32c29988d
>{"id":"ed51b63b-a63b-4e6a-8c36-45f32c29988d","event":"VOLUME.DELETE","reso
>urce":"com.cloud.storage.Volume","account":"f66d4d60-bbdf-11e2-8bb5-525400
>14c04d","zone":"5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4"}
>management-server.ResourceStateEvent.OperationSucceeded.Volume.ed51b63b-a6
>3b-4e6a-8c36-45f32c29988d
>{"id":"ed51b63b-a63b-4e6a-8c36-45f32c29988d","old-state":"Destroy","new-st
>ate":"Destroy","resource":"Volume"}
>
>So, it would appear that three messages are generated when deleting a
>volume. A resource change, a usage event, and then a resource change
>confirmation. If I follow things up in the log, I see what triggers it.
>
>management-server.ActionEvent.VM-DESTROY.VirtualMachine.*
>{"status":"Scheduled","event":"VM.DESTROY","account":"f66d4d60-bbdf-11e2-8
>bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}
>
>Based on this, I'm not sure UsageEvent is actually adding any value.
>Worse, there is no way to tie the resource events to the action event
>that kicked those subordinate actions off.
I get the point. Its lot of noise on the message bus in default
configuration. Subscriber semantics permits that you subscribe to what are
you interested. Also each event has its own purpose. For e.g I could build
a totally de-coupled (from CloudStack) usage server for CloudStack just by
consuming usage events. Nevertheless its good to have flexibility. I
opened bug CLOUDSTACK-3272 to configure what events are published on the
event bus. Again this is a small fix, care to pick it up?
>
>Let me know how you'd like to proceed on these issues.
I already created the map of entity type for each event in the
'EventTypes' so adding this info is not a problem. Let me see if there is
a elegant way of getting entity UUID published for action event messages
as part of CLOUDSTACK-1673.
>
>-Ryan Dietrich
Re: event bus details
Posted by Ryan Dietrich <ry...@betterservers.com>.
> For every api command, pretty much there is an action event generated that
> gets published on to event bus as well. CLOUDSTACK-3190 is open bug that
> needs to be fixed so that entity type being operated and UUID details of
> entity are published. It just tedious job to fix all the places action
> events are generated. Good pick for CloudStack newbie to fix it though.
Yes, my assumption is you'd have to add another abstract method on BaseAsyncCmd to allow you to query for the UUID being modified.
The problem with this is, many of the UUID's passed into commands are transformed into their internal ID (long) via the "Parameter" annotation.
It would seem sort of ugly to have to re-query the UUID out of the database so it would be available when the job details needed to be published.
Is there any way to get raw access to the parameters sent to a command?
> This should be doable with a quick fix. I opened CLOUDSTACK-3233 for this.
> Would you mind take a look at this bug and see if you can fix it? I left
> details on what needs to be done in the bug.
Ok, I'm working on this now.
> There is RESOURCE_STATE_CHANGE_EVENT's that get published on resource
> state change of critical entities VM, network, volume, snapshot. But there
> is entity type and entity UUID details only. If you feel user/domain
> details are needed as well please go ahead and fix message body.
I will, I planned on using a configuration option to allow you to show/hide this extra information. I'll need it, but I understand that others might see this as bloat. (I'm making it default to "false").
> Event message body is key-value pair in JSON format. Body format may
> differ depending on the event category (action event, usage event,
> resource state change, alert). Can you please check if for a event
> category message are consistent? If its not please open bug.
Sure, here's a couple quick examples.
management-server.AlertEvent.ALERT-USAGE.*.* {"event":"ALERT.USAGE"}
management-server.ResourceStateEvent.OperationSucceeded.Volume.bb213f8b-d7c8-4f7d-82bd-8e4ed230eb66 {"id":"bb213f8b-d7c8-4f7d-82bd-8e4ed230eb66","old-state":"Snapshotting","new-state":"Ready","resource":"Volume"}
management-server.ActionEvent.VM-CREATE.VirtualMachine.* {"status":"Scheduled","event":"VM.CREATE","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}
management-server.UsageEvent.VOLUME-DELETE.com-cloud-storage-Volume.dc802bce-15f5-4694-be44-096d6aefca80 {"id":"dc802bce-15f5-4694-be44-096d6aefca80","event":"VOLUME.DELETE","resource":"com.cloud.storage.Volume","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","zone":"5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4"}
So, within each EventCategory, things are consistent, but between them they are totally different. When using say, GSON as the parsing routine you're force to do one of two things when receiving messages.
1. Look at the routing key with a regex or "indexOf" call to figure out what kind of message you're receiving.
2. Create a superset object that has all of the possible keys that compose all of the messages, and then use GSON to slurp everything in. Then you'd have to just check which fields were NULL to figure out what type of message you're dealing with.
Both of these solutions seem poor. Obviously a resource event is different than a usage event, but if they were at least consistent at some level I wouldn't have to have super explicit code paths for every type of message being sent. If I had to choose from any of the existing formats, I like the ResourceStateEvent the best. It clearly shows you what the type of the UUID (volume in the example) as well as the state change. ActionEvent, AlertEvent need some help.
Lastly, UsageEvent. I'm almost confused what this means. Here's an example from my logs.
management-server.ResourceStateEvent.DestroyRequested.Volume.ed51b63b-a63b-4e6a-8c36-45f32c29988d {"id":"ed51b63b-a63b-4e6a-8c36-45f32c29988d","old-state":"Ready","new-state":"Destroy","resource":"Volume"}
management-server.UsageEvent.VOLUME-DELETE.com-cloud-storage-Volume.ed51b63b-a63b-4e6a-8c36-45f32c29988d {"id":"ed51b63b-a63b-4e6a-8c36-45f32c29988d","event":"VOLUME.DELETE","resource":"com.cloud.storage.Volume","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","zone":"5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4"}
management-server.ResourceStateEvent.OperationSucceeded.Volume.ed51b63b-a63b-4e6a-8c36-45f32c29988d {"id":"ed51b63b-a63b-4e6a-8c36-45f32c29988d","old-state":"Destroy","new-state":"Destroy","resource":"Volume"}
So, it would appear that three messages are generated when deleting a volume. A resource change, a usage event, and then a resource change confirmation. If I follow things up in the log, I see what triggers it.
management-server.ActionEvent.VM-DESTROY.VirtualMachine.* {"status":"Scheduled","event":"VM.DESTROY","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}
Based on this, I'm not sure UsageEvent is actually adding any value.
Worse, there is no way to tie the resource events to the action event that kicked those subordinate actions off.
Let me know how you'd like to proceed on these issues.
-Ryan Dietrich
Re: event bus details
Posted by Murali Reddy <Mu...@citrix.com>.
On 27/06/13 5:46 AM, "Ryan Dietrich" <ry...@betterservers.com> wrote:
>Hi, I'm doing some work in the event bus. My requirements are pretty
>straightforward.
>
>1. Let me know when a command is executed.
>2. Let me know the UUID of the element being modified when that command
>is executed. (i.e.: If we're updating a virtual machine, the UUID should
>be the one for that particular VM).
For every api command, pretty much there is an action event generated that
gets published on to event bus as well. CLOUDSTACK-3190 is open bug that
needs to be fixed so that entity type being operated and UUID details of
entity are published. It just tedious job to fix all the places action
events are generated. Good pick for CloudStack newbie to fix it though.
>3. When an async command is executed, let me know when it's started, and
>every state change for that job until it is completed, and then let me
>know what the status of the job is.
This should be doable with a quick fix. I opened CLOUDSTACK-3233 for this.
Would you mind take a look at this bug and see if you can fix it? I left
details on what needs to be done in the bug.
>4. I'd like to see the human readable username and domain of the user
>that is executing the command. (I understand this one isn't as important
>to many of you, a configuration option would suffice).
>5. Lastly, I'd like to get state changes of the various components should
>be sent to the event bus, again with the user/domanin/uuid.
There is RESOURCE_STATE_CHANGE_EVENT's that get published on resource
state change of critical entities VM, network, volume, snapshot. But there
is entity type and entity UUID details only. If you feel user/domain
details are needed as well please go ahead and fix message body.
>
>ActionEvent seems driven either directly, or via annotation
>(api/src/com/cloud/event/ActionEvent.java), and relies on overrides to
>get the actual description (not sure why there is a description there at
>all actually).
>The other "StateListener" / "StateEvent" systems seem totally unrelated,
>yet encompass an alternative approach to writing messages to the event
>bus (and have a bit more meta-data that I need).
>
>Are the things I'm looking to do the actual desired use case for the
>event bus?
Absolutely valid use cases. Please do bring out the feedback, we can at
least fix it in 4.2.
>Human readable descriptions aren't enough for me, I really need machine
>consumable consistent messaging (currently it seems every message being
>pushed out to RabbitMQ follows a different format). Is there any
>documentation or plan for this system going forward?
Event message body is key-value pair in JSON format. Body format may
differ depending on the event category (action event, usage event,
resource state change, alert). Can you please check if for a event
category message are consistent? If its not please open bug.
>
>I need this working, now-ish, so I'm willing to get in and get it done,
>but again, I'd rather work with the flow, and not against it :-)
>
>Cheers,
>
>-Ryan Dietrich
>
>On Jun 26, 2013, at 8:14 AM, Murali Reddy <Mu...@citrix.com> wrote:
>
>>
>> Yeah its a bug. Fixed CLOUDSTACK-3213 for both 4.2 and 4.1.1. Thanks for
>> bringing it out.
>>
>> On 25/06/13 9:27 PM, "Marcus Sorensen" <sh...@gmail.com> wrote:
>>
>>> Thanks for the response. So am I to assume that the VM start/stop
>>> showing up under EntityType Network is also a bug?
>>>
>
>
Re: event bus details
Posted by Ryan Dietrich <ry...@betterservers.com>.
Hi, I'm doing some work in the event bus. My requirements are pretty straightforward.
1. Let me know when a command is executed.
2. Let me know the UUID of the element being modified when that command is executed. (i.e.: If we're updating a virtual machine, the UUID should be the one for that particular VM).
3. When an async command is executed, let me know when it's started, and every state change for that job until it is completed, and then let me know what the status of the job is.
4. I'd like to see the human readable username and domain of the user that is executing the command. (I understand this one isn't as important to many of you, a configuration option would suffice).
5. Lastly, I'd like to get state changes of the various components should be sent to the event bus, again with the user/domanin/uuid.
ActionEvent seems driven either directly, or via annotation (api/src/com/cloud/event/ActionEvent.java), and relies on overrides to get the actual description (not sure why there is a description there at all actually).
The other "StateListener" / "StateEvent" systems seem totally unrelated, yet encompass an alternative approach to writing messages to the event bus (and have a bit more meta-data that I need).
Are the things I'm looking to do the actual desired use case for the event bus? Human readable descriptions aren't enough for me, I really need machine consumable consistent messaging (currently it seems every message being pushed out to RabbitMQ follows a different format). Is there any documentation or plan for this system going forward?
I need this working, now-ish, so I'm willing to get in and get it done, but again, I'd rather work with the flow, and not against it :-)
Cheers,
-Ryan Dietrich
On Jun 26, 2013, at 8:14 AM, Murali Reddy <Mu...@citrix.com> wrote:
>
> Yeah its a bug. Fixed CLOUDSTACK-3213 for both 4.2 and 4.1.1. Thanks for
> bringing it out.
>
> On 25/06/13 9:27 PM, "Marcus Sorensen" <sh...@gmail.com> wrote:
>
>> Thanks for the response. So am I to assume that the VM start/stop
>> showing up under EntityType Network is also a bug?
>>
Re: event bus details
Posted by Murali Reddy <Mu...@citrix.com>.
Yeah its a bug. Fixed CLOUDSTACK-3213 for both 4.2 and 4.1.1. Thanks for
bringing it out.
On 25/06/13 9:27 PM, "Marcus Sorensen" <sh...@gmail.com> wrote:
>Thanks for the response. So am I to assume that the VM start/stop
>showing up under EntityType Network is also a bug?
>
>On Tue, Jun 25, 2013 at 6:05 AM, Murali Reddy <Mu...@citrix.com>
>wrote:
>>
>> Opened bug CLOUDSTACK-3190 for this.
>>
>> On 25/06/13 4:03 PM, "Murali Reddy" <Mu...@citrix.com> wrote:
>>
>>>
>>>Marcus,
>>>
>>>Events bus framework with current AMQP default implementation, has
>>>routing
>>>key with format
>>>'Eventsource.EventCategory.EventType.EntityType.EntityUUID' as described
>>>in [1]. If you see from the log you pasted below events of type
>>>'ResourceStateEvent' has details of entity UUID. Since it was new event
>>>type and was added in 4.1 it was easy to design so that all the entity
>>>details are published. Also intention of this event was for programatic
>>>consumption of events by external entities.
>>>
>>>Action Events existed from long time, and was implemented and used
>>>primarily for auditing messages for non-programmtic use. Unfortunately
>>>there is huge number of places for different actions corresponding to
>>>different entities need to be cleaned up. Please file a bug for some one
>>>to pick it up and work on it.
>>>
>>>[1] http://s.apache.org/MZS
>>>
>>>Thanks,
>>>Murali
>>>
>>>On 25/06/13 9:53 AM, "Marcus Sorensen" <sh...@gmail.com> wrote:
>>>
>>>>Here's another, when deleting a VPC. I see the details of all of the
>>>>things it's doing (removing the router, networks, etc), but I can't
>>>>tell which VPC was being deleted. I feel like that '*' under
>>>>ActionEvent should be telling me the uuid, like that position does in
>>>>the other events:
>>>>
>>>>[x]
>>>>'management-server.ActionEvent.VPC-DELETE.Vpc.*':'{"status":"Scheduled"
>>>>,"
>>>>e
>>>>vent":"VPC.DELETE","account":"f668198a-bbdf-11e2-8bb5-52540014c04d","us
>>>>er
>>>>"
>>>>:"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>>> [x]
>>>>'management-server.ResourceStateEvent.StopRequested.Network.b18e3e07-ae
>>>>d0
>>>>-
>>>>473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","
>>>>ol
>>>>d
>>>>-state":"Running","new-state":"Stopping","resource":"Network"}'
>>>> [x]
>>>>'management-server.ResourceStateEvent.OperationSucceeded.Network.b18e3e
>>>>07
>>>>-
>>>>aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb2
>>>>36
>>>>"
>>>>,"old-state":"Stopping","new-state":"Stopped","resource":"Network"}'
>>>> [x]
>>>>'management-server.ResourceStateEvent.ExpungeOperation.Network.b18e3e07
>>>>-a
>>>>e
>>>>d0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236
>>>>",
>>>>"
>>>>old-state":"Stopped","new-state":"Expunging","resource":"Network"}'
>>>> [x]
>>>>'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-
>>>>d4
>>>>2
>>>>8-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a"
>>>>,"
>>>>o
>>>>ld-state":"Ready","new-state":"Destroy","resource":"Volume"}'
>>>> [x]
>>>>'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-
>>>>d4
>>>>2
>>>>8-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a"
>>>>,"
>>>>o
>>>>ld-state":"Ready","new-state":"Destroy","resource":"Volume"}'
>>>> [x]
>>>>'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da
>>>>7-
>>>>d
>>>>428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3
>>>>a"
>>>>,
>>>>"old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
>>>> [x]
>>>>'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da
>>>>7-
>>>>d
>>>>428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3
>>>>a"
>>>>,
>>>>"old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
>>>>...
>>>>
>>>>On Mon, Jun 24, 2013 at 10:11 PM, Marcus Sorensen <sh...@gmail.com>
>>>>wrote:
>>>>> Hi all,
>>>>> I've been playing around with the new event bus, trying to see if
>>>>> it could be useful, and I'm a bit confused about the output. If I
>>>>> subscribe to all topics, and try to reboot a virtual machine, this is
>>>>> all I see:
>>>>>
>>>>>
>>>>>'management-server.ActionEvent.VM-REBOOT.VirtualMachine.*':'{"status":
>>>>>"S
>>>>>c
>>>>>heduled","event":"VM.REBOOT","account":"f66d4d60-bbdf-11e2-8bb5-525400
>>>>>14
>>>>>c
>>>>>04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>>>>
>>>>> I see the account info, but nothing about which VM is being rebooted.
>>>>>
>>>>> If I try to stop/start a VM, I likewise see no details in the
>>>>> ActionEvent, about the subject being acted upon:
>>>>>
>>>>>
>>>>>'management-server.ActionEvent.VM-STOP.VirtualMachine.*':'{"status":"S
>>>>>ch
>>>>>e
>>>>>duled","event":"VM.STOP","account":"f66d4d60-bbdf-11e2-8bb5-52540014c0
>>>>>4d
>>>>>"
>>>>>,"user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>>>>
>>>>> I do however see some details regarding a 'Network' resource, though
>>>>> if I were to write something to parse this output I wouldn't
>>>>> immediately know that it was related to a VM (note the 'id' here
>>>>> actually matches the VM I'm stopping, but there's nothing in the
>>>>>event
>>>>> to tell me it's a VM):
>>>>>
>>>>>
>>>>>'management-server.ResourceStateEvent.StopRequested.Network.d287a0fa-6
>>>>>b3
>>>>>b
>>>>>-4e8b-8fb2-2677778ec32c':'{"id":"d287a0fa-6b3b-4e8b-8fb2-2677778ec32c"
>>>>>,"
>>>>>o
>>>>>ld-state":"Running","new-state":"Stopping","resource":"Network"}'
>>>>>
>>>>> I'm just subscribing to "#", so I assume I'm getting everything, but
>>>>> I'm just having trouble making sense of the output.
>>>>
>>>
>>>
>>>
>>
>>
>
Re: event bus details
Posted by Marcus Sorensen <sh...@gmail.com>.
Thanks for the response. So am I to assume that the VM start/stop
showing up under EntityType Network is also a bug?
On Tue, Jun 25, 2013 at 6:05 AM, Murali Reddy <Mu...@citrix.com> wrote:
>
> Opened bug CLOUDSTACK-3190 for this.
>
> On 25/06/13 4:03 PM, "Murali Reddy" <Mu...@citrix.com> wrote:
>
>>
>>Marcus,
>>
>>Events bus framework with current AMQP default implementation, has routing
>>key with format
>>'Eventsource.EventCategory.EventType.EntityType.EntityUUID' as described
>>in [1]. If you see from the log you pasted below events of type
>>'ResourceStateEvent' has details of entity UUID. Since it was new event
>>type and was added in 4.1 it was easy to design so that all the entity
>>details are published. Also intention of this event was for programatic
>>consumption of events by external entities.
>>
>>Action Events existed from long time, and was implemented and used
>>primarily for auditing messages for non-programmtic use. Unfortunately
>>there is huge number of places for different actions corresponding to
>>different entities need to be cleaned up. Please file a bug for some one
>>to pick it up and work on it.
>>
>>[1] http://s.apache.org/MZS
>>
>>Thanks,
>>Murali
>>
>>On 25/06/13 9:53 AM, "Marcus Sorensen" <sh...@gmail.com> wrote:
>>
>>>Here's another, when deleting a VPC. I see the details of all of the
>>>things it's doing (removing the router, networks, etc), but I can't
>>>tell which VPC was being deleted. I feel like that '*' under
>>>ActionEvent should be telling me the uuid, like that position does in
>>>the other events:
>>>
>>>[x]
>>>'management-server.ActionEvent.VPC-DELETE.Vpc.*':'{"status":"Scheduled","
>>>e
>>>vent":"VPC.DELETE","account":"f668198a-bbdf-11e2-8bb5-52540014c04d","user
>>>"
>>>:"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>> [x]
>>>'management-server.ResourceStateEvent.StopRequested.Network.b18e3e07-aed0
>>>-
>>>473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","ol
>>>d
>>>-state":"Running","new-state":"Stopping","resource":"Network"}'
>>> [x]
>>>'management-server.ResourceStateEvent.OperationSucceeded.Network.b18e3e07
>>>-
>>>aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236
>>>"
>>>,"old-state":"Stopping","new-state":"Stopped","resource":"Network"}'
>>> [x]
>>>'management-server.ResourceStateEvent.ExpungeOperation.Network.b18e3e07-a
>>>e
>>>d0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236",
>>>"
>>>old-state":"Stopped","new-state":"Expunging","resource":"Network"}'
>>> [x]
>>>'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d4
>>>2
>>>8-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","
>>>o
>>>ld-state":"Ready","new-state":"Destroy","resource":"Volume"}'
>>> [x]
>>>'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d4
>>>2
>>>8-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","
>>>o
>>>ld-state":"Ready","new-state":"Destroy","resource":"Volume"}'
>>> [x]
>>>'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-
>>>d
>>>428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a"
>>>,
>>>"old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
>>> [x]
>>>'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-
>>>d
>>>428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a"
>>>,
>>>"old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
>>>...
>>>
>>>On Mon, Jun 24, 2013 at 10:11 PM, Marcus Sorensen <sh...@gmail.com>
>>>wrote:
>>>> Hi all,
>>>> I've been playing around with the new event bus, trying to see if
>>>> it could be useful, and I'm a bit confused about the output. If I
>>>> subscribe to all topics, and try to reboot a virtual machine, this is
>>>> all I see:
>>>>
>>>>
>>>>'management-server.ActionEvent.VM-REBOOT.VirtualMachine.*':'{"status":"S
>>>>c
>>>>heduled","event":"VM.REBOOT","account":"f66d4d60-bbdf-11e2-8bb5-52540014
>>>>c
>>>>04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>>>
>>>> I see the account info, but nothing about which VM is being rebooted.
>>>>
>>>> If I try to stop/start a VM, I likewise see no details in the
>>>> ActionEvent, about the subject being acted upon:
>>>>
>>>>
>>>>'management-server.ActionEvent.VM-STOP.VirtualMachine.*':'{"status":"Sch
>>>>e
>>>>duled","event":"VM.STOP","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d
>>>>"
>>>>,"user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>>>
>>>> I do however see some details regarding a 'Network' resource, though
>>>> if I were to write something to parse this output I wouldn't
>>>> immediately know that it was related to a VM (note the 'id' here
>>>> actually matches the VM I'm stopping, but there's nothing in the event
>>>> to tell me it's a VM):
>>>>
>>>>
>>>>'management-server.ResourceStateEvent.StopRequested.Network.d287a0fa-6b3
>>>>b
>>>>-4e8b-8fb2-2677778ec32c':'{"id":"d287a0fa-6b3b-4e8b-8fb2-2677778ec32c","
>>>>o
>>>>ld-state":"Running","new-state":"Stopping","resource":"Network"}'
>>>>
>>>> I'm just subscribing to "#", so I assume I'm getting everything, but
>>>> I'm just having trouble making sense of the output.
>>>
>>
>>
>>
>
>
Re: event bus details
Posted by Murali Reddy <Mu...@citrix.com>.
Opened bug CLOUDSTACK-3190 for this.
On 25/06/13 4:03 PM, "Murali Reddy" <Mu...@citrix.com> wrote:
>
>Marcus,
>
>Events bus framework with current AMQP default implementation, has routing
>key with format
>'Eventsource.EventCategory.EventType.EntityType.EntityUUID' as described
>in [1]. If you see from the log you pasted below events of type
>'ResourceStateEvent' has details of entity UUID. Since it was new event
>type and was added in 4.1 it was easy to design so that all the entity
>details are published. Also intention of this event was for programatic
>consumption of events by external entities.
>
>Action Events existed from long time, and was implemented and used
>primarily for auditing messages for non-programmtic use. Unfortunately
>there is huge number of places for different actions corresponding to
>different entities need to be cleaned up. Please file a bug for some one
>to pick it up and work on it.
>
>[1] http://s.apache.org/MZS
>
>Thanks,
>Murali
>
>On 25/06/13 9:53 AM, "Marcus Sorensen" <sh...@gmail.com> wrote:
>
>>Here's another, when deleting a VPC. I see the details of all of the
>>things it's doing (removing the router, networks, etc), but I can't
>>tell which VPC was being deleted. I feel like that '*' under
>>ActionEvent should be telling me the uuid, like that position does in
>>the other events:
>>
>>[x]
>>'management-server.ActionEvent.VPC-DELETE.Vpc.*':'{"status":"Scheduled","
>>e
>>vent":"VPC.DELETE","account":"f668198a-bbdf-11e2-8bb5-52540014c04d","user
>>"
>>:"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>> [x]
>>'management-server.ResourceStateEvent.StopRequested.Network.b18e3e07-aed0
>>-
>>473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","ol
>>d
>>-state":"Running","new-state":"Stopping","resource":"Network"}'
>> [x]
>>'management-server.ResourceStateEvent.OperationSucceeded.Network.b18e3e07
>>-
>>aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236
>>"
>>,"old-state":"Stopping","new-state":"Stopped","resource":"Network"}'
>> [x]
>>'management-server.ResourceStateEvent.ExpungeOperation.Network.b18e3e07-a
>>e
>>d0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236",
>>"
>>old-state":"Stopped","new-state":"Expunging","resource":"Network"}'
>> [x]
>>'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d4
>>2
>>8-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","
>>o
>>ld-state":"Ready","new-state":"Destroy","resource":"Volume"}'
>> [x]
>>'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d4
>>2
>>8-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","
>>o
>>ld-state":"Ready","new-state":"Destroy","resource":"Volume"}'
>> [x]
>>'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-
>>d
>>428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a"
>>,
>>"old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
>> [x]
>>'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-
>>d
>>428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a"
>>,
>>"old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
>>...
>>
>>On Mon, Jun 24, 2013 at 10:11 PM, Marcus Sorensen <sh...@gmail.com>
>>wrote:
>>> Hi all,
>>> I've been playing around with the new event bus, trying to see if
>>> it could be useful, and I'm a bit confused about the output. If I
>>> subscribe to all topics, and try to reboot a virtual machine, this is
>>> all I see:
>>>
>>>
>>>'management-server.ActionEvent.VM-REBOOT.VirtualMachine.*':'{"status":"S
>>>c
>>>heduled","event":"VM.REBOOT","account":"f66d4d60-bbdf-11e2-8bb5-52540014
>>>c
>>>04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>>
>>> I see the account info, but nothing about which VM is being rebooted.
>>>
>>> If I try to stop/start a VM, I likewise see no details in the
>>> ActionEvent, about the subject being acted upon:
>>>
>>>
>>>'management-server.ActionEvent.VM-STOP.VirtualMachine.*':'{"status":"Sch
>>>e
>>>duled","event":"VM.STOP","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d
>>>"
>>>,"user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>>
>>> I do however see some details regarding a 'Network' resource, though
>>> if I were to write something to parse this output I wouldn't
>>> immediately know that it was related to a VM (note the 'id' here
>>> actually matches the VM I'm stopping, but there's nothing in the event
>>> to tell me it's a VM):
>>>
>>>
>>>'management-server.ResourceStateEvent.StopRequested.Network.d287a0fa-6b3
>>>b
>>>-4e8b-8fb2-2677778ec32c':'{"id":"d287a0fa-6b3b-4e8b-8fb2-2677778ec32c","
>>>o
>>>ld-state":"Running","new-state":"Stopping","resource":"Network"}'
>>>
>>> I'm just subscribing to "#", so I assume I'm getting everything, but
>>> I'm just having trouble making sense of the output.
>>
>
>
>
Re: event bus details
Posted by Murali Reddy <Mu...@citrix.com>.
Marcus,
Events bus framework with current AMQP default implementation, has routing
key with format
'Eventsource.EventCategory.EventType.EntityType.EntityUUID' as described
in [1]. If you see from the log you pasted below events of type
'ResourceStateEvent' has details of entity UUID. Since it was new event
type and was added in 4.1 it was easy to design so that all the entity
details are published. Also intention of this event was for programatic
consumption of events by external entities.
Action Events existed from long time, and was implemented and used
primarily for auditing messages for non-programmtic use. Unfortunately
there is huge number of places for different actions corresponding to
different entities need to be cleaned up. Please file a bug for some one
to pick it up and work on it.
[1] http://s.apache.org/MZS
Thanks,
Murali
On 25/06/13 9:53 AM, "Marcus Sorensen" <sh...@gmail.com> wrote:
>Here's another, when deleting a VPC. I see the details of all of the
>things it's doing (removing the router, networks, etc), but I can't
>tell which VPC was being deleted. I feel like that '*' under
>ActionEvent should be telling me the uuid, like that position does in
>the other events:
>
>[x]
>'management-server.ActionEvent.VPC-DELETE.Vpc.*':'{"status":"Scheduled","e
>vent":"VPC.DELETE","account":"f668198a-bbdf-11e2-8bb5-52540014c04d","user"
>:"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
> [x]
>'management-server.ResourceStateEvent.StopRequested.Network.b18e3e07-aed0-
>473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","old
>-state":"Running","new-state":"Stopping","resource":"Network"}'
> [x]
>'management-server.ResourceStateEvent.OperationSucceeded.Network.b18e3e07-
>aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236"
>,"old-state":"Stopping","new-state":"Stopped","resource":"Network"}'
> [x]
>'management-server.ResourceStateEvent.ExpungeOperation.Network.b18e3e07-ae
>d0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","
>old-state":"Stopped","new-state":"Expunging","resource":"Network"}'
> [x]
>'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d42
>8-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","o
>ld-state":"Ready","new-state":"Destroy","resource":"Volume"}'
> [x]
>'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d42
>8-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","o
>ld-state":"Ready","new-state":"Destroy","resource":"Volume"}'
> [x]
>'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-d
>428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a",
>"old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
> [x]
>'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-d
>428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a",
>"old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
>...
>
>On Mon, Jun 24, 2013 at 10:11 PM, Marcus Sorensen <sh...@gmail.com>
>wrote:
>> Hi all,
>> I've been playing around with the new event bus, trying to see if
>> it could be useful, and I'm a bit confused about the output. If I
>> subscribe to all topics, and try to reboot a virtual machine, this is
>> all I see:
>>
>>
>>'management-server.ActionEvent.VM-REBOOT.VirtualMachine.*':'{"status":"Sc
>>heduled","event":"VM.REBOOT","account":"f66d4d60-bbdf-11e2-8bb5-52540014c
>>04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>
>> I see the account info, but nothing about which VM is being rebooted.
>>
>> If I try to stop/start a VM, I likewise see no details in the
>> ActionEvent, about the subject being acted upon:
>>
>>
>>'management-server.ActionEvent.VM-STOP.VirtualMachine.*':'{"status":"Sche
>>duled","event":"VM.STOP","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d"
>>,"user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>>
>> I do however see some details regarding a 'Network' resource, though
>> if I were to write something to parse this output I wouldn't
>> immediately know that it was related to a VM (note the 'id' here
>> actually matches the VM I'm stopping, but there's nothing in the event
>> to tell me it's a VM):
>>
>>
>>'management-server.ResourceStateEvent.StopRequested.Network.d287a0fa-6b3b
>>-4e8b-8fb2-2677778ec32c':'{"id":"d287a0fa-6b3b-4e8b-8fb2-2677778ec32c","o
>>ld-state":"Running","new-state":"Stopping","resource":"Network"}'
>>
>> I'm just subscribing to "#", so I assume I'm getting everything, but
>> I'm just having trouble making sense of the output.
>
Re: event bus details
Posted by Marcus Sorensen <sh...@gmail.com>.
Here's another, when deleting a VPC. I see the details of all of the
things it's doing (removing the router, networks, etc), but I can't
tell which VPC was being deleted. I feel like that '*' under
ActionEvent should be telling me the uuid, like that position does in
the other events:
[x] 'management-server.ActionEvent.VPC-DELETE.Vpc.*':'{"status":"Scheduled","event":"VPC.DELETE","account":"f668198a-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
[x] 'management-server.ResourceStateEvent.StopRequested.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","old-state":"Running","new-state":"Stopping","resource":"Network"}'
[x] 'management-server.ResourceStateEvent.OperationSucceeded.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","old-state":"Stopping","new-state":"Stopped","resource":"Network"}'
[x] 'management-server.ResourceStateEvent.ExpungeOperation.Network.b18e3e07-aed0-473a-aeb2-bfad00bfb236':'{"id":"b18e3e07-aed0-473a-aeb2-bfad00bfb236","old-state":"Stopped","new-state":"Expunging","resource":"Network"}'
[x] 'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Ready","new-state":"Destroy","resource":"Volume"}'
[x] 'management-server.ResourceStateEvent.DestroyRequested.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Ready","new-state":"Destroy","resource":"Volume"}'
[x] 'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
[x] 'management-server.ResourceStateEvent.OperationSucceeded.Volume.5dca4da7-d428-4f6f-a474-11eee55fdf3a':'{"id":"5dca4da7-d428-4f6f-a474-11eee55fdf3a","old-state":"Destroy","new-state":"Destroy","resource":"Volume"}'
...
On Mon, Jun 24, 2013 at 10:11 PM, Marcus Sorensen <sh...@gmail.com> wrote:
> Hi all,
> I've been playing around with the new event bus, trying to see if
> it could be useful, and I'm a bit confused about the output. If I
> subscribe to all topics, and try to reboot a virtual machine, this is
> all I see:
>
> 'management-server.ActionEvent.VM-REBOOT.VirtualMachine.*':'{"status":"Scheduled","event":"VM.REBOOT","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>
> I see the account info, but nothing about which VM is being rebooted.
>
> If I try to stop/start a VM, I likewise see no details in the
> ActionEvent, about the subject being acted upon:
>
> 'management-server.ActionEvent.VM-STOP.VirtualMachine.*':'{"status":"Scheduled","event":"VM.STOP","account":"f66d4d60-bbdf-11e2-8bb5-52540014c04d","user":"f66f14d8-bbdf-11e2-8bb5-52540014c04d"}'
>
> I do however see some details regarding a 'Network' resource, though
> if I were to write something to parse this output I wouldn't
> immediately know that it was related to a VM (note the 'id' here
> actually matches the VM I'm stopping, but there's nothing in the event
> to tell me it's a VM):
>
> 'management-server.ResourceStateEvent.StopRequested.Network.d287a0fa-6b3b-4e8b-8fb2-2677778ec32c':'{"id":"d287a0fa-6b3b-4e8b-8fb2-2677778ec32c","old-state":"Running","new-state":"Stopping","resource":"Network"}'
>
> I'm just subscribing to "#", so I assume I'm getting everything, but
> I'm just having trouble making sense of the output.