Hi Cockpit people,
A while ago the ABRT team presented [1] Cockpit module showing problems detected by ABRT and allowing users to report them. It was more less a proof of concept. But we are eager to finish this effort.
After speaking with some members of the Cockpit team on DevConf we were advised to start by writing user stories. We did so and today I presented them on the wikipage of cockpit's github [2].
We would love to have a feedback from you. What do you think of this? Is it suitable for Cockpit? We are open-minded to yours ideas.
Best regards, Matej ABRT
1: https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahoste... 2: https://github.com/cockpit-project/cockpit/wiki/Feature:-ABRT
Great work! I'm happy to see these stories up so quickly.
I added a trello card [1] on our board to track the progress on the design here.
The user stories and workflows aren't checked off on that card yet because that is done once there is agreement that the state of the wiki page is complete enough to start with the mockups.
Thanks, -Dominik
[1] https://trello.com/c/rvmmFPRd/459-design-abrt-support
On 02/01/2017 10:58 AM, Matej Marusak wrote:
Hi Cockpit people,
A while ago the ABRT team presented [1] Cockpit module showing problems detected by ABRT and allowing users to report them. It was more less a proof of concept. But we are eager to finish this effort.
After speaking with some members of the Cockpit team on DevConf we were advised to start by writing user stories. We did so and today I presented them on the wikipage of cockpit's github [2].
We would love to have a feedback from you. What do you think of this? Is it suitable for Cockpit? We are open-minded to yours ideas.
Best regards, Matej ABRT
1: https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahoste... 2: https://github.com/cockpit-project/cockpit/wiki/Feature:-ABRT _______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org
It is maybe worth a note that we already have some code done. See: https://github.com/abrt/cockpit-abrt So we can either create PR right now or when we agree on different mockup, we can make necessary alternation.
Hi, and sorry for the delayed reply. It's been a bit of traveling between conferences, and then I only remembered I hadn't replied to this mail until yesterday.
The stories looks really good! Thanks for the good work there. One thing I'm wondering about is automatic crash reporting. It's the only thing I ever use myself on my laptop, and I know it's good useful information for my OS provider (Fedora). I would never do the manual job of reporting the crashers by hand (unless they are very critical). At the same time I see how it could be a privacy concern to a specific group of people (say in the situation where you are actually developing a piece of software that is secret and maybe it's a competing product to your competitor) where it would be good you would turn any automatic reporting off.
Is automatic reporting planned for this initial version, or is that for a later version? - Andreas
On 2017-02-01 10:58, Matej Marusak wrote:
Hi Cockpit people,
A while ago the ABRT team presented [1] Cockpit module showing problems detected by ABRT and allowing users to report them. It was more less a proof of concept. But we are eager to finish this effort.
After speaking with some members of the Cockpit team on DevConf we were advised to start by writing user stories. We did so and today I presented them on the wikipage of cockpit's github [2].
We would love to have a feedback from you. What do you think of this? Is it suitable for Cockpit? We are open-minded to yours ideas.
Best regards, Matej ABRT
1: https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahoste... 2: https://github.com/cockpit-project/cockpit/wiki/Feature:-ABRT _______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org
On 02/13/2017 07:19 AM, Andreas Nilsson wrote:
Hi, and sorry for the delayed reply. It's been a bit of traveling between conferences, and then I only remembered I hadn't replied to this mail until yesterday.
The stories looks really good! Thanks for the good work there. One thing I'm wondering about is automatic crash reporting. It's the only thing I ever use myself on my laptop, and I know it's good useful information for my OS provider (Fedora). I would never do the manual job of reporting the crashers by hand (unless they are very critical). At the same time I see how it could be a privacy concern to a specific group of people (say in the situation where you are actually developing a piece of software that is secret and maybe it's a competing product to your competitor) where it would be good you would turn any automatic reporting off.
Is automatic reporting planned for this initial version, or is that for a later version?
I have in the back of my mind a memory that says that the auto-reporting feature will only happen for things that occur in OS packages, but I'm not sure what heuristic is used for that.
Hi all!
Enabling Automatic reporting is a matter of setting
AutoreportingEnabled = on in the /etc/abrt/abrt.conf file.
This can also be accomplished through a D-Bus call.
However, we wanted to start with manual analysis and reporting
of the detected problems and develop ABRT configuration capabilities
later on.
You have pointed out security problems and I appreciate that. We have an idea how
to sort out the problem with leaking potentially private stuff. For some time now
ABRT has been storing Vendor of the relevant packages. So we need to check
if everything in the report was issued by a white-list of public vendors. This hasn't been
implemented yet and it will take some time to ABRT team to do so, thus I would
not try to include Automatic reporting in the first version of ABRT for Cockpit.
Regards,
Jakub
---------- Původní zpráva ---------- Od: Andreas Nilsson lists@andreasn.se Komu: cockpit-devel@lists.fedorahosted.org Datum: 13. 2. 2017 13:20:06 Předmět: Re: Supporting ABRT in Cockpit
"Hi, and sorry for the delayed reply. It's been a bit of traveling between conferences, and then I only remembered I hadn't replied to this mail until yesterday.
The stories looks really good! Thanks for the good work there. One thing I'm wondering about is automatic crash reporting. It's the only thing I ever use myself on my laptop, and I know it's good useful information for my OS provider (Fedora). I would never do the manual job of reporting the crashers by hand (unless they are very critical). At the same time I see how it could be a privacy concern to a specific group of people (say in the situation where you are actually developing a piece of software that is secret and maybe it's a competing product to your competitor) where it would be good you would turn any automatic reporting off.
Is automatic reporting planned for this initial version, or is that for a later version? - Andreas
On 2017-02-01 10:58, Matej Marusak wrote:
Hi Cockpit people,
A while ago the ABRT team presented [1] Cockpit module showing problems
detected by ABRT and allowing users to report them. It was more less a proof of concept. But we are eager to finish this effort.
After speaking with some members of the Cockpit team on DevConf we were
advised to start by writing user stories. We did so and today I presented them on the wikipage of cockpit's github [2].
We would love to have a feedback from you. What do you think of this? Is
it suitable for Cockpit?
We are open-minded to yours ideas.
Best regards, Matej ABRT
1: https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.
fedorahosted.org/message/D6KLKDFMTRLSJSVBFY7ICTSPMHCOQO65/
2: https://github.com/cockpit-project/cockpit/wiki/Feature:-ABRT _______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org
_______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org "
On 2017-02-13 14:42, jfilak@fedoraproject.org wrote:
You have pointed out security problems and I appreciate that. We have an idea how to sort out the problem with leaking potentially private stuff. For some time now ABRT has been storing Vendor of the relevant packages. So we need to check if everything in the report was issued by a white-list of public vendors. This hasn't been implemented yet and it will take some time to ABRT team to do so, thus I would not try to include Automatic reporting in the first version of ABRT for Cockpit.
Makes sense. Thanks! - Andreas
On 2017-02-01 10:58, Matej Marusak wrote:
Hi Cockpit people,
A while ago the ABRT team presented [1] Cockpit module showing problems detected by ABRT and allowing users to report them. It was more less a proof of concept. But we are eager to finish this effort.
After speaking with some members of the Cockpit team on DevConf we were advised to start by writing user stories. We did so and today I presented them on the wikipage of cockpit's github [2].
One quick question about Paul's workflow. "Paul takes a look into logs and select filter "problems"(crashes?)." is this a systemd priority level, or is it a separate system? Currently Errors, Warning and Notices are all priority levels in Logs. Just so I can figure out how to lay it out logically in the design. - Andreas
No, it is not a systemd priority level. I only thought it would be nice to have another "filter". But the code must be modified to filter more values than only priority. Or it can look as another "filter" but have it's own behaviour. Or it can not be as filter at all and be placed somewhere else.
MM
On 2017-02-20 07:25, Matej Marusak wrote:
No, it is not a systemd priority level. I only thought it would be nice to have another "filter". But the code must be modified to filter more values than only priority. Or it can look as another "filter" but have it's own behaviour. Or it can not be as filter at all and be placed somewhere else.
Makes sense.
So I was looking at the wiki page again, and one small detail is that both in Paul's and John's cases, they are doing workstation tasks with a server tool. Could John's issue be that ftpd crashes irregulary (to still make it about file management, I like the data loss part of it, since it's super-critical), and Charles case be that a developer at his company has to join a build server (the build server would run Cockpit) to the active directory domain? - Andreas
Oh, as I read the Paul's story now again, I see that. When I was writing the story I had in my mind that they were copying files remotely (to server or between each-other) but it is not in the story. But I like your idea about crashing ftpd more than mine about file-manager. It makes more sense. Considering John's story, I don't see such big difference between ours and yours story, but if you believe it suits cockpit's purpose better, I don't mind changing that.
Will you update the stories or should I take a look on it?
MM
On 2017-02-23 10:58, Matej Marusak wrote:
Oh, as I read the Paul's story now again, I see that. When I was writing the story I had in my mind that they were copying files remotely (to server or between each-other) but it is not in the story. But I like your idea about crashing ftpd more than mine about file-manager. It makes more sense. Considering John's story, I don't see such big difference between ours and yours story, but if you believe it suits cockpit's purpose better, I don't mind changing that.
Will you update the stories or should I take a look on it?
I can do it. - Andreas
On 2017-02-23 10:58, Andreas Nilsson wrote:
On 2017-02-23 10:58, Matej Marusak wrote:
Oh, as I read the Paul's story now again, I see that. When I was writing the story I had in my mind that they were copying files remotely (to server or between each-other) but it is not in the story. But I like your idea about crashing ftpd more than mine about file-manager. It makes more sense. Considering John's story, I don't see such big difference between ours and yours story, but if you believe it suits cockpit's purpose better, I don't mind changing that.
Will you update the stories or should I take a look on it?
I can do it.
- Andreas
Tweaked the stories and uploaded two initial design proposals that should work for those stories. https://github.com/cockpit-project/cockpit/wiki/Feature:-ABRT
* Variant one is embedded into the Logs page. This threats crashes as one level above Errors. I was not sure if there needs to be a bugzilla login-thing or not, or if it works to just open bugzilla in a separate tab.
* Variant one is on it's own page. This is if it doesn't fit to mix crashes into the logs. Right now Logs is a 1-to-1 match with the journalctl command.
Let me know what you think, and if there is something wrong or missing from the designs. - Andreas
Wow, the design looks cool.
One comment: Are you sure you want to use the terms "Crash" and "Crashers"?
Not every ABRT problem is a crash:
- Python exceptions do not always cause a crash
- Kernel oopses are not crashes at all
- There might be other problem types like Eclipse ones [1]
- ABRT Java connector can be configured to report also caught exceptions [2]
Kind regards,
Jakub
1: https://pagure.io/eclipse-abrt
2: https://github.com/jfilak/abrt-java-connector
---------- Původní zpráva ---------- Od: Andreas Nilsson lists@andreasn.se Komu: cockpit-devel@lists.fedorahosted.org Datum: 27. 2. 2017 14:05:37 Předmět: Re: Supporting ABRT in Cockpit
"On 2017-02-23 10:58, Andreas Nilsson wrote:
On 2017-02-23 10:58, Matej Marusak wrote:
Oh, as I read the Paul's story now again, I see that. When I was writing the story I had in my mind that they were copying files remotely (to server or between each-other) but it is not in the story. But I like your idea about crashing ftpd more than mine about file-manager. It makes more sense. Considering John's story, I don't see such big difference between ours and yours story, but if you believe it suits cockpit's purpose better, I don't mind changing that.
Will you update the stories or should I take a look on it?
I can do it.
- Andreas
Tweaked the stories and uploaded two initial design proposals that should work for those stories. https://github.com/cockpit-project/cockpit/wiki/Feature:-ABRT
* Variant one is embedded into the Logs page. This threats crashes as one level above Errors. I was not sure if there needs to be a bugzilla login-thing or not, or if it works to just open bugzilla in a separate tab.
* Variant one is on it's own page. This is if it doesn't fit to mix crashes into the logs. Right now Logs is a 1-to-1 match with the journalctl command.
Let me know what you think, and if there is something wrong or missing from the designs. - Andreas _______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org "
On 2017-02-28 10:57, jfilak@fedoraproject.org wrote:
Wow, the design looks cool.
One comment: Are you sure you want to use the terms "Crash" and "Crashers"?
Not every ABRT problem is a crash:
- Python exceptions do not always cause a crash
- Kernel oopses are not crashes at all
- There might be other problem types like Eclipse ones [1]
- ABRT Java connector can be configured to report also caught
exceptions [2]
I'm not married to that term at all. What's a better name for it? "Problems", "Errors", "Irregularities"? - Andreas
On 02/28/2017 05:40 AM, Andreas Nilsson wrote:
On 2017-02-28 10:57, jfilak@fedoraproject.org wrote:
Wow, the design looks cool.
One comment: Are you sure you want to use the terms "Crash" and "Crashers"?
Not every ABRT problem is a crash:
- Python exceptions do not always cause a crash
- Kernel oopses are not crashes at all
- There might be other problem types like Eclipse ones [1]
- ABRT Java connector can be configured to report also caught exceptions [2]
I'm not married to that term at all. What's a better name for it? "Problems", "Errors", "Irregularities"?
Anomalies?
On 2017-02-28 14:01, Stephen Gallagher wrote:
On 02/28/2017 05:40 AM, Andreas Nilsson wrote:
On 2017-02-28 10:57, jfilak@fedoraproject.org wrote:
Wow, the design looks cool.
One comment: Are you sure you want to use the terms "Crash" and "Crashers"? Not every ABRT problem is a crash:
- Python exceptions do not always cause a crash
- Kernel oopses are not crashes at all
- There might be other problem types like Eclipse ones [1]
- ABRT Java connector can be configured to report also caught exceptions [2]
I'm not married to that term at all. What's a better name for it? "Problems", "Errors", "Irregularities"?
Anomalies?
What does the documentation (RHEL/Fedora) usually refer to abrt objects as? - Andreas
You may find mentions of "crashes" in the old documentation, but we prefer "problems".
We have been trying to move from "crashes" to "problems" since we introduced kernel oopses.
It's a never ending story. One has to think a lot before introducing a new term :)
Jakub
---------- Původní zpráva ---------- Od: Andreas Nilsson lists@andreasn.se Komu: cockpit-devel@lists.fedorahosted.org Datum: 28. 2. 2017 16:00:57 Předmět: Re: Supporting ABRT in Cockpit
"On 2017-02-28 14:01, Stephen Gallagher wrote:
On 02/28/2017 05:40 AM, Andreas Nilsson wrote:
On 2017-02-28 10:57, jfilak@fedoraproject.org wrote:
Wow, the design looks cool.
One comment: Are you sure you want to use the terms "Crash" and
"Crashers"?
Not every ABRT problem is a crash:
- Python exceptions do not always cause a crash
- Kernel oopses are not crashes at all
- There might be other problem types like Eclipse ones [1]
- ABRT Java connector can be configured to report also caught exceptions
[2]
I'm not married to that term at all. What's a better name for it?
"Problems",
"Errors", "Irregularities"?
Anomalies?
What does the documentation (RHEL/Fedora) usually refer to abrt objects as? - Andreas _______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-leave@lists.fedorahosted.org "
On 2017-02-28 16:19, jfilak@fedoraproject.org wrote:
You may find mentions of "crashes" in the old documentation, but we prefer "problems". We have been trying to move from "crashes" to "problems" since we introduced kernel oopses. It's a never ending story. One has to think a lot before introducing a new term :)
I changed all instances from "crashes" to "problems" now. https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/cras... - Andreas
I really like the design. After looking through the wireframes I was not sure about two things:
I've noticed that there is no mock-up of tab 'general'. Does this tab looks like any other log? (So contains priority, machine_id, hostname etc.?)
On topic of bugzilla - I think it would be sufficient to open BZ in separate tab with prefilled data. But from yours drawings I am not sure, where I can find link to BZ after reporting it. (Both it can come after reporting to FAF (if BZ was already created) or after I use 'file issue' and fill everything).
MM
On 2017-03-01 07:59, Matej Marusak wrote:
I really like the design. After looking through the wireframes I was not sure about two things:
I've noticed that there is no mock-up of tab 'general'. Does this tab looks like any other log? (So contains priority, machine_id, hostname etc.?)
I think so at least. Does it make sense?
On topic of bugzilla - I think it would be sufficient to open BZ in separate tab with prefilled data. But from yours drawings I am not sure, where I can find link to BZ after reporting it. (Both it can come after reporting to FAF (if BZ was already created) or after I use 'file issue' and fill everything).
Sorry for not specifying that before. I've added what happens once you filed a bug to the mockup: https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/cras... - Andreas
Dne 27.2.2017 v 14:05 Andreas Nilsson napsal(a):
Let me know what you think, and if there is something wrong or missing from the designs.
I like it too.
I would not ask for bugzilla login/password in Cockpit. When reporting issue I would propose to use button with link: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&comment=foobar which will open BZ in your browser with prefilled description/components and it is up to your browser/last pass to use correct credentials.
We thought about reporting to bugzilla bit more and it does not seem to be that simple to only open new tab. We would like to see a complex reporting solution (something like reporting with gnome-abrt [1] - that means asking if user wants to retrace locally or remotely, asking for review of data, login to BZ...). Implementing this is a rather complex job (although some work has already been done). Therefore our suggestion is to in the first version support only ureports (to faf). Later we would add support for reporting to bugzilla since we want to make it properly.
Also when sending ureport we probably don't need the pop-up window asking for conformation since ureport does not contain any private data. This window will be however needed when reporting to bugzilla.
MM
On 2017-03-02 14:32, Matej Marusak wrote:
We thought about reporting to bugzilla bit more and it does not seem to be that simple to only open new tab. We would like to see a complex reporting solution (something like reporting with gnome-abrt [1] - that means asking if user wants to retrace locally or remotely, asking for review of data, login to BZ...). Implementing this is a rather complex job (although some work has already been done). Therefore our suggestion is to in the first version support only ureports (to faf). Later we would add support for reporting to bugzilla since we want to make it properly.
Yeah, makes sense. Lets leave it out of the first iteration and do it in a later version.
Also when sending ureport we probably don't need the pop-up window asking for conformation since ureport does not contain any private data. This window will be however needed when reporting to bugzilla.
Excellent. That simplifies the UI a lot. Made these changes to the mockup: https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/cras... - Andreas
Dne 2.3.2017 v 15:17 Andreas Nilsson napsal(a):
Excellent. That simplifies the UI a lot. Made these changes to the mockup: https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/cras...
I was thinking about the "Report" button and "Reported". The term "report" is little bit overloaded as someone can expect that it will in fact open a BZ issue. How we can emphasize the difference between "File issue"? The fact that "Report" button send just microreport to FAF (stripped of any private data)? I was thinking about: * "Send MicroReport" - too long * "μReport" or "microReport" - too cryptic? * leave it as is I would welcome any other ideas.
On 2017-03-03 09:53, Miroslav Suchý wrote:
Dne 2.3.2017 v 15:17 Andreas Nilsson napsal(a):
Excellent. That simplifies the UI a lot. Made these changes to the mockup: https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/cras...
I was thinking about the "Report" button and "Reported". The term "report" is little bit overloaded as someone can expect that it will in fact open a BZ issue. How we can emphasize the difference between "File issue"? The fact that "Report" button send just microreport to FAF (stripped of any private data)? I was thinking about:
- "Send MicroReport" - too long
- "μReport" or "microReport" - too cryptic?
- leave it as is
I would welcome any other ideas.
Yeah, "Microreport" is probably a bit cryptic indeed, and very much an implementation detail in my mind. Looking at reporting functions from other systems, they are a bit more explicit about where they send them. * "Send to Apple" in MacOS http://cdn.osxdaily.com/wp-content/uploads/2009/12/disable-crash-reporter.pn... * "Tell Mozilla about this..." https://support.mozilla.org/legacyfs/online/sumo-media/gallery/images/2013-0... * "Windows can send descriptions of problems on this server to Microsoft..." (in the settings only) https://i.stack.imgur.com/lo6fC.png
Those are mostly concerned with who you're reporting this information to, and doesn't worry too much about the distinction between the report collector and the bug tracker. One solution could be to give it a tooltip with a string like "Report to Fedora Analysis Framework" or "Report to Fedora problem analysis server". That addresses both the destination and difference to bugzilla. I wouldn't put it directly in the button, since it's such a long string, and it can become even longer in some languages.
How does it work in the cases of RHEL or CentOS? Does those problems get publicly published in the same place, or do they have separate problem collector services? - Andreas
On 2017-03-03 12:56, Andreas Nilsson wrote:
Those are mostly concerned with who you're reporting this information to, and doesn't worry too much about the distinction between the report collector and the bug tracker.
Just looked over some RHEL6 documentation, and I saw "Report Problem" used as part of a string there. I think that could work. So my suggestion would be "Report Problem" + the longer tooltip with the destination and provider. - Andreas
On 03/03/2017 07:00 AM, Andreas Nilsson wrote:
On 2017-03-03 12:56, Andreas Nilsson wrote:
Those are mostly concerned with who you're reporting this information to, and doesn't worry too much about the distinction between the report collector and the bug tracker.
Just looked over some RHEL6 documentation, and I saw "Report Problem" used as part of a string there. I think that could work. So my suggestion would be "Report Problem" + the longer tooltip with the destination and provider.
I'm just going to leave this here:
cockpit-devel@lists.fedorahosted.org
-
'Dominik Perpeet' -
Andreas Nilsson -
jfilak＠fedoraproject.org -
Matej Marusak -
Miroslav Suchý -
msuchy＠redhat.com
-
Stephen Gallagher