zowe-install.sh -I should not touch ~/.zowe_profile

[OnnoVdT]

Describe the bug zowe-install.sh -I, which does only install of Zowe, still uses/updates ~/.zowe_profile, while the data within is only needed for customization/runtime. This can break automated install by a userid that does not have ~/.zowe_profile set up properly.

To Reproduce Steps to reproduce the behavior:

1. delete/rename ~/.zowe_profile if present
2. ensure node is not installed in default location
3. invoke smpe.sh to do a SMP/E build in batch
4. you're now in an endless loop asking for the node directory

Expected behavior ~/.zowe_profile should be removed completely (values belong in zowe.yaml), but until then, all references to it should move in zowe-isntall.sh to after -i (install) processing.

Screenshots none

Desktop (please complete the following information): n/a

Smartphone (please complete the following information): n/a

Additional context none

[stevenhorsman]

Should be covered by #446

[stevenhorsman]

I'm fine with removing the .zowe_profile and that makes a lot of sense. The remaining question I have is what to do with the ZOWE_ZOSMF_PORT, ZOWE_JAVA_HOME, ZOWE_EXPLORER_HOST, ZOWE_IPADDRESS, ZOWE_EXPLORER_HOST, ZOWE_NODE_HOME variables. Do we want to still try and be clever and detect them? I think we have the following options:

1. At install time calculate/prompt for them and bake the result into the config.properties (Closest to my WIP branch)
   • The issue with this is SMP/E - the install is done on a separate machine, so unlikely to accurate. Do we just wipe them during SMP/E or have some custom SMP/E processing to re-populate. This might be a strategy we need for injecting a default rootDir/configDir
2. At 'config' time calculate/prompt for them and bake the result into the config.properties.
   • Are we even going to have a configure step after CUPIDS? Maybe for things like the certificate setup that are one time steps?
3. Allow users to leave the properties blank in the config.properties and we'll try and work them out at launch time, or fail validation otherwise
   • This isn't a great user experience as we cannot prompt during launch, so if our guesses are wrong we are likely to cause more failures?
4. Tell the users they always have to fill in the config.properties and remove our logic to try and guess
   • This means the default install will always have to be modified to run, which we've been trying to avoid until now.

@OnnoVdT @Joe-Winchester - any suggestions, or elaboration on new suggestions or other things that I've missed?

[stevenhorsman]

resolved by #844