cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Ough <alex.o...@sungard.com>
Subject Re: Entity UUID and Type missing on ActionEvent event notifications
Date Mon, 16 Dec 2013 16:58:04 GMT
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.Reddy@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.grizzanti@sungard.com>
> Date: Thursday, 12 December 2013 10:16 PM
> To: Murali Reddy <murali.reddy@citrix.com>, "dev@cloudstack.apache.org"
> <dev@cloudstack.apache.org>, Alex Ough <alex.ough@sungard.com>, Nitin Mehta
> <Nitin.Mehta@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.grizzanti@sungard.com
> w: 215.446.1431
> c: 570.575.0315
>
> On December 11, 2013 at 6:33:25 AM, Murali Reddy (murali.reddy@citrix.com)
> wrote:
>
> On 11/12/13 3:01 AM, "David Grizzanti" <david.grizzanti@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.grizzanti@sungard.com
>>w: 215.446.1431
>>c: 570.575.0315
>>
>>On December 6, 2013 at 4:26:40 PM, Alex Ough (alex.ough@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.ough@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.Reddy@citrix.com>
>>>
>>> wrote:
>>>>
>>>> On 05/12/13 12:01 AM, "Alex Ough" <alex.ough@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.Mehta@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.grizzanti@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.grizzanti@sungard.com
>>>> >> >w: 215.446.1431
>>>> >> >c: 570.575.0315
>>>> >> >
>>>> >> >On November 20, 2013 at 2:45:50 AM, Murali Reddy
>>>> >> >(murali.reddy@citrix.com) wrote:
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >On 20/11/13 2:15 AM, "David Grizzanti"
>>>><david.grizzanti@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.reddy@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.grizzanti@sungard.com
>>>> >> >>w: 215.446.1431
>>>> >> >>c: 570.575.0315
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>
>>
>>
>
>
>

Mime
View raw message