From 5eec5cc7ae303edd5a68d8d6b1c54603d196b2ef Mon Sep 17 00:00:00 2001 From: Bjoern Gruening Date: Tue, 4 Jun 2024 21:30:24 +0200 Subject: [PATCH] rebuild Galaxy config --- doc/source/admin/galaxy_options.rst | 94 ++++++++++++++++++++++ lib/galaxy/config/sample/galaxy.yml.sample | 48 +++++++++++ 2 files changed, 142 insertions(+) diff --git a/doc/source/admin/galaxy_options.rst b/doc/source/admin/galaxy_options.rst index dd84ad13fb6b..cdf82ab688fd 100644 --- a/doc/source/admin/galaxy_options.rst +++ b/doc/source/admin/galaxy_options.rst @@ -748,6 +748,97 @@ :Type: seq +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +``object_store_templates_config_file`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +:Description: + Configured Object Store templates configuration file. + The value of this option will be resolved with respect to + . +:Default: ``object_store_templates.yml`` +:Type: str + + +~~~~~~~~~~~~~~~~~~~~~~~~~~ +``object_store_templates`` +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +:Description: + Configured Object Store templates embedded into Galaxy's config. +:Default: ``None`` +:Type: seq + + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +``file_source_templates_config_file`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +:Description: + Configured user file source templates configuration file. + The value of this option will be resolved with respect to + . +:Default: ``file_source_templates.yml`` +:Type: str + + +~~~~~~~~~~~~~~~~~~~~~~~~~ +``file_source_templates`` +~~~~~~~~~~~~~~~~~~~~~~~~~ + +:Description: + Configured user file source templates embedded into Galaxy's + config. +:Default: ``None`` +:Type: seq + + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +``user_config_templates_index_by`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +:Description: + Configure URIs for user object stores to use either the object ID + ('id') or UUIDs ('uuid'). Either is fine really, Galaxy doesn't + typically expose database objects by 'id' but there isn't any + obvious disadvantage to doing it in this case and it keeps user + exposed URIs much smaller. The default of UUID feels a little more + like a typical way to do this within Galaxy though. Do not change + this value once user object stores have been created. +:Default: ``uuid`` +:Type: str + + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +``user_config_templates_use_saved_configuration`` +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +:Description: + User defined object stores and file sources are saved in the + database with their last valid configuration. It may be the case + that the admin changes file source and object store templates over + time such that the variables and secrets an instance is saved with + no longer match the configuration's expected values. For this + reason, admins should always add new versions of templates instead + of just changing them - however people take shortcuts and + divergences might happen. If a template is changed in such a way + it breaks or if a template disappears from the library of + templates this parameter controls how and if the database version + will be used. + By default, it will simply be used as a 'fallback' if a + configuration cannot be resolved against the template version in + the configuration file. Using 'preferred' instead will mean the + stored database version is always used. This ensures a greater + degree of reproducibility without effort on the part of the admin + but also means that small issues are not easy to fix. Using + 'never' instead will ensure the config templates are always only + loaded from the template library files - this might make sense for + admins who want to disable templates without worrying about the + contents of the database. +:Default: ``fallback`` +:Type: str + + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ``enable_mulled_containers`` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -5506,3 +5597,6 @@ This requires the help_forum_api_url to be set. :Default: ``false`` :Type: bool + + + diff --git a/lib/galaxy/config/sample/galaxy.yml.sample b/lib/galaxy/config/sample/galaxy.yml.sample index 7d0b2cd340bb..bb4c6fc32d4f 100644 --- a/lib/galaxy/config/sample/galaxy.yml.sample +++ b/lib/galaxy/config/sample/galaxy.yml.sample @@ -705,6 +705,54 @@ galaxy: # FileSource plugins described embedded into Galaxy's config. #file_sources: null + # Configured Object Store templates configuration file. + # The value of this option will be resolved with respect to + # . + #object_store_templates_config_file: object_store_templates.yml + + # Configured Object Store templates embedded into Galaxy's config. + #object_store_templates: null + + # Configured user file source templates configuration file. + # The value of this option will be resolved with respect to + # . + #file_source_templates_config_file: file_source_templates.yml + + # Configured user file source templates embedded into Galaxy's config. + #file_source_templates: null + + # Configure URIs for user object stores to use either the object ID + # ('id') or UUIDs ('uuid'). Either is fine really, Galaxy doesn't + # typically expose database objects by 'id' but there isn't any + # obvious disadvantage to doing it in this case and it keeps user + # exposed URIs much smaller. The default of UUID feels a little more + # like a typical way to do this within Galaxy though. Do not change + # this value once user object stores have been created. + #user_config_templates_index_by: uuid + + # User defined object stores and file sources are saved in the + # database with their last valid configuration. It may be the case + # that the admin changes file source and object store templates over + # time such that the variables and secrets an instance is saved with + # no longer match the configuration's expected values. For this + # reason, admins should always add new versions of templates instead + # of just changing them - however people take shortcuts and + # divergences might happen. If a template is changed in such a way it + # breaks or if a template disappears from the library of templates + # this parameter controls how and if the database version will be + # used. + # By default, it will simply be used as a 'fallback' if a + # configuration cannot be resolved against the template version in the + # configuration file. Using 'preferred' instead will mean the stored + # database version is always used. This ensures a greater degree of + # reproducibility without effort on the part of the admin but also + # means that small issues are not easy to fix. Using 'never' instead + # will ensure the config templates are always only loaded from the + # template library files - this might make sense for admins who want + # to disable templates without worrying about the contents of the + # database. + #user_config_templates_use_saved_configuration: fallback + # Enable Galaxy to fetch containers registered with quay.io generated # from tool requirements resolved through Conda. These containers # (when available) have been generated using mulled -