zowe / zac Goto Github PK
View Code? Open in Web Editor NEWZowe Leadership Committee collaboration
License: Creative Commons Attribution 4.0 International
Zowe Leadership Committee collaboration
License: Creative Commons Attribution 4.0 International
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?
Breaking out the Requirements Issue opened by Bruce Armstrong and replacing it with new issues for the known activities.
Bob Dahlberg is putting something together - will attach proposal. Would be good for ZLC to comment and determine who could mentor.
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?
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.
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.
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.
Can we look into using a tool like Grimoire Lab to help us assess the health of our community?
@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/
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.
@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)?
Gain agreement on design, staff implementation effort, set schedule and deliver for JWT/OAuth Single Sign On
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:
Review consolidated list of z/OSMF requirements including priorities examples
Investigate and setup a Docker Hub the Zowe org can use. Coordinate with OMP/LinuxFoundation.
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.
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?
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 textid
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
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)
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:
Need to get this moved over sooner than later. Would be good to get website settled down for LF CS to review ASAP.
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.
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
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
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.
Update https://zowe.org/contribute/
to include instructions on how someone can open a Waffle Issue against Zowe
Drawing from issue #17 breaking this out as a separate item for tracking.
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
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)
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.
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?
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.
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
The contribute page (https://zowe.org/contribute/) could be revamped in several ways:
Zowe team owes what sizing info we can to Vicom for z box proposal.
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.
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 ?
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.
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?
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.
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.
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.
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)
https://bestpractices.coreinfrastructure.org/en - needs to be achieved before 1.0 release. Suggest starting to work through as soon as possible.
Management
We need to document the certs we are shipping, where they are located and their expiration date
Execute closed beta of z/OSMF Lite (internal and external users) to validate design
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.
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.
Is there anything we can do to market or promote the bi-weekly Zowe playbacks to a larger customer audience?
Research the current HA capability (auto restart), document (if needed) plus build case for true HA based on field requirements
A temporary squad should be formed to architect the install. This would include:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.