Thanks Anders. I will do that before pushing.
Regards, Vu From: Anders Widell [mailto:anders.wid...@ericsson.com] Sent: Thursday, August 4, 2016 3:23 PM To: Vu Minh Nguyen <vu.m.ngu...@dektech.com.au>; 'Lennart Lund' <lennart.l...@ericsson.com>; mahesh.va...@oracle.com Cc: opensaf-devel@lists.sourceforge.net Subject: Re: [devel] [PATCH 1 of 1] log: Readme file for long DN support [#1315] Hi Vu! Could you re-format the README files so that you keep the line length below 80 characters? Hint: If you are using the emacs configuration provided on the wiki (which you should :-), then you can easily re-format the text by pressing M-q in each paragraph. Also delete all trailing whitespace at the end of the lines. Hint: You can do this by marking all the text and then typing M-x delete-trailing-whitespace thanks, Anders Widell On 08/03/2016 12:28 PM, Vu Minh Nguyen wrote: Hi Lennart, Please see my responses in line, started with [Vu]. I will create a new README file for saflogger tool and put the info related to new test cases to `~/tests/logsv/README`. Updated files are attached. Please have a look. Thanks. Regards, Vu -----Original Message----- From: Lennart Lund [mailto:lennart.l...@ericsson.com] Sent: Wednesday, August 3, 2016 2:50 PM To: Vu Minh Nguyen <mailto:vu.m.ngu...@dektech.com.au> <vu.m.ngu...@dektech.com.au>; mahesh.va...@oracle.com <mailto:mahesh.va...@oracle.com> Cc: opensaf-devel@lists.sourceforge.net <mailto:opensaf-devel@lists.sourceforge.net> Subject: RE: [PATCH 1 of 1] log: Readme file for long DN support [#1315] Hi Vu In general this document should not be a document describing what to implement instead it should describe what is implemented and what in the log service that is affected by long DN and to some extent how it is implemented. See some comments/examples inline. To have information here about the saflogger tool I think is ok but maybe it is a good idea to have a README file in the .../tools/saflog/ directory? [Vu] Ok. I will create new README file for saflogger tool. The file content is attached (README file) Also some comments inline [Lennart] Comments on the other patches will follow Thanks Lennart -----Original Message----- From: Vu Minh Nguyen [mailto:vu.m.ngu...@dektech.com.au] Sent: den 4 juli 2016 05:07 To: mahesh.va...@oracle.com <mailto:mahesh.va...@oracle.com> ; Lennart Lund <mailto:lennart.l...@ericsson.com> <lennart.l...@ericsson.com> Cc: opensaf-devel@lists.sourceforge.net <mailto:opensaf-devel@lists.sourceforge.net> Subject: [PATCH 1 of 1] log: Readme file for long DN support [#1315] osaf/services/saf/logsv/README_LONGDN | 138 ++++++++++++++++++++++++++++++++++ 1 files changed, 138 insertions(+), 0 deletions(-) Show changes for long DN, including: 1) saflogger tool 2) log agent 3) log services 4) test suite diff --git a/osaf/services/saf/logsv/README_LONGDN b/osaf/services/saf/logsv/README_LONGDN new file mode 100644 --- /dev/null +++ b/osaf/services/saf/logsv/README_LONGDN @@ -0,0 +1,138 @@ +# +# -*- OpenSAF -*- +# +# (C) Copyright 2016 The OpenSAF Foundation +# +# This program is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY +# or FITNESS FOR A PARTICULAR PURPOSE. This file and program are licensed +# under the GNU Lesser General Public License Version 2.1, February 1999. +# The complete license can be accessed from the following location: +# http://opensource.org/licenses/lgpl-license.php +# See the Copying file included with the OpenSAF distribution for full +# licensing terms. +# +# Author(s): Ericsson AB +# + +I. GENERAL INFORMATION (#1315) +============================== + +The SaNameT type, which is used to pass distinguished stream DNs name in saLogStreamOpen_2() API, +or in `logSvcUsrName`, `notificationObject` or `notifyingObject` which belong to `SaLogRecordT` +data structure passed to `saLogWriteLogAsync()` API, contains a fixed-size buffer that limits +the string length to a maximum of 255 bytes. + +#1315 ticket was raised for LOG to support long DN. The use cases could be: +UC1) Write log records using the long DN in @Sl, @No, @Ng tokens using Log API. +UC2) Create any long DN name stream using Log API. +UC3) Write record to long DN app stream using saflogger tool. [Lennart] A stream name is not a DN. Please rephrase. [Vu] I rephrased it. + +The implementation was split into following parts: +1) Update saflogger tool - add one more option `-f` +2) Update LOG agent (API) to support Long DN +3) Update LOG service to support Long DN +4) Create test cases + +Besides, README file and OpenSAF_LOG_PR.odt have to be updated. [Lennart] Remove this sentence [Vu] Done. + + +II) IMPLEMENTATION (#1315) +============================== + +1) Update saflogger tool - Add One More Option `-f` [Lennart] This document shall contain information for existing implementation not what to be implemented. This means that frases like Update saflogger... or Add one more... etc. should not be used. This comment applies also to the rest of the document This header could be changed to something like: 1) saflogger tool, '-f' option [Vu] Done. +------------------------------------------------- +`-f` option is only applicable for application stream. Means it is only valid +when comes together with option `-a`. If no `-f` is provided, default behavior is maintained. [Lennart] Consider refrasing to: Means it is only valid with option `-a`. [Vu] Done + +Why need to add new option `-f` to saflogger tool? +When long DN is supported, user is able to put long DN name after option `- a`, and saflogger tool will +use that long DN for log file name of that app stream. In that case, the log file name will be over 256 characters in length. +As the result, logsv could get failed to create such long file name (most Unix system supports file name length up to 255 characters). + + +2) Update LOG Agent (API) to Support Long DN +--------------------------------------------- +All internal SaNameT will be replaced by SaConstStringT and functions handling extended SaNameT are used. + +One point needs to be noticed is that, with extended SaNameT, data size could be up to 2048 bytes (not limited to 256 bytes any more). +As the result, several condition checking for max length size against 256 bytes will be updated to 2048 bytes (kOsafMaxDnLength). +So, when supported long DN client (e.g: log client running on OpenSAF 5.1 or newer versions) sends an record containing long DN +(e.g: `notificationObject` length > 256 bytes) to active Log service not support long DN (e.g: active log running on OpenSAF 5.0 +or older versions), that log client will get `SA_AIS_ERR_TRY_AGAIN` always and make cause the log client hang. +There is no problem with the opposite case (non-support long DN do communicate with supported long DN). + + +3) Update LOG Service to Support Long DN +---------------------------------------- +In original code, logsv used NCS PATRICIA TREE as an database to hold all existing LOG streams in system, +and taking stream DN as the keyword for searching/adding/deleting tree elements. +NCS PATRICIA TREE has a limitation with keyword size. It is only supported the key size up to 600 bytes. +With long DN, stream DN could be up to 2024 bytes (kOsafMaxDnLength), that tree is no longer valid. + +Besides, logsv is providing other database named `stream_array` which is used to hold all LOG existing streams. +When there is any new stream created, `log_stream_t` holding information of that stream, will be added to that database +and when the stream is closed and no client connects to that stream, it will be removed from the database. +That database is a two-dimensional array with data format: + { + { <streamId1>, <pointer to `log_stream_t`> }, + { <streamId2>, <pointer to `log_stream_t`> }, + ... + } + +Logsv is able to query below infos from `stream_array` that logsv used to do so based on NCS PATRICIA TREE: +- Is there any current log stream with specific DN in system? +- Or what are the current log existing streams in system? +Therefore, NCS PATRICIA TREE can be removed from logsv code. `stream_array` database can play the same role as NCS_PATRICIA_TREE. + +More on `stream_array` database. All rooms in `stream_array` is clean/reset at startup. +First three rooms are reserved for well-known streams. +At the moment (OpenSAF 5.1), there are total 67 rooms (64 for app streams + 3 for well-known streams). +Adding/deleting/searching items to/from this database is fast. + +In addition to above change, internal SaNameT will be replaced by SaConstStringT or C++ strings and functions handling extended SaNameT are used. + +NOTES: +If active node is OpenSAF 5.1 or newer communicate with older versions such as OpenSAF 5.0 (not support Long DN), +then if there is operation on creating app stream with Long DN, standby node will be crashed. +This will happen because active node sends checkpoint data to standby node, and there is copying data operation (strcpy) +to SaNameT type. Make the data is overflowed. strcpy() should not be used anywhere in code, but strncpy() instead. + +To avoid this happens, two options: +a) During upgrade, make sure there is no long DN operation run until the upgrade is finished. +b) Raise one ticket to fix all places using strcpy() + + +4) Create Test Cases +----------------------------- +New test suite - suite #13 with ten test cases were created to cover minimum requirement described at `GENERAL` section. +Including five normal use cases and five abnormal use cases. + +Each test cases is done with following frame: +a) Backup data such as current IMM attribute values, so that it can be restored back after test run. +b) Set up environment such as enabling long DN support in IMM, change log stream attribute values +c) Write log record containing long DN or creating streams with Long DN. +d) Verify the data if it contains what we expect to have such as log file contains long DN at specific token or not. +e) Close all opened handles +f) Restore the data back to original values. + +At verifying step, if the environment variable `LOGTEST_ENABLE_STDOUT` is set, user will be able to see +the verifying data such as long notifyingObj at specific log file name. +And when running the test suite #13, user does not have to to take care how to set up environment +for long DN testing, all precondition are set to make sure the long DN work. + +Users can refer to these test cases to see how to pass long DN data to LOG APIs, +and what are precondition settings for using extended SaNameT. +The tests are located in the file `~/tests/logsv/tet_log_longDN.c` + +Besides, some other tests/check have been done: +a) Valgrind check +b) Upgrade/downgrade test +c) Cppcheck run + + +III. REFERENCES +======================= + +1) OpenSAF_Extensions_PR.odt + ---------------------------------------------------------------------------- -- _______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net <mailto:Opensaf-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/opensaf-devel ------------------------------------------------------------------------------ _______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
