Support provisioning features from maven repository

[alvinso]

UFO: https://ibm.box.com/s/ngs772ajg0b4ryvfpxxvy2j7dcqphnmc

STE: https://ibm.box.com/s/mib9tx87qhr0jyupzzz69n9h3j5xsoyd (updated)

FAT approval summary: #10039 (updated)

The Open Liberty maven plugin currently supports installing features from Open Liberty on a kernel image, but the following issues exist:

1. You need a maven build, which isn't well adapted for preparing docker image where command line based tools work better
2. You can't install a feature that isn't part of Open Liberty, so no third party features.

This epic is to address these issues so Open Liberty can easily consume new features.

[mchenggit]

WAD Review Comments:

1. Place Github issue in the WAD - updated WAD
2. p. 2: Clarify earlier in the document that it's a new command line tool - updated WAD
3. Change "Operator" to something else so as to not confuse with Kubernetes Operators - updated WAD
4. p. 10: another option is to use 2-stage docker build to copy only what's needed to the second stage. - updated WAD
5. p. 11: Clarify how this will be similar to configure.sh, and whether configure.sh will be updated to leverage the new tool - updated WAD
6. p. 11: For --no-cache, clarify it will not update local cache - updated WAD
7. p. 14: Use some other terminology than "legacy" - updated WAD
8. p. 14: Remove "pom" from the diagram as it's not required for the tool. - updated WAD
9. p. 16: Clarify only 1 repository is supported, and why that is sufficient for now. - clarified with customers and they install from one repo
10. p. 17: move '--to" option to a different epic. - updated WAD
11. p. 17: Rename "installServer" to something that better describes what the tools does, which is to install those features required by server.xml. - updated WAD
12. p. 17: Move support for user features to a different epic. - updated WAD
13. p. 22: Address whether there are changes to: appsody stack, transformation advisor, and existing guides to how to containerize Liberty - worked with Arthur and opening issue to update configure.sh to call featureUtility for Open Liberty

Captured chat session during WAD review concerning 11 above:
from Yee-Kang Chang to everyone:
May be "provisionServer" for "installServer". (I will prefer shorter actions if possible in general but "install" and "provision" or even "install" alone may make it more confusing than necessary.)
from Jared Anderson to everyone:
I was thinking "installServerFeatures", or just having "install"and have --featureName or --serverName . This latter option would simplify the options.
from Alasdair Nottingham to everyone:
I don't want to do things like --featureName and --serverName because it makes the tool harder to use
from Alasdair Nottingham to everyone:
we have a convention already

[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? yes
   Have these issues been addressed in the implementation? yes

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? repo connection, and feature not found issues
   b) Who did you demo to? EOI meeting / install test team / L2 (STE) - pending
   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? error messages and debug info will avoid PMRs and help L2 to identify root cause without engaging L3.

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? SVT is not needed for this feature
   Kevin Lefebvre
   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? L2 should be able to quickly address those problems without need to engage L3
   Yes

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. WAS L3: Liberty Install

[alvinso]

Feature Ship Release Readiness Checklist

Instructions:

• Paste everything below the next line into the GitHub epic for a feature as the first comment.

==================================================================================

---

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 - (G Scott Johnston). 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)

[marikaj123]

According to Alvin the translated code is in the buid. Globalization approval is provided. Thank you.

[gscottj]

This feature has been implemented as part of the the existing Liberty CLI interface which affords access for persons with disabilities.

[chirp1]

I'm approving the feature. Hermanjit provided us the information to be documented here: OpenLiberty/docs#849 Remember that since this doc issue will go on the doc backlog, the doc for this epic might not be completed in time for 20.0.0.1. So, be sure to supply information in your blog post, such as an example so that customers know what to do with the feature.

[frowe]

UFO review

1. Dalia to have a conversation about migration with Alasdair regarding feature resolution.
2. Remove TBD from screenshot on slide 16
3. Erin Harris pointed out that on Slide 18, adding WebSphereApplicationServer.properties may cause the tools a problem since if they find the prop file, they may expect the installUtility to exist in bin dir.
4. Typo on slide 26 ifs -> isf Alasdair requested that ifs either work, or at least emit error asking if you meant isf
5. Slide 27 add ability to list installable features, consider adding ability to list installed features
6. Slide 43, migration impact slide - Dahlia wants to have a further discussion on migration impacts

[alvinso]

Response to review comments:

1. Alasdair discussed with Dahlia about the migration, no impact on migration.
2. Removed TBD from screenshot on slide 16
3. Erin confirmed that the tools will not depend on WebSphereApplicationServer.properties
4. Fixed typo on slide 26, error message will help users with correct options
5. Added "find" action for list installable features, installed features can be listed using the existing productInfo command
6. No migration impact for slide 43.

[chirp1]

The ID issue at OpenLiberty/docs#849 seems to have the information that we need. I mentioned to Hermanjit that the documentation is done in a prioritized order. So, the documentation might not be done by the time that the feature eGA's. The blog post would need to contain enough information, such as examples, so that the user can do something with the command until the final documentation is written. Hermanjit is fine with this approach. Approving.