Install Experience To Be

Install Experience To Be:

1. Hills

• Enterprise Installer
• Upgrade
• Configure
• Start
• Lifecycle
• Extend
• Sysplex Aware
• Automation
• Development and Testing

Enterprise Installer

As a system programmer I can install Zowe using SMP/E

As an extender of Zowe I can deliver emergency fixes and user mods to my customers

As a customer I can have a single Zowe instance with supported extensions from multiple vendors without the need for duplicate base Zowe installs per vendor.

As a customer with commercial offerings from different vendors on top of a single Zowe I do not incur any issues when receiving emergency fixes to the base Zowe that are detected by a particular vendor needing a fix to base Zowe code

https://github.com/zowe/zowe-install-packaging/issues/414

Upgrade

As a system programmer I can update Zowe to the next release without losing configuration data or user preferences.

Configuration data includes ports, key and trust store data, dependency locations (z/OSMF, Java, node). User preferences include MVD pinned items, app preferences, … After the upgrade I do not have to redefine the configuration data. As a site if I have extended Zowe with additional non-base desktop apps, southbound servers, these are preserved during the upgraded and not lost

Technical details:

• Separate runtime and instance data

Configure

As a system programmer or developer I can configure variable configuration data in my Zowe instance in a single place (for example ports, locations of dependencies, keystores). There should be no need to edit configuration data deep in files themselves, allowing a fully automated and paramaterized bring up of a Zowe instance. Configuration of Zowe should be similar to other z/OS runtimes based on PROCLIB, PARMLIB pairing

As an extender of Zowe I may have startup configuration that needs to be dynamically controlled by introducing configuration variable data my own PARMLIB values into the ZOWE parmlib and have these flowed into my application.

As an extender of Zowe I may need access to other PARMLIB values that have shared scope, such as location of pre-reqs (Java, node, z/OSMF, gateway ports, ...)

https://github.com/zowe/zowe-install-packaging/issues/415

Start

As a developer or application tester from a single Zowe install I can start independent isolated Zowe runtimes without having to create separate Zowe installs. This allows testing of a private dev/shared dev/staging environment for a developer of an extension MVD app or southbound API server. Some config data would be shared (key and trust store, dependency locations).
Some config data would be isolated (ports) Each independent instance can define extension apps (API southbound servers, MVD apps).

Lifecycle

As a system programmer bringing up a Zowe instance, I can throttle which services are run. Base ZWESVR will bring up the core services of API Mediation Layer and Virtual Desktop servers, however other services and applications can be configured to be not started, and can be started and stopped and lifecycled independently of the core. Likewise core application services such as the API mediation layer or the desktop can be lifecycled without requiring the overriding started task to be stopped and restarted.

Extend

As an ISV or distributor of an extension of Zowe's capabilities, I would like to be able to extend an already installed Zowe on a USS file system without requiring any changes to the base Zowe runtime of configuration. This will allow upgrade of the base without my configuration extensions being lost.

Sysplex aware

As a system programmer I can have a single instance of Zowe installed on an LPAR that is able to be started on other LPARs on the same sysplex

Automation

As a system programmer installing and configuring Zowe instances, I can run the installation and configuration parts via automation (Zowe CLI script, z/OS shell scripts, z/OSMF workflows).

The installation and configuration script need to be able to run in an unattended mode without requiring interaction with the user. I can provide all the input to processes in one place. The process needs to be repeatable - the same input leads to name results. I can provide configuration values explicitly so they are not used from global system configuration or user specific profile unless I want. The auto-detection capabilities are useful but should be overridable and should be separated from the installation process into an individual step before the installation actions start.

Development and Testing

As a Zowe contributor, I can see the effects of my code changes as early as possible in the development process. I do not wait for a long time and do a lot of effort to see my changes in a PAX file and installed to z/OS. I can update my instance of Zowe on my workstation or my z/OS system quickly and with a good level of granularity using a standard process without ad-hoc update scripts.

This item is quite important because it enables us to developing Zowe in a better way.

Technical details:

• Packaging of Zowe on z/OS