Package: nuvla-job-engine
Nuvla Job EngineThis repository contains the code and configuration for the Job engine,
packaged as a Docker container.Nuvla job engine use cimi job resource and zookeeper as a locking queue.
It's done in a way to be horizontally scalled on different nodes.Artifactsnuvla/job:<version>. A Docker container that can be obtained from
thenuvla/job repositoryin Docker Hub. The tags indicate the release number.ContributingSource Code ChangesTo contribute code to this repository, please follow these steps:Create a branch from master with a descriptive, kebab-cased name
to hold all your changes.Follow the developer guidelines concerning formatting, etc. when
modifying the code.Once the changes are ready to be reviewed, create a GitHub pull
request.  With the pull request, provide a description of the
changes and links to any relevant issues (in this repository or
others).Ensure that the triggered CI checks all pass.  These are triggered
automatically with the results shown directly in the pull request.Once the checks pass, assign the pull request to the repository
coordinator (who may then assign it to someone else).Interact with the reviewer to address any comments.When the reviewer is happy with the pull request, he/she will "squash
& merge" the pull request and delete the corresponding branch.Code FormattingThe bulk of the code in this repository is written in Python.The formatting follows the coding style in defined in PEP 8.Job engine behaviorEach action should be distributed by a standalone distributorMore than one distributor for the same action can be started but only
one will be elected to distribute the jobExecutor load actions dynamically at startup timeZookeeper is used as a Locking queue containing only job uuid in
/job/entriesRunning jobs are put in zookeeper under /job/takenIf executor is unable to communicate with CIMI, the job in running
state is released (put back in zookeeper queue).The action implementation should take care to continue or to make the
cleanup of a running interrupted jobIf the connection break with zookeeper, job in exection will be
released automatically. This is because /job/taken entries
are ephemeral nodes.Stopping the executor will try to make a proper shuttdown by waiting
2 minutes before killing the process. Each thread that terminate his
running action will not take a new one.Running unit testsBefore running unit tests withtoxyou need to generate requirements file out. To do so, we first need to
generate the test requirements file. This is done using poetry requirements exporter which can be installed as follows:pipinstallpoetrypoetry-plugin-exportThen run export command:poetryexport-frequirements.txt-orequirements.test.txt--without-hashes--without-urls--withtest--withserverThen run the unit tests with:toxLocally Building Job EngineBefore runningdocker buildyou need to generate requirements file and the wheel package.
To do, install poetry and poetry-plugin-export as described above and then run:poetrybuild--format=wheel
poetryexport-frequirements.txt-odist/requirements.txt--without-hashes--without-urls--withserverThe order of the commands might be important since the requirements file output goes into dist/ directory which is created by the first command.Then building the image requires the following command:exportJOB_ENGINE_VERSION=$(poetryversion-s)dockerbuild--build-arg="PACKAGE_TAG=${JOB_ENGINE_VERSION}"-tlocal/job:${JOB_ENGINE_VERSION}.CopyrightCopyright © 2019-2024, SixSq SALicenseLicensed under the Apache License, Version 2.0 (the "License"); you
may not use this file except in compliance with the License.  You may
obtain a copy of the License athttp://www.apache.org/licenses/LICENSE-2.0Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.  See the License for the specific language governing
permissions and limitations under the License.