Hi, In my work with satellite I had identified some areas of improvement related with reporting. As a background of my use, some things I'd like to do from the reporting perspective are:
-Create report for scheduled tasks, including what servers did succeed, failed or are still pending. -Create reports for server with pending updates. -Reports based in other inventory info as hardware or custom info. Regarding your questions, here you have some info: == USER TASKS == The main user tasks here (with some questions for you :) ) are: - Store Reports - Question for you: how long after they are generated would reports be useful for your organization? a month? a year? After that point would you prefer to delete them or put them in an archive so they are out-of-the-way? - What's your policy on deleting reports? Mmmm, I would not need to store all reports, but probably a Save Report function would be desirable to leave reports stored in the server. - Retrieve reports, in different formats - Question for you: how do you send reports to other folks in your organization? Would you only want them to have access to one or two particular reports, and not allow them to see others? Would they have access to your internal network so you'd be giving them an URL to the Telemetry UI, or would you manage sending them a pdf/txt/csv/etc copy of the report that you'd download out of Telemetry? pdf/csv is a must for us. For those users that may need it we could create them a read only user (I think some work was already done for read only users) in the satellite server, and they could create their reports. - Schedule reports to run regularly - What affects how often you schedule the types of reports you run in your organization today? Would you mostly run them manually / on-demand or would you want them to be generated regularly? - Would you want to be emailed reports on a regular basis, or emailed URLs to the reports on a regular basis? How do you typically receive them? I'd probably use more manual reporting that scheduling, however it could be an option for some cases. - Create new reports - How often do you end up creating new reports? If you had a system like this for Spacewalk, would you want to create more? I have created reports very rarely using perl scripts with the API. If I had a nice reporting system and interface I'd create some others for sure. However, It'd be nice to have a library of the most common reports created in the tool... if possible :) Regarding the walkthrough, a couple of ideas: * To create some reports I'd need to see the available values for a field. In example, let's think in a case where I want to have a report with the result of a software installation scheduled task, including the definition, packages involved, what servers did succeed (and time of the action), what servers failed and what servers are still pending. I'd like to have a generic report "Software Tasks Result". I would only have to change the action identificator. Finally, I'd need to be able to see the list of actions to select the desired one. * Could this reporting interface be integrated into the spacewalk interface? I think this is a very valuable feature, and could be part of the application itself. * Since the launch of Spacewalk, I'm not very sure about the relationship with spacewalk, will it be included in the Red Hat Satellite Server provided by Red Hat? Best regards, Alfredo -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Máirín Duffy Sent: Friday, November 07, 2008 8:08 PM To: [email protected] Cc: [EMAIL PROTECTED] Subject: [Spacewalk-list] Spacewalk Reporting Feature (Telemetry & Web UIthoughts) Hi folks! I don't know if you have gotten a chance to check it out yet, but Todd Sanders has written a reporting app for Spacewalk that lets you store & manage reports on Spacewalk data - it's called Telemetry: https://fedorahosted.org/spacewalk/wiki/PlayPen/Telemetry I'd like to design a nice web UI for Telemetry. I wanted to show you a quick conceptual mockup I did and some ideas I put together for how the UI could be organized. I'd love to hear your feedback / critique / ideas for how this would/wouldn't work for your usage of Spacewalk. Based on that feedback I'll draw up a screen flow diagram and hopefully full set of better mockups (better because they've taken your feedback into account :) ) So anyhow, here's my mockup: https://fedorahosted.org/spacewalk/wiki/PlayPen/Telemetry#Design == USER TASKS == The main user tasks here (with some questions for you :) ) are: - Store Reports - Question for you: how long after they are generated would reports be useful for your organization? a month? a year? After that point would you prefer to delete them or put them in an archive so they are out-of-the-way? - What's your policy on deleting reports? - Retrieve reports, in different formats - Question for you: how do you send reports to other folks in your organization? Would you only want them to have access to one or two particular reports, and not allow them to see others? Would they have access to your internal network so you'd be giving them an URL to the Telemetry UI, or would you manage sending them a pdf/txt/csv/etc copy of the report that you'd download out of Telemetry? - Schedule reports to run regularly - What affects how often you schedule the types of reports you run in your organization today? Would you mostly run them manually / on-demand or would you want them to be generated regularly? - Would you want to be emailed reports on a regular basis, or emailed URLs to the reports on a regular basis? How do you typically receive them? - Create new reports - How often do you end up creating new reports? If you had a system like this for Spacewalk, would you want to create more? == WALKTHROUGH == I wrote up a walkthrough of the ideas behind this mockup in the wiki page; I'll paste it here too. I'd love to hear your feedback on specific points: This mockup is just a brainstorm to try to work out a general structure/layout, it can completely change. It's more meant to be a discussion starter. Here is what I started thinking so far by sketching out the mockup: * Overview: just little preview widgets to give you a feel for what data lay in the other screens, with links to jump to the full data sets... (now that I'm looking at it, each report could have csv / txt / html / pdf icons next to it to let you download them in one click directly from the overview page) * Run a report: a wizard that walks you through running a report; it'll let you choose which report type you'd like to run, enter in your username/pass for the report, and schedule the report or let you run it directly. * Create a new report: This is probably the part of the ui that reaches most far and would likely be lower priority / out-of-scope at first. But, I think if possible: o it would be nice to have a wizard that asks you all the questions that you get asked in the individual report config files and generates a config file for you. o It could have an upload form for the api script. One idea here too could be a text field for the api script, to write it in the page, and it could be pre-filled with some stub code and have some kind of basic API cheatsheet along the bottom with a link to the full API guide. o there could be a templates section at the end that shows the various templates associated with the report and lets you at least view them if not modify them. * Report library: a directory showing all the various types of reports, ideally categorized (not sure how best to handle the categorization), with maybe a calendar for each report that will let you see which days of which months that report was generated and will let you click to see them, as crude as it is i was thinking something like this (but prettier!): http://intranet.corp.redhat.com/ic/intranet/RHEL5MeetingMinutes.html o maybe by default the calendar for this current month is shown and you click a link to zoom in on all the monthly calendars for that report type. * Report schedule: a schedule-based view of reports, to show you which reports run on which basis (hourly / daily / weekly / monthly) and to let you modify the schedules for those reports or stop them from running * Report templates: similar to the report-library view, but per report it'll list out what templates are available (html/ pdf/ csv/ etc) and let you add another template type In addition to this, reports will probably need two views: * Report Details view: report type's name, what satellites the report runs on, (a lot of the .conf file details), a listing of the templates available for the report, and a full calendar for that report (the report schedule page would link specifically to that full calendar section) * Specific report run details: the results from a particular run of that report, with date/timestamp, user who ran the report, and the report output This hopefully can be refined and simplified a lot more. Next we need to draw up a flow diagram for the UI and then based on feedback from the above and that do some better screen mockups. Anyhow, again, I'd love to hear your thoughts on this, general or specific. Would something like this for Spacewalk help you? Thanks, ~m _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
