Move the z/OSMF workflows out of Zowe builds into a separate downloadable location

[Joe-Winchester]

The Zowe workflows are included with the SMP/E distribution. This means that they are difficult to refresh.

Describe the solution you'd like
Provide a way for the workflows to be available outside of a Zowe distribution.

Possible options

• Provide then in a github repo that a customer can obtain the raw XML for.
• Provide an archive file in artifactory that a customer can download, sftp to their z/OS file system, expand, and point z/OSMF at
• Provide the workflows in the zorrow project, e.g. https://github.com/openmainframeproject/zorow

[Joe-Winchester]

Comments from Marne Walle - IBM architect of z/OS installation and distribution
...

1. My assumption: You've got several workflows, one of which does the SMP/E installation of the FMID that is in the smp-zip file on the internet you download. This SMP-Installation Workflow is run first, then other workflows (I'll call Customization Workflows) can run afterwards. The Customization Workflows "match up" with the code in Zowe that is installed. Meaning, the configuration work is closely tied to what content is in the PTF, so we need to deliver those workflows in a PTF concurrent with the code they support.

2. Today all workflows are in the FMID, but you've got this chicken-egg problem with the SMP-Installation Workflow specifically. I don't see problems with the other workflows, as they are all post-installation which could cover PTF installation as well as FMID installation. So, you are looking at if you should separate out the SMP-Installation Workflow to delivery in a different package than the smp-zip file.
   Marna's Answer: Yes. For the SMP-Installation Workflow, it should be separated so you can independently fix or enhance what you need corresponding to FMID in the smp-zip file, and fully avoid any FMID refresh. Whether that was Joe's Updated to fix Explorer related security issues #1 or Added code to pre-create directories for Liberty that need to have th… #2 below, that's your call based on how your users will need it. My two cents would be to put it right next to the smp-file though (https://www.zowe.org/download ), so it's in the same location and you don't have to go elsewhere to find it. And the user will know it is a match for the smp-zip file. Please don't: recut the FMID to include the SMP-Installation Workflow changes, or put it in a different FMID (which only has the SMP-Installation Workflow) that you refresh/reship. These recuts are likely to be discontinued inside IBM, but beyond that, it is only done for incorporated PTFs onto an existing FMID to "sqaush" the service. With the SMP-Installation Workflow not being in the FMID or service (and "outside"), this isn't a reason to refresh anyway.

If you want to contribute this SMP-Installation Workflow to zorow, that would be great! I just would contribute it as more of an example of installing any FMID, rather than The Way To SMP/E Install Zowe.

3. Let's assume you now have the SMP-Installation Workflow available outside of the smp-zip file (probably from the same location on the web). The customer would then use the SMP-Installation Workflow (which itself might be in a zip itself if you 've got supporting programs for it), and is kept up to date for simply the FMID installation. Once the SMP-Installation Workflow is done, the customer moves on to the Customization Workflows which are found in the FMID's target libraries (and nicely match the code that is in the target libraries).

4. Now comes time for a PTF. Note, I could even install the PTFs before I'd even initially completed any Customization Workflow at all, which is a very likely scenario. Who wants to customize "old" code, when they could install PTFs and customize the code level they are going to use? The PTF hits a Customization Workflow, so it contains both the new code and the updated Customization Workflow. This PTF has a nice HOLD ACTION which says to run that Customization Workflow after the PTF installed.
   My assumption: this Customizaton Workflow should be run after the code is installed into the target library, so there is never a chicken-egg problem with these types of workflows.

5. Consideration: z/OSMF Software Update is about thisclose to being GA. With z/OSMF Software Update, this provides a friendly and simple way to install PTFs on an existing Software Instance. I would recommend that when available, we recommend Zowe users to use this, especially if they selected your SMP-Installation Workflow path. I'd say this would be the best simple interactive way for PTFs to be installed after the FMID has been laid down. It also helps with your desire to do a refresh, as it won't be as hard to do PTF installation, so who needs a refresh.
   The catch: you need to install PTFs with z/OSMF Software Update on a Software Instance. After your SMP-Installation Workflow, you don't have a Software Instance just yet. Your SMP-Installation Workflow could do an additional step at the end, to define that Software Instance (using existing REST APIs https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.izua700/izuprog_API_AddSoftwareInstance.htm ) to get that done. Then you're set for position for easier PTF installation.

6. Longer Term Consideration: We've talked about using a Zowe Portable Software Instance to install. This could replace your SMP-Installation Workflow, by putting the user through the z/OSMF Software Management application, rather than the Workflow application.
   Benefit: In the Portable Software Instance, you can "hook up" your Customization Workflows to be launched into directly for the user. Meaning, your 4 (?) Customization Workflows could be "managed" within your Portable Software Instance. The user could download the smp-zip file (now, really, a Portable Software Instance) to their workstation and unzip it there. z/OSMF Software Management can pull it from the workstation, so there is no hassle with an upload anymore.
   Heck, if you still wanted to do a "refresh", you easily could that by exporting a higher service level of Zowe in the Portable Software Instance (meaning: the FMID and more PTFs are pre-installed) and letting new users take the higher level, or existing users could re-take a higher level. Creating a Portable Software Instance is extremely easy, once you have the Software Instance to create it from. It would be a "refresh" that you deliver and control yourself. You could automate that to happen every PTF, if you wanted.
   Downside: The user will need z/OSMF Software Management, in addition to Workflows, accessible on the driving system. This is not a problem, I think.

7. Much Longer Term Consideration: Were we to ever have REST APIs to drive the z/OSMF Software Management deployment (which is interactive with the z/OSMF GUI today) and PTF installation (which will be interactive with z/OSMF Software Update), you could even leverage an automation engine such as Ansible to do your installation. Workflow invocation is drivable from Ansible today, if you cared.
   ...

[jp669844]

z/OSMF PSWI is available together with configuration workflows. I believe SMP/E workflows are not needed and in Zowe v3, they should be removed.