Sonal - This is a great proposal. In addition, you should also include all the first class entities involved in the event. Say its a detach iso on a vm - then I should have uuids for both the iso and the vm. This would definitely help giving more information and in debugging.
Thanks, -Nitin On 17/03/14 9:52 AM, "Alena Prokharchyk" <alena.prokharc...@citrix.com> wrote: >On #1 I would say “display UUID INSTEAD of the DB id in the events API”. >We should never expose the DB ids to the API caller, especially if the >caller is not an admin. I guess we just never revised the events after >UUIDs were introduced. > >On #4. We should distinguish between end user and an admin and determine >which errors are allowed to be shown to the end user. For example, he >shouldn’t see any errors related to physical resources allocation error as >he has no knowledge about hosts/storages/physical network topology. > > >-Alena. > > > >On 3/17/14, 9:40 AM, "John Kinsella" <j...@stratosec.co> wrote: > >>I didn’t see comments from others, but this sounds great to me. More info >>is always better IMHO. >> >>On Mar 11, 2014, at 2:31 AM, Sonal Ojha >><sonal.o...@sungard.com<mailto:sonal.o...@sungard.com>> wrote: >> >>Currently the event logged in CloudStack doesn't give detailed >>information >>about the event that has occurred. The information provided in each event >>shown on the cloudstack ui doesn't provide specifics, particularly in >>case >>of errors. For example, the message shown on the cloudstack ui is just >>"Error while starting Vm. Vm Id: <id>" in case of failure to start a vm , >>which doesnt help much. >> >>I would like to propose some changes to enhance the events to be more >>informative. Like: >> >>1) Instead of just showing resource database id in the event details it >>should also display resource UUID. Since all the cloudstack apis take >>input >>as resource uuid it would be helpful to see the same on the ui as well. >>Like in the quickview mode introduce another field as resource UUID which >>would specify the UUID for the resource on which the event occurred. >> >>2) Enhance the events and listEvents API to include the resource UUID so >>that it can be queried by the resource UUID as well. >> >>3) Currently, the event description messages are specified in the >>*Cmd.java >>file instead, all of them should be externalize to a resource file. This >>would be helpful even for internationalization. >> >>4) Provide more detailed messages in case of error events. Messages such >>as >>"Error while starting VM" are generic to take any action. >> >>These changes could be taken forward in phases, some suggestion like >> >>Phase I - >>include 2 and 3 point mentioned above >>Phase II - >>include 1 and 4 point mentioned above >> >>Thoughts / Suggestions ? >> >>-- >> >>Regards, >> >>___________________________________________________ >> >>*Sonal Ojha* ● Senior Engineer - Product Developement ● SunGard >>Availability Services, India ● Mobile: +91 9922412645● Email: >>sonal.o...@sungard.com<mailto:sonal.o...@sungard.com> ● Website: >>http://www.sungardas.in/ >> >>8 Times Winner – BC Service Provider of the Year – 2011, 2010, 2009, >>2006, >>2005, 2002, 2000, 1999; Finalist – 2008, 2007, 2004, 2001 ● Excellence in >>Infrastructure Management – 2010 ● Outstanding Excellence in Business >>Continuity – 2008 ● Business Continuity Provider of the Year (BCM >>Service) >>– 2013 BCI Global Awards ● Business Continuity Provider of the Year (BCM >>Product) – 2013 BCI India Awards >> >>Stratosec<http://stratosec.co/> - Compliance as a Service >>o: 415.315.9385 >>@johnlkinsella<http://twitter.com/johnlkinsella> >> >
