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> >
