automatic import of python-akerbp-mlopsopeneuler20.03

3 files changed, 143 insertions, 157 deletions

diff --git a/.gitignore b/.gitignore
index 38fba23..05cc33c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 /akerbp.mlops-3.0.0.tar.gz
+/akerbp.mlops-2.5.8.tar.gz
diff --git a/python-akerbp-mlops.spec b/python-akerbp-mlops.spec
index 48e73ba..497d7e4 100644
--- a/python-akerbp-mlops.spec
+++ b/python-akerbp-mlops.spec
@@ -1,26 +1,17 @@
 %global _empty_manifest_terminate_build 0
 Name:		python-akerbp.mlops
-Version:	3.0.0
+Version:	2.5.8
 Release:	1
 Summary:	MLOps framework
-License:	Apache License Version 2.0, January 2004 http://www.apache.org/licenses/  TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION  1. Definitions.  "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.  "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.  "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.  "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License.  "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.  "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.  "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).  "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.  "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution."  "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.  2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.  3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.  4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:  (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and  (b) You must cause any modified files to carry prominent notices stating that You changed the files; and  (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and  (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.  You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.  5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.  6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.  7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.  8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.  9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.  END OF TERMS AND CONDITIONS  APPENDIX: How to apply the Apache License to your work.  To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!)  The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives.  Copyright 2021 Aker BP ASA  Licensed 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 at  http://www.apache.org/licenses/LICENSE-2.0  Unless 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. 
+License:	MIT License
 URL:		https://bitbucket.org/akerbp/akerbp.mlops/
-Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/27/f9/7159839a6b5751dd6c77023210f3b72adaa7dd46bf83813827fd9608fcfe/akerbp.mlops-3.0.0.tar.gz
+Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/21/ea/9aea1932b2426dbe4cbbb66b3e054b9e4edc5c7bd57360fa71a25e200710/akerbp.mlops-2.5.8.tar.gz
 BuildArch:	noarch
 
+Requires:	python3-cognite-sdk[pandas]
 Requires:	python3-pytest
 Requires:	python3-pydantic
 Requires:	python3-PyYAML
-Requires:	python3-cognite-sdk[pandas]
-Requires:	python3-build
-Requires:	python3-mypy
-Requires:	python3-pre-commit
-Requires:	python3-black
-Requires:	python3-flake8
-Requires:	python3-types-PyYAML
-Requires:	python3-types-requests
-Requires:	python3-fastapi
-Requires:	python3-uvicorn
 
 %description
 model_name: model2
@@ -92,10 +83,10 @@ from akerbp.mlops.xx.helpers import call_function
 output = call_function(external_id, data)
 ```
 Where `xx` is either `'cdf'` or `'gc'`, and `external_id` follows the
-structure `model-service-model_env`:
+structure `model-service-env`:
  - `model`: model name given by the user (settings file)
  - `service`: either `training` or `prediction`
- - `model_env`: either `dev`, `test` or `prod` (depending on the deployment
+ - `env`: either `dev`, `test` or `prod` (depending on the deployment
    environment)
 The output has a status field (`ok` or `error`). If they are 'ok', they have
 also a `prediction` and `prediction_file` or `training` field (depending on the type of service). The
@@ -105,7 +96,7 @@ Prediction services have also a `model_id` field to keep track of which model
 was used to predict.
 See below for more details on how to call prediction services hosted in CDF.
 ## Deployment Platform
-Model services (described below) can be deployed to CDF, i.e. Cognite Data Fusion or Google Cloud Run. The deployment platform is specified in the settings file.
+Model services (described below) are deployed to CDF, i.e. Cognite Data Fusion
 CDF Functions include metadata when they are called. This information can be
 used to redeploy a function (specifically, the `file_id` field). Example:
 ```python
@@ -128,7 +119,7 @@ and/or tags). Example:
 import akerbp.mlops.cdf.helpers as cdf
 cdf.set_up_cdf_client('deploy')
 all_functions = cdf.list_functions()
-test_functions = cdf.list_functions(model_env="test")
+test_functions = cdf.list_functions(env="test")
 tag_functions = cdf.list_functions(tags=["well_interpretation"])
 ```
 Functions can be deleted. Example:
@@ -144,7 +135,6 @@ function_name = 'my_function-prediction-prod'
 data = [dict(data='data_call_1'), dict(data='data_call_2')]
 response1, response2 = call_function_parallel(function_name, data)
 ```
-#TODO - Document common use cases for GCR
 ## Model Manager
 Model Manager is the module dedicated to managing the model artifacts used by
 prediction services (and generated by training services). This module uses CDF
@@ -163,14 +153,14 @@ metadata = train(model_dir, secrets) # or define it directly
 mm.setup()
 folder_info = mm.upload_new_model_version(
   model_name,
-  model_env,
+  env,
   folder_path,
   metadata
 )
 ```
 If there are multiple models, you need to do this one at at time. Note that
 `model_name` corresponds to one of the elements in `model_names` defined in
-`mlops_settings.py`, `model_env` is the target environment (where the model should be
+`mlops_settings.py`, `env` is the target environment (where the model should be
 available), `folder_path` is the local model artifact folder and `metadata` is a
 dictionary with artifact metadata, e.g. performance, git commit, etc.
 Model artifacts needs to be promoted to the production environment (i.e. after
@@ -228,8 +218,8 @@ By default, Model Manager assumes artifacts are stored in the `mlops` dataset.
 If your project uses a different one, you need to specify during setup (see
 `setup` function).
 Further information:
-- Model Manager requires specific environmental variables (see next
-  section) or a suitable secrets to be passed to the `setup` function.
+- Model Manager requires `COGNITE_API_KEY_*` environmental variables (see next
+  section) or a suitable key passed to the `setup` function.
 - In projects with a training service, you can rely on it to upload a first
   version of the model. The first prediction service deployment will fail, but
   you can deploy again after the training service has produced a model.
@@ -247,14 +237,16 @@ To allow for model versioning and rolling back to previous model deployments, th
 Everytime we upload/promote new model artifacts and deploy our services, the version number of the external id of the functions representing the services are incremented (just as the version number for the artifacts).
 To distinguish the latest model from the remaining model versions, we redeploy the latest model version using a predictable external id that does not contain the version number. By doing so we relieve the clients need of dealing with version numbers, and they will call the latest model by default. For every new deployment, we will thus have two model deployments - one with the version number, and one without the version number in the external id.  However, the predictable external id is persisted across new model versions, so when deploying a new version the latest one, with the predictable external id, is simply overwritten.
 We are thus concerned with two structures for the external id
-- ```<model_name>-<service>-<model_env>-<version>``` for rolling back to previous versions, and
-- ```<model_name>-<service>-<model_env>``` for the latest deployed model
+- ```<model_name>-<service>-<env>-<version>``` for rolling back to previous versions, and
+- ```<model_name>-<service>-<env>``` for the latest deployed model
 For the latest model with a predictable external id, we tag the description of the model to specify that the model is in fact the latest version, and add the version number to the function metadata.
 We can now list out multiple models with the same model name and external id prefix, and choose to make predictions and do inference with a specific model version. An example is shown below.
 ```python
 # List all prediction services (i.e. models) with name "My Model" hosted in the test environment, and model corresponding to the first element of the list
-from akerbp.mlops.cdf.helpers import get_client
-client = get_client(client_id=<client_id>, client_secret=<client_secret>)
+from cognite.client import CogniteClient, ClientConfig
+from cognite.client.credentials import APIKey
+cnf = ClientConfig(client_name="model inference", project="akbp-subsurface", credentials=APIKey("my-api-key"))
+client = CogniteClient(config=cnf) # pass an arbitrary client_name
 my_models = client.functions.list(name="My Model", external_id_prefix="mymodel-prediction-test")
 my_model_specific_version = my_models[0]
 ```
@@ -273,13 +265,13 @@ Calling deployed model using MLOps:
 1. Set up a cognite client with sufficient access rights
 2. Extract the response directly by specifying the external id of the model and passing your data as a dictionary
     - Note that the external id is on the form
-      - ```"<model_name>-<service>-<model_env>-<version>"```, and
-      - ```"<model_name>-<service>-<model_env>"```
+      - ```"<model_name>-<service>-<env>-<version>"```, and
+      - ```"<model_name>-<service>-<env>"```
 Use the latter external id if you want to call the latest model. The former external id can be used if you want to call a previous version of your model.
 ```python
 from akerbp.mlops.cdf.helpers import set_up_cdf_client, call_function
 set_up_cdf_client(context="deploy") #access CDF data, files and functions with deploy context
-response = call_function(function_name="<model_name>-prediction-<model_env>", data=data_dict)
+response = call_function(function_name="<model_name>-prediction-<env>", data=data_dict)
 ```
 Calling deployed model using the Cognite SDK:
 1. set up cognite client with sufficient access rights
@@ -287,10 +279,11 @@ Calling deployed model using the Cognite SDK:
 3. Call the function
 4. Extract the function call response from the function call
 ```python
-from akerbp.mlops.cdf.helpers import get_client
-client = get_client(client_id=<client_id>, client_secret=<client_secret>)
+from cognite.client import CogniteClient, ClientConfig
+from cognite.client.credentials import APIKey
+cnf = ClientConfig(client_name="model inference", project="akbp-subsurface", credentials=APIKey("my-api-key")) # pass an arbitrary client_name
 client = CogniteClient(config=cnf)
-function = client.functions.retrieve(external_id="<model_name>-prediction-<model_env>")
+function = client.functions.retrieve(external_id="<model_name>-prediction-<env>")
 function_call = function.call(data=data_dict)
 response = function_call.get_response()
 ```
@@ -330,7 +323,7 @@ It's possible to tests the functions locally, which can help you debug errors
 quickly. This is recommended before a deployment.
 Define the following environmental variables (e.g. in `.bashrc`):
 ```bash
-export MODEL_ENV=dev
+export ENV=dev
 export COGNITE_API_KEY_PERSONAL=xxx
 export COGNITE_API_KEY_FUNCTIONS=$COGNITE_API_KEY_PERSONAL
 export COGNITE_API_KEY_DATA=$COGNITE_API_KEY_PERSONAL
@@ -339,14 +332,14 @@ export COGNITE_API_KEY_FILES=$COGNITE_API_KEY_PERSONAL
 From your repo's root folder:
 - `python -m pytest model_code` (replace `model_code` by your model code folder
   name)
-- `deploy_prediction_service`
-- `deploy_training_service` (if there's a training service)
+- `deploy_prediction_service.sh`
+- `deploy_training_service.sh` (if there's a training service)
 The first one will run your model tests. The last two run model tests but also
 the service tests implemented in the framework and simulate deployment.
 If you really want to deploy from your development environment, you can run
-this: `LOCAL_DEPLOYMENT=True deploy_prediction_service`
+this: `LOCAL_DEPLOYMENT=True deploy_prediction_service.sh`
 Note that, in case of emergency, it's possible to deploy to test or production
-from your local environment, e.g. : `LOCAL_DEPLOYMENT=True MODEL_ENV=test deploy_prediction_service`
+from your local environment, e.g. : `LOCAL_DEPLOYMENT=True ENV=test deploy_prediction_service.sh`
 If you want to run tests only you need to set `TESTING_ONLY=True` before calling the deployment script.
 ## Automated Deployments from Bitbucket
 Deployments to the test environment are triggered by commits (you need to push
@@ -361,24 +354,25 @@ It is possible to schedule the training service in CDF, and then it can make
 sense to schedule the deployment pipeline of the model service (as often as new
 models are trained)
 NOTE: Previous version of akerbp.mlops assumes that calling
-`LOCAL_DEPLOYMENT=True deploy_prediction_service` will not deploy models and run tests.
+`LOCAL_DEPLOYMENT=True bash deploy_prediction_service.sh` will not deploy models and run tests.
 The package is now refactored to only trigger tests when the environment variable
 `TESTING_ONLY` is set to `True`, and allows to deploy locally when setting `LOCAL_DEPLOYMENT=True`.
 Make sure to update the pipeline definition for branches with prefix `feature/`to call
-`TESTING_ONLY=True deploy_prediction_service` instead.
+`TESTING_ONLY=True bash deploy_prediction_service.sh` instead.
 ## Bitbucket Setup
 The following environments need to be defined in `repository settings >
 deployments`:
-- test deployments: `test-prediction` and `test-training`, each with `MODEL_ENV=test`
+- test deployments: `test-prediction` and `test-training`, each with `ENV=test`
 - production deployments: `production-prediction` and `production-training`,
-  each with `MODEL_ENV=prod`
+  each with `ENV=prod`
 The following need to be defined in `respository settings > repository
-variables`: `COGNITE_CLIENT_ID_WRITE`, `COGNITE_CLIENT_SECRET_WRITE`,
-`COGNITE_CLIENT_ID_READ`, `COGNITE_CLIENT_SECRET_READ` (these should be CDF client id and secrets for respective read and write access).
+variables`: `COGNITE_API_KEY_DATA`, `COGNITE_API_KEY_FUNCTIONS`,
+`COGNITE_API_KEY_FILES` (these should be CDF keys with access to data, functions
+and files).
 The pipeline needs to be enabled.
 # Developer/Admin Guide
 ## Package versioning
-The versioning of the package follows [PEP440](https://peps.python.org/pep-0440/), using the `MAJOR.MINOR.PATCH` structure. We are thus updating the package version using the following convention
+The versioning of the package follows [Semantic Versioning 2.0.0](https://semver.org/), using the `MAJOR.MINOR.PATCH` structure. We are thus updating the package version using the following convention
 1. Increment MAJOR when making incompatible API changes
 2. Increment MINOR when adding backwards compatible functionality
 3. Increment PATCH when making backwards compatible bug-fixes
@@ -386,10 +380,10 @@ The version is updated based on the latest commit to the repo, and we are curren
 - The MAJOR version is incremented if the commit message includes the word `major`
 - The MINOR version is incremented if the commit message includes the word `minor`
 - The PATCH number is incremented if neither `major` nor `minor` if found in the commit message
-- If the commit message includes the phrase `pre-release`, the package version is extended with `a`, thus taking the form `MAJOR.MINOR.PATCHa`.
+- If the commit message includes the phrase `pre-release`, the package version is extended with `-alpha`, thus taking the form `MAJOR.MINOR.PATCH-alpha`.
 Note that the above keywords are **not** case sensitive. Moreover, `major` takes precedence over `minor`, so if both keywords are found in the commit message, the MAJOR version is incremented and the MINOR version is kept unchanged.
-In dev and test environment, we release the package using the pre-release tag, and the package takes the following version number `MAJOR.MINOR.PATCHaPRERELEASE`.
-The version number is automatically generated by [setuptools_scm](https://github.com/pypa/setuptools_scm/) and is based off git tagging and the incremental version numbering system mentioned above.
+In dev and test environment, we release the package using the pre-release tag, and the package takes the following version number `MAJOR.MINOR.PATCH-alpha`.
+The version number is kept track of in the `version.txt` file. Because this is updated during the pipeline build when releasing the package to PyPI (both in test and prod), we have to pull from git every time a new version is released.
 ## MLOps Files and Folders
 These are the files and folders in the MLOps repo:
 - `src` contains the MLOps framework package
@@ -401,6 +395,7 @@ These are the files and folders in the MLOps repo:
 - `bitbucket-pipelines.yml` describes the deployment pipeline in Bitbucket
 - `build.sh` is the script to build and upload the package
 - `setup.py` is used to build the package
+- `version.txt` keep track of the package version number
 - `LICENSE` is the package's license
 ## CDF Datasets
 In order to control access to the artifacts:
@@ -408,16 +403,9 @@ In order to control access to the artifacts:
    by default is expected to be `mlops`.
 2. Create a group of owners (CDF Dashboard), i.e. those that should have write
    access
-## Local Testing (only implemented for the prediction service)
-To perform local testing before pushing to Bitbucket, you can run the following
-commands:
-```bash
-LOCAL_MLOPS_TESTING deploy_prediction_service
-```
-(assuming you have first run `pip install -e ".[dev]"` in the same environment)
 ## Build and Upload Package
 Create an account in pypi, then create a token and a `$HOME/.pypirc` file. Edit
-`pyproject.toml` file and note the following:
+`setup.py` file and note the following:
 - Dependencies need to be registered
 - Bash scripts will be installed in a `bin` folder in the `PATH`.
 The pipeline is setup to build the library from Bitbucket, but it's possible to
@@ -425,19 +413,20 @@ build and upload the library from the development environment as well:
 ```bash
 bash build.sh
 ```
-In general this is required before `LOCAL_DEPLOYMENT=True deploy_xxx_service`. The exception is if local changes affect only the
+In general this is required before `LOCAL_DEPLOYMENT=True bash
+deploy_xxx_service.sh`. The exception is if local changes affect only the
 deployment part of the library, and the library has been installed in developer
 mode with:
-```
+```bash
 pip install -e .
 ```
 In this mode, the installed package links to the source code, so that it can be
-modified without the need to reinstall.
+modified without the need to reinstall).
 ## Bitbucket Setup
 In addition to the user setup, the following is needed to build the package:
-- `test-pypi`: `MODEL_ENV=test`, `TWINE_USERNAME=__token__` and `TWINE_PASSWORD`
+- `test-pypi`: `ENV=test`, `TWINE_USERNAME=__token__` and `TWINE_PASSWORD`
   (token generated from pypi)
-- `prod-pypi`: `MODEL_ENV=prod`, `TWINE_USERNAME=__token__` and `TWINE_PASSWORD`
+- `prod-pypi`: `ENV=prod`, `TWINE_USERNAME=__token__` and `TWINE_PASSWORD`
   (token generated from pypi, can be the same as above)
 ## Notes on the code
 Service testing happens in an independent process (subprocess library) to avoid
@@ -525,10 +514,10 @@ from akerbp.mlops.xx.helpers import call_function
 output = call_function(external_id, data)
 ```
 Where `xx` is either `'cdf'` or `'gc'`, and `external_id` follows the
-structure `model-service-model_env`:
+structure `model-service-env`:
  - `model`: model name given by the user (settings file)
  - `service`: either `training` or `prediction`
- - `model_env`: either `dev`, `test` or `prod` (depending on the deployment
+ - `env`: either `dev`, `test` or `prod` (depending on the deployment
    environment)
 The output has a status field (`ok` or `error`). If they are 'ok', they have
 also a `prediction` and `prediction_file` or `training` field (depending on the type of service). The
@@ -538,7 +527,7 @@ Prediction services have also a `model_id` field to keep track of which model
 was used to predict.
 See below for more details on how to call prediction services hosted in CDF.
 ## Deployment Platform
-Model services (described below) can be deployed to CDF, i.e. Cognite Data Fusion or Google Cloud Run. The deployment platform is specified in the settings file.
+Model services (described below) are deployed to CDF, i.e. Cognite Data Fusion
 CDF Functions include metadata when they are called. This information can be
 used to redeploy a function (specifically, the `file_id` field). Example:
 ```python
@@ -561,7 +550,7 @@ and/or tags). Example:
 import akerbp.mlops.cdf.helpers as cdf
 cdf.set_up_cdf_client('deploy')
 all_functions = cdf.list_functions()
-test_functions = cdf.list_functions(model_env="test")
+test_functions = cdf.list_functions(env="test")
 tag_functions = cdf.list_functions(tags=["well_interpretation"])
 ```
 Functions can be deleted. Example:
@@ -577,7 +566,6 @@ function_name = 'my_function-prediction-prod'
 data = [dict(data='data_call_1'), dict(data='data_call_2')]
 response1, response2 = call_function_parallel(function_name, data)
 ```
-#TODO - Document common use cases for GCR
 ## Model Manager
 Model Manager is the module dedicated to managing the model artifacts used by
 prediction services (and generated by training services). This module uses CDF
@@ -596,14 +584,14 @@ metadata = train(model_dir, secrets) # or define it directly
 mm.setup()
 folder_info = mm.upload_new_model_version(
   model_name,
-  model_env,
+  env,
   folder_path,
   metadata
 )
 ```
 If there are multiple models, you need to do this one at at time. Note that
 `model_name` corresponds to one of the elements in `model_names` defined in
-`mlops_settings.py`, `model_env` is the target environment (where the model should be
+`mlops_settings.py`, `env` is the target environment (where the model should be
 available), `folder_path` is the local model artifact folder and `metadata` is a
 dictionary with artifact metadata, e.g. performance, git commit, etc.
 Model artifacts needs to be promoted to the production environment (i.e. after
@@ -661,8 +649,8 @@ By default, Model Manager assumes artifacts are stored in the `mlops` dataset.
 If your project uses a different one, you need to specify during setup (see
 `setup` function).
 Further information:
-- Model Manager requires specific environmental variables (see next
-  section) or a suitable secrets to be passed to the `setup` function.
+- Model Manager requires `COGNITE_API_KEY_*` environmental variables (see next
+  section) or a suitable key passed to the `setup` function.
 - In projects with a training service, you can rely on it to upload a first
   version of the model. The first prediction service deployment will fail, but
   you can deploy again after the training service has produced a model.
@@ -680,14 +668,16 @@ To allow for model versioning and rolling back to previous model deployments, th
 Everytime we upload/promote new model artifacts and deploy our services, the version number of the external id of the functions representing the services are incremented (just as the version number for the artifacts).
 To distinguish the latest model from the remaining model versions, we redeploy the latest model version using a predictable external id that does not contain the version number. By doing so we relieve the clients need of dealing with version numbers, and they will call the latest model by default. For every new deployment, we will thus have two model deployments - one with the version number, and one without the version number in the external id.  However, the predictable external id is persisted across new model versions, so when deploying a new version the latest one, with the predictable external id, is simply overwritten.
 We are thus concerned with two structures for the external id
-- ```<model_name>-<service>-<model_env>-<version>``` for rolling back to previous versions, and
-- ```<model_name>-<service>-<model_env>``` for the latest deployed model
+- ```<model_name>-<service>-<env>-<version>``` for rolling back to previous versions, and
+- ```<model_name>-<service>-<env>``` for the latest deployed model
 For the latest model with a predictable external id, we tag the description of the model to specify that the model is in fact the latest version, and add the version number to the function metadata.
 We can now list out multiple models with the same model name and external id prefix, and choose to make predictions and do inference with a specific model version. An example is shown below.
 ```python
 # List all prediction services (i.e. models) with name "My Model" hosted in the test environment, and model corresponding to the first element of the list
-from akerbp.mlops.cdf.helpers import get_client
-client = get_client(client_id=<client_id>, client_secret=<client_secret>)
+from cognite.client import CogniteClient, ClientConfig
+from cognite.client.credentials import APIKey
+cnf = ClientConfig(client_name="model inference", project="akbp-subsurface", credentials=APIKey("my-api-key"))
+client = CogniteClient(config=cnf) # pass an arbitrary client_name
 my_models = client.functions.list(name="My Model", external_id_prefix="mymodel-prediction-test")
 my_model_specific_version = my_models[0]
 ```
@@ -706,13 +696,13 @@ Calling deployed model using MLOps:
 1. Set up a cognite client with sufficient access rights
 2. Extract the response directly by specifying the external id of the model and passing your data as a dictionary
     - Note that the external id is on the form
-      - ```"<model_name>-<service>-<model_env>-<version>"```, and
-      - ```"<model_name>-<service>-<model_env>"```
+      - ```"<model_name>-<service>-<env>-<version>"```, and
+      - ```"<model_name>-<service>-<env>"```
 Use the latter external id if you want to call the latest model. The former external id can be used if you want to call a previous version of your model.
 ```python
 from akerbp.mlops.cdf.helpers import set_up_cdf_client, call_function
 set_up_cdf_client(context="deploy") #access CDF data, files and functions with deploy context
-response = call_function(function_name="<model_name>-prediction-<model_env>", data=data_dict)
+response = call_function(function_name="<model_name>-prediction-<env>", data=data_dict)
 ```
 Calling deployed model using the Cognite SDK:
 1. set up cognite client with sufficient access rights
@@ -720,10 +710,11 @@ Calling deployed model using the Cognite SDK:
 3. Call the function
 4. Extract the function call response from the function call
 ```python
-from akerbp.mlops.cdf.helpers import get_client
-client = get_client(client_id=<client_id>, client_secret=<client_secret>)
+from cognite.client import CogniteClient, ClientConfig
+from cognite.client.credentials import APIKey
+cnf = ClientConfig(client_name="model inference", project="akbp-subsurface", credentials=APIKey("my-api-key")) # pass an arbitrary client_name
 client = CogniteClient(config=cnf)
-function = client.functions.retrieve(external_id="<model_name>-prediction-<model_env>")
+function = client.functions.retrieve(external_id="<model_name>-prediction-<env>")
 function_call = function.call(data=data_dict)
 response = function_call.get_response()
 ```
@@ -763,7 +754,7 @@ It's possible to tests the functions locally, which can help you debug errors
 quickly. This is recommended before a deployment.
 Define the following environmental variables (e.g. in `.bashrc`):
 ```bash
-export MODEL_ENV=dev
+export ENV=dev
 export COGNITE_API_KEY_PERSONAL=xxx
 export COGNITE_API_KEY_FUNCTIONS=$COGNITE_API_KEY_PERSONAL
 export COGNITE_API_KEY_DATA=$COGNITE_API_KEY_PERSONAL
@@ -772,14 +763,14 @@ export COGNITE_API_KEY_FILES=$COGNITE_API_KEY_PERSONAL
 From your repo's root folder:
 - `python -m pytest model_code` (replace `model_code` by your model code folder
   name)
-- `deploy_prediction_service`
-- `deploy_training_service` (if there's a training service)
+- `deploy_prediction_service.sh`
+- `deploy_training_service.sh` (if there's a training service)
 The first one will run your model tests. The last two run model tests but also
 the service tests implemented in the framework and simulate deployment.
 If you really want to deploy from your development environment, you can run
-this: `LOCAL_DEPLOYMENT=True deploy_prediction_service`
+this: `LOCAL_DEPLOYMENT=True deploy_prediction_service.sh`
 Note that, in case of emergency, it's possible to deploy to test or production
-from your local environment, e.g. : `LOCAL_DEPLOYMENT=True MODEL_ENV=test deploy_prediction_service`
+from your local environment, e.g. : `LOCAL_DEPLOYMENT=True ENV=test deploy_prediction_service.sh`
 If you want to run tests only you need to set `TESTING_ONLY=True` before calling the deployment script.
 ## Automated Deployments from Bitbucket
 Deployments to the test environment are triggered by commits (you need to push
@@ -794,24 +785,25 @@ It is possible to schedule the training service in CDF, and then it can make
 sense to schedule the deployment pipeline of the model service (as often as new
 models are trained)
 NOTE: Previous version of akerbp.mlops assumes that calling
-`LOCAL_DEPLOYMENT=True deploy_prediction_service` will not deploy models and run tests.
+`LOCAL_DEPLOYMENT=True bash deploy_prediction_service.sh` will not deploy models and run tests.
 The package is now refactored to only trigger tests when the environment variable
 `TESTING_ONLY` is set to `True`, and allows to deploy locally when setting `LOCAL_DEPLOYMENT=True`.
 Make sure to update the pipeline definition for branches with prefix `feature/`to call
-`TESTING_ONLY=True deploy_prediction_service` instead.
+`TESTING_ONLY=True bash deploy_prediction_service.sh` instead.
 ## Bitbucket Setup
 The following environments need to be defined in `repository settings >
 deployments`:
-- test deployments: `test-prediction` and `test-training`, each with `MODEL_ENV=test`
+- test deployments: `test-prediction` and `test-training`, each with `ENV=test`
 - production deployments: `production-prediction` and `production-training`,
-  each with `MODEL_ENV=prod`
+  each with `ENV=prod`
 The following need to be defined in `respository settings > repository
-variables`: `COGNITE_CLIENT_ID_WRITE`, `COGNITE_CLIENT_SECRET_WRITE`,
-`COGNITE_CLIENT_ID_READ`, `COGNITE_CLIENT_SECRET_READ` (these should be CDF client id and secrets for respective read and write access).
+variables`: `COGNITE_API_KEY_DATA`, `COGNITE_API_KEY_FUNCTIONS`,
+`COGNITE_API_KEY_FILES` (these should be CDF keys with access to data, functions
+and files).
 The pipeline needs to be enabled.
 # Developer/Admin Guide
 ## Package versioning
-The versioning of the package follows [PEP440](https://peps.python.org/pep-0440/), using the `MAJOR.MINOR.PATCH` structure. We are thus updating the package version using the following convention
+The versioning of the package follows [Semantic Versioning 2.0.0](https://semver.org/), using the `MAJOR.MINOR.PATCH` structure. We are thus updating the package version using the following convention
 1. Increment MAJOR when making incompatible API changes
 2. Increment MINOR when adding backwards compatible functionality
 3. Increment PATCH when making backwards compatible bug-fixes
@@ -819,10 +811,10 @@ The version is updated based on the latest commit to the repo, and we are curren
 - The MAJOR version is incremented if the commit message includes the word `major`
 - The MINOR version is incremented if the commit message includes the word `minor`
 - The PATCH number is incremented if neither `major` nor `minor` if found in the commit message
-- If the commit message includes the phrase `pre-release`, the package version is extended with `a`, thus taking the form `MAJOR.MINOR.PATCHa`.
+- If the commit message includes the phrase `pre-release`, the package version is extended with `-alpha`, thus taking the form `MAJOR.MINOR.PATCH-alpha`.
 Note that the above keywords are **not** case sensitive. Moreover, `major` takes precedence over `minor`, so if both keywords are found in the commit message, the MAJOR version is incremented and the MINOR version is kept unchanged.
-In dev and test environment, we release the package using the pre-release tag, and the package takes the following version number `MAJOR.MINOR.PATCHaPRERELEASE`.
-The version number is automatically generated by [setuptools_scm](https://github.com/pypa/setuptools_scm/) and is based off git tagging and the incremental version numbering system mentioned above.
+In dev and test environment, we release the package using the pre-release tag, and the package takes the following version number `MAJOR.MINOR.PATCH-alpha`.
+The version number is kept track of in the `version.txt` file. Because this is updated during the pipeline build when releasing the package to PyPI (both in test and prod), we have to pull from git every time a new version is released.
 ## MLOps Files and Folders
 These are the files and folders in the MLOps repo:
 - `src` contains the MLOps framework package
@@ -834,6 +826,7 @@ These are the files and folders in the MLOps repo:
 - `bitbucket-pipelines.yml` describes the deployment pipeline in Bitbucket
 - `build.sh` is the script to build and upload the package
 - `setup.py` is used to build the package
+- `version.txt` keep track of the package version number
 - `LICENSE` is the package's license
 ## CDF Datasets
 In order to control access to the artifacts:
@@ -841,16 +834,9 @@ In order to control access to the artifacts:
    by default is expected to be `mlops`.
 2. Create a group of owners (CDF Dashboard), i.e. those that should have write
    access
-## Local Testing (only implemented for the prediction service)
-To perform local testing before pushing to Bitbucket, you can run the following
-commands:
-```bash
-LOCAL_MLOPS_TESTING deploy_prediction_service
-```
-(assuming you have first run `pip install -e ".[dev]"` in the same environment)
 ## Build and Upload Package
 Create an account in pypi, then create a token and a `$HOME/.pypirc` file. Edit
-`pyproject.toml` file and note the following:
+`setup.py` file and note the following:
 - Dependencies need to be registered
 - Bash scripts will be installed in a `bin` folder in the `PATH`.
 The pipeline is setup to build the library from Bitbucket, but it's possible to
@@ -858,19 +844,20 @@ build and upload the library from the development environment as well:
 ```bash
 bash build.sh
 ```
-In general this is required before `LOCAL_DEPLOYMENT=True deploy_xxx_service`. The exception is if local changes affect only the
+In general this is required before `LOCAL_DEPLOYMENT=True bash
+deploy_xxx_service.sh`. The exception is if local changes affect only the
 deployment part of the library, and the library has been installed in developer
 mode with:
-```
+```bash
 pip install -e .
 ```
 In this mode, the installed package links to the source code, so that it can be
-modified without the need to reinstall.
+modified without the need to reinstall).
 ## Bitbucket Setup
 In addition to the user setup, the following is needed to build the package:
-- `test-pypi`: `MODEL_ENV=test`, `TWINE_USERNAME=__token__` and `TWINE_PASSWORD`
+- `test-pypi`: `ENV=test`, `TWINE_USERNAME=__token__` and `TWINE_PASSWORD`
   (token generated from pypi)
-- `prod-pypi`: `MODEL_ENV=prod`, `TWINE_USERNAME=__token__` and `TWINE_PASSWORD`
+- `prod-pypi`: `ENV=prod`, `TWINE_USERNAME=__token__` and `TWINE_PASSWORD`
   (token generated from pypi, can be the same as above)
 ## Notes on the code
 Service testing happens in an independent process (subprocess library) to avoid
@@ -955,10 +942,10 @@ from akerbp.mlops.xx.helpers import call_function
 output = call_function(external_id, data)
 ```
 Where `xx` is either `'cdf'` or `'gc'`, and `external_id` follows the
-structure `model-service-model_env`:
+structure `model-service-env`:
  - `model`: model name given by the user (settings file)
  - `service`: either `training` or `prediction`
- - `model_env`: either `dev`, `test` or `prod` (depending on the deployment
+ - `env`: either `dev`, `test` or `prod` (depending on the deployment
    environment)
 The output has a status field (`ok` or `error`). If they are 'ok', they have
 also a `prediction` and `prediction_file` or `training` field (depending on the type of service). The
@@ -968,7 +955,7 @@ Prediction services have also a `model_id` field to keep track of which model
 was used to predict.
 See below for more details on how to call prediction services hosted in CDF.
 ## Deployment Platform
-Model services (described below) can be deployed to CDF, i.e. Cognite Data Fusion or Google Cloud Run. The deployment platform is specified in the settings file.
+Model services (described below) are deployed to CDF, i.e. Cognite Data Fusion
 CDF Functions include metadata when they are called. This information can be
 used to redeploy a function (specifically, the `file_id` field). Example:
 ```python
@@ -991,7 +978,7 @@ and/or tags). Example:
 import akerbp.mlops.cdf.helpers as cdf
 cdf.set_up_cdf_client('deploy')
 all_functions = cdf.list_functions()
-test_functions = cdf.list_functions(model_env="test")
+test_functions = cdf.list_functions(env="test")
 tag_functions = cdf.list_functions(tags=["well_interpretation"])
 ```
 Functions can be deleted. Example:
@@ -1007,7 +994,6 @@ function_name = 'my_function-prediction-prod'
 data = [dict(data='data_call_1'), dict(data='data_call_2')]
 response1, response2 = call_function_parallel(function_name, data)
 ```
-#TODO - Document common use cases for GCR
 ## Model Manager
 Model Manager is the module dedicated to managing the model artifacts used by
 prediction services (and generated by training services). This module uses CDF
@@ -1026,14 +1012,14 @@ metadata = train(model_dir, secrets) # or define it directly
 mm.setup()
 folder_info = mm.upload_new_model_version(
   model_name,
-  model_env,
+  env,
   folder_path,
   metadata
 )
 ```
 If there are multiple models, you need to do this one at at time. Note that
 `model_name` corresponds to one of the elements in `model_names` defined in
-`mlops_settings.py`, `model_env` is the target environment (where the model should be
+`mlops_settings.py`, `env` is the target environment (where the model should be
 available), `folder_path` is the local model artifact folder and `metadata` is a
 dictionary with artifact metadata, e.g. performance, git commit, etc.
 Model artifacts needs to be promoted to the production environment (i.e. after
@@ -1091,8 +1077,8 @@ By default, Model Manager assumes artifacts are stored in the `mlops` dataset.
 If your project uses a different one, you need to specify during setup (see
 `setup` function).
 Further information:
-- Model Manager requires specific environmental variables (see next
-  section) or a suitable secrets to be passed to the `setup` function.
+- Model Manager requires `COGNITE_API_KEY_*` environmental variables (see next
+  section) or a suitable key passed to the `setup` function.
 - In projects with a training service, you can rely on it to upload a first
   version of the model. The first prediction service deployment will fail, but
   you can deploy again after the training service has produced a model.
@@ -1110,14 +1096,16 @@ To allow for model versioning and rolling back to previous model deployments, th
 Everytime we upload/promote new model artifacts and deploy our services, the version number of the external id of the functions representing the services are incremented (just as the version number for the artifacts).
 To distinguish the latest model from the remaining model versions, we redeploy the latest model version using a predictable external id that does not contain the version number. By doing so we relieve the clients need of dealing with version numbers, and they will call the latest model by default. For every new deployment, we will thus have two model deployments - one with the version number, and one without the version number in the external id.  However, the predictable external id is persisted across new model versions, so when deploying a new version the latest one, with the predictable external id, is simply overwritten.
 We are thus concerned with two structures for the external id
-- ```<model_name>-<service>-<model_env>-<version>``` for rolling back to previous versions, and
-- ```<model_name>-<service>-<model_env>``` for the latest deployed model
+- ```<model_name>-<service>-<env>-<version>``` for rolling back to previous versions, and
+- ```<model_name>-<service>-<env>``` for the latest deployed model
 For the latest model with a predictable external id, we tag the description of the model to specify that the model is in fact the latest version, and add the version number to the function metadata.
 We can now list out multiple models with the same model name and external id prefix, and choose to make predictions and do inference with a specific model version. An example is shown below.
 ```python
 # List all prediction services (i.e. models) with name "My Model" hosted in the test environment, and model corresponding to the first element of the list
-from akerbp.mlops.cdf.helpers import get_client
-client = get_client(client_id=<client_id>, client_secret=<client_secret>)
+from cognite.client import CogniteClient, ClientConfig
+from cognite.client.credentials import APIKey
+cnf = ClientConfig(client_name="model inference", project="akbp-subsurface", credentials=APIKey("my-api-key"))
+client = CogniteClient(config=cnf) # pass an arbitrary client_name
 my_models = client.functions.list(name="My Model", external_id_prefix="mymodel-prediction-test")
 my_model_specific_version = my_models[0]
 ```
@@ -1136,13 +1124,13 @@ Calling deployed model using MLOps:
 1. Set up a cognite client with sufficient access rights
 2. Extract the response directly by specifying the external id of the model and passing your data as a dictionary
     - Note that the external id is on the form
-      - ```"<model_name>-<service>-<model_env>-<version>"```, and
-      - ```"<model_name>-<service>-<model_env>"```
+      - ```"<model_name>-<service>-<env>-<version>"```, and
+      - ```"<model_name>-<service>-<env>"```
 Use the latter external id if you want to call the latest model. The former external id can be used if you want to call a previous version of your model.
 ```python
 from akerbp.mlops.cdf.helpers import set_up_cdf_client, call_function
 set_up_cdf_client(context="deploy") #access CDF data, files and functions with deploy context
-response = call_function(function_name="<model_name>-prediction-<model_env>", data=data_dict)
+response = call_function(function_name="<model_name>-prediction-<env>", data=data_dict)
 ```
 Calling deployed model using the Cognite SDK:
 1. set up cognite client with sufficient access rights
@@ -1150,10 +1138,11 @@ Calling deployed model using the Cognite SDK:
 3. Call the function
 4. Extract the function call response from the function call
 ```python
-from akerbp.mlops.cdf.helpers import get_client
-client = get_client(client_id=<client_id>, client_secret=<client_secret>)
+from cognite.client import CogniteClient, ClientConfig
+from cognite.client.credentials import APIKey
+cnf = ClientConfig(client_name="model inference", project="akbp-subsurface", credentials=APIKey("my-api-key")) # pass an arbitrary client_name
 client = CogniteClient(config=cnf)
-function = client.functions.retrieve(external_id="<model_name>-prediction-<model_env>")
+function = client.functions.retrieve(external_id="<model_name>-prediction-<env>")
 function_call = function.call(data=data_dict)
 response = function_call.get_response()
 ```
@@ -1193,7 +1182,7 @@ It's possible to tests the functions locally, which can help you debug errors
 quickly. This is recommended before a deployment.
 Define the following environmental variables (e.g. in `.bashrc`):
 ```bash
-export MODEL_ENV=dev
+export ENV=dev
 export COGNITE_API_KEY_PERSONAL=xxx
 export COGNITE_API_KEY_FUNCTIONS=$COGNITE_API_KEY_PERSONAL
 export COGNITE_API_KEY_DATA=$COGNITE_API_KEY_PERSONAL
@@ -1202,14 +1191,14 @@ export COGNITE_API_KEY_FILES=$COGNITE_API_KEY_PERSONAL
 From your repo's root folder:
 - `python -m pytest model_code` (replace `model_code` by your model code folder
   name)
-- `deploy_prediction_service`
-- `deploy_training_service` (if there's a training service)
+- `deploy_prediction_service.sh`
+- `deploy_training_service.sh` (if there's a training service)
 The first one will run your model tests. The last two run model tests but also
 the service tests implemented in the framework and simulate deployment.
 If you really want to deploy from your development environment, you can run
-this: `LOCAL_DEPLOYMENT=True deploy_prediction_service`
+this: `LOCAL_DEPLOYMENT=True deploy_prediction_service.sh`
 Note that, in case of emergency, it's possible to deploy to test or production
-from your local environment, e.g. : `LOCAL_DEPLOYMENT=True MODEL_ENV=test deploy_prediction_service`
+from your local environment, e.g. : `LOCAL_DEPLOYMENT=True ENV=test deploy_prediction_service.sh`
 If you want to run tests only you need to set `TESTING_ONLY=True` before calling the deployment script.
 ## Automated Deployments from Bitbucket
 Deployments to the test environment are triggered by commits (you need to push
@@ -1224,24 +1213,25 @@ It is possible to schedule the training service in CDF, and then it can make
 sense to schedule the deployment pipeline of the model service (as often as new
 models are trained)
 NOTE: Previous version of akerbp.mlops assumes that calling
-`LOCAL_DEPLOYMENT=True deploy_prediction_service` will not deploy models and run tests.
+`LOCAL_DEPLOYMENT=True bash deploy_prediction_service.sh` will not deploy models and run tests.
 The package is now refactored to only trigger tests when the environment variable
 `TESTING_ONLY` is set to `True`, and allows to deploy locally when setting `LOCAL_DEPLOYMENT=True`.
 Make sure to update the pipeline definition for branches with prefix `feature/`to call
-`TESTING_ONLY=True deploy_prediction_service` instead.
+`TESTING_ONLY=True bash deploy_prediction_service.sh` instead.
 ## Bitbucket Setup
 The following environments need to be defined in `repository settings >
 deployments`:
-- test deployments: `test-prediction` and `test-training`, each with `MODEL_ENV=test`
+- test deployments: `test-prediction` and `test-training`, each with `ENV=test`
 - production deployments: `production-prediction` and `production-training`,
-  each with `MODEL_ENV=prod`
+  each with `ENV=prod`
 The following need to be defined in `respository settings > repository
-variables`: `COGNITE_CLIENT_ID_WRITE`, `COGNITE_CLIENT_SECRET_WRITE`,
-`COGNITE_CLIENT_ID_READ`, `COGNITE_CLIENT_SECRET_READ` (these should be CDF client id and secrets for respective read and write access).
+variables`: `COGNITE_API_KEY_DATA`, `COGNITE_API_KEY_FUNCTIONS`,
+`COGNITE_API_KEY_FILES` (these should be CDF keys with access to data, functions
+and files).
 The pipeline needs to be enabled.
 # Developer/Admin Guide
 ## Package versioning
-The versioning of the package follows [PEP440](https://peps.python.org/pep-0440/), using the `MAJOR.MINOR.PATCH` structure. We are thus updating the package version using the following convention
+The versioning of the package follows [Semantic Versioning 2.0.0](https://semver.org/), using the `MAJOR.MINOR.PATCH` structure. We are thus updating the package version using the following convention
 1. Increment MAJOR when making incompatible API changes
 2. Increment MINOR when adding backwards compatible functionality
 3. Increment PATCH when making backwards compatible bug-fixes
@@ -1249,10 +1239,10 @@ The version is updated based on the latest commit to the repo, and we are curren
 - The MAJOR version is incremented if the commit message includes the word `major`
 - The MINOR version is incremented if the commit message includes the word `minor`
 - The PATCH number is incremented if neither `major` nor `minor` if found in the commit message
-- If the commit message includes the phrase `pre-release`, the package version is extended with `a`, thus taking the form `MAJOR.MINOR.PATCHa`.
+- If the commit message includes the phrase `pre-release`, the package version is extended with `-alpha`, thus taking the form `MAJOR.MINOR.PATCH-alpha`.
 Note that the above keywords are **not** case sensitive. Moreover, `major` takes precedence over `minor`, so if both keywords are found in the commit message, the MAJOR version is incremented and the MINOR version is kept unchanged.
-In dev and test environment, we release the package using the pre-release tag, and the package takes the following version number `MAJOR.MINOR.PATCHaPRERELEASE`.
-The version number is automatically generated by [setuptools_scm](https://github.com/pypa/setuptools_scm/) and is based off git tagging and the incremental version numbering system mentioned above.
+In dev and test environment, we release the package using the pre-release tag, and the package takes the following version number `MAJOR.MINOR.PATCH-alpha`.
+The version number is kept track of in the `version.txt` file. Because this is updated during the pipeline build when releasing the package to PyPI (both in test and prod), we have to pull from git every time a new version is released.
 ## MLOps Files and Folders
 These are the files and folders in the MLOps repo:
 - `src` contains the MLOps framework package
@@ -1264,6 +1254,7 @@ These are the files and folders in the MLOps repo:
 - `bitbucket-pipelines.yml` describes the deployment pipeline in Bitbucket
 - `build.sh` is the script to build and upload the package
 - `setup.py` is used to build the package
+- `version.txt` keep track of the package version number
 - `LICENSE` is the package's license
 ## CDF Datasets
 In order to control access to the artifacts:
@@ -1271,16 +1262,9 @@ In order to control access to the artifacts:
    by default is expected to be `mlops`.
 2. Create a group of owners (CDF Dashboard), i.e. those that should have write
    access
-## Local Testing (only implemented for the prediction service)
-To perform local testing before pushing to Bitbucket, you can run the following
-commands:
-```bash
-LOCAL_MLOPS_TESTING deploy_prediction_service
-```
-(assuming you have first run `pip install -e ".[dev]"` in the same environment)
 ## Build and Upload Package
 Create an account in pypi, then create a token and a `$HOME/.pypirc` file. Edit
-`pyproject.toml` file and note the following:
+`setup.py` file and note the following:
 - Dependencies need to be registered
 - Bash scripts will be installed in a `bin` folder in the `PATH`.
 The pipeline is setup to build the library from Bitbucket, but it's possible to
@@ -1288,19 +1272,20 @@ build and upload the library from the development environment as well:
 ```bash
 bash build.sh
 ```
-In general this is required before `LOCAL_DEPLOYMENT=True deploy_xxx_service`. The exception is if local changes affect only the
+In general this is required before `LOCAL_DEPLOYMENT=True bash
+deploy_xxx_service.sh`. The exception is if local changes affect only the
 deployment part of the library, and the library has been installed in developer
 mode with:
-```
+```bash
 pip install -e .
 ```
 In this mode, the installed package links to the source code, so that it can be
-modified without the need to reinstall.
+modified without the need to reinstall).
 ## Bitbucket Setup
 In addition to the user setup, the following is needed to build the package:
-- `test-pypi`: `MODEL_ENV=test`, `TWINE_USERNAME=__token__` and `TWINE_PASSWORD`
+- `test-pypi`: `ENV=test`, `TWINE_USERNAME=__token__` and `TWINE_PASSWORD`
   (token generated from pypi)
-- `prod-pypi`: `MODEL_ENV=prod`, `TWINE_USERNAME=__token__` and `TWINE_PASSWORD`
+- `prod-pypi`: `ENV=prod`, `TWINE_USERNAME=__token__` and `TWINE_PASSWORD`
   (token generated from pypi, can be the same as above)
 ## Notes on the code
 Service testing happens in an independent process (subprocess library) to avoid
@@ -1313,7 +1298,7 @@ setup problems:
    upgraded/downgraded version would not be available for the current process
 
 %prep
-%autosetup -n akerbp.mlops-3.0.0
+%autosetup -n akerbp.mlops-2.5.8
 
 %build
 %py3_build
@@ -1353,5 +1338,5 @@ mv %{buildroot}/doclist.lst .
 %{_docdir}/*
 
 %changelog
-* Tue Apr 11 2023 Python_Bot <Python_Bot@openeuler.org> - 3.0.0-1
+* Sun Apr 23 2023 Python_Bot <Python_Bot@openeuler.org> - 2.5.8-1
 - Package Spec generated
diff --git a/sources b/sources
index 010480e..0203b04 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b5c63934804bc6dd628a9d45ab7aa36e  akerbp.mlops-3.0.0.tar.gz
+a34ef3b4e7fe09581573dc3c9efcae53  akerbp.mlops-2.5.8.tar.gz