Install script should use environment variables where possible

[telnoratti]

Currently the install script prompts on every variable that needs to be set, usually with some default. This is not particularly conducive for automated deployments as inserting a new input would break any scripts used to configure it now in unpredictable ways. For the dataverse-aws project I need to provide a newline delimited list of options and I'm concerned about this breaking in future updates that add new variables. I suggest the following behaviour:

1. For a given input, check if a corresponding environment variable exists. If yes, use that and skip all other steps.
2. If a flag "--automated" is specified in the install script, use the default value and skip all other steps.
3. Prompt the user for input using the default value if nothing is specified.

Step 2 would fix the issue of unpredictable builds and potentially breaking deployments, but since it requires the user consciously trying to deploy in an automated fashion it would not break the user experience when simply running the install script.

[pdurbin]

@telnoratti you seem to be saying you don't like the approach at https://github.com/IQSS/dataverse/blob/v4.5/scripts/deploy/phoenix.dataverse.org/install which is a bash script that defines a bunch of variables and then calls the installer script written in Perl.

At https://github.com/IQSS/dataverse/blob/v4.5/scripts/vagrant/install-dataverse.sh#L13 I call installer with some arguments (./install --hostname localhost $MAILSERVER_ARG --gfdir /home/glassfish/glassfish4 -y --force) but I'm not sure how much that helps. --force is something I added, and is supposed to be a bit like your --automated idea.

[telnoratti]

That script runs the glassfish-setup.sh and that works fine, especially I doubt users are trying to run glassfish-setup.sh in a non-automated way. The problem is with the install script.

Being able to specify all arguments as cli options is useful, but I think doesn't cover the use case of the --automated flag. So in dataverse-aws, I have a string that is basically a list of options delimited by new lines, but if another option is added to the install script, say SMTP relay port, then that will break. What I'd like is a way to tell the install script to use the defaults unless I override it specifically somehow. A cli option is just as good as an environment variable.

Hope this clears up my issue.

[pdurbin]

@telnoratti does the work done by @pameyer in #3799 help?

[oscardssmith]

My guess would be that it helps, but does not solve. The advantage of the approach outlined above is that defaults would be specified as key-value pairs, which causes things to work better if the fields are changed in the future.

[pdurbin]

@oscardssmith there already key value pairs at http://guides.dataverse.org/en/4.7/_downloads/default.config

This is documented at http://guides.dataverse.org/en/4.7/installation/installation-main.html#running-the-dataverse-installer

[pdurbin]

@telnoratti did you get a chance to look at #3799 or the docs linked above for running the installer non-interactively?

Also, there was some discussion today having to do with #4763 how at least in an OpenShift (and maybe Kubernetes) environment, there's a preference for not specifying secrets explicitly and only referencing them as environment variables.

Also, please feel free to weigh in on the future of the dataverse-aws repo at IQSS/dataverse-aws#11

Thanks!

[pdurbin]

@telnoratti I'd like to encourage you to review the installer redesign in pull request #4805 for #4764. Closing.