Re: errors.ubuntu.com: support for Server?
On 12 June 2013 22:01, Jorge O. Castro wrote: > On Fri, Jun 7, 2013 at 5:02 AM, Robie Basak wrote: >>> I'm intimately familiar with preseeding, that being my former life and >>> all, but I'm afraid I don't know what you mean by "global level." I >>> take it that's something related to MAAS? >> >> What I mean is that MAAS would have an option in its web UI that adjusts >> this preseed option for everything in one go, rather than the user >> having to customize preseeds manually. > > One thing we could also do is making an "error submission" subordinate > charm that we can encourage people to use on their development and > testing environments. That way people exploring certain stacks can > enable the submissions via an option in the Juju GUI but still run > clean in production. I like the idea. Let's work closely with the design team for juju to find the most usable way of exposing the error reporting toggle, then find an implementation to match. Jorge, last we spoke you were going to bring this up with the Juju GUI team. Shall we move this thread over to one of their lists? -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: errors.ubuntu.com: support for Server?
On 24 May 2013 17:20, Robie Basak wrote: > On Thu, May 16, 2013 at 07:01:54AM -0700, Evan Dandrea wrote: > What I mean is that data does not get uploaded without the user knowing > about it. So in my terms, error reporting on the desktop _is_ opt-in. In > the Desktop case, the user knows about it when the error reporting > dialog pops up. In the Server case, this is more difficult to achieve, > since there is not necessarily any UI available to prompt the user after > an error. Ah, thank you for clarifying. >> I'd prefer that we kept with the existing model of not asking >> questions, as this has been core to the redesign of apport and the >> development of the error tracker. > > OK, but we do effectively ask a single question on the desktop, right? We do. By "not asking questions" I mean not asking any questions beyond what is absolutely necessary. So yes, at some point we need to ask for their consent in sending all error reports, with each one, or even some combination of both – saying "no" to automatic error reporting could still notify you via motd that you have reports to manually process. What I do not think we should do is ask questions beyond that. Historically they've been confusing to our audience, but more importantly they reduce the likelihood that someone will respond. It's extra work, and they might not have the time for it. There are better ways. We can use scale to our advantage and given a report that's missing some critical detail we didn't anticipate, programmatically tell the next reporter's system to attach additional information. This involves no additional human interaction and is theoretically as fast as a few seconds as opposed to the usual Launchpad bug response time of days or weeks, if ever. >> 2) Any extra bit of work you put between a user and submitting an >> error report will cause some of those users to not send the report. >> They'll be hesitant to send subsequent reports if the process was >> previously onerous. > > Agreed - we need to make sure that the UX is as simple as possible. Great! >> > Production server operators may want to vet reports before agreeing to >> > send them, so an interactive CLI like aa-logprof(8) or apport-cli(1) >> > that allows users to see exactly what they are submitting would be >> > useful. So essentially a CLI equivalent of the GUI error reporting >> > dialog. >> >> The documentation for apport discusses one possible approach: >> >> http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/README#L51 >> >> The problem I have with this is that it's a very manual step. I'm not >> convinced many people who would otherwise be okay with automatic >> reporting will actually notice the message and follow through. It also >> delays our knowing the frequency of serious issues by relying on >> server administrators to log in and process the reports. > > Could this be reasonable as one fallback position for those who ask d-i > to turn off automatic uploads, or if we choose not to follow that path? Yes, I think unless the user explicitly disables the collection of reports (disabling apport in /etc/default/apport), we should still tell them what it's doing and how they can further process the results. So I would be very happy in taking that .bashrc chunk from apport and putting it in motd as a first step. > So where do we go from here? It seems that we have two proposals: > > 0) I presume that with both proposals we have the option of choosing > different defaults between stable and development releases? Yes, though do keep in mind that if we restrict ourselves to just development releases we are going to miss out on problems that would only crop up post-release. We've had serious ones with each new release of the desktop OS. > 1) A d-i prompt asking about error reporting. Outcome: automatic uploads > of error reports, or not. I understand that you want this to default to > automatic uploads, and your reasons. Yes please. > 2) The bash prompt modification at [1] by default. Yes please. :) > For MAAS, I presume that we could make the d-i preseed configurable at a > global level. I'm intimately familiar with preseeding, that being my former life and all, but I'm afraid I don't know what you mean by "global level." I take it that's something related to MAAS? > I'm not sure about juju without MAAS. Perhaps a configuration parameter > for the environment could feed cloud-init? That's vaguely what I was thinking. Either using constraints or kindly requesting that a new environments.yaml option be added to represent error reporting. The benefit of the latter is that's it's more discoverable, even if disabled by default. We could automatically populate it into environments.yaml with a comment explaining what it does and asking them to help make Ubuntu better by turning it on. We should ask them directly though, perhaps as a separate discussion to this one. Thanks! -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com ht
Re: errors.ubuntu.com: support for Server?
On Fri, Jun 7, 2013 at 5:02 AM, Robie Basak wrote: >> I'm intimately familiar with preseeding, that being my former life and >> all, but I'm afraid I don't know what you mean by "global level." I >> take it that's something related to MAAS? > > What I mean is that MAAS would have an option in its web UI that adjusts > this preseed option for everything in one go, rather than the user > having to customize preseeds manually. One thing we could also do is making an "error submission" subordinate charm that we can encourage people to use on their development and testing environments. That way people exploring certain stacks can enable the submissions via an option in the Juju GUI but still run clean in production. -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: errors.ubuntu.com: support for Server?
On Mon, Jun 03, 2013 at 05:35:48PM +0100, Evan Dandrea wrote: > On 24 May 2013 17:20, Robie Basak wrote: > > For MAAS, I presume that we could make the d-i preseed configurable at a > > global level. > > I'm intimately familiar with preseeding, that being my former life and > all, but I'm afraid I don't know what you mean by "global level." I > take it that's something related to MAAS? What I mean is that MAAS would have an option in its web UI that adjusts this preseed option for everything in one go, rather than the user having to customize preseeds manually. signature.asc Description: Digital signature -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: errors.ubuntu.com: support for Server?
On Thu, May 16, 2013 at 07:01:54AM -0700, Evan Dandrea wrote: > Why do you assume an opt-in system? Error reporting on the desktop is > not opt-in, and for good reason: our data would be heavily skewed to > the types of people who already know that the error reporting > functionality exists, can find the toggle to turn it on, and are so What I mean is that data does not get uploaded without the user knowing about it. So in my terms, error reporting on the desktop _is_ opt-in. In the Desktop case, the user knows about it when the error reporting dialog pops up. In the Server case, this is more difficult to achieve, since there is not necessarily any UI available to prompt the user after an error. > I'd prefer that we kept with the existing model of not asking > questions, as this has been core to the redesign of apport and the > development of the error tracker. OK, but we do effectively ask a single question on the desktop, right? > 1) We have been historically quite bad at understanding our audience > when programmatically communicating with them. [...] > 2) Any extra bit of work you put between a user and submitting an > error report will cause some of those users to not send the report. > They'll be hesitant to send subsequent reports if the process was > previously onerous. Agreed - we need to make sure that the UX is as simple as possible. [...] > I think we should find a solution with that balance in mind. I've > suggested in the past that we do this at installation time with the > default option being to enable error reporting. So in the case of > debian-installer, a d-i component that asks whether you want to > disable error reporting. In the case of juju and maas, I'm not sure. This is certainly worth considering. > > Some implmentation ideas: > > > > Production server operators may want to vet reports before agreeing to > > send them, so an interactive CLI like aa-logprof(8) or apport-cli(1) > > that allows users to see exactly what they are submitting would be > > useful. So essentially a CLI equivalent of the GUI error reporting > > dialog. > > The documentation for apport discusses one possible approach: > > http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/README#L51 > > The problem I have with this is that it's a very manual step. I'm not > convinced many people who would otherwise be okay with automatic > reporting will actually notice the message and follow through. It also > delays our knowing the frequency of serious issues by relying on > server administrators to log in and process the reports. Could this be reasonable as one fallback position for those who ask d-i to turn off automatic uploads, or if we choose not to follow that path? > > Or perhaps some kind of remote ssh enhancement to the existing GUI error > > reporting dialog, so users get the same UI on a desktop machine that > > connects to a server machine, picks up the crash reports there generates > > and sends reports via the local GUI? > > That assumes they're running Ubuntu everywhere. It's presumably > confusing as you're suddenly getting error reports out of the blue. > We've been bitten hard by this with the "system internal" error > reports that pop up, confusing users who thought they hadn't actually > done anything. > > But most importantly, it's extra work for the end-users to get going. > Lets make the barrier to sending these reports as low as possible. Fair enough. [...] So where do we go from here? It seems that we have two proposals: 0) I presume that with both proposals we have the option of choosing different defaults between stable and development releases? 1) A d-i prompt asking about error reporting. Outcome: automatic uploads of error reports, or not. I understand that you want this to default to automatic uploads, and your reasons. 2) The bash prompt modification at [1] by default. For MAAS, I presume that we could make the d-i preseed configurable at a global level. I'm not sure about juju without MAAS. Perhaps a configuration parameter for the environment could feed cloud-init? Any other proposals from anyone? Robie [1]: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/README#L51 signature.asc Description: Digital signature -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
Re: errors.ubuntu.com: support for Server?
Hi,
Le 16/05/2013 09:10, Robie Basak a écrit :
> Some implmentation ideas:
One item that came up during the discussions of the kdump-tools
blueprint[1] was the eventual possibility to send the error reports
triggered by kernel crashes to an intermediate "in house" server that
would act as a proxy/filter/gateway/{insert your favorite term here}
before sending it to daisy.ubuntu.com
This would be particularly useful in data center where servers do not
have direct visibility to the Internet. It would also be an interesting
source of information to review for sysadmins who want to know
where/what is failing in their infrastructure.
Configured as a proxy, it would proxy the events and keep a local copy
of the reports before sending to daisy.ubuntu.com. Configured as a
gateway, sysadmins could elect to send the reports, sanitize the data
before sending or investigate the issue themselves. This would also be
an incentive to them to build their own apport tools for their own
in-house software if they want to.
This is just brainsorming, but many of us in the discussion thought that
having an intermediate server before sending things out could be useful.
HTH,
...Louis
[1] https://blueprints.launchpad.net/ubuntu/+spec/servercloud-r-kdump-tool
--
Louis Bouchard
Backline Support Analyst
Canonical Ltd
Ubuntu support: http://canonical.com/support
--
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam
Re: errors.ubuntu.com: support for Server?
Hi Robie, Thanks for kicking off this discussion. On Thu, May 16, 2013 at 12:10 AM, Robie Basak wrote: > that will cause us to misinterpret the results? Is there any need to > categorise the reports at submission time (eg. perhaps ask the reporter > a question)? I'd prefer that we kept with the existing model of not asking questions, as this has been core to the redesign of apport and the development of the error tracker. Two points on this: 1) We have been historically quite bad at understanding our audience when programmatically communicating with them. "Thanks for reporting this bug. It seems you have unity running. Is the issue you are reporting is related to unity itself rather than compiz?" What's Unity? What's Compiz? Even if I know what both of those are, how on Earth do I know which one is responsible for my bug? I'm just going to close this thing because I don't know what the correct answer is. 2) Any extra bit of work you put between a user and submitting an error report will cause some of those users to not send the report. They'll be hesitant to send subsequent reports if the process was previously onerous. > What should the UX be? How should we protect privacy and avoid reports > inadvertently being submitted by users who do not wish to submit them? > > Should we have different UX defaults between the development and > production releases? > > If the system is opt-in (which I assume it will be), will we have enough > users opting in for the system to be useful? Why do you assume an opt-in system? Error reporting on the desktop is not opt-in, and for good reason: our data would be heavily skewed to the types of people who already know that the error reporting functionality exists, can find the toggle to turn it on, and are so passionate about providing error data that they do turn it on. On the desktop, this is handled by a checkbox that's ticked by default with the heading: "Send an error report to help fix this problem." I think we should find a solution with that balance in mind. I've suggested in the past that we do this at installation time with the default option being to enable error reporting. So in the case of debian-installer, a d-i component that asks whether you want to disable error reporting. In the case of juju and maas, I'm not sure. > Some implmentation ideas: > > Production server operators may want to vet reports before agreeing to > send them, so an interactive CLI like aa-logprof(8) or apport-cli(1) > that allows users to see exactly what they are submitting would be > useful. So essentially a CLI equivalent of the GUI error reporting > dialog. The documentation for apport discusses one possible approach: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/README#L51 The problem I have with this is that it's a very manual step. I'm not convinced many people who would otherwise be okay with automatic reporting will actually notice the message and follow through. It also delays our knowing the frequency of serious issues by relying on server administrators to log in and process the reports. > Or perhaps some kind of remote ssh enhancement to the existing GUI error > reporting dialog, so users get the same UI on a desktop machine that > connects to a server machine, picks up the crash reports there generates > and sends reports via the local GUI? That assumes they're running Ubuntu everywhere. It's presumably confusing as you're suddenly getting error reports out of the blue. We've been bitten hard by this with the "system internal" error reports that pop up, confusing users who thought they hadn't actually done anything. But most importantly, it's extra work for the end-users to get going. Lets make the barrier to sending these reports as low as possible. > An update-motd enhancement to notify server operators that crash reports > are pending. This could provide the command to type to enter the > interactive CLI to submit them and a reference to a manpage with more > details on how to turn off local crash report collection. > > A bash prompt enhancement present only during development, which prompts > users with a shorter version of the motd prompt. Or would this be too > intrusive? I thought of it because I imagine users not logging in much > to test servers, and so might not see the motd prompt (I rarely see the > motd prompt when I test, since I use ssh shared connections and > short-lived cloud instances). > > Other thoughts: > > Right now I feel that the information we get from users about Server > quality is poor. As always, some bug reports are awesome, are from > competent submitters, and highlight real problems which we need to fix. > But many bugs filed appear to be automatic and in response to postinst > failures due to local misconfigurations. I think this overrepresents the > set of users who are experimenting and underrepresents the users > who are using Server in production. I'm not sure we get any other real > feedback abo
Re: errors.ubuntu.com: support for Server?
Another idea: A debconf option to automatically upload all crash reports, and an installer prompt to enable this. Could the debconf priority and default differ in the installer depending on whether we're on the development release or not? -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
errors.ubuntu.com: support for Server?
errors.ubuntu.com has been a great success on the desktop[1]. Would support for sending reports from server installations be useful? Even though vUDS is already underway, I thought a mailing list discussion would be more useful than a session to throw ideas around first. We can always arrange a separate out-of-band discussion on G+ if it looks like this would be useful. What would you like to see? Here are some questions and ideas to get us started. Who would be willing to submit reports? Production servers? Test deployments? Experimenters? Any other categories? Which of these categories of reports will be useful to us? Are there any that will cause us to misinterpret the results? Is there any need to categorise the reports at submission time (eg. perhaps ask the reporter a question)? What should the UX be? How should we protect privacy and avoid reports inadvertently being submitted by users who do not wish to submit them? Should we have different UX defaults between the development and production releases? If the system is opt-in (which I assume it will be), will we have enough users opting in for the system to be useful? Some implmentation ideas: Production server operators may want to vet reports before agreeing to send them, so an interactive CLI like aa-logprof(8) or apport-cli(1) that allows users to see exactly what they are submitting would be useful. So essentially a CLI equivalent of the GUI error reporting dialog. Or perhaps some kind of remote ssh enhancement to the existing GUI error reporting dialog, so users get the same UI on a desktop machine that connects to a server machine, picks up the crash reports there generates and sends reports via the local GUI? An update-motd enhancement to notify server operators that crash reports are pending. This could provide the command to type to enter the interactive CLI to submit them and a reference to a manpage with more details on how to turn off local crash report collection. A bash prompt enhancement present only during development, which prompts users with a shorter version of the motd prompt. Or would this be too intrusive? I thought of it because I imagine users not logging in much to test servers, and so might not see the motd prompt (I rarely see the motd prompt when I test, since I use ssh shared connections and short-lived cloud instances). Other thoughts: Right now I feel that the information we get from users about Server quality is poor. As always, some bug reports are awesome, are from competent submitters, and highlight real problems which we need to fix. But many bugs filed appear to be automatic and in response to postinst failures due to local misconfigurations. I think this overrepresents the set of users who are experimenting and underrepresents the users who are using Server in production. I'm not sure we get any other real feedback about quality right now, apart from general inferences that we can draw from talking to people. So if we think it's worthwhile, I'd love to see better sources of this information. So...what should we do, if anything? Please discuss! [Daviey] Just need to work out, *if* it is worth doing .. *how* to do it.. and *who* to do it :) [1]: http://www.youtube.com/watch?v=PPQ7k0jRUE4#t=30m8s signature.asc Description: Digital signature -- ubuntu-server mailing list ubuntu-server@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-server More info: https://wiki.ubuntu.com/ServerTeam
