You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Alex Ough <al...@sungard.com> on 2013/12/04 19:31:34 UTC
Re: Entity UUID and Type missing on ActionEvent event notifications
All,
I made a comment on its jira,
CLOUDSTACK-3190<https://issues.apache.org/jira/browse/CLOUDSTACK-3190>,
so can anyone confirm what I found?
I guess it is related with some refactoring related with 'CallContext'
class.
If correct, I'd like make changes because it is a blocker of what I'm
working on for CLOUDSTACK-4992<https://issues.apache.org/jira/browse/CLOUDSTACK-4992>
.
Thanks
Alex Ough
On Wed, Nov 20, 2013 at 1:37 PM, Nitin Mehta <Ni...@citrix.com> wrote:
> David - CallContext gets created during the entry point of the API.
> I haven't had the chance to completely investigate but I am hoping that
> you can push the UUID then or on completion of the API (in case where you
> are creating the actual resource).
> See if that works else there is no other way out.
>
> Another feedback on Rabbit MQ would be to push the list of all the first
> class objects (UUIDs) that are affected in the event description if
> possible. Say user invokes attachVolume to a vm. It would be good to
> always push vm uuid.
> Just putting in the volume uuid necessitates another call to CS and also
> that this was attach volume operation.
>
> Thanks,
> -Nitin
>
> On 20/11/13 8:23 AM, "David Grizzanti" <da...@sungard.com>
> wrote:
>
> >Thanks for the feedback and info on the existing bug filed for this.
> >
> >Nitin - I was originally thinking along the lines of what Murali has
> >recently commented (i.e. adding Entity Details in the UserContext in all
> >the places where an Action Event is generated). The particular case I
> >was using this for when I found the issue was for creating a network,
> >which is not an async job. The AsyncJobManager I believe it generating a
> >different type of event that what I was originally looking at.
> >
> >Let me know your thoughts.
> >
> >Thanks
> >
> >--
> >David Grizzanti
> >Software Engineer
> >Sungard Availability Services
> >
> >e: david.grizzanti@sungard.com
> >w: 215.446.1431
> >c: 570.575.0315
> >
> >On November 20, 2013 at 2:45:50 AM, Murali Reddy
> >(murali.reddy@citrix.com) wrote:
> >
> >
> >
> >On 20/11/13 2:15 AM, "David Grizzanti" <da...@sungard.com>
> >wrote:
> >
> >>Hi All,
> >>
> >>I noticed that the event messages going to rabbitmq of type
> >>"ActionEvent"
> >>are missing any reference to the entity Id/UUID. Was this omission
> >>intentional? Poking through the code, I was able to find that adding the
> >>
> >>information on to the event is fairly straightforward (albeit a bit
> >>tedious). Does anyone have any objections to updating these event types
> >>with this information? I can file the appropriate Jira, but wanted to
> >>check in with the list first to get opinions.
> >
> >David,
> >
> >Omission is not intentional. Please see [1] for earlier discussion. There
> >
> >is a bug opened as well[2].
> >
> >If you see ActionEventUtils, there is code that gets 'entity type' and
> >'entity uuid' from the CallContext and fills the details on the message
> >published. I added this as generic mechanism. Unfortunately, there is not
> >
> >a single place where if you populate the entity type and uuid in the call
> >
> >context then things would fall in place. So its tedious job of adding the
> >
> >entity type and uuid details to the call context to all the methods
> >annotated with 'ActionEvent', but other wise it is a much needed fix.
> >
> >[1]
> >
> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201306.mbox/%3CCDF
> >1
> >DB6A.424D9%25murali.reddy@citrix.com%3E
> >[2] https://issues.apache.org/jira/browse/CLOUDSTACK-3190
> >
> >
> >> Example event for network creation below.
> >>
> >>Thanks
> >>
> >>----------
> >>@source="management-server", @type="ActionEvent",
> >>@action="NETWORK-CREATE", @resource_type="Network", @resource_id="*">
> >>{
> >> "status": "Completed",
> >> "event": "NETWORK.CREATE",
> >> "account": "6d836cf8-47cd-11e3-a130-606d02c0c082",
> >> "user": "6d838544-47cd-11e3-a130-606d02c0c082"
> >>}
> >>
> >>--
> >>David Grizzanti
> >>Software Engineer
> >>Sungard Availability Services
> >>
> >>e: david.grizzanti@sungard.com
> >>w: 215.446.1431
> >>c: 570.575.0315
> >
> >
> >
>
>
>
Re: Entity UUID and Type missing on ActionEvent event
notifications
Posted by David Grizzanti <da...@sungard.com>.
Murali,
Another thing I wanted to mention along the same lines is that ActionEvents issued for resources in a project, don't have a project ID. They have an account ID, but it's the UUID for the project account ID, instead of the project ID. This is not that useful as you can't use that account ID for anything in the API. I created a bug and added a patch for this in https://issues.apache.org/jira/browse/CLOUDSTACK-5496 if you could take a look.
Thanks
--
David Grizzanti
Software Engineer
Sungard Availability Services
e: david.grizzanti@sungard.com
w: 215.446.1431
c: 570.575.0315
On December 17, 2013 at 1:26:04 AM, Murali Reddy (murali.reddy@citrix.com) wrote:
Yes, they are not in master and 4.3. For master/4.3 we will have to use
generic CallContext.current().putContextParameter() to store the entity
details as key/value pairs.
On 16/12/13 10:28 PM, "Alex Ough" <al...@sungard.com> wrote:
>A little confusion here because 'setEntityDetails' in 'UserContext' is
>no longer used in master.
>Is this functionality only for 4.2 and not supported in master?
>
>Thanks
>Alex Ough
>
>On Mon, Dec 16, 2013 at 8:35 AM, Murali Reddy <Mu...@citrix.com>
>wrote:
>> David,
>>
>> Your analysis is right. There is no single place to put logic which
>>will fix
>> all api commands. So adding setEntityDetails call on each of the method
>>that
>> is annotated with ActionEvent is right approach.
>>
>> Thanks,
>> Murali
>>
>> From: David Grizzanti <da...@sungard.com>
>> Date: Thursday, 12 December 2013 10:16 PM
>> To: Murali Reddy <mu...@citrix.com>, "dev@cloudstack.apache.org"
>> <de...@cloudstack.apache.org>, Alex Ough <al...@sungard.com>, Nitin
>>Mehta
>> <Ni...@citrix.com>
>> Subject: Re: Entity UUID and Type missing on ActionEvent event
>>notifications
>>
>> Murali/All,
>>
>> Opening this discussion back up to decide how to approach fixing this.
>>I
>> looked over what Nitin mentioned, but given that I don't know a whole
>>lot
>> about the inner working of the code I don't see anywhere that it would
>>make
>> sense to put this logic so that it applies to all API commands. At the
>> outset of the API command where UserContext/CallContext get
>>initialized, the
>> resource is not created yet (for Creation cases, so it doesn't yet have
>>a
>> UUID). At the completion of the API command, the Action Event has
>>already
>> been generated.
>>
>> It seems that there are already places where details are being added to
>>the
>> UserContext in implementation classes:
>> server/src/com/cloud/projects/ProjectManagerImpl.java:
>> UserContext.current().setEventDetails("Project id=" + project.getId());
>>
>> Let me know what other thoughts you may have, otherwise I'd like to
>>proceed
>> with adding a setEntityDetails call to each of the places where
>> setEventDetails are placed to accomplish this.
>>
>> --
>> David Grizzanti
>> Software Engineer
>> Sungard Availability Services
>>
>> e: david.grizzanti@sungard.com
>> w: 215.446.1431
>> c: 570.575.0315
>>
>> On December 11, 2013 at 6:33:25 AM, Murali Reddy
>>(murali.reddy@citrix.com)
>> wrote:
>>
>> On 11/12/13 3:01 AM, "David Grizzanti" <da...@sungard.com>
>>wrote:
>>
>>>Murali,
>>>
>>>I spoke with Alex regarding this issue and it appears there may have
>>>been
>>>some mix up in what the original intent of the bug was and what actually
>>>got fixed. To me, the idea behind this was to address the bug that the
>>>entity UUID was not getting added to ActionEvents for all resource
>>>types.
>>> When I looked at this fix today and spoke with Alex, I think what was
>>>fixed was only for accounts/users/domains.
>>
>> David,
>>
>> You are right. Original intent of the bug is to fix all the action
>>events
>> corresponding to all entities. I added a mechanism to persist the entity
>> type and entity UUID into the CallContext/UserContext, these details are
>> retrieved in the action event interceptor and published on to the event
>> bus. Unfortunately there is no single place where we can persist entity
>> UUID & type in the CallContext, so that all the action events are taken
>> care automatically. So in 4.2 for account/user/domain sync across the
>> zones for regions feature, I just fixed action events related to these
>> three entities. There was regression in 4.3, which Alex's fix will fix
>>it.
>> But generally original intent of the bug 3190 is not fixed yet. May its
>> better we open a different bug, as wrong commits went in to the bug.
>>
>> Thanks,
>> Murali
>>
>>>
>>>Not sure where the break down happened, but was wondering how you
>>>thought
>>>we should address this? Open a new Jira to track the changes given the
>>>history of the existing one or re-open
>>>https://issues.apache.org/jira/browse/CLOUDSTACK-3190?
>>>
>>>Thanks
>>>
>>>--
>>>David Grizzanti
>>>Software Engineer
>>>Sungard Availability Services
>>>
>>>e: david.grizzanti@sungard.com
>>>w: 215.446.1431
>>>c: 570.575.0315
>>>
>>>On December 6, 2013 at 4:26:40 PM, Alex Ough (alex.ough@sungard.com)
>>>wrote:
>>>
>>>I modified the fix to make a little simpler, so can you review it
>>>please?
>>>
>>>
>>>I'd like to finalize this as soon as possible to move on with
>>>CLOUDSTACK-4992.
>>>
>>>Thanks
>>>Alex Ough
>>>
>>>On Thu, Dec 5, 2013 at 1:32 PM, Alex Ough <al...@sungard.com> wrote:
>>>> All,
>>>>
>>>> I submitted the review request, so please review it and let me know if
>>>>there
>>>> is anything missing/incorrect.
>>>>
>>>> Thanks
>>>> Alex Ough
>>>>
>>>>
>>>> On Wed, Dec 4, 2013 at 11:29 PM, Murali Reddy
>>>><Mu...@citrix.com>
>>>>
>>>> wrote:
>>>>>
>>>>> On 05/12/13 12:01 AM, "Alex Ough" <al...@sungard.com> wrote:
>>>>>
>>>>> >All,
>>>>> >
>>>>> >I made a comment on its jira,
>>>>>
>>>>>>CLOUDSTACK-3190<https://issues.apache.org/jira/browse/CLOUDSTACK-3190
>>>>>>>,
>>>>>>
>>>>> >so can anyone confirm what I found?
>>>>> >I guess it is related with some refactoring related with
>>>>>'CallContext'
>>>>> >class.
>>>>>
>>>>> Alex,
>>>>>
>>>>> Yes, it regressed during shift from UserContext to CallContext.
>>>>>Please
>>>>>go
>>>>> ahead with changes
>>>>>
>>>>> >
>>>>> >If correct, I'd like make changes because it is a blocker of what
>>>>>I'm
>>>>>
>>>>> >working on for
>>>>>
>>>>>>CLOUDSTACK-4992<https://issues.apache.org/jira/browse/CLOUDSTACK-4992
>>>>>>>
>>>>>>
>>>>> >.
>>>>> >
>>>>> >Thanks
>>>>> >Alex Ough
>>>>> >
>>>>> >
>>>>> >On Wed, Nov 20, 2013 at 1:37 PM, Nitin Mehta
>>>>><Ni...@citrix.com>
>>>>>
>>>>> >wrote:
>>>>> >
>>>>> >> David - CallContext gets created during the entry point of the
>>>>>API.
>>>>>
>>>>> >> I haven't had the chance to completely investigate but I am hoping
>>>>>that
>>>>> >> you can push the UUID then or on completion of the API (in case
>>>>>where
>>>>> >>you
>>>>> >> are creating the actual resource).
>>>>> >> See if that works else there is no other way out.
>>>>> >>
>>>>> >> Another feedback on Rabbit MQ would be to push the list of all the
>>>>> >> first
>>>>> >> class objects (UUIDs) that are affected in the event description
>>>>>if
>>>>>
>>>>> >> possible. Say user invokes attachVolume to a vm. It would be good
>>>>>to
>>>>> >> always push vm uuid.
>>>>> >> Just putting in the volume uuid necessitates another call to CS
>>>>>and
>>>>>
>>>>> >> also
>>>>> >> that this was attach volume operation.
>>>>> >>
>>>>> >> Thanks,
>>>>> >> -Nitin
>>>>> >>
>>>>> >> On 20/11/13 8:23 AM, "David Grizzanti"
>>>>><da...@sungard.com>
>>>>> >> wrote:
>>>>> >>
>>>>> >> >Thanks for the feedback and info on the existing bug filed for
>>>>>this.
>>>>> >> >
>>>>> >> >Nitin - I was originally thinking along the lines of what Murali
>>>>>has
>>>>> >> >recently commented (i.e. adding Entity Details in the UserContext
>>>>>in
>>>>> >>all
>>>>> >> >the places where an Action Event is generated). The particular
>>>>>case I
>>>>> >> >was using this for when I found the issue was for creating a
>>>>>network,
>>>>> >> >which is not an async job. The AsyncJobManager I believe it
>>>>> >>generating a
>>>>> >> >different type of event that what I was originally looking at.
>>>>> >> >
>>>>> >> >Let me know your thoughts.
>>>>> >> >
>>>>> >> >Thanks
>>>>> >> >
>>>>> >> >--
>>>>> >> >David Grizzanti
>>>>> >> >Software Engineer
>>>>> >> >Sungard Availability Services
>>>>> >> >
>>>>> >> >e: david.grizzanti@sungard.com
>>>>> >> >w: 215.446.1431
>>>>> >> >c: 570.575.0315
>>>>> >> >
>>>>> >> >On November 20, 2013 at 2:45:50 AM, Murali Reddy
>>>>> >> >(murali.reddy@citrix.com) wrote:
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >On 20/11/13 2:15 AM, "David Grizzanti"
>>>>><da...@sungard.com>
>>>>> >> >wrote:
>>>>> >> >
>>>>> >> >>Hi All,
>>>>> >> >>
>>>>> >> >>I noticed that the event messages going to rabbitmq of type
>>>>> >> >>"ActionEvent"
>>>>> >> >>are missing any reference to the entity Id/UUID. Was this
>>>>>omission
>>>>> >> >>intentional? Poking through the code, I was able to find that
>>>>>adding
>>>>> >>the
>>>>> >> >>
>>>>> >> >>information on to the event is fairly straightforward (albeit a
>>>>>bit
>>>>> >> >>tedious). Does anyone have any objections to updating these
>>>>>event
>>>>>
>>>>> >>types
>>>>> >> >>with this information? I can file the appropriate Jira, but
>>>>>wanted to
>>>>> >> >>check in with the list first to get opinions.
>>>>> >> >
>>>>> >> >David,
>>>>> >> >
>>>>> >> >Omission is not intentional. Please see [1] for earlier
>>>>>discussion.
>>>>> >>There
>>>>> >> >
>>>>> >> >is a bug opened as well[2].
>>>>> >> >
>>>>> >> >If you see ActionEventUtils, there is code that gets 'entity
>>>>>type'
>>>>>and
>>>>> >> >'entity uuid' from the CallContext and fills the details on the
>>>>> >> > message
>>>>> >> >published. I added this as generic mechanism. Unfortunately,
>>>>>there
>>>>>is
>>>>> >>not
>>>>> >> >
>>>>> >> >a single place where if you populate the entity type and uuid in
>>>>>the
>>>>> >>call
>>>>> >> >
>>>>> >> >context then things would fall in place. So its tedious job of
>>>>>adding
>>>>> >>the
>>>>> >> >
>>>>> >> >entity type and uuid details to the call context to all the
>>>>>methods
>>>>> >> >annotated with 'ActionEvent', but other wise it is a much needed
>>>>>fix.
>>>>> >> >
>>>>> >> >[1]
>>>>> >> >
>>>>> >>
>>>>>
>>>>> >>
>>>>>>>http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201306.mbox/
>>>>>>>%3
>>>>>>>CCD
>>>>> >>F
>>>>> >> >1
>>>>> >> >DB6A.424D9%25murali.reddy@citrix.com%3E
>>>>> >> >[2] https://issues.apache.org/jira/browse/CLOUDSTACK-3190
>>>>> >> >
>>>>> >> >
>>>>> >> >> Example event for network creation below.
>>>>> >> >>
>>>>> >> >>Thanks
>>>>> >> >>
>>>>> >> >>----------
>>>>> >> >>@source="management-server", @type="ActionEvent",
>>>>> >> >>@action="NETWORK-CREATE", @resource_type="Network",
>>>>>@resource_id="*">
>>>>> >> >>{
>>>>> >> >> "status": "Completed",
>>>>> >> >> "event": "NETWORK.CREATE",
>>>>> >> >> "account": "6d836cf8-47cd-11e3-a130-606d02c0c082",
>>>>> >> >> "user": "6d838544-47cd-11e3-a130-606d02c0c082"
>>>>> >> >>}
>>>>> >> >>
>>>>> >> >>--
>>>>> >> >>David Grizzanti
>>>>> >> >>Software Engineer
>>>>> >> >>Sungard Availability Services
>>>>> >> >>
>>>>> >> >>e: david.grizzanti@sungard.com
>>>>> >> >>w: 215.446.1431
>>>>> >> >>c: 570.575.0315
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>
Re: Entity UUID and Type missing on ActionEvent event notifications
Posted by Murali Reddy <Mu...@citrix.com>.
Yes, they are not in master and 4.3. For master/4.3 we will have to use
generic CallContext.current().putContextParameter() to store the entity
details as key/value pairs.
On 16/12/13 10:28 PM, "Alex Ough" <al...@sungard.com> wrote:
>A little confusion here because 'setEntityDetails' in 'UserContext' is
>no longer used in master.
>Is this functionality only for 4.2 and not supported in master?
>
>Thanks
>Alex Ough
>
>On Mon, Dec 16, 2013 at 8:35 AM, Murali Reddy <Mu...@citrix.com>
>wrote:
>> David,
>>
>> Your analysis is right. There is no single place to put logic which
>>will fix
>> all api commands. So adding setEntityDetails call on each of the method
>>that
>> is annotated with ActionEvent is right approach.
>>
>> Thanks,
>> Murali
>>
>> From: David Grizzanti <da...@sungard.com>
>> Date: Thursday, 12 December 2013 10:16 PM
>> To: Murali Reddy <mu...@citrix.com>, "dev@cloudstack.apache.org"
>> <de...@cloudstack.apache.org>, Alex Ough <al...@sungard.com>, Nitin
>>Mehta
>> <Ni...@citrix.com>
>> Subject: Re: Entity UUID and Type missing on ActionEvent event
>>notifications
>>
>> Murali/All,
>>
>> Opening this discussion back up to decide how to approach fixing this.
>>I
>> looked over what Nitin mentioned, but given that I don't know a whole
>>lot
>> about the inner working of the code I don't see anywhere that it would
>>make
>> sense to put this logic so that it applies to all API commands. At the
>> outset of the API command where UserContext/CallContext get
>>initialized, the
>> resource is not created yet (for Creation cases, so it doesn't yet have
>>a
>> UUID). At the completion of the API command, the Action Event has
>>already
>> been generated.
>>
>> It seems that there are already places where details are being added to
>>the
>> UserContext in implementation classes:
>> server/src/com/cloud/projects/ProjectManagerImpl.java:
>> UserContext.current().setEventDetails("Project id=" + project.getId());
>>
>> Let me know what other thoughts you may have, otherwise I'd like to
>>proceed
>> with adding a setEntityDetails call to each of the places where
>> setEventDetails are placed to accomplish this.
>>
>> --
>> David Grizzanti
>> Software Engineer
>> Sungard Availability Services
>>
>> e: david.grizzanti@sungard.com
>> w: 215.446.1431
>> c: 570.575.0315
>>
>> On December 11, 2013 at 6:33:25 AM, Murali Reddy
>>(murali.reddy@citrix.com)
>> wrote:
>>
>> On 11/12/13 3:01 AM, "David Grizzanti" <da...@sungard.com>
>>wrote:
>>
>>>Murali,
>>>
>>>I spoke with Alex regarding this issue and it appears there may have
>>>been
>>>some mix up in what the original intent of the bug was and what actually
>>>got fixed. To me, the idea behind this was to address the bug that the
>>>entity UUID was not getting added to ActionEvents for all resource
>>>types.
>>> When I looked at this fix today and spoke with Alex, I think what was
>>>fixed was only for accounts/users/domains.
>>
>> David,
>>
>> You are right. Original intent of the bug is to fix all the action
>>events
>> corresponding to all entities. I added a mechanism to persist the entity
>> type and entity UUID into the CallContext/UserContext, these details are
>> retrieved in the action event interceptor and published on to the event
>> bus. Unfortunately there is no single place where we can persist entity
>> UUID & type in the CallContext, so that all the action events are taken
>> care automatically. So in 4.2 for account/user/domain sync across the
>> zones for regions feature, I just fixed action events related to these
>> three entities. There was regression in 4.3, which Alex's fix will fix
>>it.
>> But generally original intent of the bug 3190 is not fixed yet. May its
>> better we open a different bug, as wrong commits went in to the bug.
>>
>> Thanks,
>> Murali
>>
>>>
>>>Not sure where the break down happened, but was wondering how you
>>>thought
>>>we should address this? Open a new Jira to track the changes given the
>>>history of the existing one or re-open
>>>https://issues.apache.org/jira/browse/CLOUDSTACK-3190?
>>>
>>>Thanks
>>>
>>>--
>>>David Grizzanti
>>>Software Engineer
>>>Sungard Availability Services
>>>
>>>e: david.grizzanti@sungard.com
>>>w: 215.446.1431
>>>c: 570.575.0315
>>>
>>>On December 6, 2013 at 4:26:40 PM, Alex Ough (alex.ough@sungard.com)
>>>wrote:
>>>
>>>I modified the fix to make a little simpler, so can you review it
>>>please?
>>>
>>>
>>>I'd like to finalize this as soon as possible to move on with
>>>CLOUDSTACK-4992.
>>>
>>>Thanks
>>>Alex Ough
>>>
>>>On Thu, Dec 5, 2013 at 1:32 PM, Alex Ough <al...@sungard.com> wrote:
>>>> All,
>>>>
>>>> I submitted the review request, so please review it and let me know if
>>>>there
>>>> is anything missing/incorrect.
>>>>
>>>> Thanks
>>>> Alex Ough
>>>>
>>>>
>>>> On Wed, Dec 4, 2013 at 11:29 PM, Murali Reddy
>>>><Mu...@citrix.com>
>>>>
>>>> wrote:
>>>>>
>>>>> On 05/12/13 12:01 AM, "Alex Ough" <al...@sungard.com> wrote:
>>>>>
>>>>> >All,
>>>>> >
>>>>> >I made a comment on its jira,
>>>>>
>>>>>>CLOUDSTACK-3190<https://issues.apache.org/jira/browse/CLOUDSTACK-3190
>>>>>>>,
>>>>>>
>>>>> >so can anyone confirm what I found?
>>>>> >I guess it is related with some refactoring related with
>>>>>'CallContext'
>>>>> >class.
>>>>>
>>>>> Alex,
>>>>>
>>>>> Yes, it regressed during shift from UserContext to CallContext.
>>>>>Please
>>>>>go
>>>>> ahead with changes
>>>>>
>>>>> >
>>>>> >If correct, I'd like make changes because it is a blocker of what
>>>>>I'm
>>>>>
>>>>> >working on for
>>>>>
>>>>>>CLOUDSTACK-4992<https://issues.apache.org/jira/browse/CLOUDSTACK-4992
>>>>>>>
>>>>>>
>>>>> >.
>>>>> >
>>>>> >Thanks
>>>>> >Alex Ough
>>>>> >
>>>>> >
>>>>> >On Wed, Nov 20, 2013 at 1:37 PM, Nitin Mehta
>>>>><Ni...@citrix.com>
>>>>>
>>>>> >wrote:
>>>>> >
>>>>> >> David - CallContext gets created during the entry point of the
>>>>>API.
>>>>>
>>>>> >> I haven't had the chance to completely investigate but I am hoping
>>>>>that
>>>>> >> you can push the UUID then or on completion of the API (in case
>>>>>where
>>>>> >>you
>>>>> >> are creating the actual resource).
>>>>> >> See if that works else there is no other way out.
>>>>> >>
>>>>> >> Another feedback on Rabbit MQ would be to push the list of all the
>>>>> >> first
>>>>> >> class objects (UUIDs) that are affected in the event description
>>>>>if
>>>>>
>>>>> >> possible. Say user invokes attachVolume to a vm. It would be good
>>>>>to
>>>>> >> always push vm uuid.
>>>>> >> Just putting in the volume uuid necessitates another call to CS
>>>>>and
>>>>>
>>>>> >> also
>>>>> >> that this was attach volume operation.
>>>>> >>
>>>>> >> Thanks,
>>>>> >> -Nitin
>>>>> >>
>>>>> >> On 20/11/13 8:23 AM, "David Grizzanti"
>>>>><da...@sungard.com>
>>>>> >> wrote:
>>>>> >>
>>>>> >> >Thanks for the feedback and info on the existing bug filed for
>>>>>this.
>>>>> >> >
>>>>> >> >Nitin - I was originally thinking along the lines of what Murali
>>>>>has
>>>>> >> >recently commented (i.e. adding Entity Details in the UserContext
>>>>>in
>>>>> >>all
>>>>> >> >the places where an Action Event is generated). The particular
>>>>>case I
>>>>> >> >was using this for when I found the issue was for creating a
>>>>>network,
>>>>> >> >which is not an async job. The AsyncJobManager I believe it
>>>>> >>generating a
>>>>> >> >different type of event that what I was originally looking at.
>>>>> >> >
>>>>> >> >Let me know your thoughts.
>>>>> >> >
>>>>> >> >Thanks
>>>>> >> >
>>>>> >> >--
>>>>> >> >David Grizzanti
>>>>> >> >Software Engineer
>>>>> >> >Sungard Availability Services
>>>>> >> >
>>>>> >> >e: david.grizzanti@sungard.com
>>>>> >> >w: 215.446.1431
>>>>> >> >c: 570.575.0315
>>>>> >> >
>>>>> >> >On November 20, 2013 at 2:45:50 AM, Murali Reddy
>>>>> >> >(murali.reddy@citrix.com) wrote:
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >> >On 20/11/13 2:15 AM, "David Grizzanti"
>>>>><da...@sungard.com>
>>>>> >> >wrote:
>>>>> >> >
>>>>> >> >>Hi All,
>>>>> >> >>
>>>>> >> >>I noticed that the event messages going to rabbitmq of type
>>>>> >> >>"ActionEvent"
>>>>> >> >>are missing any reference to the entity Id/UUID. Was this
>>>>>omission
>>>>> >> >>intentional? Poking through the code, I was able to find that
>>>>>adding
>>>>> >>the
>>>>> >> >>
>>>>> >> >>information on to the event is fairly straightforward (albeit a
>>>>>bit
>>>>> >> >>tedious). Does anyone have any objections to updating these
>>>>>event
>>>>>
>>>>> >>types
>>>>> >> >>with this information? I can file the appropriate Jira, but
>>>>>wanted to
>>>>> >> >>check in with the list first to get opinions.
>>>>> >> >
>>>>> >> >David,
>>>>> >> >
>>>>> >> >Omission is not intentional. Please see [1] for earlier
>>>>>discussion.
>>>>> >>There
>>>>> >> >
>>>>> >> >is a bug opened as well[2].
>>>>> >> >
>>>>> >> >If you see ActionEventUtils, there is code that gets 'entity
>>>>>type'
>>>>>and
>>>>> >> >'entity uuid' from the CallContext and fills the details on the
>>>>> >> > message
>>>>> >> >published. I added this as generic mechanism. Unfortunately,
>>>>>there
>>>>>is
>>>>> >>not
>>>>> >> >
>>>>> >> >a single place where if you populate the entity type and uuid in
>>>>>the
>>>>> >>call
>>>>> >> >
>>>>> >> >context then things would fall in place. So its tedious job of
>>>>>adding
>>>>> >>the
>>>>> >> >
>>>>> >> >entity type and uuid details to the call context to all the
>>>>>methods
>>>>> >> >annotated with 'ActionEvent', but other wise it is a much needed
>>>>>fix.
>>>>> >> >
>>>>> >> >[1]
>>>>> >> >
>>>>> >>
>>>>>
>>>>> >>
>>>>>>>http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201306.mbox/
>>>>>>>%3
>>>>>>>CCD
>>>>> >>F
>>>>> >> >1
>>>>> >> >DB6A.424D9%25murali.reddy@citrix.com%3E
>>>>> >> >[2] https://issues.apache.org/jira/browse/CLOUDSTACK-3190
>>>>> >> >
>>>>> >> >
>>>>> >> >> Example event for network creation below.
>>>>> >> >>
>>>>> >> >>Thanks
>>>>> >> >>
>>>>> >> >>----------
>>>>> >> >>@source="management-server", @type="ActionEvent",
>>>>> >> >>@action="NETWORK-CREATE", @resource_type="Network",
>>>>>@resource_id="*">
>>>>> >> >>{
>>>>> >> >> "status": "Completed",
>>>>> >> >> "event": "NETWORK.CREATE",
>>>>> >> >> "account": "6d836cf8-47cd-11e3-a130-606d02c0c082",
>>>>> >> >> "user": "6d838544-47cd-11e3-a130-606d02c0c082"
>>>>> >> >>}
>>>>> >> >>
>>>>> >> >>--
>>>>> >> >>David Grizzanti
>>>>> >> >>Software Engineer
>>>>> >> >>Sungard Availability Services
>>>>> >> >>
>>>>> >> >>e: david.grizzanti@sungard.com
>>>>> >> >>w: 215.446.1431
>>>>> >> >>c: 570.575.0315
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>
Re: Entity UUID and Type missing on ActionEvent event notifications
Posted by Alex Ough <al...@sungard.com>.
A little confusion here because 'setEntityDetails' in 'UserContext' is
no longer used in master.
Is this functionality only for 4.2 and not supported in master?
Thanks
Alex Ough
On Mon, Dec 16, 2013 at 8:35 AM, Murali Reddy <Mu...@citrix.com> wrote:
> David,
>
> Your analysis is right. There is no single place to put logic which will fix
> all api commands. So adding setEntityDetails call on each of the method that
> is annotated with ActionEvent is right approach.
>
> Thanks,
> Murali
>
> From: David Grizzanti <da...@sungard.com>
> Date: Thursday, 12 December 2013 10:16 PM
> To: Murali Reddy <mu...@citrix.com>, "dev@cloudstack.apache.org"
> <de...@cloudstack.apache.org>, Alex Ough <al...@sungard.com>, Nitin Mehta
> <Ni...@citrix.com>
> Subject: Re: Entity UUID and Type missing on ActionEvent event notifications
>
> Murali/All,
>
> Opening this discussion back up to decide how to approach fixing this. I
> looked over what Nitin mentioned, but given that I don't know a whole lot
> about the inner working of the code I don't see anywhere that it would make
> sense to put this logic so that it applies to all API commands. At the
> outset of the API command where UserContext/CallContext get initialized, the
> resource is not created yet (for Creation cases, so it doesn't yet have a
> UUID). At the completion of the API command, the Action Event has already
> been generated.
>
> It seems that there are already places where details are being added to the
> UserContext in implementation classes:
> server/src/com/cloud/projects/ProjectManagerImpl.java:
> UserContext.current().setEventDetails("Project id=" + project.getId());
>
> Let me know what other thoughts you may have, otherwise I'd like to proceed
> with adding a setEntityDetails call to each of the places where
> setEventDetails are placed to accomplish this.
>
> --
> David Grizzanti
> Software Engineer
> Sungard Availability Services
>
> e: david.grizzanti@sungard.com
> w: 215.446.1431
> c: 570.575.0315
>
> On December 11, 2013 at 6:33:25 AM, Murali Reddy (murali.reddy@citrix.com)
> wrote:
>
> On 11/12/13 3:01 AM, "David Grizzanti" <da...@sungard.com> wrote:
>
>>Murali,
>>
>>I spoke with Alex regarding this issue and it appears there may have been
>>some mix up in what the original intent of the bug was and what actually
>>got fixed. To me, the idea behind this was to address the bug that the
>>entity UUID was not getting added to ActionEvents for all resource types.
>> When I looked at this fix today and spoke with Alex, I think what was
>>fixed was only for accounts/users/domains.
>
> David,
>
> You are right. Original intent of the bug is to fix all the action events
> corresponding to all entities. I added a mechanism to persist the entity
> type and entity UUID into the CallContext/UserContext, these details are
> retrieved in the action event interceptor and published on to the event
> bus. Unfortunately there is no single place where we can persist entity
> UUID & type in the CallContext, so that all the action events are taken
> care automatically. So in 4.2 for account/user/domain sync across the
> zones for regions feature, I just fixed action events related to these
> three entities. There was regression in 4.3, which Alex's fix will fix it.
> But generally original intent of the bug 3190 is not fixed yet. May its
> better we open a different bug, as wrong commits went in to the bug.
>
> Thanks,
> Murali
>
>>
>>Not sure where the break down happened, but was wondering how you thought
>>we should address this? Open a new Jira to track the changes given the
>>history of the existing one or re-open
>>https://issues.apache.org/jira/browse/CLOUDSTACK-3190?
>>
>>Thanks
>>
>>--
>>David Grizzanti
>>Software Engineer
>>Sungard Availability Services
>>
>>e: david.grizzanti@sungard.com
>>w: 215.446.1431
>>c: 570.575.0315
>>
>>On December 6, 2013 at 4:26:40 PM, Alex Ough (alex.ough@sungard.com)
>>wrote:
>>
>>I modified the fix to make a little simpler, so can you review it please?
>>
>>
>>I'd like to finalize this as soon as possible to move on with
>>CLOUDSTACK-4992.
>>
>>Thanks
>>Alex Ough
>>
>>On Thu, Dec 5, 2013 at 1:32 PM, Alex Ough <al...@sungard.com> wrote:
>>> All,
>>>
>>> I submitted the review request, so please review it and let me know if
>>>there
>>> is anything missing/incorrect.
>>>
>>> Thanks
>>> Alex Ough
>>>
>>>
>>> On Wed, Dec 4, 2013 at 11:29 PM, Murali Reddy <Mu...@citrix.com>
>>>
>>> wrote:
>>>>
>>>> On 05/12/13 12:01 AM, "Alex Ough" <al...@sungard.com> wrote:
>>>>
>>>> >All,
>>>> >
>>>> >I made a comment on its jira,
>>>>
>>>>>CLOUDSTACK-3190<https://issues.apache.org/jira/browse/CLOUDSTACK-3190>,
>>>>>
>>>> >so can anyone confirm what I found?
>>>> >I guess it is related with some refactoring related with
>>>>'CallContext'
>>>> >class.
>>>>
>>>> Alex,
>>>>
>>>> Yes, it regressed during shift from UserContext to CallContext. Please
>>>>go
>>>> ahead with changes
>>>>
>>>> >
>>>> >If correct, I'd like make changes because it is a blocker of what I'm
>>>>
>>>> >working on for
>>>>
>>>>>CLOUDSTACK-4992<https://issues.apache.org/jira/browse/CLOUDSTACK-4992>
>>>>>
>>>> >.
>>>> >
>>>> >Thanks
>>>> >Alex Ough
>>>> >
>>>> >
>>>> >On Wed, Nov 20, 2013 at 1:37 PM, Nitin Mehta <Ni...@citrix.com>
>>>>
>>>> >wrote:
>>>> >
>>>> >> David - CallContext gets created during the entry point of the API.
>>>>
>>>> >> I haven't had the chance to completely investigate but I am hoping
>>>>that
>>>> >> you can push the UUID then or on completion of the API (in case
>>>>where
>>>> >>you
>>>> >> are creating the actual resource).
>>>> >> See if that works else there is no other way out.
>>>> >>
>>>> >> Another feedback on Rabbit MQ would be to push the list of all the
>>>> >> first
>>>> >> class objects (UUIDs) that are affected in the event description if
>>>>
>>>> >> possible. Say user invokes attachVolume to a vm. It would be good
>>>>to
>>>> >> always push vm uuid.
>>>> >> Just putting in the volume uuid necessitates another call to CS and
>>>>
>>>> >> also
>>>> >> that this was attach volume operation.
>>>> >>
>>>> >> Thanks,
>>>> >> -Nitin
>>>> >>
>>>> >> On 20/11/13 8:23 AM, "David Grizzanti"
>>>><da...@sungard.com>
>>>> >> wrote:
>>>> >>
>>>> >> >Thanks for the feedback and info on the existing bug filed for
>>>>this.
>>>> >> >
>>>> >> >Nitin - I was originally thinking along the lines of what Murali
>>>>has
>>>> >> >recently commented (i.e. adding Entity Details in the UserContext
>>>>in
>>>> >>all
>>>> >> >the places where an Action Event is generated). The particular
>>>>case I
>>>> >> >was using this for when I found the issue was for creating a
>>>>network,
>>>> >> >which is not an async job. The AsyncJobManager I believe it
>>>> >>generating a
>>>> >> >different type of event that what I was originally looking at.
>>>> >> >
>>>> >> >Let me know your thoughts.
>>>> >> >
>>>> >> >Thanks
>>>> >> >
>>>> >> >--
>>>> >> >David Grizzanti
>>>> >> >Software Engineer
>>>> >> >Sungard Availability Services
>>>> >> >
>>>> >> >e: david.grizzanti@sungard.com
>>>> >> >w: 215.446.1431
>>>> >> >c: 570.575.0315
>>>> >> >
>>>> >> >On November 20, 2013 at 2:45:50 AM, Murali Reddy
>>>> >> >(murali.reddy@citrix.com) wrote:
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >On 20/11/13 2:15 AM, "David Grizzanti"
>>>><da...@sungard.com>
>>>> >> >wrote:
>>>> >> >
>>>> >> >>Hi All,
>>>> >> >>
>>>> >> >>I noticed that the event messages going to rabbitmq of type
>>>> >> >>"ActionEvent"
>>>> >> >>are missing any reference to the entity Id/UUID. Was this
>>>>omission
>>>> >> >>intentional? Poking through the code, I was able to find that
>>>>adding
>>>> >>the
>>>> >> >>
>>>> >> >>information on to the event is fairly straightforward (albeit a
>>>>bit
>>>> >> >>tedious). Does anyone have any objections to updating these event
>>>>
>>>> >>types
>>>> >> >>with this information? I can file the appropriate Jira, but
>>>>wanted to
>>>> >> >>check in with the list first to get opinions.
>>>> >> >
>>>> >> >David,
>>>> >> >
>>>> >> >Omission is not intentional. Please see [1] for earlier
>>>>discussion.
>>>> >>There
>>>> >> >
>>>> >> >is a bug opened as well[2].
>>>> >> >
>>>> >> >If you see ActionEventUtils, there is code that gets 'entity type'
>>>>and
>>>> >> >'entity uuid' from the CallContext and fills the details on the
>>>> >> > message
>>>> >> >published. I added this as generic mechanism. Unfortunately, there
>>>>is
>>>> >>not
>>>> >> >
>>>> >> >a single place where if you populate the entity type and uuid in
>>>>the
>>>> >>call
>>>> >> >
>>>> >> >context then things would fall in place. So its tedious job of
>>>>adding
>>>> >>the
>>>> >> >
>>>> >> >entity type and uuid details to the call context to all the
>>>>methods
>>>> >> >annotated with 'ActionEvent', but other wise it is a much needed
>>>>fix.
>>>> >> >
>>>> >> >[1]
>>>> >> >
>>>> >>
>>>>
>>>> >>
>>>>>>http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201306.mbox/%3
>>>>>>CCD
>>>> >>F
>>>> >> >1
>>>> >> >DB6A.424D9%25murali.reddy@citrix.com%3E
>>>> >> >[2] https://issues.apache.org/jira/browse/CLOUDSTACK-3190
>>>> >> >
>>>> >> >
>>>> >> >> Example event for network creation below.
>>>> >> >>
>>>> >> >>Thanks
>>>> >> >>
>>>> >> >>----------
>>>> >> >>@source="management-server", @type="ActionEvent",
>>>> >> >>@action="NETWORK-CREATE", @resource_type="Network",
>>>>@resource_id="*">
>>>> >> >>{
>>>> >> >> "status": "Completed",
>>>> >> >> "event": "NETWORK.CREATE",
>>>> >> >> "account": "6d836cf8-47cd-11e3-a130-606d02c0c082",
>>>> >> >> "user": "6d838544-47cd-11e3-a130-606d02c0c082"
>>>> >> >>}
>>>> >> >>
>>>> >> >>--
>>>> >> >>David Grizzanti
>>>> >> >>Software Engineer
>>>> >> >>Sungard Availability Services
>>>> >> >>
>>>> >> >>e: david.grizzanti@sungard.com
>>>> >> >>w: 215.446.1431
>>>> >> >>c: 570.575.0315
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
>
Re: Entity UUID and Type missing on ActionEvent event
notifications
Posted by David Grizzanti <da...@sungard.com>.
Alex,
That may be true for master when UserContext was replaced. But, on 4.2.0 when UserContext is still in use, the UUIDs are missing.
ActionEventUtils does pull the entity uuid and types to send on to the publishOnEventBus, but those variables are never being set to anything in UserContext/CallContext - they are NULL.
--
David Grizzanti
Software Engineer
Sungard Availability Services
e: david.grizzanti@sungard.com
w: 215.446.1431
c: 570.575.0315
On December 12, 2013 at 11:23:13 PM, Alex Ough (alex.ough@sungard.com) wrote:
David,
I'm not sure if this is correct, but wasn't 'UserContext' switched
with 'CallContext', which caused the missing UUIDs for
Domain/Account/User?
And if you see '/server/src/com/cloud/event/ActionEventUtils' class,
it accesses 'CallContext' to store the entity uuids and types in
'publishOnEventBus' method.
Correct me if I'm wrong.
Thanks
Alex Ough
On Thu, Dec 12, 2013 at 10:46 AM, David Grizzanti
<da...@sungard.com> wrote:
> Murali/All,
>
> Opening this discussion back up to decide how to approach fixing this. I
> looked over what Nitin mentioned, but given that I don't know a whole lot
> about the inner working of the code I don't see anywhere that it would make
> sense to put this logic so that it applies to all API commands. At the
> outset of the API command where UserContext/CallContext get initialized, the
> resource is not created yet (for Creation cases, so it doesn't yet have a
> UUID). At the completion of the API command, the Action Event has already
> been generated.
>
> It seems that there are already places where details are being added to the
> UserContext in implementation classes:
> server/src/com/cloud/projects/ProjectManagerImpl.java:
> UserContext.current().setEventDetails("Project id=" + project.getId());
>
> Let me know what other thoughts you may have, otherwise I'd like to proceed
> with adding a setEntityDetails call to each of the places where
> setEventDetails are placed to accomplish this.
>
> --
> David Grizzanti
> Software Engineer
> Sungard Availability Services
>
> e: david.grizzanti@sungard.com
> w: 215.446.1431
> c: 570.575.0315
>
> On December 11, 2013 at 6:33:25 AM, Murali Reddy (murali.reddy@citrix.com)
> wrote:
>
> On 11/12/13 3:01 AM, "David Grizzanti" <da...@sungard.com> wrote:
>
>>Murali,
>>
>>I spoke with Alex regarding this issue and it appears there may have been
>>some mix up in what the original intent of the bug was and what actually
>>got fixed. To me, the idea behind this was to address the bug that the
>>entity UUID was not getting added to ActionEvents for all resource types.
>> When I looked at this fix today and spoke with Alex, I think what was
>>fixed was only for accounts/users/domains.
>
> David,
>
> You are right. Original intent of the bug is to fix all the action events
> corresponding to all entities. I added a mechanism to persist the entity
> type and entity UUID into the CallContext/UserContext, these details are
> retrieved in the action event interceptor and published on to the event
> bus. Unfortunately there is no single place where we can persist entity
> UUID & type in the CallContext, so that all the action events are taken
> care automatically. So in 4.2 for account/user/domain sync across the
> zones for regions feature, I just fixed action events related to these
> three entities. There was regression in 4.3, which Alex's fix will fix it.
> But generally original intent of the bug 3190 is not fixed yet. May its
> better we open a different bug, as wrong commits went in to the bug.
>
> Thanks,
> Murali
>
>>
>>Not sure where the break down happened, but was wondering how you thought
>>we should address this? Open a new Jira to track the changes given the
>>history of the existing one or re-open
>>https://issues.apache.org/jira/browse/CLOUDSTACK-3190?
>>
>>Thanks
>>
>>--
>>David Grizzanti
>>Software Engineer
>>Sungard Availability Services
>>
>>e: david.grizzanti@sungard.com
>>w: 215.446.1431
>>c: 570.575.0315
>>
>>On December 6, 2013 at 4:26:40 PM, Alex Ough (alex.ough@sungard.com)
>>wrote:
>>
>>I modified the fix to make a little simpler, so can you review it please?
>>
>>
>>I'd like to finalize this as soon as possible to move on with
>>CLOUDSTACK-4992.
>>
>>Thanks
>>Alex Ough
>>
>>On Thu, Dec 5, 2013 at 1:32 PM, Alex Ough <al...@sungard.com> wrote:
>>> All,
>>>
>>> I submitted the review request, so please review it and let me know if
>>>there
>>> is anything missing/incorrect.
>>>
>>> Thanks
>>> Alex Ough
>>>
>>>
>>> On Wed, Dec 4, 2013 at 11:29 PM, Murali Reddy <Mu...@citrix.com>
>>>
>>> wrote:
>>>>
>>>> On 05/12/13 12:01 AM, "Alex Ough" <al...@sungard.com> wrote:
>>>>
>>>> >All,
>>>> >
>>>> >I made a comment on its jira,
>>>>
>>>>>CLOUDSTACK-3190<https://issues.apache.org/jira/browse/CLOUDSTACK-3190>,
>>>>>
>>>> >so can anyone confirm what I found?
>>>> >I guess it is related with some refactoring related with
>>>>'CallContext'
>>>> >class.
>>>>
>>>> Alex,
>>>>
>>>> Yes, it regressed during shift from UserContext to CallContext. Please
>>>>go
>>>> ahead with changes
>>>>
>>>> >
>>>> >If correct, I'd like make changes because it is a blocker of what I'm
>>>>
>>>> >working on for
>>>>
>>>>>CLOUDSTACK-4992<https://issues.apache.org/jira/browse/CLOUDSTACK-4992>
>>>>>
>>>> >.
>>>> >
>>>> >Thanks
>>>> >Alex Ough
>>>> >
>>>> >
>>>> >On Wed, Nov 20, 2013 at 1:37 PM, Nitin Mehta <Ni...@citrix.com>
>>>>
>>>> >wrote:
>>>> >
>>>> >> David - CallContext gets created during the entry point of the API.
>>>>
>>>> >> I haven't had the chance to completely investigate but I am hoping
>>>>that
>>>> >> you can push the UUID then or on completion of the API (in case
>>>>where
>>>> >>you
>>>> >> are creating the actual resource).
>>>> >> See if that works else there is no other way out.
>>>> >>
>>>> >> Another feedback on Rabbit MQ would be to push the list of all the
>>>> >> first
>>>> >> class objects (UUIDs) that are affected in the event description if
>>>>
>>>> >> possible. Say user invokes attachVolume to a vm. It would be good
>>>>to
>>>> >> always push vm uuid.
>>>> >> Just putting in the volume uuid necessitates another call to CS and
>>>>
>>>> >> also
>>>> >> that this was attach volume operation.
>>>> >>
>>>> >> Thanks,
>>>> >> -Nitin
>>>> >>
>>>> >> On 20/11/13 8:23 AM, "David Grizzanti"
>>>><da...@sungard.com>
>>>> >> wrote:
>>>> >>
>>>> >> >Thanks for the feedback and info on the existing bug filed for
>>>>this.
>>>> >> >
>>>> >> >Nitin - I was originally thinking along the lines of what Murali
>>>>has
>>>> >> >recently commented (i.e. adding Entity Details in the UserContext
>>>>in
>>>> >>all
>>>> >> >the places where an Action Event is generated). The particular
>>>>case I
>>>> >> >was using this for when I found the issue was for creating a
>>>>network,
>>>> >> >which is not an async job. The AsyncJobManager I believe it
>>>> >>generating a
>>>> >> >different type of event that what I was originally looking at.
>>>> >> >
>>>> >> >Let me know your thoughts.
>>>> >> >
>>>> >> >Thanks
>>>> >> >
>>>> >> >--
>>>> >> >David Grizzanti
>>>> >> >Software Engineer
>>>> >> >Sungard Availability Services
>>>> >> >
>>>> >> >e: david.grizzanti@sungard.com
>>>> >> >w: 215.446.1431
>>>> >> >c: 570.575.0315
>>>> >> >
>>>> >> >On November 20, 2013 at 2:45:50 AM, Murali Reddy
>>>> >> >(murali.reddy@citrix.com) wrote:
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >On 20/11/13 2:15 AM, "David Grizzanti"
>>>><da...@sungard.com>
>>>> >> >wrote:
>>>> >> >
>>>> >> >>Hi All,
>>>> >> >>
>>>> >> >>I noticed that the event messages going to rabbitmq of type
>>>> >> >>"ActionEvent"
>>>> >> >>are missing any reference to the entity Id/UUID. Was this
>>>>omission
>>>> >> >>intentional? Poking through the code, I was able to find that
>>>>adding
>>>> >>the
>>>> >> >>
>>>> >> >>information on to the event is fairly straightforward (albeit a
>>>>bit
>>>> >> >>tedious). Does anyone have any objections to updating these event
>>>>
>>>> >>types
>>>> >> >>with this information? I can file the appropriate Jira, but
>>>>wanted to
>>>> >> >>check in with the list first to get opinions.
>>>> >> >
>>>> >> >David,
>>>> >> >
>>>> >> >Omission is not intentional. Please see [1] for earlier
>>>>discussion.
>>>> >>There
>>>> >> >
>>>> >> >is a bug opened as well[2].
>>>> >> >
>>>> >> >If you see ActionEventUtils, there is code that gets 'entity type'
>>>>and
>>>> >> >'entity uuid' from the CallContext and fills the details on the
>>>> >> > message
>>>> >> >published. I added this as generic mechanism. Unfortunately, there
>>>>is
>>>> >>not
>>>> >> >
>>>> >> >a single place where if you populate the entity type and uuid in
>>>>the
>>>> >>call
>>>> >> >
>>>> >> >context then things would fall in place. So its tedious job of
>>>>adding
>>>> >>the
>>>> >> >
>>>> >> >entity type and uuid details to the call context to all the
>>>>methods
>>>> >> >annotated with 'ActionEvent', but other wise it is a much needed
>>>>fix.
>>>> >> >
>>>> >> >[1]
>>>> >> >
>>>> >>
>>>>
>>>> >>
>>>>>>http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201306.mbox/%3
>>>>>>CCD
>>>> >>F
>>>> >> >1
>>>> >> >DB6A.424D9%25murali.reddy@citrix.com%3E
>>>> >> >[2] https://issues.apache.org/jira/browse/CLOUDSTACK-3190
>>>> >> >
>>>> >> >
>>>> >> >> Example event for network creation below.
>>>> >> >>
>>>> >> >>Thanks
>>>> >> >>
>>>> >> >>----------
>>>> >> >>@source="management-server", @type="ActionEvent",
>>>> >> >>@action="NETWORK-CREATE", @resource_type="Network",
>>>>@resource_id="*">
>>>> >> >>{
>>>> >> >> "status": "Completed",
>>>> >> >> "event": "NETWORK.CREATE",
>>>> >> >> "account": "6d836cf8-47cd-11e3-a130-606d02c0c082",
>>>> >> >> "user": "6d838544-47cd-11e3-a130-606d02c0c082"
>>>> >> >>}
>>>> >> >>
>>>> >> >>--
>>>> >> >>David Grizzanti
>>>> >> >>Software Engineer
>>>> >> >>Sungard Availability Services
>>>> >> >>
>>>> >> >>e: david.grizzanti@sungard.com
>>>> >> >>w: 215.446.1431
>>>> >> >>c: 570.575.0315
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
>
Re: Entity UUID and Type missing on ActionEvent event notifications
Posted by Alex Ough <al...@sungard.com>.
David,
I'm not sure if this is correct, but wasn't 'UserContext' switched
with 'CallContext', which caused the missing UUIDs for
Domain/Account/User?
And if you see '/server/src/com/cloud/event/ActionEventUtils' class,
it accesses 'CallContext' to store the entity uuids and types in
'publishOnEventBus' method.
Correct me if I'm wrong.
Thanks
Alex Ough
On Thu, Dec 12, 2013 at 10:46 AM, David Grizzanti
<da...@sungard.com> wrote:
> Murali/All,
>
> Opening this discussion back up to decide how to approach fixing this. I
> looked over what Nitin mentioned, but given that I don't know a whole lot
> about the inner working of the code I don't see anywhere that it would make
> sense to put this logic so that it applies to all API commands. At the
> outset of the API command where UserContext/CallContext get initialized, the
> resource is not created yet (for Creation cases, so it doesn't yet have a
> UUID). At the completion of the API command, the Action Event has already
> been generated.
>
> It seems that there are already places where details are being added to the
> UserContext in implementation classes:
> server/src/com/cloud/projects/ProjectManagerImpl.java:
> UserContext.current().setEventDetails("Project id=" + project.getId());
>
> Let me know what other thoughts you may have, otherwise I'd like to proceed
> with adding a setEntityDetails call to each of the places where
> setEventDetails are placed to accomplish this.
>
> --
> David Grizzanti
> Software Engineer
> Sungard Availability Services
>
> e: david.grizzanti@sungard.com
> w: 215.446.1431
> c: 570.575.0315
>
> On December 11, 2013 at 6:33:25 AM, Murali Reddy (murali.reddy@citrix.com)
> wrote:
>
> On 11/12/13 3:01 AM, "David Grizzanti" <da...@sungard.com> wrote:
>
>>Murali,
>>
>>I spoke with Alex regarding this issue and it appears there may have been
>>some mix up in what the original intent of the bug was and what actually
>>got fixed. To me, the idea behind this was to address the bug that the
>>entity UUID was not getting added to ActionEvents for all resource types.
>> When I looked at this fix today and spoke with Alex, I think what was
>>fixed was only for accounts/users/domains.
>
> David,
>
> You are right. Original intent of the bug is to fix all the action events
> corresponding to all entities. I added a mechanism to persist the entity
> type and entity UUID into the CallContext/UserContext, these details are
> retrieved in the action event interceptor and published on to the event
> bus. Unfortunately there is no single place where we can persist entity
> UUID & type in the CallContext, so that all the action events are taken
> care automatically. So in 4.2 for account/user/domain sync across the
> zones for regions feature, I just fixed action events related to these
> three entities. There was regression in 4.3, which Alex's fix will fix it.
> But generally original intent of the bug 3190 is not fixed yet. May its
> better we open a different bug, as wrong commits went in to the bug.
>
> Thanks,
> Murali
>
>>
>>Not sure where the break down happened, but was wondering how you thought
>>we should address this? Open a new Jira to track the changes given the
>>history of the existing one or re-open
>>https://issues.apache.org/jira/browse/CLOUDSTACK-3190?
>>
>>Thanks
>>
>>--
>>David Grizzanti
>>Software Engineer
>>Sungard Availability Services
>>
>>e: david.grizzanti@sungard.com
>>w: 215.446.1431
>>c: 570.575.0315
>>
>>On December 6, 2013 at 4:26:40 PM, Alex Ough (alex.ough@sungard.com)
>>wrote:
>>
>>I modified the fix to make a little simpler, so can you review it please?
>>
>>
>>I'd like to finalize this as soon as possible to move on with
>>CLOUDSTACK-4992.
>>
>>Thanks
>>Alex Ough
>>
>>On Thu, Dec 5, 2013 at 1:32 PM, Alex Ough <al...@sungard.com> wrote:
>>> All,
>>>
>>> I submitted the review request, so please review it and let me know if
>>>there
>>> is anything missing/incorrect.
>>>
>>> Thanks
>>> Alex Ough
>>>
>>>
>>> On Wed, Dec 4, 2013 at 11:29 PM, Murali Reddy <Mu...@citrix.com>
>>>
>>> wrote:
>>>>
>>>> On 05/12/13 12:01 AM, "Alex Ough" <al...@sungard.com> wrote:
>>>>
>>>> >All,
>>>> >
>>>> >I made a comment on its jira,
>>>>
>>>>>CLOUDSTACK-3190<https://issues.apache.org/jira/browse/CLOUDSTACK-3190>,
>>>>>
>>>> >so can anyone confirm what I found?
>>>> >I guess it is related with some refactoring related with
>>>>'CallContext'
>>>> >class.
>>>>
>>>> Alex,
>>>>
>>>> Yes, it regressed during shift from UserContext to CallContext. Please
>>>>go
>>>> ahead with changes
>>>>
>>>> >
>>>> >If correct, I'd like make changes because it is a blocker of what I'm
>>>>
>>>> >working on for
>>>>
>>>>>CLOUDSTACK-4992<https://issues.apache.org/jira/browse/CLOUDSTACK-4992>
>>>>>
>>>> >.
>>>> >
>>>> >Thanks
>>>> >Alex Ough
>>>> >
>>>> >
>>>> >On Wed, Nov 20, 2013 at 1:37 PM, Nitin Mehta <Ni...@citrix.com>
>>>>
>>>> >wrote:
>>>> >
>>>> >> David - CallContext gets created during the entry point of the API.
>>>>
>>>> >> I haven't had the chance to completely investigate but I am hoping
>>>>that
>>>> >> you can push the UUID then or on completion of the API (in case
>>>>where
>>>> >>you
>>>> >> are creating the actual resource).
>>>> >> See if that works else there is no other way out.
>>>> >>
>>>> >> Another feedback on Rabbit MQ would be to push the list of all the
>>>> >> first
>>>> >> class objects (UUIDs) that are affected in the event description if
>>>>
>>>> >> possible. Say user invokes attachVolume to a vm. It would be good
>>>>to
>>>> >> always push vm uuid.
>>>> >> Just putting in the volume uuid necessitates another call to CS and
>>>>
>>>> >> also
>>>> >> that this was attach volume operation.
>>>> >>
>>>> >> Thanks,
>>>> >> -Nitin
>>>> >>
>>>> >> On 20/11/13 8:23 AM, "David Grizzanti"
>>>><da...@sungard.com>
>>>> >> wrote:
>>>> >>
>>>> >> >Thanks for the feedback and info on the existing bug filed for
>>>>this.
>>>> >> >
>>>> >> >Nitin - I was originally thinking along the lines of what Murali
>>>>has
>>>> >> >recently commented (i.e. adding Entity Details in the UserContext
>>>>in
>>>> >>all
>>>> >> >the places where an Action Event is generated). The particular
>>>>case I
>>>> >> >was using this for when I found the issue was for creating a
>>>>network,
>>>> >> >which is not an async job. The AsyncJobManager I believe it
>>>> >>generating a
>>>> >> >different type of event that what I was originally looking at.
>>>> >> >
>>>> >> >Let me know your thoughts.
>>>> >> >
>>>> >> >Thanks
>>>> >> >
>>>> >> >--
>>>> >> >David Grizzanti
>>>> >> >Software Engineer
>>>> >> >Sungard Availability Services
>>>> >> >
>>>> >> >e: david.grizzanti@sungard.com
>>>> >> >w: 215.446.1431
>>>> >> >c: 570.575.0315
>>>> >> >
>>>> >> >On November 20, 2013 at 2:45:50 AM, Murali Reddy
>>>> >> >(murali.reddy@citrix.com) wrote:
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >On 20/11/13 2:15 AM, "David Grizzanti"
>>>><da...@sungard.com>
>>>> >> >wrote:
>>>> >> >
>>>> >> >>Hi All,
>>>> >> >>
>>>> >> >>I noticed that the event messages going to rabbitmq of type
>>>> >> >>"ActionEvent"
>>>> >> >>are missing any reference to the entity Id/UUID. Was this
>>>>omission
>>>> >> >>intentional? Poking through the code, I was able to find that
>>>>adding
>>>> >>the
>>>> >> >>
>>>> >> >>information on to the event is fairly straightforward (albeit a
>>>>bit
>>>> >> >>tedious). Does anyone have any objections to updating these event
>>>>
>>>> >>types
>>>> >> >>with this information? I can file the appropriate Jira, but
>>>>wanted to
>>>> >> >>check in with the list first to get opinions.
>>>> >> >
>>>> >> >David,
>>>> >> >
>>>> >> >Omission is not intentional. Please see [1] for earlier
>>>>discussion.
>>>> >>There
>>>> >> >
>>>> >> >is a bug opened as well[2].
>>>> >> >
>>>> >> >If you see ActionEventUtils, there is code that gets 'entity type'
>>>>and
>>>> >> >'entity uuid' from the CallContext and fills the details on the
>>>> >> > message
>>>> >> >published. I added this as generic mechanism. Unfortunately, there
>>>>is
>>>> >>not
>>>> >> >
>>>> >> >a single place where if you populate the entity type and uuid in
>>>>the
>>>> >>call
>>>> >> >
>>>> >> >context then things would fall in place. So its tedious job of
>>>>adding
>>>> >>the
>>>> >> >
>>>> >> >entity type and uuid details to the call context to all the
>>>>methods
>>>> >> >annotated with 'ActionEvent', but other wise it is a much needed
>>>>fix.
>>>> >> >
>>>> >> >[1]
>>>> >> >
>>>> >>
>>>>
>>>> >>
>>>>>>http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201306.mbox/%3
>>>>>>CCD
>>>> >>F
>>>> >> >1
>>>> >> >DB6A.424D9%25murali.reddy@citrix.com%3E
>>>> >> >[2] https://issues.apache.org/jira/browse/CLOUDSTACK-3190
>>>> >> >
>>>> >> >
>>>> >> >> Example event for network creation below.
>>>> >> >>
>>>> >> >>Thanks
>>>> >> >>
>>>> >> >>----------
>>>> >> >>@source="management-server", @type="ActionEvent",
>>>> >> >>@action="NETWORK-CREATE", @resource_type="Network",
>>>>@resource_id="*">
>>>> >> >>{
>>>> >> >> "status": "Completed",
>>>> >> >> "event": "NETWORK.CREATE",
>>>> >> >> "account": "6d836cf8-47cd-11e3-a130-606d02c0c082",
>>>> >> >> "user": "6d838544-47cd-11e3-a130-606d02c0c082"
>>>> >> >>}
>>>> >> >>
>>>> >> >>--
>>>> >> >>David Grizzanti
>>>> >> >>Software Engineer
>>>> >> >>Sungard Availability Services
>>>> >> >>
>>>> >> >>e: david.grizzanti@sungard.com
>>>> >> >>w: 215.446.1431
>>>> >> >>c: 570.575.0315
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
>
Re: Entity UUID and Type missing on ActionEvent event notifications
Posted by Murali Reddy <Mu...@citrix.com>.
David,
Your analysis is right. There is no single place to put logic which will fix all api commands. So adding setEntityDetails call on each of the method that is annotated with ActionEvent is right approach.
Thanks,
Murali
From: David Grizzanti <da...@sungard.com>>
Date: Thursday, 12 December 2013 10:16 PM
To: Murali Reddy <mu...@citrix.com>>, "dev@cloudstack.apache.org<ma...@cloudstack.apache.org>" <de...@cloudstack.apache.org>>, Alex Ough <al...@sungard.com>>, Nitin Mehta <Ni...@citrix.com>>
Subject: Re: Entity UUID and Type missing on ActionEvent event notifications
Murali/All,
Opening this discussion back up to decide how to approach fixing this. I looked over what Nitin mentioned, but given that I don't know a whole lot about the inner working of the code I don't see anywhere that it would make sense to put this logic so that it applies to all API commands. At the outset of the API command where UserContext/CallContext get initialized, the resource is not created yet (for Creation cases, so it doesn't yet have a UUID). At the completion of the API command, the Action Event has already been generated.
It seems that there are already places where details are being added to the UserContext in implementation classes:
server/src/com/cloud/projects/ProjectManagerImpl.java: UserContext.current().setEventDetails("Project id=" + project.getId());
Let me know what other thoughts you may have, otherwise I'd like to proceed with adding a setEntityDetails call to each of the places where setEventDetails are placed to accomplish this.
--
David Grizzanti
Software Engineer
Sungard Availability Services
e: david.grizzanti@sungard.com<ma...@sungard.com>
w: 215.446.1431
c: 570.575.0315
On December 11, 2013 at 6:33:25 AM, Murali Reddy (murali.reddy@citrix.com<ma...@citrix.com>) wrote:
On 11/12/13 3:01 AM, "David Grizzanti" <da...@sungard.com>> wrote:
>Murali,
>
>I spoke with Alex regarding this issue and it appears there may have been
>some mix up in what the original intent of the bug was and what actually
>got fixed. To me, the idea behind this was to address the bug that the
>entity UUID was not getting added to ActionEvents for all resource types.
> When I looked at this fix today and spoke with Alex, I think what was
>fixed was only for accounts/users/domains.
David,
You are right. Original intent of the bug is to fix all the action events
corresponding to all entities. I added a mechanism to persist the entity
type and entity UUID into the CallContext/UserContext, these details are
retrieved in the action event interceptor and published on to the event
bus. Unfortunately there is no single place where we can persist entity
UUID & type in the CallContext, so that all the action events are taken
care automatically. So in 4.2 for account/user/domain sync across the
zones for regions feature, I just fixed action events related to these
three entities. There was regression in 4.3, which Alex's fix will fix it.
But generally original intent of the bug 3190 is not fixed yet. May its
better we open a different bug, as wrong commits went in to the bug.
Thanks,
Murali
>
>Not sure where the break down happened, but was wondering how you thought
>we should address this? Open a new Jira to track the changes given the
>history of the existing one or re-open
>https://issues.apache.org/jira/browse/CLOUDSTACK-3190?
>
>Thanks
>
>--
>David Grizzanti
>Software Engineer
>Sungard Availability Services
>
>e: david.grizzanti@sungard.com<ma...@sungard.com>
>w: 215.446.1431
>c: 570.575.0315
>
>On December 6, 2013 at 4:26:40 PM, Alex Ough (alex.ough@sungard.com<ma...@sungard.com>)
>wrote:
>
>I modified the fix to make a little simpler, so can you review it please?
>
>
>I'd like to finalize this as soon as possible to move on with
>CLOUDSTACK-4992.
>
>Thanks
>Alex Ough
>
>On Thu, Dec 5, 2013 at 1:32 PM, Alex Ough <al...@sungard.com>> wrote:
>> All,
>>
>> I submitted the review request, so please review it and let me know if
>>there
>> is anything missing/incorrect.
>>
>> Thanks
>> Alex Ough
>>
>>
>> On Wed, Dec 4, 2013 at 11:29 PM, Murali Reddy <Mu...@citrix.com>>
>>
>> wrote:
>>>
>>> On 05/12/13 12:01 AM, "Alex Ough" <al...@sungard.com>> wrote:
>>>
>>> >All,
>>> >
>>> >I made a comment on its jira,
>>>
>>>>CLOUDSTACK-3190<https://issues.apache.org/jira/browse/CLOUDSTACK-3190>,
>>>>
>>> >so can anyone confirm what I found?
>>> >I guess it is related with some refactoring related with
>>>'CallContext'
>>> >class.
>>>
>>> Alex,
>>>
>>> Yes, it regressed during shift from UserContext to CallContext. Please
>>>go
>>> ahead with changes
>>>
>>> >
>>> >If correct, I'd like make changes because it is a blocker of what I'm
>>>
>>> >working on for
>>>
>>>>CLOUDSTACK-4992<https://issues.apache.org/jira/browse/CLOUDSTACK-4992>
>>>>
>>> >.
>>> >
>>> >Thanks
>>> >Alex Ough
>>> >
>>> >
>>> >On Wed, Nov 20, 2013 at 1:37 PM, Nitin Mehta <Ni...@citrix.com>>
>>>
>>> >wrote:
>>> >
>>> >> David - CallContext gets created during the entry point of the API.
>>>
>>> >> I haven't had the chance to completely investigate but I am hoping
>>>that
>>> >> you can push the UUID then or on completion of the API (in case
>>>where
>>> >>you
>>> >> are creating the actual resource).
>>> >> See if that works else there is no other way out.
>>> >>
>>> >> Another feedback on Rabbit MQ would be to push the list of all the
>>> >> first
>>> >> class objects (UUIDs) that are affected in the event description if
>>>
>>> >> possible. Say user invokes attachVolume to a vm. It would be good
>>>to
>>> >> always push vm uuid.
>>> >> Just putting in the volume uuid necessitates another call to CS and
>>>
>>> >> also
>>> >> that this was attach volume operation.
>>> >>
>>> >> Thanks,
>>> >> -Nitin
>>> >>
>>> >> On 20/11/13 8:23 AM, "David Grizzanti"
>>><da...@sungard.com>>
>>> >> wrote:
>>> >>
>>> >> >Thanks for the feedback and info on the existing bug filed for
>>>this.
>>> >> >
>>> >> >Nitin - I was originally thinking along the lines of what Murali
>>>has
>>> >> >recently commented (i.e. adding Entity Details in the UserContext
>>>in
>>> >>all
>>> >> >the places where an Action Event is generated). The particular
>>>case I
>>> >> >was using this for when I found the issue was for creating a
>>>network,
>>> >> >which is not an async job. The AsyncJobManager I believe it
>>> >>generating a
>>> >> >different type of event that what I was originally looking at.
>>> >> >
>>> >> >Let me know your thoughts.
>>> >> >
>>> >> >Thanks
>>> >> >
>>> >> >--
>>> >> >David Grizzanti
>>> >> >Software Engineer
>>> >> >Sungard Availability Services
>>> >> >
>>> >> >e: david.grizzanti@sungard.com<ma...@sungard.com>
>>> >> >w: 215.446.1431
>>> >> >c: 570.575.0315
>>> >> >
>>> >> >On November 20, 2013 at 2:45:50 AM, Murali Reddy
>>> >> >(murali.reddy@citrix.com<ma...@citrix.com>) wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> >On 20/11/13 2:15 AM, "David Grizzanti"
>>><da...@sungard.com>>
>>> >> >wrote:
>>> >> >
>>> >> >>Hi All,
>>> >> >>
>>> >> >>I noticed that the event messages going to rabbitmq of type
>>> >> >>"ActionEvent"
>>> >> >>are missing any reference to the entity Id/UUID. Was this
>>>omission
>>> >> >>intentional? Poking through the code, I was able to find that
>>>adding
>>> >>the
>>> >> >>
>>> >> >>information on to the event is fairly straightforward (albeit a
>>>bit
>>> >> >>tedious). Does anyone have any objections to updating these event
>>>
>>> >>types
>>> >> >>with this information? I can file the appropriate Jira, but
>>>wanted to
>>> >> >>check in with the list first to get opinions.
>>> >> >
>>> >> >David,
>>> >> >
>>> >> >Omission is not intentional. Please see [1] for earlier
>>>discussion.
>>> >>There
>>> >> >
>>> >> >is a bug opened as well[2].
>>> >> >
>>> >> >If you see ActionEventUtils, there is code that gets 'entity type'
>>>and
>>> >> >'entity uuid' from the CallContext and fills the details on the
>>> >> > message
>>> >> >published. I added this as generic mechanism. Unfortunately, there
>>>is
>>> >>not
>>> >> >
>>> >> >a single place where if you populate the entity type and uuid in
>>>the
>>> >>call
>>> >> >
>>> >> >context then things would fall in place. So its tedious job of
>>>adding
>>> >>the
>>> >> >
>>> >> >entity type and uuid details to the call context to all the
>>>methods
>>> >> >annotated with 'ActionEvent', but other wise it is a much needed
>>>fix.
>>> >> >
>>> >> >[1]
>>> >> >
>>> >>
>>>
>>> >>
>>>>>http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201306.mbox/%3
>>>>>CCD
>>> >>F
>>> >> >1
>>> >> >DB6A.424D9%25murali.reddy@citrix.com%3E<mailto:DB6A.424D9%25murali.reddy@citrix.com%3E>
>>> >> >[2] https://issues.apache.org/jira/browse/CLOUDSTACK-3190
>>> >> >
>>> >> >
>>> >> >> Example event for network creation below.
>>> >> >>
>>> >> >>Thanks
>>> >> >>
>>> >> >>----------
>>> >> >>@source="management-server", @type="ActionEvent",
>>> >> >>@action="NETWORK-CREATE", @resource_type="Network",
>>>@resource_id="*">
>>> >> >>{
>>> >> >> "status": "Completed",
>>> >> >> "event": "NETWORK.CREATE",
>>> >> >> "account": "6d836cf8-47cd-11e3-a130-606d02c0c082",
>>> >> >> "user": "6d838544-47cd-11e3-a130-606d02c0c082"
>>> >> >>}
>>> >> >>
>>> >> >>--
>>> >> >>David Grizzanti
>>> >> >>Software Engineer
>>> >> >>Sungard Availability Services
>>> >> >>
>>> >> >>e: david.grizzanti@sungard.com<ma...@sungard.com>
>>> >> >>w: 215.446.1431
>>> >> >>c: 570.575.0315
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>
>
>
Re: Entity UUID and Type missing on ActionEvent event
notifications
Posted by David Grizzanti <da...@sungard.com>.
Murali/All,
Opening this discussion back up to decide how to approach fixing this. I looked over what Nitin mentioned, but given that I don't know a whole lot about the inner working of the code I don't see anywhere that it would make sense to put this logic so that it applies to all API commands. At the outset of the API command where UserContext/CallContext get initialized, the resource is not created yet (for Creation cases, so it doesn't yet have a UUID). At the completion of the API command, the Action Event has already been generated.
It seems that there are already places where details are being added to the UserContext in implementation classes:
server/src/com/cloud/projects/ProjectManagerImpl.java: UserContext.current().setEventDetails("Project id=" + project.getId());
Let me know what other thoughts you may have, otherwise I'd like to proceed with adding a setEntityDetails call to each of the places where setEventDetails are placed to accomplish this.
--
David Grizzanti
Software Engineer
Sungard Availability Services
e: david.grizzanti@sungard.com
w: 215.446.1431
c: 570.575.0315
On December 11, 2013 at 6:33:25 AM, Murali Reddy (murali.reddy@citrix.com) wrote:
On 11/12/13 3:01 AM, "David Grizzanti" <da...@sungard.com> wrote:
>Murali,
>
>I spoke with Alex regarding this issue and it appears there may have been
>some mix up in what the original intent of the bug was and what actually
>got fixed. To me, the idea behind this was to address the bug that the
>entity UUID was not getting added to ActionEvents for all resource types.
> When I looked at this fix today and spoke with Alex, I think what was
>fixed was only for accounts/users/domains.
David,
You are right. Original intent of the bug is to fix all the action events
corresponding to all entities. I added a mechanism to persist the entity
type and entity UUID into the CallContext/UserContext, these details are
retrieved in the action event interceptor and published on to the event
bus. Unfortunately there is no single place where we can persist entity
UUID & type in the CallContext, so that all the action events are taken
care automatically. So in 4.2 for account/user/domain sync across the
zones for regions feature, I just fixed action events related to these
three entities. There was regression in 4.3, which Alex's fix will fix it.
But generally original intent of the bug 3190 is not fixed yet. May its
better we open a different bug, as wrong commits went in to the bug.
Thanks,
Murali
>
>Not sure where the break down happened, but was wondering how you thought
>we should address this? Open a new Jira to track the changes given the
>history of the existing one or re-open
>https://issues.apache.org/jira/browse/CLOUDSTACK-3190?
>
>Thanks
>
>--
>David Grizzanti
>Software Engineer
>Sungard Availability Services
>
>e: david.grizzanti@sungard.com
>w: 215.446.1431
>c: 570.575.0315
>
>On December 6, 2013 at 4:26:40 PM, Alex Ough (alex.ough@sungard.com)
>wrote:
>
>I modified the fix to make a little simpler, so can you review it please?
>
>
>I'd like to finalize this as soon as possible to move on with
>CLOUDSTACK-4992.
>
>Thanks
>Alex Ough
>
>On Thu, Dec 5, 2013 at 1:32 PM, Alex Ough <al...@sungard.com> wrote:
>> All,
>>
>> I submitted the review request, so please review it and let me know if
>>there
>> is anything missing/incorrect.
>>
>> Thanks
>> Alex Ough
>>
>>
>> On Wed, Dec 4, 2013 at 11:29 PM, Murali Reddy <Mu...@citrix.com>
>>
>> wrote:
>>>
>>> On 05/12/13 12:01 AM, "Alex Ough" <al...@sungard.com> wrote:
>>>
>>> >All,
>>> >
>>> >I made a comment on its jira,
>>>
>>>>CLOUDSTACK-3190<https://issues.apache.org/jira/browse/CLOUDSTACK-3190>,
>>>>
>>> >so can anyone confirm what I found?
>>> >I guess it is related with some refactoring related with
>>>'CallContext'
>>> >class.
>>>
>>> Alex,
>>>
>>> Yes, it regressed during shift from UserContext to CallContext. Please
>>>go
>>> ahead with changes
>>>
>>> >
>>> >If correct, I'd like make changes because it is a blocker of what I'm
>>>
>>> >working on for
>>>
>>>>CLOUDSTACK-4992<https://issues.apache.org/jira/browse/CLOUDSTACK-4992>
>>>>
>>> >.
>>> >
>>> >Thanks
>>> >Alex Ough
>>> >
>>> >
>>> >On Wed, Nov 20, 2013 at 1:37 PM, Nitin Mehta <Ni...@citrix.com>
>>>
>>> >wrote:
>>> >
>>> >> David - CallContext gets created during the entry point of the API.
>>>
>>> >> I haven't had the chance to completely investigate but I am hoping
>>>that
>>> >> you can push the UUID then or on completion of the API (in case
>>>where
>>> >>you
>>> >> are creating the actual resource).
>>> >> See if that works else there is no other way out.
>>> >>
>>> >> Another feedback on Rabbit MQ would be to push the list of all the
>>> >> first
>>> >> class objects (UUIDs) that are affected in the event description if
>>>
>>> >> possible. Say user invokes attachVolume to a vm. It would be good
>>>to
>>> >> always push vm uuid.
>>> >> Just putting in the volume uuid necessitates another call to CS and
>>>
>>> >> also
>>> >> that this was attach volume operation.
>>> >>
>>> >> Thanks,
>>> >> -Nitin
>>> >>
>>> >> On 20/11/13 8:23 AM, "David Grizzanti"
>>><da...@sungard.com>
>>> >> wrote:
>>> >>
>>> >> >Thanks for the feedback and info on the existing bug filed for
>>>this.
>>> >> >
>>> >> >Nitin - I was originally thinking along the lines of what Murali
>>>has
>>> >> >recently commented (i.e. adding Entity Details in the UserContext
>>>in
>>> >>all
>>> >> >the places where an Action Event is generated). The particular
>>>case I
>>> >> >was using this for when I found the issue was for creating a
>>>network,
>>> >> >which is not an async job. The AsyncJobManager I believe it
>>> >>generating a
>>> >> >different type of event that what I was originally looking at.
>>> >> >
>>> >> >Let me know your thoughts.
>>> >> >
>>> >> >Thanks
>>> >> >
>>> >> >--
>>> >> >David Grizzanti
>>> >> >Software Engineer
>>> >> >Sungard Availability Services
>>> >> >
>>> >> >e: david.grizzanti@sungard.com
>>> >> >w: 215.446.1431
>>> >> >c: 570.575.0315
>>> >> >
>>> >> >On November 20, 2013 at 2:45:50 AM, Murali Reddy
>>> >> >(murali.reddy@citrix.com) wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> >On 20/11/13 2:15 AM, "David Grizzanti"
>>><da...@sungard.com>
>>> >> >wrote:
>>> >> >
>>> >> >>Hi All,
>>> >> >>
>>> >> >>I noticed that the event messages going to rabbitmq of type
>>> >> >>"ActionEvent"
>>> >> >>are missing any reference to the entity Id/UUID. Was this
>>>omission
>>> >> >>intentional? Poking through the code, I was able to find that
>>>adding
>>> >>the
>>> >> >>
>>> >> >>information on to the event is fairly straightforward (albeit a
>>>bit
>>> >> >>tedious). Does anyone have any objections to updating these event
>>>
>>> >>types
>>> >> >>with this information? I can file the appropriate Jira, but
>>>wanted to
>>> >> >>check in with the list first to get opinions.
>>> >> >
>>> >> >David,
>>> >> >
>>> >> >Omission is not intentional. Please see [1] for earlier
>>>discussion.
>>> >>There
>>> >> >
>>> >> >is a bug opened as well[2].
>>> >> >
>>> >> >If you see ActionEventUtils, there is code that gets 'entity type'
>>>and
>>> >> >'entity uuid' from the CallContext and fills the details on the
>>> >> > message
>>> >> >published. I added this as generic mechanism. Unfortunately, there
>>>is
>>> >>not
>>> >> >
>>> >> >a single place where if you populate the entity type and uuid in
>>>the
>>> >>call
>>> >> >
>>> >> >context then things would fall in place. So its tedious job of
>>>adding
>>> >>the
>>> >> >
>>> >> >entity type and uuid details to the call context to all the
>>>methods
>>> >> >annotated with 'ActionEvent', but other wise it is a much needed
>>>fix.
>>> >> >
>>> >> >[1]
>>> >> >
>>> >>
>>>
>>> >>
>>>>>http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201306.mbox/%3
>>>>>CCD
>>> >>F
>>> >> >1
>>> >> >DB6A.424D9%25murali.reddy@citrix.com%3E
>>> >> >[2] https://issues.apache.org/jira/browse/CLOUDSTACK-3190
>>> >> >
>>> >> >
>>> >> >> Example event for network creation below.
>>> >> >>
>>> >> >>Thanks
>>> >> >>
>>> >> >>----------
>>> >> >>@source="management-server", @type="ActionEvent",
>>> >> >>@action="NETWORK-CREATE", @resource_type="Network",
>>>@resource_id="*">
>>> >> >>{
>>> >> >> "status": "Completed",
>>> >> >> "event": "NETWORK.CREATE",
>>> >> >> "account": "6d836cf8-47cd-11e3-a130-606d02c0c082",
>>> >> >> "user": "6d838544-47cd-11e3-a130-606d02c0c082"
>>> >> >>}
>>> >> >>
>>> >> >>--
>>> >> >>David Grizzanti
>>> >> >>Software Engineer
>>> >> >>Sungard Availability Services
>>> >> >>
>>> >> >>e: david.grizzanti@sungard.com
>>> >> >>w: 215.446.1431
>>> >> >>c: 570.575.0315
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>
>
>
Re: Entity UUID and Type missing on ActionEvent event notifications
Posted by Murali Reddy <Mu...@citrix.com>.
On 11/12/13 3:01 AM, "David Grizzanti" <da...@sungard.com> wrote:
>Murali,
>
>I spoke with Alex regarding this issue and it appears there may have been
>some mix up in what the original intent of the bug was and what actually
>got fixed. To me, the idea behind this was to address the bug that the
>entity UUID was not getting added to ActionEvents for all resource types.
> When I looked at this fix today and spoke with Alex, I think what was
>fixed was only for accounts/users/domains.
David,
You are right. Original intent of the bug is to fix all the action events
corresponding to all entities. I added a mechanism to persist the entity
type and entity UUID into the CallContext/UserContext, these details are
retrieved in the action event interceptor and published on to the event
bus. Unfortunately there is no single place where we can persist entity
UUID & type in the CallContext, so that all the action events are taken
care automatically. So in 4.2 for account/user/domain sync across the
zones for regions feature, I just fixed action events related to these
three entities. There was regression in 4.3, which Alex's fix will fix it.
But generally original intent of the bug 3190 is not fixed yet. May its
better we open a different bug, as wrong commits went in to the bug.
Thanks,
Murali
>
>Not sure where the break down happened, but was wondering how you thought
>we should address this? Open a new Jira to track the changes given the
>history of the existing one or re-open
>https://issues.apache.org/jira/browse/CLOUDSTACK-3190?
>
>Thanks
>
>--
>David Grizzanti
>Software Engineer
>Sungard Availability Services
>
>e: david.grizzanti@sungard.com
>w: 215.446.1431
>c: 570.575.0315
>
>On December 6, 2013 at 4:26:40 PM, Alex Ough (alex.ough@sungard.com)
>wrote:
>
>I modified the fix to make a little simpler, so can you review it please?
>
>
>I'd like to finalize this as soon as possible to move on with
>CLOUDSTACK-4992.
>
>Thanks
>Alex Ough
>
>On Thu, Dec 5, 2013 at 1:32 PM, Alex Ough <al...@sungard.com> wrote:
>> All,
>>
>> I submitted the review request, so please review it and let me know if
>>there
>> is anything missing/incorrect.
>>
>> Thanks
>> Alex Ough
>>
>>
>> On Wed, Dec 4, 2013 at 11:29 PM, Murali Reddy <Mu...@citrix.com>
>>
>> wrote:
>>>
>>> On 05/12/13 12:01 AM, "Alex Ough" <al...@sungard.com> wrote:
>>>
>>> >All,
>>> >
>>> >I made a comment on its jira,
>>>
>>>>CLOUDSTACK-3190<https://issues.apache.org/jira/browse/CLOUDSTACK-3190>,
>>>>
>>> >so can anyone confirm what I found?
>>> >I guess it is related with some refactoring related with
>>>'CallContext'
>>> >class.
>>>
>>> Alex,
>>>
>>> Yes, it regressed during shift from UserContext to CallContext. Please
>>>go
>>> ahead with changes
>>>
>>> >
>>> >If correct, I'd like make changes because it is a blocker of what I'm
>>>
>>> >working on for
>>>
>>>>CLOUDSTACK-4992<https://issues.apache.org/jira/browse/CLOUDSTACK-4992>
>>>>
>>> >.
>>> >
>>> >Thanks
>>> >Alex Ough
>>> >
>>> >
>>> >On Wed, Nov 20, 2013 at 1:37 PM, Nitin Mehta <Ni...@citrix.com>
>>>
>>> >wrote:
>>> >
>>> >> David - CallContext gets created during the entry point of the API.
>>>
>>> >> I haven't had the chance to completely investigate but I am hoping
>>>that
>>> >> you can push the UUID then or on completion of the API (in case
>>>where
>>> >>you
>>> >> are creating the actual resource).
>>> >> See if that works else there is no other way out.
>>> >>
>>> >> Another feedback on Rabbit MQ would be to push the list of all the
>>> >> first
>>> >> class objects (UUIDs) that are affected in the event description if
>>>
>>> >> possible. Say user invokes attachVolume to a vm. It would be good
>>>to
>>> >> always push vm uuid.
>>> >> Just putting in the volume uuid necessitates another call to CS and
>>>
>>> >> also
>>> >> that this was attach volume operation.
>>> >>
>>> >> Thanks,
>>> >> -Nitin
>>> >>
>>> >> On 20/11/13 8:23 AM, "David Grizzanti"
>>><da...@sungard.com>
>>> >> wrote:
>>> >>
>>> >> >Thanks for the feedback and info on the existing bug filed for
>>>this.
>>> >> >
>>> >> >Nitin - I was originally thinking along the lines of what Murali
>>>has
>>> >> >recently commented (i.e. adding Entity Details in the UserContext
>>>in
>>> >>all
>>> >> >the places where an Action Event is generated). The particular
>>>case I
>>> >> >was using this for when I found the issue was for creating a
>>>network,
>>> >> >which is not an async job. The AsyncJobManager I believe it
>>> >>generating a
>>> >> >different type of event that what I was originally looking at.
>>> >> >
>>> >> >Let me know your thoughts.
>>> >> >
>>> >> >Thanks
>>> >> >
>>> >> >--
>>> >> >David Grizzanti
>>> >> >Software Engineer
>>> >> >Sungard Availability Services
>>> >> >
>>> >> >e: david.grizzanti@sungard.com
>>> >> >w: 215.446.1431
>>> >> >c: 570.575.0315
>>> >> >
>>> >> >On November 20, 2013 at 2:45:50 AM, Murali Reddy
>>> >> >(murali.reddy@citrix.com) wrote:
>>> >> >
>>> >> >
>>> >> >
>>> >> >On 20/11/13 2:15 AM, "David Grizzanti"
>>><da...@sungard.com>
>>> >> >wrote:
>>> >> >
>>> >> >>Hi All,
>>> >> >>
>>> >> >>I noticed that the event messages going to rabbitmq of type
>>> >> >>"ActionEvent"
>>> >> >>are missing any reference to the entity Id/UUID. Was this
>>>omission
>>> >> >>intentional? Poking through the code, I was able to find that
>>>adding
>>> >>the
>>> >> >>
>>> >> >>information on to the event is fairly straightforward (albeit a
>>>bit
>>> >> >>tedious). Does anyone have any objections to updating these event
>>>
>>> >>types
>>> >> >>with this information? I can file the appropriate Jira, but
>>>wanted to
>>> >> >>check in with the list first to get opinions.
>>> >> >
>>> >> >David,
>>> >> >
>>> >> >Omission is not intentional. Please see [1] for earlier
>>>discussion.
>>> >>There
>>> >> >
>>> >> >is a bug opened as well[2].
>>> >> >
>>> >> >If you see ActionEventUtils, there is code that gets 'entity type'
>>>and
>>> >> >'entity uuid' from the CallContext and fills the details on the
>>> >> > message
>>> >> >published. I added this as generic mechanism. Unfortunately, there
>>>is
>>> >>not
>>> >> >
>>> >> >a single place where if you populate the entity type and uuid in
>>>the
>>> >>call
>>> >> >
>>> >> >context then things would fall in place. So its tedious job of
>>>adding
>>> >>the
>>> >> >
>>> >> >entity type and uuid details to the call context to all the
>>>methods
>>> >> >annotated with 'ActionEvent', but other wise it is a much needed
>>>fix.
>>> >> >
>>> >> >[1]
>>> >> >
>>> >>
>>>
>>> >>
>>>>>http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201306.mbox/%3
>>>>>CCD
>>> >>F
>>> >> >1
>>> >> >DB6A.424D9%25murali.reddy@citrix.com%3E
>>> >> >[2] https://issues.apache.org/jira/browse/CLOUDSTACK-3190
>>> >> >
>>> >> >
>>> >> >> Example event for network creation below.
>>> >> >>
>>> >> >>Thanks
>>> >> >>
>>> >> >>----------
>>> >> >>@source="management-server", @type="ActionEvent",
>>> >> >>@action="NETWORK-CREATE", @resource_type="Network",
>>>@resource_id="*">
>>> >> >>{
>>> >> >> "status": "Completed",
>>> >> >> "event": "NETWORK.CREATE",
>>> >> >> "account": "6d836cf8-47cd-11e3-a130-606d02c0c082",
>>> >> >> "user": "6d838544-47cd-11e3-a130-606d02c0c082"
>>> >> >>}
>>> >> >>
>>> >> >>--
>>> >> >>David Grizzanti
>>> >> >>Software Engineer
>>> >> >>Sungard Availability Services
>>> >> >>
>>> >> >>e: david.grizzanti@sungard.com
>>> >> >>w: 215.446.1431
>>> >> >>c: 570.575.0315
>>> >> >
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>
>
>
Re: Entity UUID and Type missing on ActionEvent event
notifications
Posted by David Grizzanti <da...@sungard.com>.
Murali,
I spoke with Alex regarding this issue and it appears there may have been some mix up in what the original intent of the bug was and what actually got fixed. To me, the idea behind this was to address the bug that the entity UUID was not getting added to ActionEvents for all resource types. When I looked at this fix today and spoke with Alex, I think what was fixed was only for accounts/users/domains.
Not sure where the break down happened, but was wondering how you thought we should address this? Open a new Jira to track the changes given the history of the existing one or re-open https://issues.apache.org/jira/browse/CLOUDSTACK-3190?
Thanks
--
David Grizzanti
Software Engineer
Sungard Availability Services
e: david.grizzanti@sungard.com
w: 215.446.1431
c: 570.575.0315
On December 6, 2013 at 4:26:40 PM, Alex Ough (alex.ough@sungard.com) wrote:
I modified the fix to make a little simpler, so can you review it please?
I'd like to finalize this as soon as possible to move on with CLOUDSTACK-4992.
Thanks
Alex Ough
On Thu, Dec 5, 2013 at 1:32 PM, Alex Ough <al...@sungard.com> wrote:
> All,
>
> I submitted the review request, so please review it and let me know if there
> is anything missing/incorrect.
>
> Thanks
> Alex Ough
>
>
> On Wed, Dec 4, 2013 at 11:29 PM, Murali Reddy <Mu...@citrix.com>
> wrote:
>>
>> On 05/12/13 12:01 AM, "Alex Ough" <al...@sungard.com> wrote:
>>
>> >All,
>> >
>> >I made a comment on its jira,
>> >CLOUDSTACK-3190<https://issues.apache.org/jira/browse/CLOUDSTACK-3190>,
>> >so can anyone confirm what I found?
>> >I guess it is related with some refactoring related with 'CallContext'
>> >class.
>>
>> Alex,
>>
>> Yes, it regressed during shift from UserContext to CallContext. Please go
>> ahead with changes
>>
>> >
>> >If correct, I'd like make changes because it is a blocker of what I'm
>> >working on for
>> >CLOUDSTACK-4992<https://issues.apache.org/jira/browse/CLOUDSTACK-4992>
>> >.
>> >
>> >Thanks
>> >Alex Ough
>> >
>> >
>> >On Wed, Nov 20, 2013 at 1:37 PM, Nitin Mehta <Ni...@citrix.com>
>> >wrote:
>> >
>> >> David - CallContext gets created during the entry point of the API.
>> >> I haven't had the chance to completely investigate but I am hoping that
>> >> you can push the UUID then or on completion of the API (in case where
>> >>you
>> >> are creating the actual resource).
>> >> See if that works else there is no other way out.
>> >>
>> >> Another feedback on Rabbit MQ would be to push the list of all the
>> >> first
>> >> class objects (UUIDs) that are affected in the event description if
>> >> possible. Say user invokes attachVolume to a vm. It would be good to
>> >> always push vm uuid.
>> >> Just putting in the volume uuid necessitates another call to CS and
>> >> also
>> >> that this was attach volume operation.
>> >>
>> >> Thanks,
>> >> -Nitin
>> >>
>> >> On 20/11/13 8:23 AM, "David Grizzanti" <da...@sungard.com>
>> >> wrote:
>> >>
>> >> >Thanks for the feedback and info on the existing bug filed for this.
>> >> >
>> >> >Nitin - I was originally thinking along the lines of what Murali has
>> >> >recently commented (i.e. adding Entity Details in the UserContext in
>> >>all
>> >> >the places where an Action Event is generated). The particular case I
>> >> >was using this for when I found the issue was for creating a network,
>> >> >which is not an async job. The AsyncJobManager I believe it
>> >>generating a
>> >> >different type of event that what I was originally looking at.
>> >> >
>> >> >Let me know your thoughts.
>> >> >
>> >> >Thanks
>> >> >
>> >> >--
>> >> >David Grizzanti
>> >> >Software Engineer
>> >> >Sungard Availability Services
>> >> >
>> >> >e: david.grizzanti@sungard.com
>> >> >w: 215.446.1431
>> >> >c: 570.575.0315
>> >> >
>> >> >On November 20, 2013 at 2:45:50 AM, Murali Reddy
>> >> >(murali.reddy@citrix.com) wrote:
>> >> >
>> >> >
>> >> >
>> >> >On 20/11/13 2:15 AM, "David Grizzanti" <da...@sungard.com>
>> >> >wrote:
>> >> >
>> >> >>Hi All,
>> >> >>
>> >> >>I noticed that the event messages going to rabbitmq of type
>> >> >>"ActionEvent"
>> >> >>are missing any reference to the entity Id/UUID. Was this omission
>> >> >>intentional? Poking through the code, I was able to find that adding
>> >>the
>> >> >>
>> >> >>information on to the event is fairly straightforward (albeit a bit
>> >> >>tedious). Does anyone have any objections to updating these event
>> >>types
>> >> >>with this information? I can file the appropriate Jira, but wanted to
>> >> >>check in with the list first to get opinions.
>> >> >
>> >> >David,
>> >> >
>> >> >Omission is not intentional. Please see [1] for earlier discussion.
>> >>There
>> >> >
>> >> >is a bug opened as well[2].
>> >> >
>> >> >If you see ActionEventUtils, there is code that gets 'entity type' and
>> >> >'entity uuid' from the CallContext and fills the details on the
>> >> > message
>> >> >published. I added this as generic mechanism. Unfortunately, there is
>> >>not
>> >> >
>> >> >a single place where if you populate the entity type and uuid in the
>> >>call
>> >> >
>> >> >context then things would fall in place. So its tedious job of adding
>> >>the
>> >> >
>> >> >entity type and uuid details to the call context to all the methods
>> >> >annotated with 'ActionEvent', but other wise it is a much needed fix.
>> >> >
>> >> >[1]
>> >> >
>> >>
>>
>> >> >>http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201306.mbox/%3CCD
>> >>F
>> >> >1
>> >> >DB6A.424D9%25murali.reddy@citrix.com%3E
>> >> >[2] https://issues.apache.org/jira/browse/CLOUDSTACK-3190
>> >> >
>> >> >
>> >> >> Example event for network creation below.
>> >> >>
>> >> >>Thanks
>> >> >>
>> >> >>----------
>> >> >>@source="management-server", @type="ActionEvent",
>> >> >>@action="NETWORK-CREATE", @resource_type="Network", @resource_id="*">
>> >> >>{
>> >> >> "status": "Completed",
>> >> >> "event": "NETWORK.CREATE",
>> >> >> "account": "6d836cf8-47cd-11e3-a130-606d02c0c082",
>> >> >> "user": "6d838544-47cd-11e3-a130-606d02c0c082"
>> >> >>}
>> >> >>
>> >> >>--
>> >> >>David Grizzanti
>> >> >>Software Engineer
>> >> >>Sungard Availability Services
>> >> >>
>> >> >>e: david.grizzanti@sungard.com
>> >> >>w: 215.446.1431
>> >> >>c: 570.575.0315
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>
Re: Entity UUID and Type missing on ActionEvent event notifications
Posted by Alex Ough <al...@sungard.com>.
I modified the fix to make a little simpler, so can you review it please?
I'd like to finalize this as soon as possible to move on with CLOUDSTACK-4992.
Thanks
Alex Ough
On Thu, Dec 5, 2013 at 1:32 PM, Alex Ough <al...@sungard.com> wrote:
> All,
>
> I submitted the review request, so please review it and let me know if there
> is anything missing/incorrect.
>
> Thanks
> Alex Ough
>
>
> On Wed, Dec 4, 2013 at 11:29 PM, Murali Reddy <Mu...@citrix.com>
> wrote:
>>
>> On 05/12/13 12:01 AM, "Alex Ough" <al...@sungard.com> wrote:
>>
>> >All,
>> >
>> >I made a comment on its jira,
>> >CLOUDSTACK-3190<https://issues.apache.org/jira/browse/CLOUDSTACK-3190>,
>> >so can anyone confirm what I found?
>> >I guess it is related with some refactoring related with 'CallContext'
>> >class.
>>
>> Alex,
>>
>> Yes, it regressed during shift from UserContext to CallContext. Please go
>> ahead with changes
>>
>> >
>> >If correct, I'd like make changes because it is a blocker of what I'm
>> >working on for
>> >CLOUDSTACK-4992<https://issues.apache.org/jira/browse/CLOUDSTACK-4992>
>> >.
>> >
>> >Thanks
>> >Alex Ough
>> >
>> >
>> >On Wed, Nov 20, 2013 at 1:37 PM, Nitin Mehta <Ni...@citrix.com>
>> >wrote:
>> >
>> >> David - CallContext gets created during the entry point of the API.
>> >> I haven't had the chance to completely investigate but I am hoping that
>> >> you can push the UUID then or on completion of the API (in case where
>> >>you
>> >> are creating the actual resource).
>> >> See if that works else there is no other way out.
>> >>
>> >> Another feedback on Rabbit MQ would be to push the list of all the
>> >> first
>> >> class objects (UUIDs) that are affected in the event description if
>> >> possible. Say user invokes attachVolume to a vm. It would be good to
>> >> always push vm uuid.
>> >> Just putting in the volume uuid necessitates another call to CS and
>> >> also
>> >> that this was attach volume operation.
>> >>
>> >> Thanks,
>> >> -Nitin
>> >>
>> >> On 20/11/13 8:23 AM, "David Grizzanti" <da...@sungard.com>
>> >> wrote:
>> >>
>> >> >Thanks for the feedback and info on the existing bug filed for this.
>> >> >
>> >> >Nitin - I was originally thinking along the lines of what Murali has
>> >> >recently commented (i.e. adding Entity Details in the UserContext in
>> >>all
>> >> >the places where an Action Event is generated). The particular case I
>> >> >was using this for when I found the issue was for creating a network,
>> >> >which is not an async job. The AsyncJobManager I believe it
>> >>generating a
>> >> >different type of event that what I was originally looking at.
>> >> >
>> >> >Let me know your thoughts.
>> >> >
>> >> >Thanks
>> >> >
>> >> >--
>> >> >David Grizzanti
>> >> >Software Engineer
>> >> >Sungard Availability Services
>> >> >
>> >> >e: david.grizzanti@sungard.com
>> >> >w: 215.446.1431
>> >> >c: 570.575.0315
>> >> >
>> >> >On November 20, 2013 at 2:45:50 AM, Murali Reddy
>> >> >(murali.reddy@citrix.com) wrote:
>> >> >
>> >> >
>> >> >
>> >> >On 20/11/13 2:15 AM, "David Grizzanti" <da...@sungard.com>
>> >> >wrote:
>> >> >
>> >> >>Hi All,
>> >> >>
>> >> >>I noticed that the event messages going to rabbitmq of type
>> >> >>"ActionEvent"
>> >> >>are missing any reference to the entity Id/UUID. Was this omission
>> >> >>intentional? Poking through the code, I was able to find that adding
>> >>the
>> >> >>
>> >> >>information on to the event is fairly straightforward (albeit a bit
>> >> >>tedious). Does anyone have any objections to updating these event
>> >>types
>> >> >>with this information? I can file the appropriate Jira, but wanted to
>> >> >>check in with the list first to get opinions.
>> >> >
>> >> >David,
>> >> >
>> >> >Omission is not intentional. Please see [1] for earlier discussion.
>> >>There
>> >> >
>> >> >is a bug opened as well[2].
>> >> >
>> >> >If you see ActionEventUtils, there is code that gets 'entity type' and
>> >> >'entity uuid' from the CallContext and fills the details on the
>> >> > message
>> >> >published. I added this as generic mechanism. Unfortunately, there is
>> >>not
>> >> >
>> >> >a single place where if you populate the entity type and uuid in the
>> >>call
>> >> >
>> >> >context then things would fall in place. So its tedious job of adding
>> >>the
>> >> >
>> >> >entity type and uuid details to the call context to all the methods
>> >> >annotated with 'ActionEvent', but other wise it is a much needed fix.
>> >> >
>> >> >[1]
>> >> >
>> >>
>>
>> >> >>http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201306.mbox/%3CCD
>> >>F
>> >> >1
>> >> >DB6A.424D9%25murali.reddy@citrix.com%3E
>> >> >[2] https://issues.apache.org/jira/browse/CLOUDSTACK-3190
>> >> >
>> >> >
>> >> >> Example event for network creation below.
>> >> >>
>> >> >>Thanks
>> >> >>
>> >> >>----------
>> >> >>@source="management-server", @type="ActionEvent",
>> >> >>@action="NETWORK-CREATE", @resource_type="Network", @resource_id="*">
>> >> >>{
>> >> >> "status": "Completed",
>> >> >> "event": "NETWORK.CREATE",
>> >> >> "account": "6d836cf8-47cd-11e3-a130-606d02c0c082",
>> >> >> "user": "6d838544-47cd-11e3-a130-606d02c0c082"
>> >> >>}
>> >> >>
>> >> >>--
>> >> >>David Grizzanti
>> >> >>Software Engineer
>> >> >>Sungard Availability Services
>> >> >>
>> >> >>e: david.grizzanti@sungard.com
>> >> >>w: 215.446.1431
>> >> >>c: 570.575.0315
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>>
>>
>>
>
Re: Entity UUID and Type missing on ActionEvent event notifications
Posted by Alex Ough <al...@sungard.com>.
All,
I submitted the review request, so please review it and let me know if
there is anything missing/incorrect.
Thanks
Alex Ough
On Wed, Dec 4, 2013 at 11:29 PM, Murali Reddy <Mu...@citrix.com>wrote:
> On 05/12/13 12:01 AM, "Alex Ough" <al...@sungard.com> wrote:
>
> >All,
> >
> >I made a comment on its jira,
> >CLOUDSTACK-3190<https://issues.apache.org/jira/browse/CLOUDSTACK-3190>,
> >so can anyone confirm what I found?
> >I guess it is related with some refactoring related with 'CallContext'
> >class.
>
> Alex,
>
> Yes, it regressed during shift from UserContext to CallContext. Please go
> ahead with changes
>
> >
> >If correct, I'd like make changes because it is a blocker of what I'm
> >working on for
> >CLOUDSTACK-4992<https://issues.apache.org/jira/browse/CLOUDSTACK-4992>
> >.
> >
> >Thanks
> >Alex Ough
> >
> >
> >On Wed, Nov 20, 2013 at 1:37 PM, Nitin Mehta <Ni...@citrix.com>
> >wrote:
> >
> >> David - CallContext gets created during the entry point of the API.
> >> I haven't had the chance to completely investigate but I am hoping that
> >> you can push the UUID then or on completion of the API (in case where
> >>you
> >> are creating the actual resource).
> >> See if that works else there is no other way out.
> >>
> >> Another feedback on Rabbit MQ would be to push the list of all the first
> >> class objects (UUIDs) that are affected in the event description if
> >> possible. Say user invokes attachVolume to a vm. It would be good to
> >> always push vm uuid.
> >> Just putting in the volume uuid necessitates another call to CS and also
> >> that this was attach volume operation.
> >>
> >> Thanks,
> >> -Nitin
> >>
> >> On 20/11/13 8:23 AM, "David Grizzanti" <da...@sungard.com>
> >> wrote:
> >>
> >> >Thanks for the feedback and info on the existing bug filed for this.
> >> >
> >> >Nitin - I was originally thinking along the lines of what Murali has
> >> >recently commented (i.e. adding Entity Details in the UserContext in
> >>all
> >> >the places where an Action Event is generated). The particular case I
> >> >was using this for when I found the issue was for creating a network,
> >> >which is not an async job. The AsyncJobManager I believe it
> >>generating a
> >> >different type of event that what I was originally looking at.
> >> >
> >> >Let me know your thoughts.
> >> >
> >> >Thanks
> >> >
> >> >--
> >> >David Grizzanti
> >> >Software Engineer
> >> >Sungard Availability Services
> >> >
> >> >e: david.grizzanti@sungard.com
> >> >w: 215.446.1431
> >> >c: 570.575.0315
> >> >
> >> >On November 20, 2013 at 2:45:50 AM, Murali Reddy
> >> >(murali.reddy@citrix.com) wrote:
> >> >
> >> >
> >> >
> >> >On 20/11/13 2:15 AM, "David Grizzanti" <da...@sungard.com>
> >> >wrote:
> >> >
> >> >>Hi All,
> >> >>
> >> >>I noticed that the event messages going to rabbitmq of type
> >> >>"ActionEvent"
> >> >>are missing any reference to the entity Id/UUID. Was this omission
> >> >>intentional? Poking through the code, I was able to find that adding
> >>the
> >> >>
> >> >>information on to the event is fairly straightforward (albeit a bit
> >> >>tedious). Does anyone have any objections to updating these event
> >>types
> >> >>with this information? I can file the appropriate Jira, but wanted to
> >> >>check in with the list first to get opinions.
> >> >
> >> >David,
> >> >
> >> >Omission is not intentional. Please see [1] for earlier discussion.
> >>There
> >> >
> >> >is a bug opened as well[2].
> >> >
> >> >If you see ActionEventUtils, there is code that gets 'entity type' and
> >> >'entity uuid' from the CallContext and fills the details on the message
> >> >published. I added this as generic mechanism. Unfortunately, there is
> >>not
> >> >
> >> >a single place where if you populate the entity type and uuid in the
> >>call
> >> >
> >> >context then things would fall in place. So its tedious job of adding
> >>the
> >> >
> >> >entity type and uuid details to the call context to all the methods
> >> >annotated with 'ActionEvent', but other wise it is a much needed fix.
> >> >
> >> >[1]
> >> >
> >>
> >>
> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201306.mbox/%3CCD
> >>F
> >> >1
> >> >DB6A.424D9%25murali.reddy@citrix.com%3E
> >> >[2] https://issues.apache.org/jira/browse/CLOUDSTACK-3190
> >> >
> >> >
> >> >> Example event for network creation below.
> >> >>
> >> >>Thanks
> >> >>
> >> >>----------
> >> >>@source="management-server", @type="ActionEvent",
> >> >>@action="NETWORK-CREATE", @resource_type="Network", @resource_id="*">
> >> >>{
> >> >> "status": "Completed",
> >> >> "event": "NETWORK.CREATE",
> >> >> "account": "6d836cf8-47cd-11e3-a130-606d02c0c082",
> >> >> "user": "6d838544-47cd-11e3-a130-606d02c0c082"
> >> >>}
> >> >>
> >> >>--
> >> >>David Grizzanti
> >> >>Software Engineer
> >> >>Sungard Availability Services
> >> >>
> >> >>e: david.grizzanti@sungard.com
> >> >>w: 215.446.1431
> >> >>c: 570.575.0315
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
>
>
>
>
Re: Entity UUID and Type missing on ActionEvent event notifications
Posted by Murali Reddy <Mu...@citrix.com>.
On 05/12/13 12:01 AM, "Alex Ough" <al...@sungard.com> wrote:
>All,
>
>I made a comment on its jira,
>CLOUDSTACK-3190<https://issues.apache.org/jira/browse/CLOUDSTACK-3190>,
>so can anyone confirm what I found?
>I guess it is related with some refactoring related with 'CallContext'
>class.
Alex,
Yes, it regressed during shift from UserContext to CallContext. Please go
ahead with changes
>
>If correct, I'd like make changes because it is a blocker of what I'm
>working on for
>CLOUDSTACK-4992<https://issues.apache.org/jira/browse/CLOUDSTACK-4992>
>.
>
>Thanks
>Alex Ough
>
>
>On Wed, Nov 20, 2013 at 1:37 PM, Nitin Mehta <Ni...@citrix.com>
>wrote:
>
>> David - CallContext gets created during the entry point of the API.
>> I haven't had the chance to completely investigate but I am hoping that
>> you can push the UUID then or on completion of the API (in case where
>>you
>> are creating the actual resource).
>> See if that works else there is no other way out.
>>
>> Another feedback on Rabbit MQ would be to push the list of all the first
>> class objects (UUIDs) that are affected in the event description if
>> possible. Say user invokes attachVolume to a vm. It would be good to
>> always push vm uuid.
>> Just putting in the volume uuid necessitates another call to CS and also
>> that this was attach volume operation.
>>
>> Thanks,
>> -Nitin
>>
>> On 20/11/13 8:23 AM, "David Grizzanti" <da...@sungard.com>
>> wrote:
>>
>> >Thanks for the feedback and info on the existing bug filed for this.
>> >
>> >Nitin - I was originally thinking along the lines of what Murali has
>> >recently commented (i.e. adding Entity Details in the UserContext in
>>all
>> >the places where an Action Event is generated). The particular case I
>> >was using this for when I found the issue was for creating a network,
>> >which is not an async job. The AsyncJobManager I believe it
>>generating a
>> >different type of event that what I was originally looking at.
>> >
>> >Let me know your thoughts.
>> >
>> >Thanks
>> >
>> >--
>> >David Grizzanti
>> >Software Engineer
>> >Sungard Availability Services
>> >
>> >e: david.grizzanti@sungard.com
>> >w: 215.446.1431
>> >c: 570.575.0315
>> >
>> >On November 20, 2013 at 2:45:50 AM, Murali Reddy
>> >(murali.reddy@citrix.com) wrote:
>> >
>> >
>> >
>> >On 20/11/13 2:15 AM, "David Grizzanti" <da...@sungard.com>
>> >wrote:
>> >
>> >>Hi All,
>> >>
>> >>I noticed that the event messages going to rabbitmq of type
>> >>"ActionEvent"
>> >>are missing any reference to the entity Id/UUID. Was this omission
>> >>intentional? Poking through the code, I was able to find that adding
>>the
>> >>
>> >>information on to the event is fairly straightforward (albeit a bit
>> >>tedious). Does anyone have any objections to updating these event
>>types
>> >>with this information? I can file the appropriate Jira, but wanted to
>> >>check in with the list first to get opinions.
>> >
>> >David,
>> >
>> >Omission is not intentional. Please see [1] for earlier discussion.
>>There
>> >
>> >is a bug opened as well[2].
>> >
>> >If you see ActionEventUtils, there is code that gets 'entity type' and
>> >'entity uuid' from the CallContext and fills the details on the message
>> >published. I added this as generic mechanism. Unfortunately, there is
>>not
>> >
>> >a single place where if you populate the entity type and uuid in the
>>call
>> >
>> >context then things would fall in place. So its tedious job of adding
>>the
>> >
>> >entity type and uuid details to the call context to all the methods
>> >annotated with 'ActionEvent', but other wise it is a much needed fix.
>> >
>> >[1]
>> >
>>
>>http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201306.mbox/%3CCD
>>F
>> >1
>> >DB6A.424D9%25murali.reddy@citrix.com%3E
>> >[2] https://issues.apache.org/jira/browse/CLOUDSTACK-3190
>> >
>> >
>> >> Example event for network creation below.
>> >>
>> >>Thanks
>> >>
>> >>----------
>> >>@source="management-server", @type="ActionEvent",
>> >>@action="NETWORK-CREATE", @resource_type="Network", @resource_id="*">
>> >>{
>> >> "status": "Completed",
>> >> "event": "NETWORK.CREATE",
>> >> "account": "6d836cf8-47cd-11e3-a130-606d02c0c082",
>> >> "user": "6d838544-47cd-11e3-a130-606d02c0c082"
>> >>}
>> >>
>> >>--
>> >>David Grizzanti
>> >>Software Engineer
>> >>Sungard Availability Services
>> >>
>> >>e: david.grizzanti@sungard.com
>> >>w: 215.446.1431
>> >>c: 570.575.0315
>> >
>> >
>> >
>>
>>
>>
>