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
<david.grizza...@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.grizza...@sungard.com
> w: 215.446.1431
> c: 570.575.0315
>
> On December 11, 2013 at 6:33:25 AM, Murali Reddy (murali.re...@citrix.com)
> wrote:
>
> 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
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
>
