Launch Zowe with PARMLIB controlled configuration data running in a workspace directory

[Joe-Winchester]

Problem:
Zowe currently contains the runtime and configuration data in the same folder, so it isn't possible to launch more than Zowe runtime with separate ports and other variable data without having a new install.
At upgrade time Zowe is installed into a new folder so all of the previously set variable data is lost as it is overwritten

Solution:
Break Zowe down into a runtime_dir that is read only containing all of the code. Variable data such as ports, location of dependencies, keystore data, ... is not held in this directory
At start time ZOWE is started with a PARMLIB member that contains the variable data
The PARMLIB points to a directory that is a Zowe workspace. If the workspace does not exist it is created, if it already exists there is the ability to migrate.
The workspace data will contains an active_configuration.cfg that set environment variables for the unix shell.

Implementation details

Since completion of this work depends on #418, we will need to take a tactical approach to try and get things working before this time.

The proposal is to create a forked version of the run-zowe.sh script called, in which will we inject the variables, (in combination with standard unix environment variables) needed in the absence of a PARMLIB / etc config created.

The properties file will contain a properties which is a concatenation of all the components we're starting for this instance eg components=files-api,apiml

From this we'll start launching in the following pattern:

1. Read config variables into shell environment as variables
2. Validate properties:
   For each component in components list:
   a. Validate required properties using <ROOT_DIR>/components/<component id>/bin/validate.sh
   b. Generate unspecified ports/variables required (to remove the need for lots of explicit ports)
3. Backup config file eg. <USER_DIR>/active-configuration.cfg to <USER_DIR>/backup_configuration.yymmdd.hhmmss
4. Create new active configuration and copy properties into active-configuration (in key=value properties format).
5. (If first time then?) copy the zowe template workspace from read-only file systems Without the install changes we can just create a logs directory and try and copy the manifest from the install if we can find it?
6. Migrate config:
   For each component in components list:
   a. Run <ROOT_DIR>/components/<component_id>/bin/migrate.sh
   i. Check the config version <USER_DIR>/components/<component_id>/ and migrate if necessary? (If fails then error and prompt for rollback using the backup_configuration?)
7. Run launchers:
   For each component in components list:
   a. Run <ROOT_DIR>/components/<component_id>/bin/start.sh
   b. This component/service in a component is responsible for the following:
   i. (If first time then?) copy the component’s template config from read-only file systems if required
   ii. Inject any variables/parameters from environment variables into config. Eg. inject the hostname into an html file (use vtl?)
   iii. Create static definition if not dynamic, POST mediation layer to update defs Need to know the api-defs location - just derive from ROOT_DIR?
   iv. Start the services
   v. Once the service is started it writes to the log a fixed format message (Can we create a WTO message when issuing from BPXBATCH, also issue on shutdown)
8. Once all services are started we output an overall zowe is running message?

We will start with the file api as a first pass component with config driven from properties at launch time as it is fairly simple case and it will break ground on a bunch of the shared work #435

Once we can modify the install scripts we should move the properties out of run-zowe.sh fork and into PARMLIB/etc config/whatever we choose. #446

[JoeNemo]

This was addressed by the V2 Configmgr project.