Merge branch 'CT-147' into 'master' (783b10a1) · Commits · Gianluca Marotta / csp-lmc-old

.gitlab-ci.yml

+11 −9

Original line number	Diff line number	Diff line
		# GitLab CI in conjunction with GitLab Runner can use Docker Engine to test and build any application.
		# Docker, when used with GitLab CI, runs each job in a separate and isolated container using the predefined image that is set up in .gitlab-ci.yml.
		# In this case we use the latest python docker image to build and test this project.
		#image: nexus.engageska-portugal.pt/ska-docker/ska-python-buildenv:latest
		image: nexus.engageska-portugal.pt/ska-docker/ska-python-buildenv:latest

		variables:
		DOCKER_DRIVER: overlay2
		@@ -32,18 +32,20 @@ cache:
		# build: build the docker images for csp-lmc-mid and csp-lmc-low
		# test: execute tests on csp-lmc-common, csp-lmc-mid, csp-lmc-low
		# package: create the python packages for common, mid and low
		# publish: publish on nexus the mid and low images and the common python package
		# pages: create the badges
		# publish: publish on nexus the mid common python packages
		# pages: move the metrics files to the right folder
		# release release the images for csp-lmc-low and mid (only manual)
		stages:
		- build_common
		- linting_common
		- test_common
		- publish_common
		- build
		- test
		- linting
		- release
		- test
		- publish
		- pages
		- release

		.install_pip: &install_pip \|-
		apt-get -y update && apt-get install -yq curl python3-distutils
		@@ -66,12 +68,12 @@ pages:
		- docker-executor
		stage: pages
		variables:
		COMMON_PATH: csp-lmc-common/docker
		MIDCSP_PATH: csp-lmc-mid/docker
		COMMON_PATH: csp-lmc-common/
		MIDCSP_PATH: csp-lmc-mid/
		script:
		- pwd
		- python3 -m pip install junitparser
		#update coverage o the last release
		#update coverage to the last release
		- python3 -m pip install --upgrade coverage
		- ls -lR
		# copy the content of packages folders in public
		@@ -79,7 +81,7 @@ pages:
		# that has been cloned during the build
		- cp -R $COMMON_PATH/build/ public
		- cp -R $MIDCSP_PATH/build/* public
		- ls -lR
		- ls -lR public
		- junitparser merge public/reports/csp-lmc-common-unit-tests.xml public/reports/csp-lmc-mid-unit-tests.xml public/reports/unit-tests.xml
		- ls -lR
		- junitparser merge public/reports/csp-lmc-common-linting.xml public/reports/csp-lmc-mid-linting.xml public/reports/linting.xml

README.md

+188 −22

Original line number	Diff line number	Diff line
		@@ -10,8 +10,8 @@ CPS.LMC project
		* [Repository](#repository)
		* [CSP.LMC Common Package](#csp-lmc-common)
		* [Create the CSP.LMC Common Software python package](#python-package)
		* [CSP_Mid LMC](#mid-csp-mid-lmc)
		* [Running tests](#running-tests)
		* [CSP_Mid LMC](#CSP_Mid.LMC)
		* [CSP_Mid LMC Deployment in Kubernetes](#mid-CSP.LMC-Kubernetes-Deployment-via-Helm-Charts)
		* [CSP_Low LMC](#csp-low-lmc)
		* [Run in containers](#how-to-run-in-docker-containers)
		* [Known bugs](#known-bugs)
		@@ -39,8 +39,10 @@ the same organization:

		* project source: contains the specific project TANGO Device Class files
		* pogo: contains the POGO files of the TANGO Device Classes of the project
		* docker: containes the `docker`, `docker-compose` and `dsconfig` configuration files as well as the Makefile to generate the docker image and run the tests.
		* tests: contains the test
		* charts: stored the HEML charts to deploy the Mid CSP.LMC system under kubernets environment.
		* docker: containes the `docker`, `docker-compose` and `dsconfig` configuration files as well as
		the Makefile to generate the docker image and run the tests.

		To get a local copy of the repository:

		@@ -52,18 +54,194 @@ git clone https://gitlab.com/ska-telescope/csp-lmc.git
		* A TANGO development environment properly configured, as described in [SKA developer portal](https://developer.skatelescope.org/en/latest/tools/tango-devenv-setup.html)

		* [SKA Base classes](https://gitlab.com/ska-telescope/lmc-base-classes)
		*
		## CSP_Mid.LMC
		* access to a K8s/minikube cluster.

		# CSP_Mid.LMC

		The TANGO devices of the CSP_Mid.LMC prototype run in a containerised environment.
		Currently only a limitated number of CSP_Mid.LMC and CBF_Mid.LMC devices are run in Docker containers:

		* the MidCspMaster and MID CbfMaster
		* the MidCspCapabilityMonitor devices
		* two instances of the CSP_Mid and CBF_Mid subarrays
		* three instances of the CSP_Mid and CBF_Mid subarrays
		* four instances of the Very Coarse Channelizer (VCC) devices
		* four instance of the Frequency Slice Processor (FPS) devices
		* two instances of the TM TelState Simulator devices
		* one instance of the TANGO database

		## Containerised Mid CSP.LMC in Kubernetes

		The Mid CSP.LMC containerised TANGO servers are managed via Kubernetes.
		The system is setup so that each k8s Pod has only one Docker container that in turn
		runs only one Tango Device Server application.<br/>
		Mid CSP.LMC TANGO Servers rely on two different Docker images: `mid-csplmc` and `mid-cbf-mcs`. <br/>
		The first one runs the CSP.LMC TANGO devices and the sencond those of the Mid CBF.LMC prototype.

		### Mid CSP.LMC Kubernetes Deployment via Helm Charts

		The deployment of the system is handled by the Helm tool, via the Helm Charts, a set of YAML files describing
		how the Kubernetes resources are related.<br/>
		The Mid CSP.LMC Helm Charts are stored in the `charts` directory, organized in two sub-folders: <br/>

		* csp-proto with the Helm chart to deploy only the CSP.LMC devices (MidCspCapabilityMonitor, MidcSpMaster nad MidCspSubarray)
		* mid-csp with the Helm chart to deploy the whole Mid CSP.LMC system, including the TANGO Database and the Mid CSF.LMC devices.
		In particular, the `mid-csp` chart depends on the CSP.LMC, CBF.LMC and Tango DB charts and these dependecies are
		dynamically linked specifying the `dependencies` field in the Chart.yaml.<br/>

		The `Makefile` in the csp-lmc-mid root directory provides the targets to deploy the system, stop the running services and run
		the tests locally, on a k8s/minikube machine.

		To deploy the whole Mid CSP.LMC system run:

		``` bash
		make deploy
		```
		that installs the mid-csp helm chart specifying `test` as relase name and assigns it to the `csp-proto` namespace.

		Running the command:
		```bash
		helm list -n csp-proto
		```
		an output like the one below is shown:
		```
		NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
		test csp-proto 1 2020-09-21 10:07:19.308839059 +0200 CEST deployed mid-csp-0.1.0 0.6.8
		```

		To list all the pods and service in the csp-proto namespace, issue the command:

		```bash
		kubectl get all -n csp-proto
		```

		that provides the following output lines:

		```
		NAME READY STATUS RESTARTS AGE
		pod/databaseds-tango-base-test-0 1/1 Running 0 2m48s
		pod/mid-cbf-cbf-proto-cbfmaster-test-0 1/1 Running 0 2m50s
		pod/mid-cbf-cbf-proto-cbfsubarray01-test-0 1/1 Running 1 2m50s
		pod/mid-cbf-cbf-proto-cbfsubarray02-test-0 1/1 Running 1 2m48s
		pod/mid-cbf-cbf-proto-cbfsubarray03-test-0 1/1 Running 1 2m48s
		pod/mid-cbf-cbf-proto-fsp01-test-0 1/1 Running 0 2m49s
		pod/mid-cbf-cbf-proto-fsp02-test-0 1/1 Running 0 2m49s
		pod/mid-cbf-cbf-proto-fsp03-test-0 1/1 Running 0 2m50s
		pod/mid-cbf-cbf-proto-fsp04-test-0 1/1 Running 0 2m50s
		pod/mid-cbf-cbf-proto-tmcspsubarrayleafnodetest-test-0 1/1 Running 0 2m49s
		pod/mid-cbf-cbf-proto-tmcspsubarrayleafnodetest2-test-0 1/1 Running 0 2m48s
		pod/mid-cbf-cbf-proto-vcc001-test-0 1/1 Running 3 2m47s
		pod/mid-cbf-cbf-proto-vcc002-test-0 1/1 Running 3 2m50s
		pod/mid-cbf-cbf-proto-vcc003-test-0 1/1 Running 3 2m50s
		pod/mid-cbf-cbf-proto-vcc004-test-0 1/1 Running 3 2m49s
		pod/mid-cbf-configurator-cbf-proto-test-m6j2p 0/1 Error 0 2m50s
		pod/mid-cbf-configurator-cbf-proto-test-qm8xg 0/1 Completed 0 2m15s
		pod/midcsplmc-configurator-csp-proto-test-d7hmp 0/1 Completed 0 2m15s
		pod/midcsplmc-configurator-csp-proto-test-qnks4 0/1 Error 0 2m50s
		pod/midcsplmc-csp-proto-midcapabilitymonitor-test-0 1/1 Running 3 2m48s
		pod/midcsplmc-csp-proto-midcspmaster-test-0 1/1 Running 0 2m50s
		pod/midcsplmc-csp-proto-midcspsubarray01-test-0 1/1 Running 1 2m50s
		pod/midcsplmc-csp-proto-midcspsubarray02-test-0 1/1 Running 1 2m50s
		pod/midcsplmc-csp-proto-midcspsubarray03-test-0 1/1 Running 1 2m50s
		pod/tango-base-tangodb-0


		NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
		service/databaseds-tango-base-test NodePort 10.103.37.75 <none> 10000:31664/TCP 2m50s
		service/mid-cbf-cbf-proto-cbfmaster-test ClusterIP None <none> 1234/TCP 2m50s
		service/mid-cbf-cbf-proto-cbfsubarray01-test ClusterIP None <none> 1234/TCP 2m50s
		service/mid-cbf-cbf-proto-cbfsubarray02-test ClusterIP None <none> 1234/TCP 2m50s
		service/mid-cbf-cbf-proto-cbfsubarray03-test ClusterIP None <none> 1234/TCP 2m50s
		service/mid-cbf-cbf-proto-fsp01-test ClusterIP None <none> 1234/TCP 2m50s
		service/mid-cbf-cbf-proto-fsp02-test ClusterIP None <none> 1234/TCP 2m50s
		service/mid-cbf-cbf-proto-fsp03-test ClusterIP None <none> 1234/TCP 2m50s
		service/mid-cbf-cbf-proto-fsp04-test ClusterIP None <none> 1234/TCP 2m50s
		service/mid-cbf-cbf-proto-tmcspsubarrayleafnodetest-test ClusterIP None <none> 1234/TCP 2m50s
		service/mid-cbf-cbf-proto-tmcspsubarrayleafnodetest2-test ClusterIP None <none> 1234/TCP 2m50s
		service/mid-cbf-cbf-proto-vcc001-test ClusterIP None <none> 1234/TCP 2m50s
		service/mid-cbf-cbf-proto-vcc002-test ClusterIP None <none> 1234/TCP 2m50s
		service/mid-cbf-cbf-proto-vcc003-test ClusterIP None <none> 1234/TCP 2m50s
		service/mid-cbf-cbf-proto-vcc004-test ClusterIP None <none> 1234/TCP 2m50s
		service/midcsplmc-csp-proto-midcapabilitymonitor-test ClusterIP None <none> 1234/TCP 2m50s
		service/midcsplmc-csp-proto-midcspmaster-test ClusterIP None <none> 1234/TCP 2m50s
		service/midcsplmc-csp-proto-midcspsubarray01-test ClusterIP None <none> 1234/TCP 2m50s
		service/midcsplmc-csp-proto-midcspsubarray02-test ClusterIP None <none> 1234/TCP 2m50s
		service/midcsplmc-csp-proto-midcspsubarray03-test ClusterIP None <none> 1234/TCP 2m50s
		service/tango-base-tangodb NodePort 10.102.174.225 <none> 3306:30633/TCP 2m50s

		NAME READY AGE
		statefulset.apps/databaseds-tango-base-test 1/1 2m50s
		statefulset.apps/mid-cbf-cbf-proto-cbfmaster-test 1/1 2m50s
		statefulset.apps/mid-cbf-cbf-proto-cbfsubarray01-test 1/1 2m50s
		statefulset.apps/mid-cbf-cbf-proto-cbfsubarray02-test 1/1 2m50s
		statefulset.apps/mid-cbf-cbf-proto-cbfsubarray03-test 1/1 2m50s
		statefulset.apps/mid-cbf-cbf-proto-fsp01-test 1/1 2m50s
		statefulset.apps/mid-cbf-cbf-proto-fsp02-test 1/1 2m50s
		statefulset.apps/mid-cbf-cbf-proto-fsp03-test 1/1 2m50s
		statefulset.apps/mid-cbf-cbf-proto-fsp04-test 1/1 2m50s
		statefulset.apps/mid-cbf-cbf-proto-tmcspsubarrayleafnodetest-test 1/1 2m50s
		statefulset.apps/mid-cbf-cbf-proto-tmcspsubarrayleafnodetest2-test 1/1 2m50s
		statefulset.apps/mid-cbf-cbf-proto-vcc001-test 1/1 2m50s
		statefulset.apps/mid-cbf-cbf-proto-vcc002-test 1/1 2m50s
		statefulset.apps/mid-cbf-cbf-proto-vcc003-test 1/1 2m50s
		statefulset.apps/mid-cbf-cbf-proto-vcc004-test 1/1 2m50s
		statefulset.apps/midcsplmc-csp-proto-midcapabilitymonitor-test 1/1 2m50s
		statefulset.apps/midcsplmc-csp-proto-midcspmaster-test 1/1 2m50s
		statefulset.apps/midcsplmc-csp-proto-midcspsubarray01-test 1/1 2m50s
		statefulset.apps/midcsplmc-csp-proto-midcspsubarray02-test 1/1 2m50s
		statefulset.apps/midcsplmc-csp-proto-midcspsubarray03-test 1/1 2m50s
		statefulset.apps/tango-base-tangodb 1/1 2m50s

		NAME COMPLETIONS DURATION AGE
		job.batch/mid-cbf-configurator-cbf-proto-test 1/1 61s 2m50s
		job.batch/midcsplmc-configurator-csp-proto-test 1/1 59s 2m50s
		```
		The helm release can be deleted and the application stopped using the command:
		```bash
		make delete
		```
		that unistalls the `mid-csp` chart and delete the `test` release in the `csp-proto` namespace.

		Other Makefile targets, such as `describe` and `logs`, provide some useful information when the system has been properly deployed.

		## Run integration tests on a local k8s/minikube cluster

		The project includes a set of tests for the `MidCspMaster` and `MidCspSubarray` TANGO Devices
		that can be found in the project `tests` folder.<br/>
		To run the tests on the local k8s cluster, issue the command:

		```bash
		make k8s_test
		```
		from the root project directory.<br/>

		This command first deploys the system and then executes the integration tests.

		After tests end, run the command:

		```bash
		make delete
		```
		to uninstall the HELM charts of the `test` release.

		## Gitlab continuos integration tests

		Continuos integration tests in Gitlab rely on the `.gitlab-ci.yml` configuration file that provides al the scripts to build, test and deploy the application. <br/>
		This file has been updated to run test in K8s environment and any reference to the use of `docker-compose` as containers manager,
		has been removed. <br/>
		A new job has been added in the pipline `publish` stage to release the the `csp-proto` helm chart in the SKA Helm charts repositoryhostes under `nexus`.

		## Docker-compose support

		Support to `docker-compose` has not been completely removed even if all the main operations are
		performed in kubernetes environment.<br/>
		Use of `docker-compose` has been maintened only to simplify the development on machines that
		are not capable to run minikube in a virtual machine.<br/>
		The `docker` folder of the project contains all the files required to run the system via the
		docker-compose tool.
		From the docker folder of the project, one can still:
		• build the image running `make build`
		• start the system dockers with docker-compose executing `make up`
		• run the test on the local machine calling `make test`

		The Docker containers running the CBF_Mid devices are instantiated pulling the `mid-cbf-mcs:test` project image from the [Nexus repository](https://nexus.engageska-portugal.pt). <br/>
		The CSP_Mid.LMC project provides a [Makefile](Makefile) to start the system containers and the tests.<br/>
		@@ -75,13 +253,10 @@ The containerised environment relies on three YAML configuration files:

		Each file includes the stages to run the the `CSP_Mid.LMC TANGO DB`, the `CSP_Mid.LMC` devices and `Mid-CBF.LMC` TANGO Devices inside separate docker containers.<br/>
		These YAML files are used by `docker-compose` to run both the CSP_Mid.LMC and CBF.LMC TANGO device
		instances, that is, to run the whole `CSP_Mid.LMC` prototype.>br\>
		instances, that is, to run the whole `CSP_Mid.LMC` prototype.<br/>
		In this way, it's possible to execute some preliminary integration tests, as for example the assignment/release of receptors to a `CSP_Mid Subarray` and its configuration to execute a scan in Imaging mode.<br/>
		The `CSP_Mid.LMC` and `Mid-CBF.LMC TANGO` Devices are registered with the same TANGO DB, and its
		configuration is performed via the `dsconfig` TANGO Device provided by the [dsconfig project](https://gitlab.com/MaxIV-KitsControls/lib-maxiv-dsconfig). <br/>
		This device use a JSON file to configure the TANGO DB. <br/>
		The `CSP_Mid.LMC` and `Mid-CBF.LMC` projects provide its own JSON file:
		[midcsplmc\_dsconfig.json](csp-lmc/csp-lmc-mid/csp-lmc-mid/docker/config/midcsplmc_dsconfig.json) and [midcbf\_dsconfig.json](sp-lmc/csp-lmc-mid/csp-lmc-mid/docker/config/midcbf_dsconfig.json)

		To run the `CSP_Mid.LMC` prototype inside Docker containers,issue the command:

		@@ -99,11 +274,11 @@ mid-csp-lmc-cbf_dsconfig: the dsconfig container to configure CBF.LMC devi
		mid-csp-lmc-cbf_dsconfig: the dsconfig container to configure CSP.LMC devices in the TANGO DB
		mid-csp-lmc-midcspmaster: the CspMaster TANGO device
		mid-csp-lmc-midcapabilitymonitor: the monitor devices of the CSP_Mid.LMC Capabilities
		mid-csp-lmc-midcspsubarray[01-02]: two instances of the CspSubarray TANGO device
		mid-csp-lmc-midcspsubarray[01-023: two instances of the CspSubarray TANGO device
		mid-csp-lmc-rsyslog-csplmc: the rsyslog container for the CSP.LMC devices
		mid-csp-lmc-rsyslog-cbf : the rsyslog container for the CBF.LMC devices
		mid-csp-lmc-cbfmaster: the CbfMaster TANGO device
		mid-csp-lmc-cbfsubarray[01-02]: two instances of the CbfSubarray TANGO device
		mid-csp-lmc-cbfsubarray[01-03]: two instances of the CbfSubarray TANGO device
		mid-csp-lmc-vcc[001-004]: four instances of the Mid-CBF VCC TANGO device
		mid-csp-lmc-fsp[01-04]: four instances of the Mid-CBF FSP TANGO device
		mid-csp-lmc-tmcspsubarrayleafnodetest/2: two instances of the TelState TANGO Device
		@@ -121,15 +296,6 @@ This means that the TANGO DB running in the container is available on port 10000
		Running `jive` on the local host, the `CSP.LMC` and `Mid-CBF.LMC` TANGO Devices registered with the TANGO DB (running in a docker container)
		can be visualized and explored.

		## Running tests

		The project includes a set of tests for the `MidCspMaster` and `MidCspSubarray` TANGO Devices that can be found in the project `tests` folder.<br/>
		To run the test on the local host issue the command

		<code><pre>make test</pre></code>
		from the `docker` project directory.<br/>
		The test are run in docker containers providing the proper environment setup and isolation.

		## Known bugs

csp-lmc-common/.gitlab-ci.yml

+30 −14

Original line number	Diff line number	Diff line
		@@ -61,38 +61,54 @@ build:csp-lmc-common_image:
		#

		.test_common:
		image: nexus.engageska-portugal.pt/ska-docker/tango-builder:latest
		before_script:
		- docker login -u $DOCKER_REGISTRY_USERNAME -p $DOCKER_REGISTRY_PASSWORD $DOCKER_REGISTRY_HOST
		image: nexus.engageska-portugal.pt/ska-docker/ska-python-buildenv:latest
		tags:
		- docker-executor
		artifacts:
		paths:
		- ./$COMMON_BUILD_PATH/build/
		variables:
		COMMON_BUILD_PATH: csp-lmc-common/docker
		COMMON_BUILD_PATH: csp-lmc-common

		test:csp-lmc-common:
		extends: .test_common
		stage: test_common
		script:
		- cd $COMMON_BUILD_PATH
		- make test
		- pwd
		- python3 -m pip install -r requirements-tst.txt
		- python3 -m pip install --extra-index-url https://nexus.engageska-portugal.pt/repository/pypi/simple -r requirements.txt
		- python3 setup.py test \|tee setup_py_test.stdout
		- pwd
		- mkdir -p build/reports
		- ls -alR
		- mv setup_py_test.stdout build/csp-lmc-common-setup-test.stdout
		- mv htmlcov build/csp-lmc-common_htmlcov
		- mv coverage.xml build
		#
		# linting stage
		.linting_common:
		extends: .test_common
		stage: linting

		linting:csp-lmc-common:
		image: nexus.engageska-portugal.pt/ska-docker/ska-python-buildenv:latest
		stage: linting_common
		tags:
		- docker-executor
		artifacts:
		paths:
		- ./$COMMON_BUILD_PATH/build/
		dependencies: []
		script:
		- apt-get -y update
		- apt-get install -y python3-pip python3-setuptools python3-wheel --no-install-recommends
		- python3 -m pip install pylint2junit
		- cd $COMMON_BUILD_PATH
		- make lint

		linting:csp-lmc-common:
		extends: .linting_common
		dependencies: []
		- python3 -m pip install --extra-index-url https://nexus.engageska-portugal.pt/repository/pypi/simple -r requirements.txt
		- mkdir -p build/reports
		- pylint --output-format=parseable csp_lmc_common \| tee ./build/csp_lmc_common-code-analysis.stdout
		- pylint --output-format=pylint2junit.JunitReporter csp_lmc_common > ./build/reports/csp-lmc-common-linting.xml
		- ls -alR
		variables:
		COMMON_BUILD_PATH: csp-lmc-common

		#
		# Publish csp-lmc-common python package

csp-lmc-common/conftest.py

deleted100644 → 0

+0 −87

Original line number	Diff line number	Diff line
		"""
		A module defining a list of fixture functions.
		"""
		import importlib
		import pytest

		import tango
		from unittest import mock
		from tango import DeviceProxy
		from tango.test_context import DeviceTestContext

		@pytest.fixture(scope="class")
		def tango_context(request):
		"""Creates and returns a TANGO DeviceTestContext object.

		Parameters
		----------
		request: _pytest.fixtures.SubRequest
		A request object gives access to the requesting test context.
		"""
		test_properties = {
		'CspMaster': {'SkaLevel': '2',
		'CspCbf': 'mid_csp_cbf/sub_elt/master',
		'CspPss': 'mid_csp_pss/sub_elt/master',
		'CspPst': 'mid_csp_pst/sub_elt/master',
		},
		'CspSubarray': {'CspMaster': 'common/elt/master',
		'CbfSubarray': 'mid_csp_cbf/sub_elt/subarray_01',
		'PssSubarray': 'mid_csp_pss/sub_elt/subarray_01',
		'SubID' : 1,
		},
		}
		# TODO: package_name and class_name can be used in future
		# fq_test_class_name = request.cls.__module__
		# fq_test_class_name_details = fq_test_class_name.split(".")
		# package_name = fq_test_class_name_details[1]
		# class_name = module_name = fq_test_class_name_details[1]
		test_class_name = request.cls.__name__
		class_name = test_class_name.split('Test', 1)[-1]
		module = importlib.import_module("{}.{}".format("csp_lmc_common", class_name))
		klass = getattr(module, class_name)
		tango_context = DeviceTestContext(klass, properties=test_properties.get(class_name))
		tango_context.start()
		yield tango_context
		tango_context.stop()

		#
		# NOTE: if initialize_device is called, the tests crash with error because during the
		# CspMaster and CspMaster access to the TANGO DB to get the memorized attributes.
		# Need to mock the call to the TANGO DB get_device_attribute
		@pytest.fixture(scope="function")
		def initialize_device(tango_context):
		"""Re-initializes the device.

		Parameters
		----------
		tango_context: tango.test_context.DeviceTestContext
		Context to run a device without a database.
		"""
		yield tango_context.device.Init()

		@pytest.fixture(scope="class")
		def cbf_master():
		"""Create DeviceProxy for the CbfMaster device
		to test the device with the TANGO DB
		"""
		database = tango.Database()
		instance_list = database.get_device_exported_for_class('CbfMaster')
		for instance in instance_list.value_string:
		try:
		return tango.DeviceProxy(instance)
		except tango.DevFailed:
		continue


		@pytest.fixture(scope="class")
		def csp_master():
		"""Create DeviceProxy for the CspMaster device
		to test the device with the TANGO DB
		"""
		database = tango.Database()
		instance_list = database.get_device_exported_for_class('CspMaster')
		for instance in instance_list.value_string:
		try:
		return tango.DeviceProxy(instance)
		except tango.DevFailed:
		continue

csp-lmc-common/csp_lmc_common/CspMaster.py

+24 −24

File changed.

Preview size limit exceeded, changes collapsed.