It would be nice to be able to put flags like --backend=kubernetes into a config file.
- Mentioned In
- T158244: Improve `webservice status` output
T156626: k8s webservice restart failure with `ValueError: get() more than one object; use filter`
T190696: [Gsoc 2018] Proposal for Toolforge webservice command Improvement
T190638: GSoC 2018 proposal for Improvements for the Toolforge 'webservice' command
T177603: Proposal: Improvements for the Toolforge 'webservice' command
T175768: Improvements for the Toolforge 'webservice' command
T154504: Make webservice backend default to kubernetes
- Mentioned Here
- T156626: k8s webservice restart failure with `ValueError: get() more than one object; use filter`
T158244: Improve `webservice status` output
That is true! If we do add a .webservicerc, I hope it it's yaml (rather
than a custom format) and we very clearly define what's in service.manifest
and what's in .webservicerc :)
Also possibly in the future when we've gotten rid of GridEngine we won't
Copied from comment on https://gerrit.wikimedia.org/r/#/c/435691/ where I wrote:
I mentioned fromfile_prefix_chars in T148872#2736050 as a way to process such a file and have it match the expected CLI argument syntax. I did not elaborate there, but my idea was to find a way to run the argparse parsing logic twice: first reading the rcfile and then again reading the CLI arguments.
Thinking more about how the CLI parser for webservice works however, this may end up being a vary large amount of refactoring to accomplish. The things that are really useful to set in the rcfile for a tool are the default backend (gridengine or kubernetes) and the default webservice type (varies by backend). The way that the type is set as a positional argument becomes problematic for inclusion in an rcfile however.
An alternate way to handle this could be to use https://docs.python.org/3/library/configparser.html to read the rcfile if it exists and then inject the backend and type values found during the main section when the associated CLI argument has not been passed.
My main reason for wanting this is that I would like webservice stop; webservice start to be able to preserve maintainer configured state rather than stopping any running service and then starting a lighttpd gridengine job. It would also be nice to have webservice shell be "sticky" in the same way.