Support gRPC / gRPC-java

[pnicolucci]

---

List of Steps to complete or get approvals / sign-offs for Onboarding to the Liberty release (GM date)

Instructions:

• Do the actions below and mark them complete in the checklist when they are done.
• Make sure all feature readiness approvers put the appropriate tag on the epic to indicate their approval.

---

TARGET COMPLETION DATE Before Development Starts or 8 weeks before Onboarding

• POC Design / WAD Review Scheduled (David Chang) or N/A.
• POC Design / WAD Reviewed (Feature Owner) or N/A.
• Complete any follow-ons from the POC Review.
• Design / WAD Approval (Alasdair Nottingham) or N/A.
• No Design / No WAD Approval (Arthur De Magalhaes - cloud / Alasdair Nottingham - server) or N/A.
• SVT Requirements identified. (Epic owner / Feature owner with SVT focal point)
• ID Requirements identified. (Epic owner / Feature owner with ID focal point)
• Create a child task of the epic entitled "FAT Approval Test Summary". Add and fill in the template as described here: https://github.ibm.com/was-liberty/WS-CD-Open/wiki/Feature-Review-(Feature-Test-Summary-Process)

---

TARGET COMPLETION DATE 3 weeks before Onboarding

• Identify all open source libraries that are changing or are new. Work with Legal Release Services (Cass Tucker or Release PM) to get open source cleared and approved. Or N/A. (Epic Owner). New or changed open source impacts license and Certificate of Originality.

---

TARGET COMPLETION DATE ** 3 weeks before Onboarding**

• All new or changed PII messages are checked into the integration branch, before the last translation shipment out. (Epic Owner)

---

TARGET COMPLETION DATE 2 weeks before Onboarding

• Implementation complete. (Epic owner / Feature owner)
• All function tests complete. Ready for FAT Approval. (Epic owner / Feature owner)
• Review all known issues for Stop Ship. (Epic owner / Feature owner / PM)

---

APPROVALS with TARGET COMPLETION DATE 2 to 1 week before Onboarding

Prereq: You must have the Design Approved or No Design Approved label on the GitHub Epic.

• Accessibility - (Steven Zvonek). Accessibility testing is complete or N/A. Approver adds label focalApproved:accessibility to the Epic in Github.
• FAT Liberty SOE - (Kevin Smith). SOE FATS are running successfully or N/A . Approver adds label focalApproved:fat to the Epic in Github.
• Globalization (Marika Joannidis - Liberty / Simy Cheeran - tWAS). Translation is complete or N/A. TVT - complete or N/A. Approver adds label focalApproved:globalization to the Epic in Github.
• ID - (Kareen Deen). Documentation work is complete or N/A . Approver adds label focalApproved:id to the Epic in Github.
• Performance - (Jared Anderson). Performance testing is complete with no high severity defects or N/A . Approver adds label focalApproved:performance to the Epic in Github.
• Serviceability - (Don Bourne). Serviceability has been addressed.
• STE - (Swati Kasundra). STE chart deck is complete or N/A . Approver adds label focalApproved:ste to the Epic in Github.
• SVT - (Greg Ecock - Cloud, Brian Hanczaryk- APS). SVT is complete or N/A . Approver adds label focalApproved:svt to the Epic in Github.
• Demo - (Liberty only - Tom Evans or Chuck Bridgham). Demo is scheduled for an upcoming EOI. Approver adds label focalApproved:demo to the Epic in Github.

---

TARGET COMPLETION DATE 1 week before Onboarding

• No Stop Ship issues for the feature. (Epic owner / Feature owner / Release PM)
• Ship Readiness Review and Release Notes completed (Epic owner / Feature owner / Release PM)
• Github Epic and Epic's issues are closed / complete. All PRs are committed to the master branch. (Epic owner / Feature owner / Backlog Subtribe PM)

---

NOT REQUIRED FOR A FEATURE

• OL Guides - (Yee-Kang Chang). Assessment for OL Guides is complete or N/A.
• WDT - (Leonard Theivendra). WDT work complete or N/A.

---

Related Deliverables TARGET COMPLETION DATE General Availability

• Blog article writeup (Epic owner / Feature owner / Laura Cowen)

Design document: https://ibm.box.com/shared/static/x6vy73iadmip6ix00mzhwuz2vqgqr4x2.pptx

[pnicolucci]

Documentation work that we'll require: OpenLiberty/docs#2698

[garypicher]

WAD review actions / comments from 11/4/2019 come-back review:

1. Determine if gRPC-1.0 feature eventually split into 2, one client and one server feature
2. Design for this should consider integration with quarkus in the future (discuss with andy guibert)
3. You should prereq java 11, not 8/9
4. Slide 34 - Add support for client cert auth
5. Slide 34 - Work with Jim Mulvey to expand security slides to detail both inbound and outbound paths
6. Slide 36 - Data point with war deployed in open liberty would be good to see

Note that the consensus on the call was to focus on using a Servlet for the inbound path. This is easier for us to code, although it may make sharing code with Quarkus more difficult. We can cross that bridge when we get there.

[NottyCode]

@pnicolucci Why would this be documented in WebSphere traditional documentation when it is for Open Liberty?

[pnicolucci]

@NottyCode I closed the twas doc issue, at one point in time I believe that is where ID wanted us to open the issues for docs, we can work with ID and get an issue opened in the open liberty repo instead.

[wtlucy]

Per discussion with @steven1046, from the accessibility point of view grpc-1.0 and grpcClient-1.0 do not add any user interfaces.

[skasund]

L2 has requested STE slides for this feature. The STE template can be found at the links below. You can use either one to create the education.

Slide Template: https://ibm.box.com/s/1an42g7zdgmaj84w7dft0indqfgi8ffm

Github Template: https://pages.github.ibm.com/WASL3/site/STE/about

Please upload the completed slides to the same STE Archive BOX folder or provide me the Github link. Thanks!

[donbourne]

Serviceability Approval Comment - Please answer the following questions for serviceability approval:

1. WAD -- does the WAD identify the most likely problems customers will see and identify how the feature will enable them to diagnose and solve those problems without resorting to raising a PMR? Have these issues been addressed in the implementation?

The WAD mentions that new logging and messages have been added for this feature. I have updated the WAD to contain the ranges of the new messages that have been added, CWWKT0201-CWWKT0400, as well as new trace specs - ie. GRPC=all, io.grpc*=all, io.netty*=all. I've also added a slide covering some of the basic types of problems we expect users to encounter, and our mitigations.

2. Test and Demo -- As part of the serviceability process we're asking feature teams to test and analyze common problem paths for serviceability and demo those problem paths to someone not involved in the development of the feature (eg. L2, test team, or another development team).
   a) What problem paths were tested and demonstrated?

A number of problem paths were demonstrated: application packaging problems, a service definition problem, connection problems, and various server.xml misconfigurations including security and basic grpc and grpcclient properties.

b) Who did you demo to?

@volosied and @mrsaldana

c) Do the people you demo'd to agree that the serviceability of the demonstrated problem scenarios is sufficient to avoid PMRs for any problems customers are likely to encounter, or that L2 should be able to quickly address those problems without need to engage L3?

They agreed that the problem scenarios we covered are sufficiently covered by the feature, in conjunction with the documentation that we have planned. L2 should be able to quickly address the problems that were covered with the guidance of the STE document. We discussed a few areas where warning and error messages could be added; we decided that we can implement those as improvements in the future.

3. SVT -- SVT team is often the first team to try new features and often encounters problems setting up and using them. Note that we're not expecting SVT to do full serviceability testing -- just to sign-off on the serviceability of the problem paths they encountered.
   a) Who conducted SVT tests for this feature?

@hanczaryk

b) Do they agree that the serviceability of the problems they encountered is sufficient to avoid PMRs, or that L2 should be able to quickly address those problems without need to engage L3?

From @hanczaryk: Since no significant problems were encountered, I agree that any problems encountered were sufficient to avoid PMRs or have L2 quickly address those problems.

4. Which L2 / L3 queues will handle PMRs for this feature? Ensure they are present in the contact reference file and in the queue contact summary, and that the respective L2/L3 teams know they are supporting it. Ask Don Bourne if you need links or more info.

This will be handled by the WEB team, and we intend to create a new L3 skill for gRPC

5. Does this feature add any new metrics or emit any new JSON events? If yes, have you updated the JMX metrics reference list / Metrics reference list / JSON log events reference list in the Open Liberty docs?

Yes, new metrics were added in #13477 and #13112. We have an issue open to update those docs at: OpenLiberty/docs#2811