zowe/zac

Zowe Leadership Committee collaboration

zac's Issues

OMP projects for NPM

zlux want to publish one of our repos (zlux-widgets) as an npm package so that we can version & make use of them more easily, but it occurs to me that such a package may live under some OMP project for npm. Do we know of one? Does it make sense?

EPL-2.0 Component for OpenLiberty

Breaking out the Requirements Issue opened by Bruce Armstrong and replacing it with new issues for the known activities.

Work with VCU on capstone program.

Bob Dahlberg is putting something together - will attach proposal. Would be good for ZLC to comment and determine who could mentor.

Generic PPT Templates

During Zowe Sprint Playbacks, and possibly other user engagement sessions - the member companies of the Zowe project have PPT slides with copyrights respective to the individual companies (Broadcom, Rocket, etc.).

Could the ZLC provide a set of generic templates? What copyright info, if any, should be present on the slides?

Signing of interim builds

For non major releases where we drop n.n.n like 0.9.4, 0.9.5, etc I propose that we have a set of signing keys that the build team can use to validate the artifacts for governance purposes. I don't think that these interim builds are really "official" releases and so the signing can be done by the build team.

This item is to open this idea for discussion and identify alternatives if needed.

Ideally, for releases we need a process for signing that spreads the responsibility for signing and does not rely solely on one person.

Research / Implement pre-receive hooks rejecting unsigned commits

Developers often forget to sign their commits, especially if working with tooling that doesn't support signed commits by default. Rebasing a branch or other remedial steps for a long history of unsigned commits is painful at best. We should implement pre-receive hooks in all repositories to block unsigned commits.

z/OSMF - Dual use case (Sysprog & Dev)

Some customers will not allow developers to use z/OSMF because it is viewed as a Sysprog interface. Research and document the separation of access roles, and recommend any code changes need.

Open Source Development Metrics

Can we look into using a tool like Grimoire Lab to help us assess the health of our community?

Zowe Press Coverage To be Listed on Zowe.org

@jayenzi Can we list or create a news feed of Zowe coverage on Zowe.org somewhere?

Here's my current list:
ZDNet: https://www.zdnet.com/article/zowe-bringing-the-mainframe-to-the-open-source-world/
OMP Press Release: https://www.openmainframeproject.org/press/2018/08/28/open-mainframe-project-announces-the-launch-of-zowe-an-open-source-framework-that-strengthens-integration-with-modern-enterprise-applications
LeMagIT: https://www.lemagit.fr/actualites/252447710/Open-Source-avec-Zowe-IBM-CA-et-Rocket-Software-veulent-depoussierer-Z-OS
PacktHub: https://hub.packtpub.com/introducing-zowe-a-new-open-source-framework-to-simplify-development-on-z-os-backed-by-ibm/
Converge Network Digest: https://www.convergedigest.com/2018/08/open-source-zowe-framework-bridges-apps.html
DZone: https://dzone.com/articles/open-source-platform-strengthens-integration-with?utm_content=76358868&utm_medium=social&utm_source=twitter
Solutions Review: https://solutionsreview.com/cloud-platforms/open-mainframe-project-zowe/
Barry Baker Blog: https://www.ibm.com/blogs/systems/open-source-project-zowe-fast-simple-familiar-zos-development/?cm_mmc=OSocial_Twitter-_-Systems_Systems+-+Infrastructure-_-WW_WW-_-Zowe+Logo
Tuxmachines: http://www.tuxmachines.org/node/114948?quicktabs_bottomtabs=0
Mainframe Debate: https://mainframedebate.com/2018/08/23/raising-zowe-a-community-to-bring-developers-together/
Tim Brooks Blog: https://developer.ibm.com/code/2018/08/23/zowe-open-source-project-mainframe/
Matt Hogstrom LinkedIn Blog: https://www.linkedin.com/pulse/zowe-opensource-zos-really-matt-hogstrom/

Provide access to Z/OS instance.

I am new to mainframes and would like to try out Zowe. However, I don't have access to any Z/OS machines. Please provide a way to try out Zowe.

Default Pinned Zowe UI Plugins

@hogstrom @armstro @1000TurquoisePogs @jplinardon @stevenhorsman-ibm @nkocsis

Could the ZLC please review and vote by EOD 9/25 - the Zowe UI now defines a JSON file which will track pinned plugins on the Zowe UI taskbar. This JSON file does not, by default, contain the explorer-server plugins, but you can still reach these plugins through the "Start" menu on the bottom left of the UI and pin them from there.

Is the new behavior described above desirable or should we add scripts to the install process which set explorer-server plugins as pinned (via modifying the new JSON)?

z/OSMF - SSO participation

Gain agreement on design, staff implementation effort, set schedule and deliver for JWT/OAuth Single Sign On

Zowe Long Term Support Plan

As part of post-1.0.0 activities, we need to discuss how to support teams which have breaking changes in their near term development timeline. The term 'breaking' specifically refers to changes which would violate backwards compatibility within any public-facing API.

One suggestion:

• Given Zowe 1.x is generally available...
• New non-breaking code and maintenance flow into the 1.x PAX. We maintain nightly builds for 1.x, as well as incremental releases around sprint boundaries.
• All new code and maintenance, including breaking changes, flow into a 2.x PAX. This PAX is nightly-only until the community transitions from 1.x to 2.x. The ZLC should help or control the transition point from 1.x to 2.x as the 'currently supported' release. Once ZLC approves transition, 2.x begins incrementally releases on sprint boundaries, 3.x is created as nightly-only, and 1.x is sunset.

Consolidated z/OSMF Requirements

Review consolidated list of z/OSMF requirements including priorities examples

• SSO
• z/OSMF Lite
• Performance measurements
• Position on usage by more than sysprogs (for example developers)
• Position on sysplex support

WIP - Zowe Docker Repository

Investigate and setup a Docker Hub the Zowe org can use. Coordinate with OMP/LinuxFoundation.

z/OS Message ID Structure for Zowe

History

As the open sourcing of the ZSS has progressed it has highlighted the need for us to work with the IBM Message ID structure where applicable. I'm going to presume that some may not be fully aware of z/OS messages so a quick pre-amble, then the challenge and recommendation for discussion.

Messages are a core theme on z/OS and are issued when specific events occur. These messages are sent to a variety of destinations like the master console, JES log, System Log, specific consoles and Job Logs.

The messages are intended to document, inform and are also used to drive automation through systems like IBM's System Automation, CA Technologies' Ops MVS or BMC's AutoOperator. To be useful for automation, event technologies rely on the well formed message structure to change automation states, drive actions.

Zowe needs to generate a set of messages that are consistent with this long-standing approach. Not all messages that flow from Zowe need to follow this (debug logs, application messages, etc.) That said, most consumers and other ISVs will expect compatibility with this approach.

Format

The net is that messages for our purposes are:

CCCSnnnnt

CCC = Message prefix. Each of these is three characters long and generally refers to a product. A product outside of IBM has to reserve the use of the prefix to avoid colliding with other products.

S = for Zowe this is a sub-system identifier. We need to identify these. Here are the components I can think of off the top of my head.

A - API Mediation Layer
C - Zowe Command Line
D - Zowe Desktop
E - Explorer (not sure if this is needed as Explorers are currently more application specific. If we elevated them to part of the Desktop (like Finder on Mac or Explorer on Windows this would make sense as a component)
S - ZSS subsystem services

On reserve right now from IBM are the following prefixes:

OMP - I reserved this generally for the OpenMainframe Project
ZWE - For Zowe use.

Are there other prefixes we should reserve?

More detail on message formats

The message structure is fairly straight forward. Quoting from the IBM Messages manual:

The message body consists of three parts: the reply identifier (optional), the message identifier, and the message text. The following formats are possible:

id CCCnnn text
id CCCnnns text
id CCCnnnns text
id CCCnnnnns text
id CCCSnnns text

id
Reply identifier: It is optional. It appears if an operator reply is required. The operator specifies it in the reply.
CCCnnn, CCCnnns, CCCnnnns, CCCnnnnns, CCCSnnns
Message identifier.
CCC
A prefix to identify the component, subsystem, or product that produced the message. The prefix is three characters.

S
The subcomponent identifier, which is an optional addition to the prefix to identify the subcomponent that produced the message. The subcomponent identifier is one character.
nnn, nnnn, nnnnn
A serial number to identify the individual message. The serial number is three, four, or five decimal digits.
s
An optional type code, which is one of the following:

A
Immediate Action: System operator action is always immediately required. A system operator must do something now, such as mount a tape cartridge or attach a DASD.
The associated task does not continue until the requested action has been taken.

D
Immediate Decision: System operator decision/action is always immediately required. All system messages issuing the “D” type code must enumerate the available options. A system operator must make a decision now by selecting a reply from the enumerated options and responding to the system immediately.
The associated task does not continue until the operator communicates the decision to the system.

E
Eventual action: System operator action will be required. A system operator must eventually an appropriate action.
The associated task continues independent of system operator action.

I
Information: System operator action is not required. Communication in this category is for advisory purposes and may provoke system operator action.
The associated task continues independent of system operator action.

S
Severe error: Severe error messages are for a system programmer.
T
Terminate: The IEBCOPY program terminates.
W
System Wait: System operator action is always required immediately. A system catastrophe has occurred (hardware or software or both). The system must be re-IPLed to continue or a major subsystem must be re-started.
text
Text: The text provides information, describes an error, or requests an operator action.

More to come, interrupted

Discuss - DB2 Plugin Dependencies

Summary:

The DB2 plugin utilizes the dependency ibm_db, an open source MIT-licensed module which at install time downloads proprietary ODBC binaries that require a client-side license to run. For our offline CLI installation package with DB2, we currently redistribute the ODBC binaries. We need to review our strategy for this plugin and its packaging.

Some options:
-keep repackaging odbc binaries, but note the terms of the license as part of a commercial install and point users to rocket/ibm doc for acquiring the client license. install works, plugin usage fails until license is fulfilled.
-require users to provide the binaries + license themselves. We must test & doc how this process works for our plugin.
-try to get an exemption for ODBC license usage in Zowe
-refactor DB2 to use some other technology (no known tech at time of writing)

Zowe GA 1.0.0 Goals

List planned or desired GA 1.0.0 goals, and specify each goal accordingly.

Add goals to this document:
https://github.com/zowe/zlc/tree/ga-feature/releases

Track children epics/stories:

Transfer zowe.org domain name and website to LF IT

Need to get this moved over sooner than later. Would be good to get website settled down for LF CS to review ASAP.

"Built on Zowe" Website section

We should consider a section on the Zowe website which references products that are "built on Zowe" or "built with Zowe". This can demonstrate an ecosystem of downstream products that leverage the open source community. Need to investigate process for accepting products into the public display.

We should define and publish our process on zowe.org

I propose to publish our development process or a link to a wiki with the process in the community page. External observers and people interested in downloading links are interested in process items such as

• What is the general release road map
• What is the iteration schedule for new builds
• Where are the release notes / new and noteworthy for each release
• How to submit defects
• How get defects triaged and how can I track progress on my issues

A really good example for such a process and wiki answering many question external parties and contributors have is here: https://github.com/Microsoft/vscode/wiki/Development-Process

Zowe.org Home Page

Can we consider rethinking the Zowe.org home page? The "Why Zowe?" seems to be addressed by the OMP's static project site. Perhaps it would be more useful to give a brief project overview of "What" Zowe is instead.

OMP Landing page imagery

Can we look at changing the imagery on the OMP landing page that promotes Zowe? We should at least strive for a minimum AA WCAG compliance. The text is being lost on the light parts of the background image and making it difficult to read.

Update Zowe Contribute Page to include Waffle

Update https://zowe.org/contribute/
to include instructions on how someone can open a Waffle Issue against Zowe

EPL-2.0 Component for ZSS

Drawing from issue #17 breaking this out as a separate item for tracking.

z/OSMF - Performance measure

Create a plan to determine scaleabilty of z/OSMF when used by potentially 100-1000s concurrent requests, execute the scale testing, provide guidance on tuning and/or code hot spots for redesign

Investigate Code Analysis Tools

As part of CII Best Practices fulfillment, the ZLC should investigate and review tool recommendations for the working squads in the project.

Focus:
Java Tooling (explorer, apiml)
Typescript/Javascript Tooling (zlux, cli)

https://zowe.org/contribute/ needs a How to Submit a Defect page

People can contribute in all kinds of ways to an open source project. Contributing code is one way, but the far more common (and important one) is contributing Issues. We need a page that provides guidelines on how to submit an issue.

There are currently 45 Repositories in github, so it is impossible for end-user to find the right place. This page should provide pointers to top-level repos or Squad-level planning repos to which to file the defects. It should also explain any other conventions and tags to use (e.g. for expressing severity).

Those top-level repositories to which people file their defects need to be monitored and the issue needs a reply and triage within a week to give the contributor their feeling that their feedback is valuable and has been heard and not lost somewhere.

Process - Project Planning (PI Planning)

Is it worthwhile to consider a project wide planning cadence for after Zowe GA 1.0.0? Something very similar to, if not exactly, SAFE PI Planning?

Remove dependencies on non-EPL 2.0 Code bases

Currently Zowe relies on some binaries that are not consumable with compatible licenses. The two known now are:

ZSS - provided by Rocket Software
WebSphere Open Liberty - IBM

These two dependencies limit the openness of Zowe.

Allow CLI as separate download

Simplification of install steps for CLI - today it requires unpax of the CLI from the Zowe convenience build and then download - proposal is to have separate CLI package so unpax not needed

Zowe.org Contribute Page Refresh

The contribute page (https://zowe.org/contribute/) could be revamped in several ways:

• Add links and descriptions on the slack channels
• Add graphic for squads and brief description of how the interact?
• Add link to squad Waffle boards/backlog
• Add link to groups.io for list of list of scheduled squad meetings

Follow up on z box sizing with OMP/Vicom

Zowe team owes what sizing info we can to Vicom for z box proposal.

Set commit process w/ identified approvers

Allow teams to create their own branch. Master would be managed by a small set of core contributors and is updated through pull requests. Initial membership based on people who did most commits in prior giza foundation work. Add the top two committers. If there is a third that can be added based on affiliation for now that would be ideal. Teams to decide. Sean Grady to document.

Agenda update for 09-05 zLC meeting

Open Source Needs - Discussion.
Can you add or merge this into the section please ?
When December zowe-1.0,pax is built this can only contain EPL 2.0 licensed content. The current open beta zowe-0.9.0.pax has non EPL 2.0 licensed content which when removed means that none of the MVD desktop will function (as this uses zSS to authenticate to SAF). The 3 explorers (JES, MVS, USS) will not function as these use WebSphere Liberty for z/OS 17.2. The TN3270 and VT Terminal will not function as these use zSS. Note that the editor squad is currently building out alternative editors using zSS that also will not be able to be included in the zowe-1.0.pax EPL 2.0 licensed.
Options. 1) Modify software stack so it includes EPL 2.0 compliant components in order to deliver its function. 2) Move more of the current software from IBM/Rocket license and ownership to zowe.org. 3) Provide a non EPL 2.0 licensed component that is a Zowe pre-req (similar to node) that includes the non EPL 2.0 licensed pieces.

Other issues I'd like to see discussed.
API mediation - SSO, API transformation, certificate trusting, ...
In the process of onboarding tools and runtimes to the Zowe API mediation layer a number of issues have been identified that need addressing. There is no current solution in Zowe for single sign on (SSO). No-one is currently working on this as the ESM is not present so an alternative is needed.

https:// certificate for the MVD server has expired
The current certificate self signed by Sean expired on March 2018. Can we get a new certificate that isn't self signed and authorized by a trusted authority and replace this in the next build ?

Builds
The current build is a mixture of repositories from github.com/zowe and github.com/gizafoundation. When will this switch over so we have a build that is fully sourced from zowe.org ?

Zowe Site Flow

Need to review different site flows and improve user navigation. Jay/BJ/Jessica?

Proposed changes to the arrows in green.

Zowe Conformance Program

We need to think about what a Zowe Compliance program looks like. What are the benefits of being Zowe compliant? What metrics will we use to measure compliance? How is it enforced? etc.

Youtube Channel

Need to determine where we can host our demos, tutorials, etc. Can we have a "featured channel" on the OMP's youtube channel? Or do we need to create our own Zowe youtube channel?

Review/Approve Zowe 1.0 Messaging

Can the ZLC please review and approve the Zowe 1.0 messaging which will be used in a variety of ways including press releases and social promotions.

Please review and make changes to the boxnote here: https://ibm.box.com/s/eh5pxhodvp38cwb9uvnnu9i5vjja9468

The 1.0 campaign planning doc is here: https://docs.google.com/document/d/1GZBziZb9YNopb8PpSW-irBdUjhIQVRpAISUgS_1UcKU/edit?usp=sharing

Please reviewing and making the appropriate edits, please approve by commenting on this issue.

Review @brightside usages for GA

For Zowe GA, we need to review leftover Brightside mentions within Zowe CLI and Zowe CLI Installation Doc, and prioritize resolution of them with target dates.

Research/Guide - SSO for GA 1

The Zowe group needs to take stock of the current state of SSO and whether ESM will be available by GA 1 or not.

Formulate a plan for SSO GA 1. Work with architects.

Coordinate SHARE submissions Oct 5 deadline

Should broadcast deadline to squads and early adopters. Coordinate content tailored for each track (feedback was last SHARE had several repeats of content - understandable as first time)

Achieve CII Best Practices badge

https://bestpractices.coreinfrastructure.org/en - needs to be achieved before 1.0 release. Suggest starting to work through as soon as possible.

Certificate Strategy

Management

We need to document the certs we are shipping, where they are located and their expiration date

z/OSMF Lite - Closed beta and delivery

Execute closed beta of z/OSMF Lite (internal and external users) to validate design

Zowe Charter

Can we look at creating a better way for people to view/consume the Zowe charter? i.e. how to propose a new project, how to become a committer, how to become a leader, etc.

Zowe - Automated License Scanning

Currently the Linux Foundation / Open Mainframe Project is responsible for running licensing and dependency compliance scans against Zowe repositories, and candidate repositories to be donated to Zowe.

We should discuss if there's any automation the Zowe Org can setup to scan ourselves independently and produce reports that we can evaluate and forward to the LinuxFoundation / OMP. This would allow us to scan frequently as part of our build process, and to independently review candidate repository contributions.

Discuss - Promote Zowe Playbacks

Is there anything we can do to market or promote the bi-weekly Zowe playbacks to a larger customer audience?

z/OSMF - High Avialability

Research the current HA capability (auto restart), document (if needed) plus build case for true HA based on field requirements

Form temporary Installation Squad

A temporary squad should be formed to architect the install. This would include:

• packaging of various components
• ability to apply ptfs or delta installs without compete re-install
• will it be SMPE or other