Closed armstro closed 2 years ago
Whenever y'all are ready to start here, let me know.
John - my crystal ball is foggy on this but my guess is this is 30 days out.....TSC mission and establishment and joint PI Planning are higher priorities at the moment.
Want to bump this up - starting to see more public movement and advise that getting ahead of more growth would be something to consider sooner than later.
Once we get TSC moving we will come back to this item ......
OK
OK - I wanted to dust off this item and see about getting it started..... @jmertic you mentioned Kubernetes has a program for Support - I found this https://www.cncf.io/certification/kcsp/ - do you have any other info? The good news is the criteria is short and sweet but the problem seems to be it is difficult to apply to Zowe....(like Three or more engineers who pass the Certified Kubernetes Administrator (CKA) exam. )..... but the list is a place to start. Do you have other examples for Support Conformance?
That's probably the best I've seen thus far.
I'd not get hung up on the precise details, but more think about what you would hope that anyone saying they could support Zowe should be able to do. This might be having certain skillsets on staff. This might be community involvement. Might have something related other capacities. I'd encourage y'all to be creative on the way you think about this.
Update - Peter, Mike D and myself have been working on Support Conformance criteria in a couple documents (modeled after the current Zowe conformance programs for Web UI, API ML, etc.) - summary of status and key issues here - more work to do:
Plans are for additional working sessions and to include others with experience with the existing conformance programs to gain lessons learned and advice.
Glad this is taking shape! A few thoughts based on the questions...
Please pull me in when appropriate.
Many thanks to Rose for keeping up moving on the Support Conformance Program. Latest draft is attached - comments:
1) We state Support can be Comprehensive (meaning all of Core Zowe) or a subset (i.e, Partial). We also state "Best Practices" implies Support beyond Core - do we want to coin a term other than Best Practice - like Comprehensive+ ?
2) Do we need to a "finger print" program equivalent for non-z/OS components ? If one already exists does it need to be made more visible to the community?
3) Question on "no forked code" - does it just need to state abide by EPL2.0 with any code changes?
4) Question on timeliness of reporting security vulnerabilities - I think 3-5 days? What would hold up a report being made? Do we need to say vulnerabilities would not be made public until a mitigation is ready for distribution?
5) I think we need to work with the TSC on the definition of Core Zowe. I think TSC owns the declaration of core changes when a component, app, extension is ready to be considered core. Support vendors not ready to support a new core component would have the ability to work with the TSC.
This does look good - thanks Rose!
Some comments...
Support Vendor agrees to support any binary-equivalent of all Zowe core components, regardless of where obtained
This feels like it could get messy, and considering some of the recent activities we've seen with ransomware the phrase "regardless of where obtained" is also something that should be discouraged.
We should also define "binary-equivalent"
Support Vendor Agrees: to abide by "no forked code distributions of Zowe" - for either full distributions of Zowe OR any partial code distributed as a core Zowe enhancement or fix
Something that should be defined, as Rose pointed out.
Support Vendor confirms: comprehensive penetration tests are conducted annually by said Support Vendor and said Support Vendor is able to provide to OMP, reports demonstrating as such, when asked to do so
What does this mean?
Support Vendor agrees: to adhere to all documented Zowe TSC Engineering Standards [include a link to the standards here] for any support-related code change (fixes, patches, PTFs etc.) submission
Support Vendor Confirms: Said Vendor has read, understands and agrees to abide by the Zowe TSC Support-Vendor-Fix Process [include a link to the process here]
Support Vendor agrees: to adhere to all documented Zowe TSC Documentation Standards [include a link to the standards here] for any support-related code change (fixes, patches, PTFs etc.) submission that includes documentation
I'd think this would basically be the contribution guidelines, right? Not sure if there is some difference that would be expected here.
Support Vendor Agrees: to contribute all fixes to the Zowe community in a timely manner, as soon as possible and such contributions may be delayed for no longer than 3 months (90 days)
The last part seems to be putting a contract on the squads, which should have the right to accept or reject the contribution ( or even delay it if it makes sense to apply at a later time ).
"Active contributors" should also be defined, but I'm also wondering if that could exclude those who don't have the right skills on the bench to contribute code.
John - if you can join the ZLC call today maybe we can talk thru some of these
Regarding multiple sources of the code - we already have zowe.org, 2 vendor sites, npmjs registry, Docker hub (not yet core) as multiple sources .....I don't think we can control where the code is hosted (don't want to limit other Support Providers from having their own distribution)
Regarding binary equivalent - so we have focused on ways to validate the code is genuine via "finger print app" (fancy name for hash) shipped in the z/OS components and (we think) the VS Code and npmjs registries have something similar.
See my comments regarding forked code - I think we just wanting to say they agree to EPL2.0......Support Vendors may need to fork the code for an emergency fix but need to agree to contribute the fix back to the community.
I think the intent is the vendor should participate in the Security subgroup that works on and security vulnerability that are found (it does not need to be limited to pen testing but any testing or defect report)
Adhering the TSC policies does need to be clarified - We need to discuss with the TSC - they have not seen this yet. - we just mean the Support Provider needs to follow the TSC policies - using automated testing, documentation, etc.
We can discuss "active contributor" definition - the point is that a Support person/org should do more than raise issues for the squad to address and we would prefer a contributor/committer. How we define this idea of "active" is something to discuss.
Bruce Armstrong IBM Z Product Manager assigned to zowe.org 4205 S MIAMI BLVD, DURHAM NC 27703-9141 Email: @.*** Tel: 919-254-8773 Cell: 919-931-3132
From: John Mertic @.> To: zowe/zlc @.> Cc: Bruce Armstrong @.>, Assign @.> Date: 05/25/2021 07:33 AM Subject: [EXTERNAL] Re: [zowe/zlc] Establishment of Zowe Support Provider Conformance Program (#182)
This does look good - thanks Rose! Some comments... Support Vendor agrees to support any binary-equivalent of all Zowe core components, regardless of where obtained This feels like it could get messy, and considering some of the recent activities This does look good - thanks Rose! Some comments... Support Vendor agrees to support any binary-equivalent of all Zowe core components, regardless of where obtained This feels like it could get messy, and considering some of the recent activities we've seen with ransomware the phrase "regardless of where obtained" is also something that should be discouraged. We should also define "binary-equivalent" Support Vendor Agrees: to abide by "no forked code distributions of Zowe"
Let me try to summarize the changes made after the ZLC call this morning (and we need to work with the TSC on a few items).
In layman's terms
Areas where we need to work with TSC
I added new text for footnote 1.2 and made items 9 and 11 requirements (x was missing) Zowe.Support.Conformance.V1b.-.5-25-21.xlsx
Zowe.Support.Conformance.V1-Near Final .xlsx OK - I did my best to incorporate all the comments from today's ZLC - please read top to bottom including footnotes. I would like to bring this to a vote ASAP. I think we also agreed TSC will own "what is core".
Looking better! I think there is some wordsmithing that can be done to clean things up, but nothing major.
I read the whole thing and reworded item #2 and also made a bunch of really minor comments.
I am happy to integrate into a new version myself if you want – just say the word Bruce.
From: Bruce Armstrong @.> Sent: Tuesday, June 1, 2021 1:48 PM To: zowe/zlc @.> Cc: Peter Fandel @.>; Assign @.> Subject: Re: [zowe/zlc] Establishment of Zowe Support Provider Conformance Program (#182)
EXTERNAL EMAIL
Zowe.Support.Conformance.V1-Near Final .xlsxhttps://github.com/zowe/zlc/files/6578384/Zowe.Support.Conformance.V1-Near.Final.xlsx OK - I did my best to incorporate all the comments from today's ZLC - please read top to bottom including footnotes. I would like to bring this to a vote ASAP. I think we also agreed TSC will own "what is core".
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHubhttps://github.com/zowe/zlc/issues/182#issuecomment-852325442, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHBGVU5QQXMX5RF7D62CBVTTQUMMZANCNFSM4MSDQJUA.
This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.
@PeterFandelAtRocket happy to have you "hold the pen" on this - I had asked Rose to review but I don't see her on the issue assignee list so she may not be seeing these updates. (and I am not sure she's even in the zlc issues repo to be assigned). My comments to your comments:
Unless @pdubz3 or Rose have any objections - I say make your changes - leave links as TBD. We make Jakub aware of the "near final" proposal. He's already taken to the TSC the issues we need help with (defining active contributor, confirming there are ways to declare code as "authentic", what is core, etc.) but we need to give the TSC some time to sort that out.
@jmertic we briefly discussed having some "public vetting" of the Support Conformance criteria - if you have particular parties we should seek out for feedback, we can take that next step if you want.
I think we (ZLC) needs to put 1-2 slides together to summarize what we are proposing for easier presentation.
No objection to Peter making the updates he proposed.
Minor wording question, we may have covered this before so I apologize in advance if we have ... if a criterion is indicated as "required" is it less ambiguous to avoid words like "should" in the description in favor of words like "must"? For example in the first section, saying "Customers being supported should not be required to go to a particular vendor distribution channel ..." makes that sound more like a recommendation or best practice. I would suggest "Customers being supported must not be required to go to a particular vendor distribution channel." Thoughts on this?
Zowe.Support.Conformance.V1-Near.Final.rev2.xlsx
I applied all my edits as well as replaced "should" with "must" per Mike's previous comment.
I also made the cells containing URLs to be active hyperlinks.
I left the Joe W italicized comment for now.
Thank you @PeterFandelAtRocket. There's a second instance of "should" in one of the footnotes but I'm less certain as to whether it's really a "must". The footnote is about emergency fixes and it reads "Support Vendor Agrees: If any fixes require changes to the Zowe codebase then under the terms of the EPL 2.0 license, the modified code must be made available to the Zowe community. This should be in the form of a git issue be created that describes the original defect together with either a pull request, or a link to where the support vendor has published their updated code. This must be done in a timely manner after the support vendor has made the updated code available to their customer and delayed for no longer than 3 months (90 days). "
Replaced other 'should' with 'must' Zowe.Support.Conformance.V1-Near.Final.rev3.xlsx
@armstro @PeterFandelAtRocket @pdubz3 : Apologies for the late review. This looks really good! I've attached a V4 with some minor comments for your consideration. They do not change the underlying messaging, this was my attempt to make the point a bit more clear. Zowe.Support.Conformance.V1-Near.Final.rev4.xlsx
Thanks Rose - regarding "how the notification" will occur to the TSC regarding emergency fixes - @nkocsis was working with the TSC on how customer issues could be raised and be better visible - maybe there is something that can be done for emergency defects? Just a thought
Regarding filling in some of the links - the TSC is working on how to describe core (https://github.com/zowe/community/pull/1213) , active contributor so we are getting closer to having something to present to John.
Once we have a process in place where we know that the squads are reviewing the incoming customer issues then I would expect that it would handle "Emergency" defects.
Proposed 1 slide for July 21 webinar - draft - 2-3 mins max
2021 July Zowe Quarterly Webinar Series - Support Conformance Slide .pptx
Bruce, thanks for taking the time to create a slide for the webinar. As we discussed offline I created a second draft using mostly your content but focusing a little more on the value of the program to the Zowe user, and then the steps a vendor takes and the principles of the program. I left the original but added a second slide for the alternate draft.
2021.July.Zowe.Quarterly.Webinar.Series.-.Support.Conformance.Slide.pptx
Thanks Mike - your slide is great - let's go with it.
Zowe.Support.Conformance.V1-Near.Final.rev5.xlsx
Captured link to define "core" in the spreadsheet
Zowe.Support.Conformance.V1-Near.Near.Final.rev6.xlsx
If we are going to preview (and request comments for) the Support Conformance at the up coming Zowe Quarterly Webinar then I thought I would tweak some of the open gaps we had in prior spreadsheet. Please read closely - I incorporated Rose's comments. I think we need to take to TSC for comment but can be done while we ask for comments in the wider community. Maybe we have a new issue created to link to in the Webinar slides?
Few things to note:
All of this can be tweaked further
@RASakach for the life of me I can get urls in the text to be actual links - my excel skills are lacking. If you know the steps please advise.
@armstro Please review to ensure all URLs have been changed - I believe I found all of them. Zowe.Support.Conformance.V1-Final.July.19.2021+links.xlsx
Thanks x100 Rose - links look good and I checked each one - they work!
Done!
Proposal is to create a set of conformance criteria to be a Zowe Support Provider.
Examples