Current a few things (mostly in zowe-init.sh IIRC) prompt the user for input/response. These are problematic for automation.
Conversation about this between Jack and I:
I'm not sure if we can provide a second way other than read, or provide an option to disable prompt. There are many chances I hit the prompt and the script simply paused when working with automation and it's very hard to find out where we are or which env var is missing. This is getting worse when we are using Ansible. The ansible playbook won't return anything on stdout before the script ends. So when it hits the prompt, there is no way the client side knows what's wrong. Also if we cancel the playbook on client-side, the shell script is still running on server side, we have to login to the server and kill the process.
Checking PS1 existence could be a way to check if the shell is in interactive mode but seems not covering all scenarios. So far seems checking i in $- is more promising.
@stevenhorsman
stevenhorsman 2 hours ago Author Member
I guess there are a couple of problems:
These scripts are called a fair way down the stack, so passing a flag through all is not great. We could make a opt on zowe-configure-instance.sh/zowe-setup-certificates.sh to make it non interactive and export a shell variable based on that? I'm not sure if -i would be confusing for non-interactive though!
What behaviour do we want for non-interactive? We obviously don't want to exit the script, so just print an error and continue?
@jackjia-ibm
jackjia-ibm 2 hours ago Member
NODE_HOME is mandatory in this case and for future steps to start Zowe, so I think if it's non-interactive mode, it's safe we prompt the error and exit the script.
@stevenhorsman
stevenhorsman 29 minutes ago Author Member
My concern is that not all of our scripts are idempotent, so I don't know if we will hit issues when the user fixes the issue then re-runs. Do you mind if I create a new issue for this rather than have to solve it right now?
Current a few things (mostly in zowe-init.sh IIRC) prompt the user for input/response. These are problematic for automation.
Conversation about this between Jack and I:
I'm not sure if we can provide a second way other than read, or provide an option to disable prompt. There are many chances I hit the prompt and the script simply paused when working with automation and it's very hard to find out where we are or which env var is missing. This is getting worse when we are using Ansible. The ansible playbook won't return anything on stdout before the script ends. So when it hits the prompt, there is no way the client side knows what's wrong. Also if we cancel the playbook on client-side, the shell script is still running on server side, we have to login to the server and kill the process.
Checking PS1 existence could be a way to check if the shell is in interactive mode but seems not covering all scenarios. So far seems checking i in $- is more promising.
@stevenhorsman stevenhorsman 2 hours ago Author Member I guess there are a couple of problems:
These scripts are called a fair way down the stack, so passing a flag through all is not great. We could make a opt on zowe-configure-instance.sh/zowe-setup-certificates.sh to make it non interactive and export a shell variable based on that? I'm not sure if -i would be confusing for non-interactive though! What behaviour do we want for non-interactive? We obviously don't want to exit the script, so just print an error and continue? @jackjia-ibm jackjia-ibm 2 hours ago Member NODE_HOME is mandatory in this case and for future steps to start Zowe, so I think if it's non-interactive mode, it's safe we prompt the error and exit the script.
@stevenhorsman stevenhorsman 29 minutes ago Author Member My concern is that not all of our scripts are idempotent, so I don't know if we will hit issues when the user fixes the issue then re-runs. Do you mind if I create a new issue for this rather than have to solve it right now?