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" <alex.o...@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 <murali.re...@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 <david.grizza...@sungard.com>
>> Date: Thursday, 12 December 2013 10:16 PM
>> To: Murali Reddy <murali.re...@citrix.com>, "dev@cloudstack.apache.org"
>> <dev@cloudstack.apache.org>, Alex Ough <alex.o...@sungard.com>, Nitin
>>Mehta
>> <nitin.me...@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.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
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>
