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.grizza...@sungard.com
w: 215.446.1431
c: 570.575.0315
On December 17, 2013 at 1:26:04 AM, Murali Reddy (murali.re...@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" <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
>>>>> >> >
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>
