> -----Original Message-----
> From: users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] On Behalf
> Of Rick Beldin
> Sent: Dienstag, 8. Januar 2013 15:54
> To: Itamar Heim
> Cc: users@ovirt.org
> Subject: Re: [Users] What do you want to see in oVirt next?
> On Tue 08 Jan 2013 04:41:01 AM EST, Itamar Heim wrote:
> > On 01/07/2013 06:11 PM, Rick Beldin wrote:
> >> - cleaner work-flow in creating and associating storage, especially
> >> NFS
> >>
> Some of this is no doubt my newbie-ness to ovirt.  Most of my comments
> below have to do with the manager.
> I started playing with RHEV 3.1 since I am responsible for delivering support
> on it but just yesterday started playing with Fedora 17 and all-in-one for 
> ease
> of setup.  I will try and document the specifics, but the things I recall were
> things like:
> - inability to setup NFS storage on the cluster until I had added a host.  I 
> think
>   I missed some key concept here, but my feeling was that I
> would/could/should
>   setup the manager (engine) first and then add virtual hosts.
> Instead, there
>   seems to be a procedural step.
> - along those lines the UI could do more to guide a user, a first-time wizard
>   that would guide you through cluster and datacenter setups that are
> independent
>   of the hosts.  Guide Me is a good start, but perhaps it needs some
> expansion.
> >> - better error reporting from engine back to admin user during admin
> >> operations.
> >
> - here's an example.  Just installed AIO on Fedora 17.  After going through
>   everything, it says 'Install Failed'.   The Event entry has a
> correlation id,
>   which can be used to figure out what went wrong.  (I guess).  It seems like
>   there could be more information provided to the admin on what to do next
> aside
>   install again?  Tooltip on what to do with correlation id? 

Whenever you report a problem here in the list, you get asked for engine and 
vdsm logs. So, these logs are essential and a way to access (at least the 
relevant parts) via the GUI would be perfect. Ideally, every task should have a 
unique ID and this ID should show up in the engine logs as well as the vdsm 
logs on the nodes in a way that they could easily filtered.

My dream would be a message like "Install failed" as a clickable link which 
then opens a log viewer and shows the engine log filtered by this ID as well as 
the vdsm log from the involved node filtered by this ID.

>  Oddly,
> I can't
>   right click on Event text to bring up copy/paste menu with Chrome or FF.
> Ctrl-c
>   worked with Chrome but not FF:
> Host local_host installation failed. The required action is taking longer than
> allowed by configuration. Verify host networking and storage settings..
>   That gives you a clue, but then what? A handy pointer to the log file would
>   be good.
> - Eons ago, in another product space, a complex product with hooks into
> networking
>   and whatnot had a tiny diagnostic script that would attempt to emulate the
>   requirements of the product.  Perhaps that is needed here - something
> outside
>   of the framework that could be a checklist of ports not open, permissions,
> etc.
>   Things that an admin needs to address outside of engine.
> - A menu item that would call the sosreport-like thing to collect data would
> aid
>   in supportability.
> - A meta-page with pointers/contents to all logs, databases and so forth
> would
>   be helpful.  There is a lot of content scattered over the disk.
> - A meta-page with a listing of critical processes.
> Some of these things are doubtless outside the scope of abstraction that is
> currently there, but the manager is the connection between the admin and
> the hosts.  As a critical resource the admin will likely not only be the one
> administering to guests, but to the engine as well.   Making that
> person's
> life easier will aid in acceptance and reduce long-term support costs.
> My 2cents...
> Rick
> _______________________________________________
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

Kind regards

Users mailing list

Reply via email to