How to Report Issues in Arvados

First: Thanks for helping us improve Arvados!

If you encounter a problem using Arvados, the surest way to see it fixed is to report an issue on our bug tracker. The best bug reports include:

  • all the steps you took that led to the issue,
  • the action Arvados took, including the full text of any error messages it reported, and
  • the action you expected Arvados to take (even if that's as simple as "it shouldn't crash").

If the problem involves Workbench, it can also be very helpful to report the Workbench and API versions you were using (click the Help icon at the top right, and choose "show version/debugging info").


Some issues are best illustrated with reference to specific data in Arvados—for example, maybe you're having trouble accessing a particular collection. When you file issues like this, please be aware that certain identifiers, like portable data hashes and block locators from Collection objects, can reveal details about your work to the public. Here are some guidelines to help protect your privacy:
  • API tokens should not be shared.
  • Collection portable data hashes like 1f4b0bc7583c2a7f9102c395f4ffc5e3+45 and block identifiers like acbd18db4cc2f85cedef654fccc4a4d8+3 should not be shared if you don't want people to know which datasets you are working with.[1]
  • Keep block permission signatures are not sensitive as long as you don't share your API tokens.
  • Arvados UUIDs like zzzzz-yyyyy-abcde12345fghij do not reveal anything about the content of jobs, pipeline instances, pipeline templates, and collections (except, of course, to other users who have access to those items via Arvados's sharing features).
  • If you're having trouble with sensitive data or processes, refer to it through the UUIDs of data that are safe to talk about—for example, "the input parameter of pipeline instance P," or "the output of job J."
  • If you're including a large error message like a backtrace from a command-line tool, please take care to edit out any sensitive identifiers, and other strings like filenames, that shouldn't be public.

1 Showing a hash does not give anyone access to the data content, but it does enable someone who already has access to that data by some other means (or even just its data hash) to confirm that you were using it. You might not want to reveal the fact that you are using that dataset, even if the dataset itself only contains unrestricted public data.

Updated by Michael Crusoe almost 2 years ago · 8 revisions