Hi Praveen, Thanks so much. I am checking and fixing.
Best regards, Long Nguyen. On 8/12/2016 6:40 PM, praveen malviya wrote: > Hi Long, > > I have checked. The problem is not with ava_sanamet_is_valid(). Agent > is getting that env variable for AMFND when it instantiates the > component using CLC-CLI script. This needs to be fixed in amfnd patch. > > Thanks, > Praveen > > > > On 12-Aug-16 3:33 PM, praveen malviya wrote: >> >> >> On 12-Aug-16 1:27 PM, Long Nguyen wrote: >>> Hi Praveen, >>> >>> Actually, since Anders introduced the extended SaNameT in leap core, he >>> also added the osaf_extended_name_init() into leap. >>> Amf agent uses leap library (i.e. saAmfInitialize()). So, applications >>> under amf control enabled long DN implicitly. >>> The SA_AIS_ERR_NAME_TOO_LONG return code is not returned in our case >>> (still SA_AIS_OK) due to the above reason. Consequently, the >>> applications are not crashed. >>> >>> I am not sure if it is right to add osaf_extended_name_init() into >>> leap. >>> However, it is the case now. >>> >> Addition of osaf_extended_name_init() into leap is right because every >> agent has to support long and short dn applications. But >> osaf_extended_name_init() distinguish a long or short dn application >> based on whether application has set "SA_ENABLE_EXTENDED_NAMES" or >> not.If you see the implementation of this API, based on this exported >> variable it remembers whether application is a long dn one or short dn >> one. For this only only applications are recommended via documentation >> to set this environment variable before calling any SAF API if they want >> handle longdn.In this way when first SAF API is called (generally >> sa,*>Initialize()), leap initialization will be done as a part of agent >> creation. Inside leap init it will call osaf_extended_name_init() which >> will use the environment variable to remember about the nature of >> application. >> >> The idea of CCB rejection was based on this only that an agent knows >> via osaf_extended_* APIs that it is created by a longdn or shortdn >> application. And this information can be passed to amfnd and hence to >> AMFD. >> >> But now what needs to be explored is why AMF Dispatch() is not returning >> NAME_TOO_LONG when you have already coded for it? Since old AMF demo has >> not enabled long dn, Dispatch() must return this error code. >> Is there any problem with ava_sanamet_is_valid()? >> Let us debug that. >> >> >>> Can you please share with us your ideas? Do we still need to truncate >>> long names in this case? >> As we have discussed, rejection of CCB can be postponed as it requires >> new messages or introduction of new fields in old messages, all the way >> from AMFA to AMFD. >> So we are left with three options: >> 1) Dispatch() will return NAME_TOO_LONG without invoking callback. >> Current patch is doing this. >> This has one disadvantage that comp/application may exit/crash. >> 2)Dispatch will return SA_AIS_OK "without" invoking the callback. >> This will not confuse application. >> There is one disadvantage here, AMF has an illegal COMPCSI. >> 3)Dispatch will return SA_AIS_OK "by" invoking the callback with >> truncated values. >> This has one advantage that AMF does not have illegal COMPCSI. >> One disadvantage is that if comp is serving more CSI and then it >> will >> not be able to rightly distinguish between the CSI names. >> >> Option 2) sounds Ok to me as it will not create problems with >> application as AMF is not invoking any callback and atleast application >> is serving existing CSIs. Regarding the illegal COMPCSI in AMF: A user >> can always delete it and deletion will not again result in CSI remove >> callback because of the same reasons. At the same time we are cautioning >> the user via documentation (REAMDME and PR doc). >> >> >> thanks, >> Praveen >> >> >>> >>> Best regards, >>> Long Nguyen. >>> >>> On 8/11/2016 3:04 PM, Long Nguyen wrote: >>>> Hi Praveen, >>>> >>>> Thanks for your suggestion. >>>> In the situation you described below, you add a csi dynamically (long >>>> DN) to an application (not support long DN). >>>> So, we only need to truncate the csi name. This will help the >>>> application not crashed. >>>> In my opinion, we only need to truncate in case of CSISet or >>>> CSIRemove. There may be some problems with applications associated >>>> with more than one csi, if the applications base on csi names to do >>>> special things. >>>> In case of protection group, when we call saAmfProtectionGroupTrack, >>>> we have to specify the csi_name. It is not in the case of long DN >>>> since the application does not support long DN. >>>> >>>> Best regards, >>>> Long Nguyen. >>>> >>>> On 8/11/2016 1:29 PM, praveen malviya wrote: >>>>> Hi, >>>>> >>>>> I think, as of now, approaches discussed in this mail thread can be >>>>> mixed for a temporary solution: Dispatch() can return SA_AIS_OK by >>>>> invoking the callback(s) with truncated values for any long field >>>>> (like comp name, csi name etc). In this way comp will have callbacks >>>>> and AMF will also be maintaining legal COMPCSIs. Actual values can be >>>>> logged. Also the the PR doc and Readme should talk how truncation >>>>> will be performed. >>>>> I think, this can be done in this release. >>>>> Other solution of rejecting the CCB itself can be postponed as of >>>>> now. >>>>> >>>>> >>>>> Thanks, >>>>> Praveen >>>>> >>>>> On 11-Aug-16 10:03 AM, Long Nguyen wrote: >>>>>> Hi Praveen and others, >>>>>> >>>>>> I have an idea marked with [Long] below. >>>>>> >>>>>> Best regards, >>>>>> Long Nguyen. >>>>>> >>>>>> On 8/3/2016 1:45 PM, praveen malviya wrote: >>>>>>> >>>>>>> >>>>>>> On 02-Aug-16 3:39 AM, minh chau wrote: >>>>>>>> Hi Praveen, >>>>>>>> >>>>>>>> One comment with [Minh] in line. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Minh >>>>>>>> >>>>>>>> On 01/08/16 17:22, Gary Lee wrote: >>>>>>>>> Hi Praveen >>>>>>>>> >>>>>>>>> On 1/08/2016 4:29 PM, praveen malviya wrote: >>>>>>>>>> Hi Gary, Long, >>>>>>>>>> >>>>>>>>>> Some comments/observations: >>>>>>>>>> -In AMFD saAisNameBorrow() is used in logging and AMFND uses >>>>>>>>>> osaf_extended_name_borrow(). >>>>>>>>>> For osaf_extended_name_borrow() note in osaf_extended_name.h >>>>>>>>>> says it >>>>>>>>>> is intended for mainly agent libraries. But middle-ware services >>>>>>>>>> always use core libs. At the same time saAisNameBorrow(), I >>>>>>>>>> think, is >>>>>>>>>> for application. >>>>>>>>>> any reason of using them this way and what is the recommended >>>>>>>>>> way? >>>>>>>>> I think I used both styles in amfd. I think we can change >>>>>>>>> saAisNameXX >>>>>>>>> to osaf_extended_name_XX just before pushing, to make it >>>>>>>>> consistent >>>>>>>>> with the rest of the OpenSAF services. >>>>>>>>>> -I think, one case may arrive from upgrade perspective. >>>>>>>>>> Suppose any application (say amf_demo app) is running without >>>>>>>>>> enabling long dn and a csi, with its RDn greater than 256, is >>>>>>>>>> added >>>>>>>>>> dynamically (long dn enabled in IMM). In this case AMFD will >>>>>>>>>> assign >>>>>>>>>> this csi to the running component. Component will not be able to >>>>>>>>>> read >>>>>>>>>> the CSI and may crash. >>>>>>>>>> This is related to invocation of CSI_SET callback but same >>>>>>>>>> will be >>>>>>>>>> valid for PG tracking also. There may be other cases also. >>>>>>>>>> Even truncation will not work in this case. >>>>>>>> [Minh] I think the agent patch that Gary submitted currently >>>>>>>> returns >>>>>>>> SA_AIS_ERR_NAME_TOO_LONG in saAmfDispatch() if long DN callback >>>>>>>> comes to >>>>>>>> legacy application (unadapted long DN app). The real callback >>>>>>>> won't be >>>>>>>> issued but application may crash if it exit() on non-SA_AIS_OK >>>>>>>> from >>>>>>>> Dispatch(). I guess you have seen this with #1553? Do you think >>>>>>>> it's >>>>>>>> good way if amf agent drops the long DN callback and also >>>>>>>> Dispatch() >>>>>>>> returns OK to legacy app, and print error in syslog? >>>>>>> Not observed in the context of #1553, but I remember about such >>>>>>> a fix >>>>>>> in NTF long dn changes. >>>>>>> Returning SA_AIS_OK in Dispatch() call saves application from >>>>>>> crash, >>>>>>> but the problem in AMF is still different as it will maintain a >>>>>>> COMPCSI relationship without comp being actually assigned for that. >>>>>>> >>>>>>> Can we think of a way where AMF will not allow this conf change by >>>>>>> rejecting the CCB operation itself. For this AMF should know >>>>>>> that this >>>>>>> application supports Long dn or not. But this information needs >>>>>>> to be >>>>>>> carried from agent to AMFD. >>>>>>> Before going for such a way, I think, we can ask opinion from other >>>>>>> AMF maintainers. >>>>>>> [Long] You have the good solution. However, it is hard to know >>>>>>> if an >>>>>>> application supports long DN or not at the time of CCB >>>>>>> operration. Can >>>>>>> we make your suggestion as an enhancement later? >>>>>>> >>>>>>> Thanks, >>>>>>> Praveen >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>> - While running some tests observed crashes in amfnd and amfd. >>>>>>>>>> I will update #1642 with bt information. >>>>>>>>> Minh will answer this bit. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Gary >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> ------------------------------------------------------------------------------ >> >> >> What NetFlow Analyzer can do for you? Monitors network bandwidth and >> traffic >> patterns at an interface-level. Reveals which users, apps, and >> protocols are >> consuming the most bandwidth. Provides multi-vendor support for NetFlow, >> J-Flow, sFlow and other flows. Make informed decisions using capacity >> planning reports. http://sdm.link/zohodev2dev >> _______________________________________________ >> Opensaf-devel mailing list >> Opensaf-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >> > ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev _______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
