Project

General

Profile

Idea #13996

Updated by Tom Clegg about 5 years ago

This will enable an operator # Copy legacy config keys to move their configs from their existing RailsAPI configuration file (@/etc/arvados/api/application.yml@) to their equivalent cluster config file (@/etc/arvados/config.yml@), then delete the RailsAPI-specific file. 

 Features needed: 

 * The old Rails-only configuration file has precedence (otherwise, merely upgrading to this version could cause unanticipated config changes). keys (see [[Config migration key mapping]]) 
 * The operator can easily find out whether deleting their legacy config file would affect their runtime configuration. 
 * The operator can delete their legacy config file. 

 Suggested implementation: 

 At startup: 
 # Load the new cluster config defaults from static file included in package (this can be in the RailsAPI subtree for now, although in the future all arvados components will ship with a copy of it) 
 # Load new the actual cluster config from @/etc/arvados/config.yml@ (#13646) 
 # Load the legacy config @/etc/arvados/api/application.yml@ / @config/application.yml@ 
 # Copy legacy config keys to equivalent cluster config keys 

 Update @Rails.configuration@ API server application references to @Rails.configuration@ need to be updated to use the corresponding keys in the new config. 

 Provide script(s) or a rake task(s) for "dump" and "diff" to assist with config migration: 
 * "dump": load configuration (as above) and write task which reads the resulting config to stdout/file. This is the quickest way for the operator to make the legacy config file superfluous so it can be deleted. 
 * "diff": show and dumps the changes made by the "copy legacy config keys" step. This suits an operator who wants to update their new config incrementally and/or preserve comments in their new cluster config. 

 *NOT* included here: 

 * mechanism to split config into multiple files/fragments ("include") 
 * mechanism to overlay multiple configs (like the legacy config does with "common" + "production" sections) 
 * mechanism to avoid storing secrets in the config file 
 * update other components to read RailsAPI configs from the cluster config file instead of the discovery document 

Back