Removing AppConfig.xsd from config is not suggested in the earlier mails: > The Appconfig.xsd and NCSconfig.xsd from the opensaf/samples/avsv directory > shall be removed in the next release.
The XML parser and Appconfig.xsd must be packaged together in the controller rpm. I think there is no other option. Of course AppConfig.xml is the responsibility of an application but not the corresponding schema file! This should be changed back to the way it was in 1.0-2. Regards, Hans Mathivanan Np-G19859 wrote: > There were multiple instances of AppConfig.xsd & NCSConfig.xsd during > 1.2 release & one of them was incorrect. > So from 1.3 onwards, AppConfig.xsd & AppConfig.xml are placed in > opensaf/samples/avsv/ directory alone. > The motive is, If users wish to run their applications or the avsv demo, > they shall copy these to /etc/opt/opensaf and modify the AppConfig.xml > accordingly. > > The following mail threads would explain the context, > http://list.opensaf.org/archives/users/2007-August/000155.html > http://list.opensaf.org/archives/users/2007-August/000145.html > > Regards, > Mathi. > > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Hans Feldt >> Sent: Friday, November 16, 2007 3:54 PM >> To: Kumar Nagendra-G20235 >> Cc: [email protected] >> Subject: Re: [Users] [OpenSAF 1.0-4] Why does standby >> component not become active after rebooting a host with >> active component? >> >> Neither 1.0-3 or 1.0-4 contains : >> >> %config /etc/opt/opensaf/AppConfig.xsd >> >> in the rpm spec file, could that be the problem? I just found >> this is syslog: >> >>> Nov 16 11:15:53 SC_2_1 ncs_scap: NCS_AvSv: Errors occurred >> in DOM tree >>> during parsing xml file: /etc/opt/opensaf/AppConfig.xml, no output >>> available >> Regards, >> Hans >> >> >> Kumar Nagendra-G20235 wrote: >>> Dear Anatoly, >>> >>> Send the logs by runing the scripts >>> opensaf/tools/utilities/collect_logs_controller.sh on both ACT and >>> STDBY. >>> >>> Regards >>> -Nagendra >>> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of >> Anatoly Shirokov >>> Sent: Friday, November 16, 2007 2:35 PM >>> To: [email protected] >>> Subject: Re: [Users] [OpenSAF 1.0-4] Why does standby component not >>> become active after rebooting a host with active component? >>> >>> Additionally log from standby host powered by OpenSAF 1.0-3: >>> >>> Nov 16 11:52:53 host5 solid_amf_adapter: starting Solid AMF Adapter >>> (pid:4954, cmd: /opt/aissolid/bin/solid_amf_adapter).. >>> Nov 16 11:52:53 host5 solid_amf_adapter: loading configuration file >>> (/opt/aissolid/bin/solid.ini).. >>> Nov 16 11:52:55 host5 solid_amf_adapter: MDS_LOG:0 Nov 16 11:52:55 >>> host5 >>> solid_amf_adapter: select result: 1 Nov 16 11:52:55 host5 >>> solid_amf_adapter: result code: 0 Nov 16 11:52:55 host5 >>> solid_amf_adapter: requesting the >>> safComp=CompT_SAA,safSu=SU_SAA,safNode=SC_2_1 component to >> assume the >>> SA_AMF_HA_STANDB Y state for the safCsi=CSI_SAA,safSi=SI_SAA.. >>> Nov 16 11:52:55 host5 solid_amf_adapter: >>> adapter->m_amf_driver->saAmfHealthcheckStop(adapter-> m_handle, >>> compName, healthcheckKey): SA_AIS_ERR >>> _NOT_EXIST () >>> Nov 16 11:52:55 host5 solid_amf_adapter: healthchecking the >>> safComp=CompT_SAA,safSu=SU_SAA,safNode=SC_2_1 component, the 6B6579 >>> key.. >>> Nov 16 11:52:55 host5 solid_amf_adapter: protection group >>> notificationfor csi: safCsi=CSI_SAA,safSi=SI_SAA: >>> Nov 16 11:52:55 host5 solid_amf_adapter: name: >>> safComp=CompT_SAA,safSu=SU_SAA,safNode=SC_2_1, state: >>> SA_AMF_HA_STANDBY, change: STATE CHANGED Nov 16 11:52:56 host5 >>> solid_amf_adapter: netcopy requested notification Nov 16 11:53:00 >>> host5 >>> solid_amf_adapter: healthchecking the >>> safComp=CompT_SAA,safSu=SU_SAA,safNode=SC_2_1 component, the 6B6579 >>> key.. >>> Nov 16 11:53:00 host5 solid_amf_adapter: netcopy finished >> notification >>> Nov 16 11:53:05 host5 solid_amf_adapter: healthchecking the >>> safComp=CompT_SAA,safSu=SU_SAA,safNode=SC_2_1 component, the 6B6579 >>> key.. >>> Nov 16 11:53:35 host5 last message repeated 6 times Nov 16 11:53:36 >>> host5 solid_amf_adapter: starting Solid AMF Adapter (pid:5017, cmd: >>> /opt/aissolid/bin/solid_amf_adapter).. >>> Nov 16 11:53:36 host5 solid_amf_adapter: loading configuration file >>> (/opt/aissolid/bin/solid.ini).. >>> Nov 16 11:53:37 host5 solid_amf_adapter: MDS_LOG:0 Nov 16 11:53:37 >>> host5 >>> solid_amf_adapter: select result: 1 Nov 16 11:53:37 host5 >>> solid_amf_adapter: result code: 0 Nov 16 11:53:37 host5 >>> solid_amf_adapter: requesting the >>> safComp=CompT_SAA,safSu=SU_SAA,safNode=SC_2_1 component to >> assume the >>> SA_AMF_HA_STANDB Y state for the safCsi=CSI_SAA,safSi=SI_SAA.. >>> Nov 16 11:53:37 host5 solid_amf_adapter: >>> adapter->m_amf_driver->saAmfHealthcheckStop(adapter-> m_handle, >>> compName, healthcheckKey): SA_AIS_ERR >>> _NOT_EXIST () >>> Nov 16 11:53:37 host5 solid_amf_adapter: healthchecking the >>> safComp=CompT_SAA,safSu=SU_SAA,safNode=SC_2_1 component, the 6B6579 >>> key.. >>> Nov 16 11:53:37 host5 solid_amf_adapter: protection group >>> notificationfor csi: safCsi=CSI_SAA,safSi=SI_SAA: >>> Nov 16 11:53:37 host5 solid_amf_adapter: name: >>> safComp=CompT_SAA,safSu=SU_SAA,safNode=SC_2_1, state: >>> SA_AMF_HA_STANDBY, change: STATE CHANGED Nov 16 11:53:42 host5 >>> solid_amf_adapter: healthchecking the >>> safComp=CompT_SAA,safSu=SU_SAA,safNode=SC_2_1 component, the 6B6579 >>> key.. >>> Nov 16 11:54:12 host5 last message repeated 6 times Nov 16 11:54:14 >>> host5 kernel: TIPC: Resetting link >> <1.1.31:eth0-1.1.47:eth0>, peer not >>> responding Nov 16 11:54:14 host5 kernel: TIPC: Lost link >>> <1.1.31:eth0-1.1.47:eth0> on network plane A Nov 16 11:54:14 host5 >>> kernel: TIPC: Lost contact with <1.1.47> Nov 16 11:54:14 host5 >>> solid_amf_adapter: requesting the >>> safComp=CompT_SAA,safSu=SU_SAA,safNode=SC_2_1 component to >> assume the >>> SA_AMF_HA_ACTIVE >>> state for the .. >>> Nov 16 11:54:17 host5 solid_amf_adapter: protection group >>> notificationfor csi: safCsi=CSI_SAA,safSi=SI_SAA: >>> Nov 16 11:54:17 host5 solid_amf_adapter: name: >>> safComp=CompT_SAA,safSu=SU_SAA,safNode=SC_2_2, state: SA_AMF_UNKNOW, >>> change: REMOVED >>> Nov 16 11:54:17 host5 solid_amf_adapter: healthchecking the >>> safComp=CompT_SAA,safSu=SU_SAA,safNode=SC_2_1 component, the 6B6579 >>> key.. >>> Nov 16 11:54:17 host5 solid_amf_adapter: protection group >>> notificationfor csi: safCsi=CSI_SAA,safSi=SI_SAA: >>> Nov 16 11:54:17 host5 solid_amf_adapter: name: >>> safComp=CompT_SAA,safSu=SU_SAA,safNode=SC_2_1, state: >>> SA_AMF_HA_ACTIVE, change: STATE CHANGED >>> >>> As you see the 1.0-3 works correctly. >>> >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://list.opensaf.org/maillist/listinfo/users >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://list.opensaf.org/maillist/listinfo/users >>> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://list.opensaf.org/maillist/listinfo/users >> > _______________________________________________ Users mailing list [email protected] http://list.opensaf.org/maillist/listinfo/users
