Project

General

Profile

Actions

Bug #6590

closed

[Documentation] Improve documentation of API server configuration variables

Added by Brett Smith over 9 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
Documentation
Target version:
Start date:
07/13/2015
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
0.5

Description

In the API server installation guide:

  1. Under the header "Configure the API server," near the end of the discussion explaining application.yml and application.default.yml, add a new paragraph that explains:
    • This section of the documentation highlights settings that you must, or will likely want to change for your installation.
    • application.default.yml includes comments that explain each setting in more detail, including settings not documented here that are less frequently changed.
  2. Similar to the existing subsections for specific settings, add notes explaining the following settings users are likely to want to change:
    • websockets_address
    • git_internal_dir

In application.default.yml, move settings that are more likely to be changed, along with their documenting comments, nearer the top of the file; and settings less likely to be changed nearer the bottom. Don't sweat the exact order too much. You can think of them in three basic buckets: administrator must set this; administrator may be interested in changing this; administrator is unlikely to want to change this.


Subtasks 2 (0 open2 closed)

Task #6720: WriteResolvedPeter Amstutz07/13/2015

Actions
Task #6721: Review 6590-api-config-docsResolvedPeter Amstutz07/13/2015

Actions
Actions #1

Updated by Brett Smith over 9 years ago

  • Target version changed from 2015-08-19 sprint to 2015-08-05 sprint
Actions #2

Updated by Tom Clegg over 9 years ago

I agree that the config documentation should be more convenient, but I disagree about recommending copying/customizing application.default.yml. If you do that, after a few code updates the local config file will contain a lot of convincing-looking, but outdated, documentation -- which can easily cause more trouble than the inconvenience of having to (and knowing that you have to) cross-reference a docs-and-defaults file.

Unfortunately I don't know what the silver bullet is here, either. If our upgrade procedure could automatically (and safely) update the comments in the local config file, that'd be great, but it also seems unlikely. Would it help to extend our "rake config:check" task to make a more human-readable report of {config, default setting, local setting, doc string}? It's not very interactive, but it could be done safely and reliably.

Actions #3

Updated by Peter Amstutz over 9 years ago

  • Assigned To set to Peter Amstutz
Actions #4

Updated by Brett Smith over 9 years ago

  • Description updated (diff)
Actions #5

Updated by Brett Smith over 9 years ago

  • Description updated (diff)
Actions #6

Updated by Peter Amstutz over 9 years ago

  • Status changed from New to In Progress
Actions #7

Updated by Brett Smith over 9 years ago

Reviewing 415ecc4.

  • Can you explain to me what's going on with hardcoded_api_tokens.rb.example?
  • Please remove the "Additional settings" section and merge the text into the text that's immediately under the heading "Configure the API server" as written in the description. This text already explains the relationship between application.yml and application.default.yml, so it's a good place to point out that documentation is available from the latter but changes should be made to the former.
  • "Edit /etc/arvados/api/application.yml and to configure the settings described in the following sections." - remove one of "and to"
  • "Only put local configuration in application.yml, do not edit application.default.yml." - This is two sentences. They should be separated with a period.
  • I don't think we want to tell people to generate a random uuid_prefix. I think they can use whatever generation method they want, whether random or not. Did I miss a discussion somewhere?
  • Every instance of the text "set it to application.yml:" should change "to" to "in."
  • Under websockets_address:
    • There's text "Set websockets_address to the @wss:// URL" - that at-sign looks extraneous.
    • The example contradicts the text and gives an HTTPS URL. The text is correct; the example should use the WSS scheme.
  • The paragraph describing git_internal_dir has an extra "is" in the first sentence, and the third sentence seems a little redundant with the first. What about, "The git_internal_dir setting specifies the location of Arvados' internal git repository. Arvados stores every git commit run in a Crunch job here. By default this is /var/lib/arvados/internal.git."
  • Please restore the instructions to ensure a clone of the arvados repository lives under git_repositories_dir.

Thanks.

Actions #8

Updated by Brett Smith over 9 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 50 to 100

Applied in changeset arvados|commit:f3504dc2b40eaa4235092b671ce0bece43732904.

Actions

Also available in: Atom PDF