>
>
> > From: "Stephen Benjamin" <stephen@bitbin.de>
> > To: foreman-dev@googlegroups.com
> > Sent: Sunday, November 24, 2013 11:58:29 AM
> > Subject: Re: [foreman-dev] UI notifications
> >
> >
> > >
> > >
> > >> From: "Ohad Levy" <ohadlevy@gmail.com>
> > >> To: "foreman-dev" <foreman-dev@googlegroups.com>
> > >> Sent: Saturday, November 23, 2013 3:28:25 PM
> > >> Subject: [foreman-dev] UI notifications
> > >>
> > >> Hi,
> > >>
> > >> I'm working on adding async notifications to foreman UI, where it
> > >> would be possible to show events, even if you didnt refresh the page
> > >> etc.
> > >>
> > >> I'm trying to figure out which kind of notifications would make sense,
> > >> so far I could think of the following:
> > >>
> > >> * long running tasks (e.g. when machines finish provisioning?)
> > >> * import failures (e.g. 500 ERRORS) that are generated by the API
> > >> (such as fact/enc/reports query)
> > >>
> > >> Another side, is to save failures, e.g. right now, if there is an
> > >> error (e.g. 500 error from a proxy) it gets logged, but not visible
> > >> in the UI, would it make sense to keep that errors until ack
> > >> somewhere?
> > >>
> > >> so in general, which kind of information did you find lacking, and had
> > >> to start searching logs or other places where its obvious foreman
> > >> could display it?
> > >>
> > >> thanks!
> > >> Ohad
> > >>
> > >> –
> > >> You received this message because you are subscribed to the Google
> > >> Groups
> > >> "foreman-dev" group.
> > >> To unsubscribe from this group and stop receiving emails from it, send
> > >> an
> > >> email to foreman-dev+unsubscribe@googlegroups.com.
> > >> For more options, visit https://groups.google.com/groups/opt_out.
> > >>
> > >
> > > In comparing katello notices to foreman audits, I really like the foreman
> > > audits because they tend to answer an admin's questions: "What happened
> > > in
> > > the past day, by whom, and what changed?"
> >
> > +1
> >
> > I like the audit view.
> >
> > In Spacewalk/Satellite for example, it's only possible for very few actions
> > to find out who did what and when.
> >
> > >
> > > The missing piece of audits is that they currently log only successful
> > > changes. If they could be augmented to show failures as well, that would
> > > be very helpful.
> >
> > And pending tasks (like host building?), maybe.
> >
> > I like VMware's way of showing status (at the bottom):
> > http://www.vcritical.com/wp-content/uploads/2009/05/vsphere_client_virtual_esx.png
> >
> > You always have an idea of what's going on.
>
> That's a nice UI view: Slide up and then slide down to hide right on the
> page. Would let me monitor tasks while going about other admin chores.
>
> >
> > If something deserves a notice to the user, doesn't it deserve to be
> > audited?
> > It seems like audits and notices could be one thing. Urgent user facing
> > issues get :display => true or something.
>
> Agreed. Some sort of user pref on a per-audit basis to trigger popping a
> notice or not. "Argh! Bob from accounting is having trouble logging in
> again… Better set failed login audits to pop so I can remind him his
> password was reset from 1234."
FYI: I'm working on the task statuses rework in Katello right now with improved
realtime reporting and auditing features. I will demo the work so far on today
Katello sprint demo (I can give a deep dive later on as well). Ohad: I really
recommand you to take a loot at that.
About the audit, I agree that it has a lot in common with user notifications.
What we do right now is showing the user the recent actions he triggered on resources.
We don't include however attempts that failed on model validations, as nothing
was really affected from the resource point of view.
How it works: every modification action will have a task record created (we
use dynflow for that). The task is used for both short running actions
(performing actions only locally in database) or distributed actions
(perofrming rest calls to tother services). The task is assigned to
every resource that is connected to that task somehow: there are more task -> resource relations:
- locks: when repository is being synced, we don't want to allow other actions to be performed on that resource
- links: the product that contains the repository is linked to the task as well: this allows us to include
the repository sync task in list of tasks under the product, the same mechanism gets
the task into the tasks of the organization.
Every task also holds all the information needed for auditing, the data about the resource it was run
on top of and the user that triggered it. This allows us to show the details of the task even
when the resource, that task was on, is deleted.
With this approach, we are also able very easily produce cli examples for the tasks.
So for example, when I run repository synchronization, it shows up in the repository tasks,
product tasks, provider tasks and organization tasks. Even when I delete the provider, I will
still see the information about the action in organization tasks.
It would be probably worth doing a deep-dive on that.
– Ivan
···
----- Original Message -----
> ----- Original Message -----
> > On Nov 24, 2013, at 3:50 PM, Tom McKay wrote:
> > > ----- Original Message -----
–
Stephen Benjamin
stephen@bitbin.de
–
You received this message because you are subscribed to the Google Groups
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.