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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
