On 11/12/13 3:01 AM, "David Grizzanti" <david.grizza...@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.grizza...@sungard.com >w: 215.446.1431 >c: 570.575.0315 > >On December 6, 2013 at 4:26:40 PM, Alex Ough (alex.o...@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 <alex.o...@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 <murali.re...@citrix.com> >> >> wrote: >>> >>> On 05/12/13 12:01 AM, "Alex Ough" <alex.o...@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 <nitin.me...@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" >>><david.grizza...@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.grizza...@sungard.com >>> >> >w: 215.446.1431 >>> >> >c: 570.575.0315 >>> >> > >>> >> >On November 20, 2013 at 2:45:50 AM, Murali Reddy >>> >> >(murali.re...@citrix.com) wrote: >>> >> > >>> >> > >>> >> > >>> >> >On 20/11/13 2:15 AM, "David Grizzanti" >>><david.grizza...@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.re...@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.grizza...@sungard.com >>> >> >>w: 215.446.1431 >>> >> >>c: 570.575.0315 >>> >> > >>> >> > >>> >> > >>> >> >>> >> >>> >> >>> > >>> >>> >>> >> > >
