Closed donbourne closed 4 years ago
Instructions:
[x] POC Design / WAD Review Scheduled (David Chang) or N/A.
[x] POC Design / WAD Reviewed (Feature Owner) or N/A.
[x] Complete any follow-ons from the POC Review.
[x] Design / WAD Approval (Alasdair Nottingham) or N/A.
[ ] No Design / No WAD Approval (Arthur De Magalhaes - cloud / Alasdair Nottingham - server) or N/A.
[x] SVT Requirements identified. (Epic owner / Feature owner with SVT focal point)
[x] ID Requirements identified. (Epic owner / Feature owner with ID focal point)
[x] 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)
[x] 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.
[x] All new or changed PII messages are checked into the integration branch, before the last translation shipment out. (Epic Owner)
[x] Implementation complete. (Epic owner / Feature owner)
[x] All function tests complete. Ready for FAT Approval. (Epic owner / Feature owner)
[x] Review all known issues for Stop Ship. (Epic owner / Feature owner / PM)
Prereq: You must have the Design Approved or No Design Approved label on the GitHub Epic.
[x] Accessibility - (G Scott Johnston). Accessibility testing is complete or N/A. Approver adds label focalApproved:accessibility to the Epic in Github.
[x] FAT Liberty SOE - (Kevin Smith). SOE FATS are running successfully or N/A . Approver adds label focalApproved:fat to the Epic in Github.
[x] 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.
[x] ID - (Kareen Deen). Documentation work is complete or N/A . Approver adds label focalApproved:id to the Epic in Github.
[x] 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.
[x] Serviceability - (Don Bourne). Serviceability has been addressed.
[x] STE - (Swati Kasundra). STE chart deck is complete or N/A . Approver adds label focalApproved:ste to the Epic in Github.
[x] SVT - (Greg Ecock - Cloud, Brian Hanczaryk- APS). SVT is complete or N/A . Approver adds label focalApproved:svt to the Epic in Github.
[x] 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.
[x] No Stop Ship issues for the feature. (Epic owner / Feature owner / Release PM)
[x] Ship Readiness Review and Release Notes completed (Epic owner / Feature owner / Release PM)
[x] Github Epic and Epic's issues are closed / complete. All PRs are committed to the master branch. (Epic owner / Feature owner / Backlog Subtribe PM)
[x] OL Guides - (Yee-Kang Chang). Assessment for OL Guides is complete or N/A.
[x] WDT - (Leonard Theivendra). WDT work complete or N/A.
[x] Blog article writeup (Epic owner / Feature owner / Laura Cowen)
Design Review Actions:
Design Review Actions:
* Please update the "Beta" slide to explain the reason that the feature can't be gated from GA, and explain the mitigation (i.e. not documenting the new value until approvals are obtained)
@garypicher The "Beta" slide has been updated, to include the reason and mitigation. https://ibm.box.com/s/umqmxfgaq9sto5vj0ie4y8jdnbdfdtzg
@pgunapal I think this is pointing to a pre-existing bug in our externals that I think we can fix as a part of this feature without breaking anyone.
Today Liberty has 3 different formats called basic. The console, message and trace log all have formats called basic and they are all different. This is confusing and becomes apparent when you want to be able to format the console log file consistently with the message format because they both use basic, but mean different things. This problem was really introduced when we added the JSON format.
Before this feature we have the following files and available options:
consoleFormat = basic* | json
messageFormat = basic* | json
traceFormat = enhanced* | basic | advanced
I used a * to show the default formats. The trace formats of basic and advanced are consistent with the WebSphere traditional trace formats.
I'd like to propose that we change the options to this:
consoleFormat = console* | json
messageFormat = message* | json
traceFormat = trace* | basic | advanced
In this the console basic format becomes the console format, the message basic becomes the message format and enhanced becomes the trace format. The default formats for each are console, message and trace. That allows us to add message
as an option to the consoleFormat and have consistent names and meanings for all formats.
This might seem like a breaking change, but as long as we make sure that the runtime accepts the old values as well as the new we have maintained zero migration. We just stop documenting the old names.
I notice that the metatype documentation uses lower case for basic format, but all other formats are using all upper case. So when the docs for this are done we should ensure that we use all upper case for all values to be consistent.
What are current log format names?
messageFormat = basic (default) | json
consoleFormat = basic (default) | json
traceFormat = enhanced (default) | basic | advanced
What will new names be?
messageFormat = simple (default) | json // XXX is equivalent to what we call messageFormat's basic today
consoleFormat = dev (default) | simple | json // dev is equivalent to what we call consoleFormat's basic today
traceFormat = enhanced (default) | basic | advanced
we will remove the 'basic' format from consoleFormat / messageFormat
CWWKG0032W: Unexpected value specified for property [consoleFormat], value = [basic]. Expected value(s) are: [DEV][XXX][JSON]. Default value in use: DEV.
Serviceability Approval Comment - Please answer the following questions for serviceability approval:
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?
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?
b) Who did you demo to?
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?
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? 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?
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.
@gscottj There are no addition of any new or change to any existing UI. May I get your approval on Accessibility? Thanks!
@jhanders34 There are no significant change in performance for this feature. The console.log's performance will be similar to the performance of message.log when the consoleFormat=simple is used, since both files will be identical. May I get your approval on performance? Thanks!
@skasund I have uploaded the completed STE to Box and can be found in the following link: https://ibm.box.com/s/0xao7ck8ktjzgf68umnijeotnf0lwiy3 May I get your approval for STE? Thanks!
@pgunapal Thanks for the slides. I've approved this feature.
@pgunapal Prashanth opened doc issue #809 and provided in it the info to be documented. I asked that he also include in the blog post enough info for customers to use the function. Approving.
@tevans78 Demo is scheduled for Liberty 20.6 - March 24th EOI.
@donbourne Serviceability Approval Comment - Please answer the following questions for serviceability approval:
basic
default format name is used, the warning message will be still shown, and it will use the default format and have zero-migration.b) Who did you demo to?
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?
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?
@samwatibm Messages have already been integrated and has been sent out for translation for 20.0.0.4, may I get the globalization approval for this feature?
@pgunapal Can you confirm it came back with the 20.0.0.4 translations and it's merged? Thanks.
Moved to 20.0.0.5, awaiting translated messages. Removed the Options element that introduce the new format and the default format names for messageFormat and consoleFormat, from the metatype.xml via PR #11465. The code still handles the old basic format gracefully. Will re-enable the new Options, once the translated messages are back.
@samwatibm May I have your approval on globalization?
@fmhwong Are your translations back & merged yet? If it went out with 20.0.0.5, that just came back today.
@samwatibm I think they went out in 20.0.0.5.
20.0.0.5 just came back today. Can you confirm your translations are all back and merged? Thanks.
From discussion with @NottyCode , we think that we could potentially make the console.log be switchable to the message.log enhanced format through a config setting.
WAD: https://ibm.box.com/s/6a61h3flk10skc1dwicsko4l8kpyu5wj ID: https://github.com/OpenLiberty/docs/issues/809