You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The initial use case for this was the need for galaxycfg set instance_name autostart true to override the current hardcoded default of not starting instances when supervisord starts.
However, this led me to consider whether it's better to move the file-driven configuration of [galaxy:server] in galaxy.ini into a command line-driven configuration.
In favor of putting things in galaxy.ini, it's a familiar config interface for admins and those settings persist across removal from gravity, and in a location that is expected by the admin. However, the cli config paradigm seems to be fairly popular these days (see: docker, vagrant, zfs), and has the benefit of allowing for rapid changes and instantaneous syntax checking.
One downside of the cli-driven configuration is that settings would be persisted to a the internal configstate.json which users should not edit by hand. I think people prefer to have the option to config either way - for example, if I was deploying (e.g. with Ansible), I want to be able to write a config file rather than have to call a bunch of shell commands.
The text was updated successfully, but these errors were encountered:
… working,
although no previous state is preserved at this pointi, which will be
necessary to actually update supervisor. Adding/removing configs and
instances is all done via `galaxy create` and `galaxy destroy` now,
e.g.:
% galaxy create foo/bar config/galaxy.ini
`foo` is the instance name
`bar` is the config's "alias", aka a name that can be worked with
Most of everything else not related to adding/removing configs and
setting options is completely broken because the state file data
structure has completely changed and none of those functions have been
updated yet.
The initial use case for this was the need for
galaxycfg set instance_name autostart true
to override the current hardcoded default of not starting instances whensupervisord
starts.However, this led me to consider whether it's better to move the file-driven configuration of
[galaxy:server]
ingalaxy.ini
into a command line-driven configuration.In favor of putting things in
galaxy.ini
, it's a familiar config interface for admins and those settings persist across removal from gravity, and in a location that is expected by the admin. However, the cli config paradigm seems to be fairly popular these days (see: docker, vagrant, zfs), and has the benefit of allowing for rapid changes and instantaneous syntax checking.One downside of the cli-driven configuration is that settings would be persisted to a the internal
configstate.json
which users should not edit by hand. I think people prefer to have the option to config either way - for example, if I was deploying (e.g. with Ansible), I want to be able to write a config file rather than have to call a bunch of shell commands.The text was updated successfully, but these errors were encountered: