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/%3CCD >> >>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 >> >> > >> >> > >> >> > >> >> >> >> >> >> >> > >> >> >> >
