Joe Winchester, Senior Technical Staff Member of IBM gives details on the feedback that was received during the recent “Play Forward” open call for The Open Mainframe Project’s Zowe framework. Joe also explains how the Zowe onboarding squad is looking to engage Zowe users with its “Componentize, Update, Package, Install, Distribute, Support” initiative to improve the Zowe installation process.
As the Open Mainframe Project‘s Zowe project reached 1.0 back in February 2019, the projects’ focus has changed from getting the initial contributions integrated and working together into smoothing out the overall experience of using Zowe. The Zowe onboarding squad held a “playforward” presentation and discussion on the current install and improvements on April 23rd and a recording with transcript is available at https://zoom.us/recording/share/Lf8BmxIvmpXjTwJNfqXvvB-_jgkEMEE3Id3G_VRkiT2wIumekTziMw.
Some of the feedback we got initially included:
- New releases of Zowe are fresh installs that are unable to share configuration and customization of previous releases.
- Configuration data is held in the same directory as the runtime. In order to launch multiple Zowe instances on different ports or different configurations requires different full installs
- The lack of an enterprise installer inhibits deployment into production without install history auditing, rollback, and other features that SMP/e provides.
- There is no prescribed location that a single shared and managed Zowe release gets installed into an LPAR that can be shared by different tools wishing to extend that single base. Without this there is the risk of a proliferation of Zowe instances on an LPAR. This widens the number of Zowe instances requiring maintenance and support as well as undermining the cross tool integration that is one of Zowe’s core goals.
- Zowe brings up many address spaces for functions that not all customers wish to use. Customers have asked for a more modular startup process as well as the ability to lifecycle address spaces independently similar to a micro-service runtime stack.
- Customers want the choice to consume Zowe releases, including PTFs and APARs, from commercial companies who extend Zowe through the support channels of the commercial company they have a relationship or contract with, but without impacting the ability to blend the solutions from commercial companies across a shared core Zowe software stack.
The onboarding squad in the Zowe project, which is a sub-group within the Zowe project that focuses on helping those new to Zowe with getting it successfully installed, is looking to improve this. Under an effort called “Componentize, Update, Package, Installl, Distribute, Support”, the onboarding squad wants to engage anyone who has installed Zowe to contribute to making the install experience better. Specific ideas being discussed include:
- Provide an SMP/e distribution with the ability for z/OS customers to consume base Zowe as well as apply PTFs and APARs.
- Separate runtime from launchtime data, with configuration variables being specified in a PARMLIB member so that independent launches of Zowe can be run with isolated ports and dynamic environment data
- Allow Zowe to be started in a more controlled way so that individual microservices can be independently started and stopped without bouncing the entire started task.
- Allow Zowe’s core function to be extended with new API servers and desktop applications at launch time without the base Zowe file structure requiring modification
Being an open source project means everyone can contribute to Zowe’s success, and this is a great opportunity to get started. Even if you can’t make the call, join the #zowe-onboarding channel on Slack or submit issues to the Install GitHub Repo to also participate in this work.
Cheers !
This blog originally ran on the IBM Developer blog. You can view the blog here.
