Giter VIP home page Giter VIP logo

sapstartsrv-resourceagent's Introduction

Resouce agent CI Test Coverage

SAPStartSrv-resourceAgent

pacemaker integration for instance specific sapstartsrv

Overview

This project is to implement a resource-agent for the instance specific SAP start framework. It controls the instance specific sapstartsrv process which provides the API to start, stop and check an SAP instance.

SAPStartSrv does only start, stop and probe for the server process. By intention it does not monitor the service. SAPInstance is doing in-line recovery of failed sapstartsrv processes instead.

SAPStartSrv is to be included into a resource group together with the vIP and the SAPInstance. It needs to be started before SAPInstance is starting and needs to be stopped after SAPInstance has been stopped.

SAPStartSrv could be used since SAP NetWeaver 7.40 or SAP S/4HANA (ABAP Platform >= 1909).

sapping and sappong - agents to hide/unhide the /usr/sap/sapservices files during system boot to avoid that sapstartsrv is started for an SAP Instance. sapping is running before sapinit and sappong is running after sappong.

Resource example

SAPStartSrv could be used where-ever it is not possible to mount/unmount the work directories of the SAPInstances. The example is based on https://documentation.suse.com/sbp/all/single-html/SAP_NW740_SLE12_SetupGuide/. We replace the file system resource by an SAPStartSrv resource.

primitive rsc_sapstartsrv_HA1_ASCS00 ocf:suse:SAPStartSrv \
         params InstanceName=HA1_ASCS00_sapha1as         

group grp_HA1_ASCS00 \
  rsc_ip_HA1_ASCS00 rsc_sapstartsrv_HA1_ASCS00 rsc_sap_HA1_ASCS00 \
     meta resource-stickiness=3000

Note: The resource rsc_sapstartsrv_HA1_ASCS00 does by intention not define a monitoring operation. This is, because the failing sapstartsrv must never force an SAP instance restart which would happen, as the two resources reside in one resource group.

Note: To use the python version of the resource agent, the shebang of the script file must be changed (this is done during the packaging process). Replace #!@PYTHON@ -tt by #!/usr/bin/python3 -tt with the correct python version.

Unit tests

The python version of the resource agent comes with a unit test battery. In order to run them:

cd SAPStartSrv-resourceAgent
virtualenv myvirtenv
source myvirtenv/bin/activate
myvirtenv/bin/pip install pytest-cov mock
myvirtenv/bin/py.test -vv --cov=SAPStartSrv --cov-report term tests

Or using tox (this tool will test for a broader set of python versions):

cd SAPStartSrv-resourceAgent
virtualenv myvirtenv
source myvirtenv/bin/activate
pip install tox tox-gh-actions
tox

Continuous Integration pipeline

The CI/CD pipelines are executed using github actions. This execution runs:

  • Run unit tests
  • Deliver the package content to the configured OBS[1] repository
  • Submit the new package content to the upstream OBS repository

In order to make this work in the used fork some secrets must be added in the github repository:

  • OBS_USER: Your OBS user
  • OBS_PASSWORD: Your OBS user password
  • OBS_PROJECT: Project where the package is delivered
  • TARGET_PROJECT: Target project where the new package content is submitted
  • CC_TEST_REPORTER_ID (Optional): Sent the code coverage to code climate. If it is not set this step is not executed

The delivery and submission tasks are based in a docker container: https://github.com/arbulu89/continuous-delivery

[1] OBS stands for Open Build Service

sapstartsrv-resourceagent's People

Contributors

angelabriel avatar arbulu89 avatar fmherschel avatar lpinne avatar mkoderer avatar yeoldegrove avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

sapstartsrv-resourceagent's Issues

SAPStartSrv interferences with SAPinstance

On my test cluster I see interferences between SAPStartSrv and SAPInstance.
At the beginning I have all resources for ASCS00 on valuga11.
All resources for ERS10 are running on valuga12.

Now I call SAPInstance (with ERS10 parameters and action status) either manually or via cluster (crm resource cleanup rsc_sap_EN2_ERS10) on valuga11. After that sapstartsrv is running at valuga11 to. A later status action of rsc_sapsrv_EN2_ERS10 reports now running (even if it should not be running).

The reason is, that during the probe (status action) SAPInstance needs sapstartsrv (the SAP service) to run to check, if the SAP instance is running. This has multiple negative effects:

  1. sapstartsrv for ERS10 is running multiple
  2. file "available" now toggels status "Available"/"Unavailable"
  3. file "sapstartsrv.log" gets overwritten and not longer contains the log of the running instance
  4. file "sap_suse_cluster_connector.log" gets overwritten and not longer contains the log of the running instance

Fact 2 does also have consequences in customer monitoring tools (such as nagios)
Facts 3+4 are critical in SAP support situations, because the current files are not longer match to the running instance (e.g. on valuga12)

==> We might need to add a flag (parameter in SAPInstance not to start sapstartsrv for the simplified mount use-case) during probe (aka status).

The internal method "_inititialize" needs to be checked with various full-instance-names

The (internal) method _inititialize needs to be checked with various full-instance-names. Most of the tests are already using the split values of the full instance name like self.sid, self.instance_name and self.virtual_host.

In all those cases we are not checking the correct split of the full-instance-format SID_INSTANCE-NAME_VIRTUAL-HOST-NAME.
Important is that VIRTUAL-HOST-NAME are containing underscores ("_") so the number of field when splitting the string is >=3 and not always ==3.

Test cases could be e.g.

  • full instance name is: HA1_ASCS10_suse01
  • full instance name is: HA1_ERS20_suse02
  • full instance name is: HA1_ERS20_suse02-cluster
  • full instance name is: HA1_ERS20_suse02_cluster

Package BuildRequires python3-mock

This package requires python3-mock to build, and the Python packaging team are currently working towards removing that package since the lowest version of Python currently shipped in Tumbleweed provides mocking ability via unittest.mock. I see you've already changed the test code to support importing that instead. I'd suggest removing the BuildRequires for Factory only, or if that is not possible, guarding it with suse_version < 1500.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.