Hi Vu, I don't think it is required , I will check OpenSAF_extensions_PR.
-AVM On 7/8/2016 10:30 AM, Vu Minh Nguyen wrote: > Hi Mahesh, > > In the OpenSAF_extensions_PR, it stated clearly how to enable extended > SaNameT in application at 4.3 section. > I am wondering it is redundant to re-state such info in every services that > has Long DN support. > > Regards, Vu > >> -----Original Message----- >> From: A V Mahesh [mailto:mahesh.va...@oracle.com] >> Sent: Friday, July 8, 2016 11:42 AM >> To: Vu Minh Nguyen <vu.m.ngu...@dektech.com.au>; >> lennart.l...@ericsson.com >> Cc: opensaf-devel@lists.sourceforge.net >> Subject: Re: [PATCH 1 of 1] log: Readme file for long DN support [#1315] >> >> Hi Vu, >> >> It seems this README doesn't explained , how to enable >> SA_ENABLE_EXTENDED_NAMES on a node, >> >> if some application is creating an app stream ( NOT using saflogger tool >> ) DN is longer than 255 characters in length. >> >> -AVM >> >> On 7/4/2016 8:36 AM, Vu Minh Nguyen wrote: >>> 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. >>> + >>> +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. >>> + >>> + >>> +II) IMPLEMENTATION (#1315) >>> +============================== >>> + >>> +1) Update saflogger tool - Add One More Option `-f` >>> +------------------------------------------------- >>> +`-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. >>> + >>> +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 >>> + > ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
