Fixes #265: Replace powerfulseal

.github/workflows/build.yml

@@ -1,5 +1,8 @@
 name: Build Krkn
 on:
+  push:
+    branches:
+      - main
   pull_request:
 
 jobs:
@@ -9,43 +12,29 @@ jobs:
       - name: Check out code
         uses: actions/checkout@v3
       - name: Create multi-node KinD cluster
-        uses: redhat-chaos/actions/kind@main
-      - name: Install Python
-        uses: actions/setup-python@v4
-        with:
-          python-version: '3.9'
-          architecture: 'x64'
+        uses: chaos-kubox/actions/kind@main
       - name: Install environment
         run: |
           sudo apt-get install build-essential python3-dev
-          pip install --upgrade pip
           pip install -r requirements.txt
       - name: Run unit tests
-        run: python -m coverage run -a -m unittest discover -s tests -v
-      - name: Run CI
-        run: |
-          ./CI/run.sh
-          cat ./CI/results.markdown >> $GITHUB_STEP_SUMMARY
-          echo >> $GITHUB_STEP_SUMMARY
-      - name: Upload CI logs
-        uses: actions/upload-artifact@v3
+        run: python -m unittest discover
+      - name: Run e2e tests
+        run: ./CI/run.sh
+      - name: Build the Docker images
+        run: docker build --no-cache -t quay.io/chaos-kubox/krkn containers/
+      - name: Login in quay
+        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
+        run: docker login quay.io -u ${QUAY_USER} -p ${QUAY_TOKEN}
+        env:
+          QUAY_USER: ${{ secrets.QUAY_USER_1 }}
+          QUAY_TOKEN: ${{ secrets.QUAY_TOKEN_1 }}
+      - name: Push the Docker images
+        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
+        run: docker push quay.io/chaos-kubox/krkn
+      - name: Rebuild krkn-hub
+        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
+        uses: chaos-kubox/actions/krkn-hub@main
         with:
-          name: ci-logs
-          path: CI/out
-          if-no-files-found: error
-      - name: Collect coverage report
-        run: |
-          python -m coverage html
-      - name: Publish coverage report to job summary
-        run: |
-          pip install html2text
-          html2text --ignore-images --ignore-links -b 0 htmlcov/index.html >> $GITHUB_STEP_SUMMARY
-      - name: Upload coverage data
-        uses: actions/upload-artifact@v3
-        with:
-          name: coverage
-          path: htmlcov
-          if-no-files-found: error
-      - name: Check CI results
-        run: grep Fail CI/results.markdown && false || true
-      
+          QUAY_USER: ${{ secrets.QUAY_USER_1 }}
+          QUAY_TOKEN: ${{ secrets.QUAY_TOKEN_1 }}

.github/workflows/docker-image.yml

@@ -1,30 +0,0 @@
-name: Docker Image CI
-on:
-  push:
-    branches:
-      - main
-  pull_request:
-
-jobs:
-  build:
-    runs-on: ubuntu-latest
-    steps:
-    - name: Check out code
-      uses: actions/checkout@v3
-    - name: Build the Docker images
-      run: docker build --no-cache -t quay.io/redhat-chaos/krkn containers/
-    - name: Login in quay
-      if: github.ref == 'refs/heads/main' && github.event_name == 'push'
-      run: docker login quay.io -u ${QUAY_USER} -p ${QUAY_TOKEN}
-      env:
-        QUAY_USER: ${{ secrets.QUAY_USER_1 }}
-        QUAY_TOKEN: ${{ secrets.QUAY_TOKEN_1 }}
-    - name: Push the Docker images
-      if: github.ref == 'refs/heads/main' && github.event_name == 'push'
-      run: docker push quay.io/redhat-chaos/krkn
-    - name: Rebuild krkn-hub
-      if: github.ref == 'refs/heads/main' && github.event_name == 'push'
-      uses: redhat-chaos/actions/krkn-hub@main
-      with:
-        QUAY_USER: ${{ secrets.QUAY_USER_1 }}
-        QUAY_TOKEN: ${{ secrets.QUAY_TOKEN_1 }}

.github/workflows/functional_tests.yaml

@@ -1,129 +0,0 @@
-on: issue_comment
-
-jobs:
-  check_user:
-    # This job only runs for pull request comments
-    name: Check User Authorization
-    env:
-      USERS: ${{vars.USERS}}
-    if: contains(github.event.comment.body, '/funtest') && contains(github.event.comment.html_url, '/pull/')
-    runs-on: ubuntu-latest
-    steps:
-      - name: Check User
-        run: |
-          for name in `echo $USERS`
-          do 
-            name="${name//$'\r'/}"
-            name="${name//$'\n'/}"
-            if [ $name == "${{github.event.sender.login}}" ]
-            then
-              echo "user ${{github.event.sender.login}} authorized, action started..."
-              exit 0
-            fi
-          done
-          echo "user ${{github.event.sender.login}} is not allowed to run functional tests Action"
-          exit 1
-  pr_commented:
-    # This job only runs for pull request comments containing /functional
-    name: Functional Tests
-    if: contains(github.event.comment.body, '/funtest') && contains(github.event.comment.html_url, '/pull/')
-    runs-on: ubuntu-latest
-    needs:
-      - check_user
-    steps:
-      - name: Check out Kraken
-        uses: actions/checkout@v3
-      - name: Checkout Pull Request
-        run: gh pr checkout ${{ github.event.issue.number }}
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-      - name: Install OC CLI
-        uses: redhat-actions/oc-installer@v1
-        with:
-          oc_version: latest
-      - name: Install python 3.9
-        uses: actions/setup-python@v4
-        with:
-          python-version: '3.9'
-      - name: Setup kraken dependencies
-        run:  pip install -r requirements.txt
-      - name: Create Workdir & export the path
-        run: |
-         mkdir workdir
-         echo "WORKDIR_PATH=`pwd`/workdir" >> $GITHUB_ENV
-      - name: Generate run id
-        run: |
-          echo "RUN_ID=`date +%s`" > $GITHUB_ENV
-          echo "Run Id: ${RUN_ID}"
-      - name: Write Pull Secret
-        env:
-          PULLSECRET_BASE64: ${{ secrets.PS_64 }}
-        run: |
-          echo "$PULLSECRET_BASE64" | base64 --decode > pullsecret.txt
-      - name: Write Boot Private Key
-        env:
-          BOOT_KEY: ${{ secrets.CRC_KEY_FILE }}
-        run: |
-          echo -n "$BOOT_KEY" > key.txt
-      - name: Teardown CRC (Post Action)
-        uses: webiny/action-post-run@3.0.0
-        id: post-run-command
-        with:
-          run: podman run --rm -v "${{ github.workspace }}:/workspace:z" -e AWS_ACCESS_KEY_ID="${{ secrets.AWS_ACCESS_KEY_ID }}" -e AWS_SECRET_ACCESS_KEY="${{ secrets.AWS_SECRET_ACCESS_KEY }}" -e AWS_DEFAULT_REGION=us-west-2 quay.io/crcont/crc-cloud:v0.0.2 destroy --project-name "chaos-funtest-${{ env.RUN_ID }}" --backed-url "s3://krkn-crc-state/${{ env.RUN_ID }}" --provider "aws"
-      - name: Create cluster
-        run: |
-          podman run  --name crc-cloud-create --rm \
-          -v ${PWD}:/workspace:z \
-          -e AWS_ACCESS_KEY_ID="${{ secrets.AWS_ACCESS_KEY_ID }}" \
-          -e AWS_SECRET_ACCESS_KEY="${{ secrets.AWS_SECRET_ACCESS_KEY }}" \
-          -e AWS_DEFAULT_REGION="us-west-2" \
-          quay.io/crcont/crc-cloud:v0.0.2 \
-          create aws \
-          --project-name "chaos-funtest-${RUN_ID}" \
-          --backed-url "s3://krkn-crc-state/${RUN_ID}" \
-          --output "/workspace" \
-          --aws-ami-id "ami-00f5eaf98cf42ef9f" \
-          --pullsecret-filepath /workspace/pullsecret.txt \
-          --key-filepath /workspace/key.txt
-
-      - name: Setup kubeconfig
-        continue-on-error: true
-        run: |
-          ssh  -o StrictHostKeyChecking=no -i id_rsa core@$(cat host) "cat /opt/kubeconfig" > kubeconfig
-          sed -i "s/https:\/\/api.crc.testing:6443/https:\/\/`cat host`.nip.io:6443/g" kubeconfig
-          echo "KUBECONFIG=${PWD}/kubeconfig" > $GITHUB_ENV
-
-      - name: Example deployment, GitHub Action env init
-        env:
-          NAMESPACE: test-namespace
-          DEPLOYMENT_NAME: test-nginx
-        run: ./CI/CRC/init_github_action.sh
-      - name: Setup test suite
-        run: |
-          yq -i '.kraken.port="8081"' CI/config/common_test_config.yaml
-          yq -i '.kraken.signal_address="0.0.0.0"' CI/config/common_test_config.yaml
-          yq -i '.kraken.kubeconfig_path="'${KUBECONFIG}'"' CI/config/common_test_config.yaml
-          echo "test_app_outages_gh" > ./CI/tests/my_tests
-          echo "test_container"      >> ./CI/tests/my_tests
-          echo "test_namespace"      >> ./CI/tests/my_tests
-          echo "test_net_chaos"      >> ./CI/tests/my_tests
-          echo "test_time"           >> ./CI/tests/my_tests
-
-      - name: Print affected config files
-        run: |
-          echo -e "## CI/config/common_test_config.yaml\n\n"
-          cat CI/config/common_test_config.yaml
-
-      - name: Running test suite
-        run: |
-          ./CI/run.sh
-      - name: Print test output
-        run:  cat CI/out/*
-      - name: Create coverage report
-        run: |
-          echo "# Test results" > $GITHUB_STEP_SUMMARY
-          cat CI/results.markdown >> $GITHUB_STEP_SUMMARY
-          echo "# Test coverage" >> $GITHUB_STEP_SUMMARY
-          python -m coverage report --format=markdown >> $GITHUB_STEP_SUMMARY
-
-

.gitignore

@@ -23,8 +23,6 @@ kube_burner*
 .pydevproject
 .settings
 .idea
-.vscode
-config/debug.yaml
 tags
 
 # Package files
@@ -63,7 +61,3 @@ CI/out/*
 CI/ci_results
 CI/scenarios/*node.yaml
 CI/results.markdown
-
-#env
-chaos/*
-

.gitleaks.toml

@@ -1,6 +0,0 @@
-[allowlist]
-  description = "Global Allowlist"
-
-  paths = [
-        '''kraken/arcaflow_plugin/fixtures/*'''
-  ]

CI/CRC/deployment.yaml

@@ -1,44 +0,0 @@
-apiVersion: v1
-kind: Namespace
-metadata:
-  name: $NAMESPACE
-
----
-
-apiVersion: v1
-kind: Service
-metadata:
-  name: $DEPLOYMENT_NAME-service
-  namespace: $NAMESPACE
-spec:
-  selector:
-    app: $DEPLOYMENT_NAME
-  ports:
-    - name: http
-      port: 80
-      targetPort: 8080
-  type: ClusterIP
-
---- 
-
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  namespace: $NAMESPACE
-  name: $DEPLOYMENT_NAME-deployment
-spec:
-  replicas: 3
-  selector:
-    matchLabels:
-      app: $DEPLOYMENT_NAME
-  template:
-    metadata:
-      labels:
-        app: $DEPLOYMENT_NAME
-    spec:
-      containers:
-        - name: $DEPLOYMENT_NAME
-          image: nginxinc/nginx-unprivileged:stable-alpine
-          ports:
-            - name: http
-              containerPort: 8080

CI/CRC/init_github_action.sh

@@ -1,58 +0,0 @@
-#!/bin/bash
-SCRIPT_PATH=./CI/CRC
-DEPLOYMENT_PATH=$SCRIPT_PATH/deployment.yaml
-
-[[ ! -f $DEPLOYMENT_PATH ]] && echo "[ERROR] please run $0 from GitHub action root directory" && exit 1
-[[ -z $DEPLOYMENT_NAME ]] && echo "[ERROR] please set \$DEPLOYMENT_NAME environment variable" && exit 1
-[[ -z $NAMESPACE ]] && echo "[ERROR] please set \$NAMESPACE environment variable" && exit 1
-
-
-OPENSSL=`which openssl 2>/dev/null`
-[[ $? != 0 ]] && echo "[ERROR]: openssl missing, please install it and try again" && exit 1
-OC=`which oc 2>/dev/null`
-[[ $? != 0 ]] && echo "[ERROR]: oc missing, please install it and try again" && exit 1
-SED=`which sed 2>/dev/null`
-[[ $? != 0 ]] && echo "[ERROR]: sed missing, please install it and try again" && exit 1
-JQ=`which jq 2>/dev/null`
-[[ $? != 0 ]] && echo "[ERROR]: jq missing, please install it and try again" && exit 1
-ENVSUBST=`which envsubst 2>/dev/null`
-[[ $? != 0 ]] && echo "[ERROR]: envsubst missing, please install it and try again" && exit 1
-
-
-API_PORT="6443"
-API_ADDRESS="https://api.`cat host`.nip.io:${API_PORT}"
-FQN=$DEPLOYMENT_NAME.apps.$API_ADDRESS
-
-
-echo "[INF] deploying example deployment: $DEPLOYMENT_NAME in namespace: $NAMESPACE"
-$ENVSUBST < $DEPLOYMENT_PATH | $OC apply -f - > /dev/null 2>&1
-
-echo "[INF] creating SSL self-signed certificates for route https://$FQN"
-$OPENSSL genrsa -out servercakey.pem > /dev/null 2>&1
-$OPENSSL req -new -x509 -key servercakey.pem -out serverca.crt -subj "/CN=$FQN/O=Red Hat Inc./C=US" > /dev/null 2>&1
-$OPENSSL genrsa -out server.key > /dev/null 2>&1
-$OPENSSL req -new -key server.key -out server_reqout.txt -subj "/CN=$FQN/O=Red Hat Inc./C=US" > /dev/null 2>&1
-$OPENSSL x509 -req -in server_reqout.txt -days 3650 -sha256 -CAcreateserial -CA serverca.crt -CAkey servercakey.pem -out server.crt > /dev/null 2>&1
-echo "[INF] creating deployment: $DEPLOYMENT_NAME public route: https://$FQN"
-$OC create route --namespace $NAMESPACE  edge --service=$DEPLOYMENT_NAME-service --cert=server.crt --key=server.key --ca-cert=serverca.crt --hostname="$FQN" > /dev/null 2>&1
-
-
-echo "[INF] setting github action environment variables"
-
-NODE_NAME="`$OC get nodes  -o json | $JQ -r '.items[0].metadata.name'`"
-COVERAGE_FILE="`pwd`/coverage.md"
-echo "DEPLOYMENT_NAME=$DEPLOYMENT_NAME" >> $GITHUB_ENV
-echo "DEPLOYMENT_FQN=$FQN" >> $GITHUB_ENV
-echo "API_ADDRESS=$API_ADDRESS" >> $GITHUB_ENV
-echo "API_PORT=$API_PORT" >> $GITHUB_ENV
-echo "NODE_NAME=$NODE_NAME" >> $GITHUB_ENV
-echo "NAMESPACE=$NAMESPACE" >> $GITHUB_ENV
-echo "COVERAGE_FILE=$COVERAGE_FILE" >> $GITHUB_ENV
-
-echo "[INF] deployment fully qualified name will be available in \${{ env.DEPLOYMENT_NAME }} with value $DEPLOYMENT_NAME"
-echo "[INF] deployment name will be available in \${{ env.DEPLOYMENT_FQN }} with value $FQN"
-echo "[INF] OCP API address will be available in \${{ env.API_ADDRESS }} with value $API_ADDRESS"
-echo "[INF] OCP API port will be available in \${{ env.API_PORT }} with value $API_PORT"
-echo "[INF] OCP node name will be available in \${{ env.NODE_NAME }} with value $NODE_NAME"
-echo "[INF] coverage file will ve available in \${{ env.COVERAGE_FILE }} with value $COVERAGE_FILE"
-

CI/config/common_test_config.yaml

@@ -1,6 +1,6 @@
 kraken:
     distribution: openshift                                # Distribution can be kubernetes or openshift.
-    kubeconfig_path: ~/.kube/config                        # Path to kubeconfig.
+    kubeconfig_path: /root/.kube/config                    # Path to kubeconfig.
     exit_on_failure: False                                 # Exit when a post action scenario fails.
     litmus_version: v1.13.6                                # Litmus version to install.
     litmus_uninstall: False                                # If you want to uninstall litmus if failure.
@@ -15,27 +15,17 @@ cerberus:
 performance_monitoring:
     deploy_dashboards: False                               # Install a mutable grafana and load the performance dashboards. Enable this only when running on OpenShift.
     repo: "https://github.com/cloud-bulldozer/performance-dashboards.git"
+    kube_burner_binary_url: "https://github.com/cloud-bulldozer/kube-burner/releases/download/v0.9.1/kube-burner-0.9.1-Linux-x86_64.tar.gz"
     capture_metrics: False
+    config_path: config/kube_burner.yaml                   # Define the Elasticsearch url and index name in this config.
     metrics_profile_path: config/metrics-aggregated.yaml
     prometheus_url:                                        # The prometheus url/route is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes.
     prometheus_bearer_token:                               # The bearer token is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes. This is needed to authenticate with prometheus.
     uuid:                                                  # uuid for the run is generated by default if not set.
     enable_alerts: False                                   # Runs the queries specified in the alert profile and displays the info or exits 1 when severity=error.
-    alert_profile: config/alerts.yaml                           # Path to alert profile with the prometheus queries.
+    alert_profile: config/alerts                           # Path to alert profile with the prometheus queries.
 
 tunings:
     wait_duration: 6                                       # Duration to wait between each chaos scenario.
     iterations: 1                                          # Number of times to execute the scenarios.
     daemon_mode: False                                     # Iterations are set to infinity which means that the kraken will cause chaos forever.
-telemetry:
-    enabled: False                                           # enable/disables the telemetry collection feature
-    api_url: https://ulnmf9xv7j.execute-api.us-west-2.amazonaws.com/production #telemetry service endpoint
-    username: username                                      # telemetry service username
-    password: password                                      # telemetry service password
-    prometheus_backup: True                                 # enables/disables prometheus data collection
-    full_prometheus_backup: False                           # if is set to False only the /prometheus/wal folder will be downloaded.
-    backup_threads: 5                                       # number of telemetry download/upload threads
-    archive_path: /tmp                                      # local path where the archive files will be temporarly stored
-    max_retries: 0                                          # maximum number of upload retries (if 0 will retry forever)
-    run_tag: ''                                             # if set, this will be appended to the run folder in the bucket (useful to group the runs)
-    archive_size: 10000                                     # the size of the prometheus data archive size in KB. The lower the size of archive is

CI/run.sh

@@ -1,22 +1,5 @@
 #!/bin/bash
 set -x
-MAX_RETRIES=60
-
-OC=`which oc 2>/dev/null`
-[[ $? != 0 ]] && echo "[ERROR]: oc missing, please install it and try again" && exit 1
-
-wait_cluster_become_ready() {
-  COUNT=1
-  until `$OC get namespace > /dev/null 2>&1`
-  do
-    echo "[INF] waiting OpenShift to become ready, after $COUNT check"
-    sleep 3
-    [[ $COUNT == $MAX_RETRIES ]] && echo "[ERR] max retries exceeded, failing" && exit 1
-    ((COUNT++))
-  done 
-}
-
-
 
 ci_tests_loc="CI/tests/my_tests"
 
@@ -39,7 +22,5 @@ echo '-----------------------|--------|---------' >> $results
 # Run each test
 for test_name in `cat CI/tests/my_tests`
 do
-  wait_cluster_become_ready
   ./CI/run_test.sh $test_name $results
-  wait_cluster_become_ready
 done

CI/scenarios/hello_pod.yaml

@@ -0,0 +1,31 @@
+---
+kind: Pod
+apiVersion: v1
+metadata:
+  name: hello-pod
+  creationTimestamp:
+  labels:
+    name: hello-openshift
+spec:
+  containers:
+  - name: hello-openshift
+    image: openshift/hello-openshift
+    ports:
+    - containerPort: 5050
+      protocol: TCP
+    resources: {}
+    volumeMounts:
+    - name: tmp
+      mountPath: "/tmp"
+    terminationMessagePath: "/dev/termination-log"
+    imagePullPolicy: IfNotPresent
+    securityContext:
+      capabilities: {}
+      privileged: false
+  volumes:
+  - name: tmp
+    emptyDir: {}
+  restartPolicy: Always
+  dnsPolicy: ClusterFirst
+  serviceAccount: ''
+status: {}

CI/scenarios/hello_pod_killing.yml

@@ -0,0 +1,31 @@
+config:
+  runStrategy:
+    runs: 1
+    maxSecondsBetweenRuns: 30
+    minSecondsBetweenRuns: 1
+scenarios:
+  - name: "delete hello pods"
+    steps:
+    - podAction:
+        matches:
+          - labels:
+              namespace: "default"
+              selector: "hello-openshift"
+        filters:
+          - randomSample:
+              size: 1
+        actions:
+          - kill:
+              probability: 1
+              force: true
+    - podAction:
+        matches:
+          - labels:
+              namespace: "default"
+              selector: "hello-openshift"
+        retries:
+          retriesTimeout:
+            timeout: 180
+        actions:
+          - checkPodCount:
+              count: 1

CI/scenarios/ingress_namespace.yaml

@@ -0,0 +1,7 @@
+scenarios:
+- action: delete
+  namespace: "^.*ingress.*$"
+  label_selector:
+  runs: 1
+  sleep: 15
+  wait_time: 30

CI/scenarios/network_diagnostics_namespace.yaml

@@ -1,7 +0,0 @@
-scenarios:
-  - action: delete
-    namespace: "^$openshift-network-diagnostics$"
-    label_selector:
-    runs: 1
-    sleep: 15
-    wait_time: 30

CI/scenarios/node_cpu_hog_engine.yaml

@@ -0,0 +1,34 @@
+apiVersion: litmuschaos.io/v1alpha1
+kind: ChaosEngine
+metadata:
+  name: nginx-chaos
+  namespace: litmus
+spec:
+  # It can be true/false
+  annotationCheck: 'false'
+  # It can be active/stop
+  engineState: 'active'
+  chaosServiceAccount: litmus-sa
+  monitoring: false
+  # It can be delete/retain
+  jobCleanUpPolicy: 'delete'
+  experiments:
+    - name: node-cpu-hog
+      spec:
+        components:
+          env:
+            # set chaos duration (in sec) as desired
+            - name: TOTAL_CHAOS_DURATION
+              value: '10'
+
+            # Number of cores of node CPU to be consumed
+            - name: NODE_CPU_CORE
+              value: '1'
+
+            # percentage of total nodes to target
+            - name: NODES_AFFECTED_PERC
+              value: '30'
+
+            # ENTER THE COMMA SEPARATED TARGET NODES NAME
+            - name: TARGET_NODES
+              value: $WORKER_NODE

CI/scenarios/node_cpu_hog_engine_node.yaml

@@ -0,0 +1,34 @@
+apiVersion: litmuschaos.io/v1alpha1
+kind: ChaosEngine
+metadata:
+  name: nginx-chaos
+  namespace: litmus
+spec:
+  # It can be true/false
+  annotationCheck: 'false'
+  # It can be active/stop
+  engineState: 'active'
+  chaosServiceAccount: litmus-sa
+  monitoring: false
+  # It can be delete/retain
+  jobCleanUpPolicy: 'delete'
+  experiments:
+    - name: node-cpu-hog
+      spec:
+        components:
+          env:
+            # set chaos duration (in sec) as desired
+            - name: TOTAL_CHAOS_DURATION
+              value: '10'
+
+            # Number of cores of node CPU to be consumed
+            - name: NODE_CPU_CORE
+              value: '1'
+
+            # percentage of total nodes to target
+            - name: NODES_AFFECTED_PERC
+              value: '30'
+
+            # ENTER THE COMMA SEPARATED TARGET NODES NAME
+            - name: TARGET_NODES
+              value:

CI/scenarios/node_io_engine.yaml

@@ -0,0 +1,35 @@
+apiVersion: litmuschaos.io/v1alpha1
+kind: ChaosEngine
+metadata:
+  name: nginx-chaos
+  namespace: litmus
+spec:
+  # It can be delete/retain
+  jobCleanUpPolicy: 'retain'
+  # It can be active/stop
+  engineState: 'active'
+  chaosServiceAccount: litmus-sa
+  experiments:
+    - name: node-io-stress
+      spec:
+        components:
+          env:
+            # set chaos duration (in sec) as desired
+            - name: TOTAL_CHAOS_DURATION
+              value: '10'
+
+            ## specify the size as percentage of free space on the file system
+            - name: FILESYSTEM_UTILIZATION_PERCENTAGE
+              value: '100'
+
+            ## Number of core of CPU
+            - name: CPU
+              value: '1'
+
+            ## Total number of workers default value is 4
+            - name: NUMBER_OF_WORKERS
+              value: '3'
+
+             ## enter the comma separated target nodes name
+            - name: TARGET_NODES
+              value: $WORKER_NODE

CI/scenarios/node_io_engine_node.yaml

@@ -0,0 +1,35 @@
+apiVersion: litmuschaos.io/v1alpha1
+kind: ChaosEngine
+metadata:
+  name: nginx-chaos
+  namespace: litmus
+spec:
+  # It can be delete/retain
+  jobCleanUpPolicy: 'retain'
+  # It can be active/stop
+  engineState: 'active'
+  chaosServiceAccount: litmus-sa
+  experiments:
+    - name: node-io-stress
+      spec:
+        components:
+          env:
+            # set chaos duration (in sec) as desired
+            - name: TOTAL_CHAOS_DURATION
+              value: '10'
+
+            ## specify the size as percentage of free space on the file system
+            - name: FILESYSTEM_UTILIZATION_PERCENTAGE
+              value: '100'
+
+            ## Number of core of CPU
+            - name: CPU
+              value: '1'
+
+            ## Total number of workers default value is 4
+            - name: NUMBER_OF_WORKERS
+              value: '3'
+
+             ## enter the comma separated target nodes name
+            - name: TARGET_NODES
+              value:

CI/scenarios/node_mem_engine.yaml

@@ -0,0 +1,28 @@
+apiVersion: litmuschaos.io/v1alpha1
+kind: ChaosEngine
+metadata:
+  name: nginx-chaos
+  namespace: litmus
+spec:
+  # It can be delete/retain
+  jobCleanUpPolicy: 'retain'
+  # It can be active/stop
+  engineState: 'active'
+  chaosServiceAccount: litmus-sa
+  experiments:
+    - name: node-memory-hog
+      spec:
+        components:
+          env:
+            # set chaos duration (in sec) as desired
+            - name: TOTAL_CHAOS_DURATION
+              value: '10'
+
+            ## Specify the size as percent of total node capacity Ex: '30'
+            ## Note: For consuming memory in mebibytes change the variable to MEMORY_CONSUMPTION_MEBIBYTES
+            - name: MEMORY_CONSUMPTION_PERCENTAGE
+              value: '30'
+
+            # ENTER THE COMMA SEPARATED TARGET NODES NAME
+            - name: TARGET_NODES
+              value: $WORKER_NODE

CI/scenarios/node_mem_engine_node.yaml

@@ -0,0 +1,28 @@
+apiVersion: litmuschaos.io/v1alpha1
+kind: ChaosEngine
+metadata:
+  name: nginx-chaos
+  namespace: litmus
+spec:
+  # It can be delete/retain
+  jobCleanUpPolicy: 'retain'
+  # It can be active/stop
+  engineState: 'active'
+  chaosServiceAccount: litmus-sa
+  experiments:
+    - name: node-memory-hog
+      spec:
+        components:
+          env:
+            # set chaos duration (in sec) as desired
+            - name: TOTAL_CHAOS_DURATION
+              value: '10'
+
+            ## Specify the size as percent of total node capacity Ex: '30'
+            ## Note: For consuming memory in mebibytes change the variable to MEMORY_CONSUMPTION_MEBIBYTES
+            - name: MEMORY_CONSUMPTION_PERCENTAGE
+              value: '30'
+
+            # ENTER THE COMMA SEPARATED TARGET NODES NAME
+            - name: TARGET_NODES
+              value:

CI/scenarios/volume_scenario.yaml

@@ -1,20 +1,7 @@
 apiVersion: v1
-kind: Namespace
-metadata:
-  labels:
-    kubernetes.io/metadata.name: kraken
-    pod-security.kubernetes.io/audit: privileged
-    pod-security.kubernetes.io/enforce: privileged
-    pod-security.kubernetes.io/enforce-version: v1.24
-    pod-security.kubernetes.io/warn: privileged
-    security.openshift.io/scc.podSecurityLabelSync: "false"
-  name: kraken
----
-apiVersion: v1
 kind: PersistentVolume
 metadata:
   name: kraken-test-pv
-  namespace: kraken
   labels:
     type: local
 spec:
@@ -30,7 +17,6 @@ apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
   name: kraken-test-pvc
-  namespace: kraken
 spec:
   storageClassName: manual
   accessModes:
@@ -43,7 +29,6 @@ apiVersion: v1
 kind: Pod
 metadata:
   name: kraken-test-pod
-  namespace: kraken
 spec:
   volumes:
     - name: kraken-test-pv
@@ -51,7 +36,7 @@ spec:
         claimName: kraken-test-pvc
   containers:
     - name: kraken-test-container
-      image: 'quay.io/centos7/httpd-24-centos7:latest'
+      image: 'image-registry.openshift-image-registry.svc:5000/openshift/httpd:latest'
       volumeMounts:
         - mountPath: "/home/krake-dir/"
           name: kraken-test-pv

CI/tests/my_tests

@@ -1 +1,12 @@
+test_pods
+test_nodes
+test_time
+test_app_outages
+test_container
+test_zone
+test_io_hog
+test_mem_hog
+test_cpu_hog
+test_shut_down
 test_net_chaos
+test_namespace

CI/tests/test_app_outages.sh

@@ -12,7 +12,7 @@ function functional_test_app_outage {
   export scenario_file="CI/scenarios/app_outage.yaml"
   export post_config=""
   envsubst < CI/config/common_test_config.yaml > CI/config/app_outage.yaml
-  python3 -m coverage run -a run_kraken.py -c CI/config/app_outage.yaml
+  python3 run_kraken.py -c CI/config/app_outage.yaml
   echo "App outage scenario test: Success"
 }
 

CI/tests/test_app_outages_gh.sh

@@ -1,21 +0,0 @@
-set -xeEo pipefail
-
-source CI/tests/common.sh
-
-trap error ERR
-trap finish EXIT
-
-
-function functional_test_app_outage {
-  [ -z $DEPLOYMENT_NAME ] && echo "[ERR] DEPLOYMENT_NAME variable not set, failing." && exit 1
-  yq -i '.application_outage.pod_selector={"app":"'$DEPLOYMENT_NAME'"}' CI/scenarios/app_outage.yaml
-  yq -i '.application_outage.namespace="'$NAMESPACE'"' CI/scenarios/app_outage.yaml
-  export scenario_type="application_outages"
-  export scenario_file="CI/scenarios/app_outage.yaml"
-  export post_config=""
-  envsubst < CI/config/common_test_config.yaml > CI/config/app_outage.yaml
-  python3 -m coverage run -a run_kraken.py -c CI/config/app_outage.yaml
-  echo "App outage scenario test: Success"
-}
-
-functional_test_app_outage

CI/tests/test_container.sh

@@ -14,7 +14,7 @@ function functional_test_container_crash {
   export post_config=""
   envsubst < CI/config/common_test_config.yaml > CI/config/container_config.yaml
 
-  python3 -m coverage run -a run_kraken.py -c CI/config/container_config.yaml
+  python3 run_kraken.py -c CI/config/container_config.yaml
   echo "Container scenario test: Success"
 }
 

CI/tests/test_cpu_hog.sh

@@ -0,0 +1,20 @@
+set -xeEo pipefail
+
+source CI/tests/common.sh
+
+trap error ERR
+trap finish EXIT
+
+
+function functional_test_litmus_cpu {
+
+  export scenario_type="litmus_scenarios"
+  export scenario_file="- scenarios/templates/litmus-rbac.yaml"
+  export post_config="- CI/scenarios/node_cpu_hog_engine_node.yaml"
+  envsubst < CI/config/common_test_config.yaml > CI/config/litmus_config.yaml
+  envsubst < CI/scenarios/node_cpu_hog_engine.yaml > CI/scenarios/node_cpu_hog_engine_node.yaml
+  python3 run_kraken.py -c CI/config/litmus_config.yaml
+  echo "Litmus scenario $1 test: Success"
+}
+
+functional_test_litmus_cpu

CI/tests/test_io_hog.sh

@@ -0,0 +1,20 @@
+set -xeEo pipefail
+
+source CI/tests/common.sh
+
+trap error ERR
+trap finish EXIT
+
+
+function functional_test_litmus_io {
+
+  export scenario_type="litmus_scenarios"
+  export scenario_file="- scenarios/templates/litmus-rbac.yaml"
+  export post_config="- CI/scenarios/node_io_engine_node.yaml"
+  envsubst < CI/config/common_test_config.yaml > CI/config/litmus_config.yaml
+  envsubst < CI/scenarios/node_io_engine.yaml > CI/scenarios/node_io_engine_node.yaml
+  python3 run_kraken.py -c CI/config/litmus_config.yaml
+  echo "Litmus scenario $1 test: Success"
+}
+
+functional_test_litmus_io

CI/tests/test_mem_hog.sh

@@ -0,0 +1,20 @@
+set -xeEo pipefail
+
+source CI/tests/common.sh
+
+trap error ERR
+trap finish EXIT
+
+
+function functional_test_litmus_mem {
+
+  export scenario_type="litmus_scenarios"
+  export scenario_file="- scenarios/templates/litmus-rbac.yaml"
+  export post_config="- CI/scenarios/node_mem_engine_node.yaml"
+  envsubst < CI/config/common_test_config.yaml > CI/config/litmus_config.yaml
+  envsubst < CI/scenarios/node_mem_engine.yaml > CI/scenarios/node_mem_engine_node.yaml
+  python3 run_kraken.py -c CI/config/litmus_config.yaml
+  echo "Litmus scenario $1 test: Success"
+}
+
+functional_test_litmus_mem "- CI/scenarios/node_mem_engine.yaml"

CI/tests/test_namespace.sh

@@ -7,11 +7,11 @@ trap finish EXIT
 
 function funtional_test_namespace_deletion {
   export scenario_type="namespace_scenarios"
-  export scenario_file="-  CI/scenarios/network_diagnostics_namespace.yaml"
+  export scenario_file="-  CI/scenarios/ingress_namespace.yaml"
   export post_config=""
-  yq '.scenarios.[0].namespace="^openshift-network-diagnostics$"' -i CI/scenarios/network_diagnostics_namespace.yaml
   envsubst < CI/config/common_test_config.yaml > CI/config/namespace_config.yaml
-  python3 -m coverage run -a run_kraken.py -c CI/config/namespace_config.yaml
+
+  python3 run_kraken.py -c CI/config/namespace_config.yaml
   echo $?
   echo "Namespace scenario test: Success"
 }

CI/tests/test_net_chaos.sh

@@ -12,7 +12,7 @@ function functional_test_network_chaos {
   export scenario_file="CI/scenarios/network_chaos.yaml"
   export post_config=""
   envsubst < CI/config/common_test_config.yaml > CI/config/network_chaos.yaml
-  python3 -m coverage run -a run_kraken.py -c CI/config/network_chaos.yaml
+  python3 run_kraken.py -c CI/config/network_chaos.yaml
   echo "Network Chaos test: Success"
 }
 

CI/tests/test_nodes.sh

@@ -13,7 +13,7 @@ function funtional_test_node_crash {
   export post_config=""
   envsubst < CI/config/common_test_config.yaml > CI/config/node_config.yaml
 
-  python3 -m coverage run -a run_kraken.py -c CI/config/node_config.yaml
+  python3 run_kraken.py -c CI/config/node_config.yaml
   echo "Node scenario test: Success"
 }
 

CI/tests/test_pods.sh

@@ -0,0 +1,19 @@
+set -xeEo pipefail
+
+source CI/tests/common.sh
+
+trap error ERR
+trap finish EXIT
+
+function funtional_test_pod_deletion {
+  export scenario_type="pod_scenarios"
+  export scenario_file="-  CI/scenarios/hello_pod_killing.yml"
+  export post_config=""
+  envsubst < CI/config/common_test_config.yaml > CI/config/pod_config.yaml
+
+  python3 run_kraken.py -c CI/config/pod_config.yaml
+  echo $?
+  echo "Pod scenario test: Success"
+}
+
+funtional_test_pod_deletion

CI/tests/test_shut_down.sh

@@ -12,7 +12,7 @@ function functional_test_shut_down {
   export scenario_file="- CI/scenarios/cluster_shut_down_scenario.yml"
   export post_config=""
   envsubst < CI/config/common_test_config.yaml > CI/config/shut_down.yaml
-  python3 -m coverage run -a run_kraken.py -c CI/config/shut_down.yaml
+  python3 run_kraken.py -c CI/config/shut_down.yaml
   echo "Cluster shut down scenario test: Success"
 }
 

CI/tests/test_time.sh

@@ -12,7 +12,7 @@ function functional_test_time_scenario {
   export post_config=""
   envsubst < CI/config/common_test_config.yaml > CI/config/time_config.yaml
 
-  python3 -m coverage run -a run_kraken.py -c CI/config/time_config.yaml
+  python3 run_kraken.py -c CI/config/time_config.yaml
   echo "Time scenario test: Success"
 }
 

CI/tests/test_zone.sh

@@ -13,7 +13,7 @@ function functional_test_zone_crash {
   export post_config=""
   envsubst < CI/config/common_test_config.yaml > CI/config/zone3_config.yaml
   envsubst < CI/scenarios/zone_outage.yaml > CI/scenarios/zone_outage_env.yaml
-  python3 -m coverage run -a run_kraken.py -c CI/config/zone3_config.yaml
+  python3 run_kraken.py -c CI/config/zone3_config.yaml
   echo "zone3 scenario test: Success"
 }
 

CODE_OF_CONDUCT.md

@@ -1,104 +0,0 @@
-## CNCF Community Code of Conduct v1.3
-
-Other languages available:
-- [Arabic/العربية](code-of-conduct-languages/ar.md)
-- [Bulgarian/Български](code-of-conduct-languages/bg.md)
-- [Chinese/中文](code-of-conduct-languages/zh.md)
-- [Czech/Česky](code-of-conduct-languages/cs.md)
-- [Farsi/فارسی](code-of-conduct-languages/fa.md)
-- [French/Français](code-of-conduct-languages/fr.md)
-- [German/Deutsch](code-of-conduct-languages/de.md)
-- [Hindi/हिन्दी](code-of-conduct-languages/hi.md)
-- [Indonesian/Bahasa Indonesia](code-of-conduct-languages/id.md)
-- [Italian/Italiano](code-of-conduct-languages/it.md)
-- [Japanese/日本語](code-of-conduct-languages/jp.md)
-- [Korean/한국어](code-of-conduct-languages/ko.md)
-- [Polish/Polski](code-of-conduct-languages/pl.md)
-- [Portuguese/Português](code-of-conduct-languages/pt.md)
-- [Russian/Русский](code-of-conduct-languages/ru.md)
-- [Spanish/Español](code-of-conduct-languages/es.md)
-- [Turkish/Türkçe](code-of-conduct-languages/tr.md)
-- [Ukrainian/Українська](code-of-conduct-languages/uk.md)
-- [Vietnamese/Tiếng Việt](code-of-conduct-languages/vi.md)
-
-### Community Code of Conduct
-
-As contributors, maintainers, and participants in the CNCF community, and in the interest of fostering
-an open and welcoming community, we pledge to respect all people who participate or contribute
-through reporting issues, posting feature requests, updating documentation,
-submitting pull requests or patches, attending conferences or events, or engaging in other community or project activities.
-
-We are committed to making participation in the CNCF community a harassment-free experience for everyone, regardless of age, body size, caste, disability, ethnicity, level of experience, family status, gender, gender identity and expression, marital status, military or veteran status, nationality, personal appearance, race, religion, sexual orientation, socioeconomic status, tribe, or any other dimension of diversity.
-
-## Scope
-
-This code of conduct applies:
-* within project and community spaces,
-* in other spaces when an individual CNCF community participant's words or actions are directed at or are about a CNCF project, the CNCF community, or another CNCF community participant.
-
-### CNCF Events
-
-CNCF events that are produced by the Linux Foundation with professional events staff are governed by the Linux Foundation [Events Code of Conduct](https://events.linuxfoundation.org/code-of-conduct/) available on the event page. This is designed to be used in conjunction with the CNCF Code of Conduct.
-
-## Our Standards
-
-The CNCF Community is open, inclusive and respectful. Every member of our community has the right to have their identity respected.
-
-Examples of behavior that contributes to a positive environment include but are not limited to:
-
-* Demonstrating empathy and kindness toward other people
-* Being respectful of differing opinions, viewpoints, and experiences
-* Giving and gracefully accepting constructive feedback
-* Accepting responsibility and apologizing to those affected by our mistakes,
-  and learning from the experience
-* Focusing on what is best not just for us as individuals, but for the
-  overall community
-* Using welcoming and inclusive language
-
-
-Examples of unacceptable behavior include but are not limited to:
-
-* The use of sexualized language or imagery
-* Trolling, insulting or derogatory comments, and personal or political attacks
-* Public or private harassment in any form
-* Publishing others' private information, such as a physical or email
-  address, without their explicit permission
-* Violence, threatening violence, or encouraging others to engage in violent behavior
-* Stalking or following someone without their consent
-* Unwelcome physical contact
-* Unwelcome sexual or romantic attention or advances
-* Other conduct which could reasonably be considered inappropriate in a
-  professional setting
-
-The following behaviors are also prohibited:
-* Providing knowingly false or misleading information in connection with a Code of Conduct investigation or otherwise intentionally tampering with an investigation.
-* Retaliating against a person because they reported an incident or provided information about an incident as a witness.
-
-Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct.
-By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect
-of managing a CNCF project.
-Project maintainers who do not follow or enforce the Code of Conduct may be temporarily or permanently removed from the project team.
-
-## Reporting
-
-For incidents occurring in the Kubernetes community, contact the [Kubernetes Code of Conduct Committee](https://git.k8s.io/community/committee-code-of-conduct) via <conduct@kubernetes.io>. You can expect a response within three business days.
-
-For other projects, or for incidents that are project-agnostic or impact multiple CNCF projects, please contact the [CNCF Code of Conduct Committee](https://www.cncf.io/conduct/committee/) via <conduct@cncf.io>.  Alternatively, you can contact any of the individual members of the [CNCF Code of Conduct Committee](https://www.cncf.io/conduct/committee/) to submit your report. For more detailed instructions on how to submit a report, including how to submit a report anonymously, please see our [Incident Resolution Procedures](https://github.com/cncf/foundation/blob/main/code-of-conduct/coc-incident-resolution-procedures.md). You can expect a response within three business days.
-
-For incidents occurring at CNCF event that is produced by the Linux Foundation, please contact <eventconduct@cncf.io>.
-
-## Enforcement
-
-Upon review and investigation of a reported incident, the CoC response team that has jurisdiction will determine what action is appropriate based on this Code of Conduct and its related documentation.
-
-For information about which Code of Conduct incidents are handled by project leadership, which incidents are handled by the CNCF Code of Conduct Committee, and which incidents are handled by the Linux Foundation (including its events team), see our [Jurisdiction Policy](https://github.com/cncf/foundation/blob/main/code-of-conduct/coc-committee-jurisdiction-policy.md).
-
-## Amendments
-
-Consistent with the CNCF Charter, any substantive changes to this Code of Conduct must be approved by the Technical Oversight Committee.
-
-## Acknowledgements
-
-This Code of Conduct is adapted from the Contributor Covenant
-(http://contributor-covenant.org), version 2.0 available at
-http://contributor-covenant.org/version/2/0/code_of_conduct/

MAINTAINERS.md

@@ -1,12 +0,0 @@
-## Overview
-
-This document contains a list of maintainers in this repo.
-
-## Current Maintainers
-
-| Maintainer          | GitHub ID                                                 | Email                   |
-|---------------------| --------------------------------------------------------- | ----------------------- |
-| Ravi Elluri         | [chaitanyaenr](https://github.com/chaitanyaenr)           | nelluri@redhat.com      |
-| Pradeep Surisetty   | [psuriset](https://github.com/psuriset)                   | psuriset@redhat.com     |
-| Paige Rubendall     | [paigerube14](https://github.com/paigerube14)             | prubenda@redhat.com     |
-| Tullio Sebastiani   | [tsebastiani](https://github.com/tsebastiani)             | tsebasti@redhat.com     |

README.md

@@ -1,6 +1,5 @@
-# KrknChaos aka Kraken
-[![Docker Repository on Quay](https://quay.io/repository/redhat-chaos/krkn/status "Docker Repository on Quay")](https://quay.io/repository/redhat-chaos/krkn?tab=tags&tag=latest)
-![Workflow-Status](https://github.com/redhat-chaos/krkn/actions/workflows/docker-image.yml/badge.svg)
+# Krkn aka Kraken
+[![Docker Repository on Quay](https://quay.io/repository/chaos-kubox/krkn?tab=tags&tag=latest "Docker Repository on Quay")](https://quay.io/chaos-kubox/krkn)
 
 ![Krkn logo](media/logo.png)
 
@@ -24,21 +23,19 @@ Kraken injects deliberate failures into Kubernetes/OpenShift clusters to check i
 - Test environment recommendations as to how and where to run chaos tests.
 - Chaos testing in practice.
 
-The guide is hosted at https://redhat-chaos.github.io/krknChoas.
+The guide is hosted at [https://chaos-kubox.github.io/krkn/](https://chaos-kubox.github.io/krkn/).
 
 
 ### How to Get Started
 Instructions on how to setup, configure and run Kraken can be found at [Installation](docs/installation.md).
 
-You may consider utilizing the chaos recommendation tool prior to initiating the chaos runs to profile the application service(s) under test. This tool discovers a list of Krkn scenarios with a high probability of causing failures or disruptions to your application service(s). The tool can be accessed at [Chaos-Recommender](utils/chaos_recommender/README.md).
-
 See the [getting started doc](docs/getting_started.md) on support on how to get started with your own custom scenario or editing current scenarios for your specific usage.
 
 After installation, refer back to the below sections for supported scenarios and how to tweak the kraken config to load them on your cluster.
 
 
 #### Running Kraken with minimal configuration tweaks
-For cases where you want to run Kraken with minimal configuration changes, refer to [Kraken-hub](https://github.com/redhat-chaos/krknChaos-hub). One use case is CI integration where you do not want to carry around different configuration files for the scenarios.
+For cases where you want to run Kraken with minimal configuration changes, refer to [Kraken-hub](https://github.com/chaos-kubox/krkn-hub). One use case is CI integration where you do not want to carry around different configuration files for the scenarios.
 
 ### Setting up infrastructure dependencies
 Kraken indexes the metrics specified in the profile into Elasticsearch in addition to leveraging Cerberus for understanding the health of the Kubernetes/OpenShift cluster under test. More information on the features is documented below. The infrastructure pieces can be easily installed and uninstalled by running:
@@ -59,28 +56,26 @@ Instructions on how to setup the config and the options supported can be found a
 
 ### Kubernetes/OpenShift chaos scenarios supported
 
-Scenario type               | Kubernetes    | OpenShift          
---------------------------- | ------------- |--------------------|  
+Scenario type               | Kubernetes    | OpenShift
+--------------------------- | ------------- | -------------------- |  
 [Pod Scenarios](docs/pod_scenarios.md) | :heavy_check_mark: | :heavy_check_mark: |
-[Pod Network Scenarios](docs/pod_network_scenarios.md) | :x: | :heavy_check_mark: |
 [Container Scenarios](docs/container_scenarios.md) | :heavy_check_mark: | :heavy_check_mark: |
 [Node Scenarios](docs/node_scenarios.md) | :heavy_check_mark: | :heavy_check_mark: |
 [Time Scenarios](docs/time_scenarios.md) | :x: | :heavy_check_mark: |
-[Hog Scenarios: CPU, Memory](docs/arcaflow_scenarios.md) | :heavy_check_mark: | :heavy_check_mark: |
+[Litmus Scenarios](docs/litmus_scenarios.md) | :x: | :heavy_check_mark: |
 [Cluster Shut Down Scenarios](docs/cluster_shut_down_scenarios.md) | :heavy_check_mark: | :heavy_check_mark: |
-[Service Disruption Scenarios](docs/service_disruption_scenarios.md.md) | :heavy_check_mark: | :heavy_check_mark: |
+[Namespace Scenarios](docs/namespace_scenarios.md) | :heavy_check_mark: | :heavy_check_mark: |
 [Zone Outage Scenarios](docs/zone_outage.md) | :heavy_check_mark: | :heavy_check_mark: |
 [Application_outages](docs/application_outages.md) | :heavy_check_mark: | :heavy_check_mark: |
 [PVC scenario](docs/pvc_scenario.md) | :heavy_check_mark: | :heavy_check_mark: |
 [Network_Chaos](docs/network_chaos.md) | :heavy_check_mark: | :heavy_check_mark: |
-[ManagedCluster Scenarios](docs/managedcluster_scenarios.md) | :heavy_check_mark: | :question:         |
 
 
 ### Kraken scenario pass/fail criteria and report
 It is important to make sure to check if the targeted component recovered from the chaos injection and also if the Kubernetes/OpenShift cluster is healthy as failures in one component can have an adverse impact on other components. Kraken does this by:
 - Having built in checks for pod and node based scenarios to ensure the expected number of replicas and nodes are up. It also supports running custom scripts with the checks.
-- Leveraging [Cerberus](https://github.com/openshift-scale/cerberus) to monitor the cluster under test and consuming the aggregated go/no-go signal to determine pass/fail post chaos. It is highly recommended to turn on the Cerberus health check feature available in Kraken. Instructions on installing and setting up Cerberus can be found [here](https://github.com/openshift-scale/cerberus#installation) or can be installed from Kraken using the [instructions](https://github.com/redhat-chaos/krkn#setting-up-infrastructure-dependencies). Once Cerberus is up and running, set cerberus_enabled to True and cerberus_url to the url where Cerberus publishes go/no-go signal in the Kraken config file. Cerberus can monitor [application routes](https://github.com/redhat-chaos/cerberus/blob/main/docs/config.md#watch-routes) during the chaos and fails the run if it encounters downtime as it is a potential downtime in a customers, or users environment as well. It is especially important during the control plane chaos scenarios including the API server, Etcd, Ingress etc. It can be enabled by setting `check_applicaton_routes: True` in the [Kraken config](https://github.com/redhat-chaos/krkn/blob/main/config/config.yaml) provided application routes are being monitored in the [cerberus config](https://github.com/redhat-chaos/krkn/blob/main/config/cerberus.yaml).
-- Leveraging built-in alert collection feature to fail the runs in case of critical alerts.
+- Leveraging [Cerberus](https://github.com/openshift-scale/cerberus) to monitor the cluster under test and consuming the aggregated go/no-go signal to determine pass/fail post chaos. It is highly recommended to turn on the Cerberus health check feature available in Kraken. Instructions on installing and setting up Cerberus can be found [here](https://github.com/openshift-scale/cerberus#installation) or can be installed from Kraken using the [instructions](https://github.com/chaos-kubox/krkn#setting-up-infrastructure-dependencies). Once Cerberus is up and running, set cerberus_enabled to True and cerberus_url to the url where Cerberus publishes go/no-go signal in the Kraken config file. Cerberus can monitor [application routes](https://github.com/chaos-kubox/cerberus/blob/main/docs/config.md#watch-routes) during the chaos and fails the run if it encounters downtime as it is a potential downtime in a customers, or users environment as well. It is especially important during the control plane chaos scenarios including the API server, Etcd, Ingress etc. It can be enabled by setting `check_applicaton_routes: True` in the [Kraken config](https://github.com/chaos-kubox/krkn/blob/main/config/config.yaml) provided application routes are being monitored in the [cerberus config](https://github.com/chaos-kubox/krkn/blob/main/config/cerberus.yaml).
+- Leveraging [kube-burner](docs/alerts.md) alerting feature to fail the runs in case of critical alerts.
 
 ### Signaling
 In CI runs or any external job it is useful to stop Kraken once a certain test or state gets reached. We created a way to signal to kraken to pause the chaos or stop it completely using a signal posted to a port of your choice.
@@ -95,31 +90,26 @@ Monitoring the Kubernetes/OpenShift cluster to observe the impact of Kraken chao
 
 
 ### Scraping and storing metrics long term
-Kraken supports capturing metrics for the duration of the scenarios defined in the config and indexes then into Elasticsearch to be able to store and evaluate the state of the runs long term. The indexed metrics can be visualized with the help of Grafana. It uses [Kube-burner](https://github.com/kube-burner/kube-burner) under the hood. The metrics to capture need to be defined in a metrics profile which Kraken consumes to query prometheus ( installed by default in OpenShift ) with the start and end timestamp of the run. Information on enabling and leveraging this feature can be found [here](docs/metrics.md).
+Kraken supports capturing metrics for the duration of the scenarios defined in the config and indexes then into Elasticsearch to be able to store and evaluate the state of the runs long term. The indexed metrics can be visualized with the help of Grafana. It uses [Kube-burner](https://github.com/cloud-bulldozer/kube-burner) under the hood. The metrics to capture need to be defined in a metrics profile which Kraken consumes to query prometheus ( installed by default in OpenShift ) with the start and end timestamp of the run. Information on enabling and leveraging this feature can be found [here](docs/metrics.md).
 
 
-### SLOs validation during and post chaos
-- In addition to checking the recovery and health of the cluster and components under test, Kraken takes in a profile with the Prometheus expressions to validate and alerts, exits with a non-zero return code depending on the severity set. This feature can be used to determine pass/fail or alert on abnormalities observed in the cluster based on the metrics. 
-- Kraken also provides ability to check if any critical alerts are firing in the cluster post chaos and pass/fail's. 
-
-Information on enabling and leveraging this feature can be found [here](docs/SLOs_validation.md)
-
-
-### OCM / ACM integration
-
-Kraken supports injecting faults into [Open Cluster Management (OCM)](https://open-cluster-management.io/) and [Red Hat Advanced Cluster Management for Kubernetes (ACM)](https://www.redhat.com/en/technologies/management/advanced-cluster-management) managed clusters through [ManagedCluster Scenarios](docs/managedcluster_scenarios.md).
+### Alerts
+In addition to checking the recovery and health of the cluster and components under test, Kraken takes in a profile with the Prometheus expressions to validate and alerts, exits with a non-zero return code depending on the severity set. This feature can be used to determine pass/fail or alert on abnormalities observed in the cluster based on the metrics. Information on enabling and leveraging this feature can be found [here](docs/alerts.md).
 
 
 ### Blogs and other useful resources
 - Blog post on introduction to Kraken: https://www.openshift.com/blog/introduction-to-kraken-a-chaos-tool-for-openshift/kubernetes
 - Discussion and demo on how Kraken can be leveraged to ensure OpenShift is reliable, performant and scalable: https://www.youtube.com/watch?v=s1PvupI5sD0&ab_channel=OpenShift
 - Blog post emphasizing the importance of making Chaos part of Performance and Scale runs to mimic the production environments: https://www.openshift.com/blog/making-chaos-part-of-kubernetes/openshift-performance-and-scalability-tests
-- Blog post on findings from Chaos test runs: https://cloud.redhat.com/blog/openshift/kubernetes-chaos-stories
-- Discussion with CNCF TAG App Delivery on Krkn workflow, features and addition to CNCF sandbox: [Github](https://github.com/cncf/sandbox/issues/44), [Tracker](https://github.com/cncf/tag-app-delivery/issues/465), [recording](https://www.youtube.com/watch?v=nXQkBFK_MWc&t=722s)
 
 
 ### Roadmap
-Enhancements being planned can be found in the [roadmap](ROADMAP.md).
+Following is a list of enhancements that we are planning to work on adding support in Kraken. Of course any help/contributions are greatly appreciated.
+- [Ability to visualize the metrics that are being captured by Kraken and stored in Elasticsearch](https://github.com/chaos-kubox/krkn/issues/124)
+- Ability to shape the ingress network similar to how Kraken supports [egress traffic shaping](https://github.com/chaos-kubox/krkn/blob/main/docs/network_chaos.md) today.
+- Continue to improve [Chaos Testing Guide](https://cloud-bulldozer.github.io/kraken/) in terms of adding best practices, test environment recommendations and scenarios to make sure the OpenShift platform, as well the applications running on top it, are resilient and performant under chaotic conditions.
+- Support for running Kraken on Kubernetes distribution - see https://github.com/chaos-kubox/krkn/issues/185, https://github.com/chaos-kubox/krkn/issues/186
+- Sweet logo for Kraken - see https://github.com/chaos-kubox/krkn/issues/195
 
 
 ### Contributions
@@ -133,5 +123,5 @@ Please read [this file]((CI/README.md#adding-a-test-case)) for more information
 
 ### Community
 Key Members(slack_usernames/full name): paigerube14/Paige Rubendall, mffiedler/Mike Fiedler, ravielluri/Naga Ravi Chaitanya Elluri.
-* [**#krkn on Kubernetes Slack**](https://kubernetes.slack.com)
+* [**#sig-scalability on Kubernetes Slack**](https://kubernetes.slack.com)
 * [**#forum-chaos on CoreOS Slack internal to Red Hat**](https://coreos.slack.com)

ROADMAP.md

@@ -1,15 +0,0 @@
-## Krkn Roadmap
-
-Following are a list of enhancements that we are planning to work on adding support in Krkn. Of course any help/contributions are greatly appreciated.
-
-- [ ] [Ability to run multiple chaos scenarios in parallel under load to mimic real world outages](https://github.com/redhat-chaos/krkn/issues/424)
-- [x] [Centralized storage for chaos experiments artifacts](https://github.com/redhat-chaos/krkn/issues/423)
-- [ ] [Support for causing DNS outages](https://github.com/redhat-chaos/krkn/issues/394)
-- [x] [Chaos recommender](https://github.com/redhat-chaos/krkn/tree/main/utils/chaos-recommender) to suggest scenarios having probability of impacting the service under test using profiling results 
-- [ ] Chaos AI integration to improve and automate test coverage
-- [x] [Support for pod level network traffic shaping](https://github.com/redhat-chaos/krkn/issues/393)
-- [ ] [Ability to visualize the metrics that are being captured by Kraken and stored in Elasticsearch](https://github.com/redhat-chaos/krkn/issues/124)
-- [ ] Support for running all the scenarios of Kraken on Kubernetes distribution - see https://github.com/redhat-chaos/krkn/issues/185, https://github.com/redhat-chaos/krkn/issues/186
-- [ ] Continue to improve [Chaos Testing Guide](https://redhat-chaos.github.io/krkn) in terms of adding best practices, test environment recommendations and scenarios to make sure the OpenShift platform, as well the applications running on top it, are resilient and performant under chaotic conditions.
-- [ ] [Switch documentation references to Kubernetes](https://github.com/redhat-chaos/krkn/issues/495)
-- [ ] [OCP and Kubernetes functionalities segregation](https://github.com/redhat-chaos/krkn/issues/497)

ansible/vars/kraken_vars.yml

@@ -8,13 +8,13 @@ orchestration_user: "{{ lookup('env', 'ORCHESTRATION_USER')|default('root', true
 ###############################################################################
 
 # kube config location
-kubeconfig_path: "{{ lookup('env', 'KUBECONFIG_PATH')|default('~/.kube/config', true) }}"
+kubeconfig_path: "{{ lookup('env', 'KUBECONFIG_PATH')|default('/root/.kube/config', true) }}"
 
 # kraken dir location on jump host
-kraken_dir: "{{ lookup('env', 'KRAKEN_DIR')|default('~/kraken', true) }}"
+kraken_dir: "{{ lookup('env', 'KRAKEN_DIR')|default('/root/kraken', true) }}"
 
 # kraken config path location
-kraken_config: "{{ lookup('env', 'KRAKEN_CONFIG')|default('~/kraken/config/config.yaml', true) }}"
+kraken_config: "{{ lookup('env', 'KRAKEN_CONFIG')|default('/root/kraken/config/config.yaml', true) }}"
 
 # kraken repository location
 kraken_repository: "{{ lookup('env', 'KRAKEN_REPOSITORY')|default('https://github.com/openshift-scale/kraken.git', true) }}"

config/alerts

@@ -0,0 +1,11 @@
+- expr: avg_over_time(histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[2m]))[5m:]) > 0.01
+  description: 5 minutes avg. etcd fsync latency on {{$labels.pod}} higher than 10ms {{$value}}
+  severity: error
+
+- expr: avg_over_time(histogram_quantile(0.99, rate(etcd_network_peer_round_trip_time_seconds_bucket[5m]))[5m:]) > 0.1
+  description: 5 minutes avg. etcd netowrk peer round trip on {{$labels.pod}} higher than 100ms {{$value}}
+  severity: info
+
+- expr: increase(etcd_server_leader_changes_seen_total[2m]) > 0
+  description: etcd leader changes observed
+  severity: critical

config/alerts.yaml

@@ -1,90 +0,0 @@
-# etcd
-
-- expr: avg_over_time(histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[2m]))[10m:]) > 0.01
-  description: 10 minutes avg. 99th etcd fsync latency on {{$labels.pod}} higher than 10ms. {{$value}}s
-  severity: warning
-
-- expr: avg_over_time(histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[2m]))[10m:]) > 1
-  description: 10 minutes avg. 99th etcd fsync latency on {{$labels.pod}} higher than 1s. {{$value}}s
-  severity: error
-
-- expr: avg_over_time(histogram_quantile(0.99, rate(etcd_disk_backend_commit_duration_seconds_bucket[2m]))[10m:]) > 0.007
-  description: 10 minutes avg. 99th etcd commit latency on {{$labels.pod}} higher than 30ms. {{$value}}s
-  severity: warning
-
-- expr: rate(etcd_server_leader_changes_seen_total[2m]) > 0
-  description: etcd leader changes observed
-  severity: warning
-
-- expr: (last_over_time(etcd_mvcc_db_total_size_in_bytes[5m]) / last_over_time(etcd_server_quota_backend_bytes[5m]))*100 > 95
-  description: etcd cluster database is running full. 
-  severity: critical
-  
-- expr: (last_over_time(etcd_mvcc_db_total_size_in_use_in_bytes[5m]) / last_over_time(etcd_mvcc_db_total_size_in_bytes[5m])) < 0.5
-  description: etcd database size in use is less than 50% of the actual allocated storage.
-  severity: warning  
-
-- expr: rate(etcd_server_proposals_failed_total{job=~".*etcd.*"}[15m]) > 5
-  description: etcd cluster has high number of proposal failures.
-  severity: warning 
-
-- expr: histogram_quantile(0.99, rate(etcd_network_peer_round_trip_time_seconds_bucket{job=~".*etcd.*"}[5m])) > 0.15
-  description: etcd cluster member communication is slow.
-  severity: warning 
-
-- expr: histogram_quantile(0.99, sum(rate(grpc_server_handling_seconds_bucket{job=~".*etcd.*", grpc_method!="Defragment", grpc_type="unary"}[5m])) without(grpc_type)) > 0.15
-  description: etcd grpc requests are slow.
-  severity: critical
-      
-- expr: 100 * sum(rate(grpc_server_handled_total{job=~".*etcd.*", grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded"}[5m])) without (grpc_type, grpc_code) / sum(rate(grpc_server_handled_total{job=~".*etcd.*"}[5m])) without (grpc_type, grpc_code) > 5
-  description: etcd cluster has high number of failed grpc requests.
-  severity: critical      
-      
-- expr: etcd_server_has_leader{job=~".*etcd.*"} == 0
-  description: etcd cluster has no leader.
-  severity: warning    
-    
-- expr: sum(up{job=~".*etcd.*"} == bool 1) without (instance) < ((count(up{job=~".*etcd.*"}) without (instance) + 1) / 2)
-  description: etcd cluster has insufficient number of members.
-  severity: warning      
-
-- expr: max without (endpoint) ( sum without (instance) (up{job=~".*etcd.*"} == bool 0) or count without (To) ( sum without (instance) (rate(etcd_network_peer_sent_failures_total{job=~".*etcd.*"}[120s])) > 0.01 )) > 0
-  description: etcd cluster members are down.
-  severity: warning  
-
-# API server
-- expr: avg_over_time(histogram_quantile(0.99, sum(irate(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver", verb=~"POST|PUT|DELETE|PATCH", subresource!~"log|exec|portforward|attach|proxy"}[2m])) by (le, resource, verb))[10m:]) > 1
-  description: 10 minutes avg. 99th mutating API call latency for {{$labels.verb}}/{{$labels.resource}} higher than 1 second. {{$value}}s
-  severity: error
-
-- expr: avg_over_time(histogram_quantile(0.99, sum(irate(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver", verb=~"LIST|GET", subresource!~"log|exec|portforward|attach|proxy", scope="resource"}[2m])) by (le, resource, verb, scope))[5m:]) > 1
-  description: 5 minutes avg. 99th read-only API call latency for {{$labels.verb}}/{{$labels.resource}} in scope {{$labels.scope}} higher than 1 second. {{$value}}s
-  severity: error
-
-- expr: avg_over_time(histogram_quantile(0.99, sum(irate(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver", verb=~"LIST|GET", subresource!~"log|exec|portforward|attach|proxy", scope="namespace"}[2m])) by (le, resource, verb, scope))[5m:]) > 5
-  description: 5 minutes avg. 99th read-only API call latency for {{$labels.verb}}/{{$labels.resource}} in scope {{$labels.scope}} higher than 5 seconds. {{$value}}s
-  severity: error
-
-- expr: avg_over_time(histogram_quantile(0.99, sum(irate(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver", verb=~"LIST|GET", subresource!~"log|exec|portforward|attach|proxy", scope="cluster"}[2m])) by (le, resource, verb, scope))[5m:]) > 30
-  description: 5 minutes avg. 99th read-only API call latency for {{$labels.verb}}/{{$labels.resource}} in scope {{$labels.scope}} higher than 30 seconds. {{$value}}s
-  severity: error
-
-# Control plane pods
-
-- expr: up{job=~"crio|kubelet"} == 0
-  description: "{{$labels.node}}/{{$labels.job}} down"
-  severity: warning
-
-- expr: up{job="ovnkube-node"} == 0
-  description: "{{$labels.instance}}/{{$labels.pod}} {{$labels.job}} down"
-  severity: warning
-
-# Service sync latency
-- expr: histogram_quantile(0.99, sum(rate(kubeproxy_network_programming_duration_seconds_bucket[2m])) by (le)) > 10
-  description: 99th Kubeproxy network programming latency higher than 10 seconds. {{$value}}s 
-  severity: warning
-
-# Prometheus alerts
-- expr: ALERTS{severity="critical", alertstate="firing"} > 0
-  description: Critical prometheus alert. {{$labels.alertname}}
-  severity: warning

config/alerts_openshift.yaml

@@ -1,101 +0,0 @@
-# etcd
-
-- expr: avg_over_time(histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[2m]))[10m:]) > 0.01
-  description: 10 minutes avg. 99th etcd fsync latency on {{$labels.pod}} higher than 10ms. {{$value}}s
-  severity: warning
-
-- expr: avg_over_time(histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[2m]))[10m:]) > 1
-  description: 10 minutes avg. 99th etcd fsync latency on {{$labels.pod}} higher than 1s. {{$value}}s
-  severity: error
-
-- expr: avg_over_time(histogram_quantile(0.99, rate(etcd_disk_backend_commit_duration_seconds_bucket[2m]))[10m:]) > 0.03
-  description: 10 minutes avg. 99th etcd commit latency on {{$labels.pod}} higher than 30ms. {{$value}}s
-  severity: warning
-
-- expr: rate(etcd_server_leader_changes_seen_total[2m]) > 0
-  description: etcd leader changes observed
-  severity: warning
-
-- expr: (last_over_time(etcd_mvcc_db_total_size_in_bytes[5m]) / last_over_time(etcd_server_quota_backend_bytes[5m]))*100 > 95
-  description: etcd cluster database is running full. 
-  severity: critical
-  
-- expr: (last_over_time(etcd_mvcc_db_total_size_in_use_in_bytes[5m]) / last_over_time(etcd_mvcc_db_total_size_in_bytes[5m])) < 0.5
-  description: etcd database size in use is less than 50% of the actual allocated storage.
-  severity: warning  
-
-- expr: rate(etcd_server_proposals_failed_total{job=~".*etcd.*"}[15m]) > 5
-  description: etcd cluster has high number of proposal failures.
-  severity: warning 
-
-- expr: histogram_quantile(0.99, rate(etcd_network_peer_round_trip_time_seconds_bucket{job=~".*etcd.*"}[5m])) > 0.15
-  description: etcd cluster member communication is slow.
-  severity: warning 
-
-- expr: histogram_quantile(0.99, sum(rate(grpc_server_handling_seconds_bucket{job=~".*etcd.*", grpc_method!="Defragment", grpc_type="unary"}[5m])) without(grpc_type)) > 0.15
-  description: etcd grpc requests are slow.
-  severity: critical
-      
-- expr: 100 * sum(rate(grpc_server_handled_total{job=~".*etcd.*", grpc_code=~"Unknown|FailedPrecondition|ResourceExhausted|Internal|Unavailable|DataLoss|DeadlineExceeded"}[5m])) without (grpc_type, grpc_code) / sum(rate(grpc_server_handled_total{job=~".*etcd.*"}[5m])) without (grpc_type, grpc_code) > 5
-  description: etcd cluster has high number of failed grpc requests.
-  severity: critical      
-      
-- expr: etcd_server_has_leader{job=~".*etcd.*"} == 0
-  description: etcd cluster has no leader.
-  severity: warning    
-    
-- expr: sum(up{job=~".*etcd.*"} == bool 1) without (instance) < ((count(up{job=~".*etcd.*"}) without (instance) + 1) / 2)
-  description: etcd cluster has insufficient number of members.
-  severity: warning      
-
-- expr: max without (endpoint) ( sum without (instance) (up{job=~".*etcd.*"} == bool 0) or count without (To) ( sum without (instance) (rate(etcd_network_peer_sent_failures_total{job=~".*etcd.*"}[120s])) > 0.01 )) > 0
-  description: etcd cluster members are down.
-  severity: warning  
-
-# API server
-- expr: avg_over_time(histogram_quantile(0.99, sum(irate(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver", verb=~"POST|PUT|DELETE|PATCH", subresource!~"log|exec|portforward|attach|proxy"}[2m])) by (le, resource, verb))[10m:]) > 1
-  description: 10 minutes avg. 99th mutating API call latency for {{$labels.verb}}/{{$labels.resource}} higher than 1 second. {{$value}}s
-  severity: error
-
-- expr: avg_over_time(histogram_quantile(0.99, sum(irate(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver", verb=~"LIST|GET", subresource!~"log|exec|portforward|attach|proxy", scope="resource"}[2m])) by (le, resource, verb, scope))[5m:]) > 1
-  description: 5 minutes avg. 99th read-only API call latency for {{$labels.verb}}/{{$labels.resource}} in scope {{$labels.scope}} higher than 1 second. {{$value}}s
-  severity: error
-
-- expr: avg_over_time(histogram_quantile(0.99, sum(irate(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver", verb=~"LIST|GET", subresource!~"log|exec|portforward|attach|proxy", scope="namespace"}[2m])) by (le, resource, verb, scope))[5m:]) > 5
-  description: 5 minutes avg. 99th read-only API call latency for {{$labels.verb}}/{{$labels.resource}} in scope {{$labels.scope}} higher than 5 seconds. {{$value}}s
-  severity: error
-
-- expr: avg_over_time(histogram_quantile(0.99, sum(irate(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver", verb=~"LIST|GET", subresource!~"log|exec|portforward|attach|proxy", scope="cluster"}[2m])) by (le, resource, verb, scope))[5m:]) > 30
-  description: 5 minutes avg. 99th read-only API call latency for {{$labels.verb}}/{{$labels.resource}} in scope {{$labels.scope}} higher than 30 seconds. {{$value}}s
-  severity: error
-
-# Control plane pods
-- expr: up{apiserver=~"kube-apiserver|openshift-apiserver"} == 0
-  description: "{{$labels.apiserver}} {{$labels.instance}} down"
-  severity: warning
-
-- expr: up{namespace=~"openshift-etcd"} == 0
-  description: "{{$labels.namespace}}/{{$labels.pod}} down"
-  severity: warning
-
-- expr: up{namespace=~"openshift-.*(kube-controller-manager|scheduler|controller-manager|sdn|ovn-kubernetes|dns)"} == 0
-  description: "{{$labels.namespace}}/{{$labels.pod}} down"
-  severity: warning
-
-- expr: up{job=~"crio|kubelet"} == 0
-  description: "{{$labels.node}}/{{$labels.job}} down"
-  severity: warning
-
-- expr: up{job="ovnkube-node"} == 0
-  description: "{{$labels.instance}}/{{$labels.pod}} {{$labels.job}} down"
-  severity: warning
-
-# Service sync latency
-- expr: histogram_quantile(0.99, sum(rate(kubeproxy_network_programming_duration_seconds_bucket[2m])) by (le)) > 10
-  description: 99th Kubeproxy network programming latency higher than 10 seconds. {{$value}}s 
-  severity: warning
-
-# Prometheus alerts
-- expr: ALERTS{severity="critical", alertstate="firing"} > 0
-  description: Critical prometheus alert. {{$labels.alertname}}
-  severity: warning

config/cerberus.yaml

@@ -1,6 +1,6 @@
 cerberus:
     distribution: openshift                              # Distribution can be kubernetes or openshift
-    kubeconfig_path: ~/.kube/config                      # Path to kubeconfig
+    kubeconfig_path: /root/.kube/config                  # Path to kubeconfig
     port: 8080                                           # http server port where cerberus status is published
     watch_nodes: True                                    # Set to True for the cerberus to monitor the cluster nodes
     watch_cluster_operators: True                        # Set to True for cerberus to monitor cluster operators

config/config.yaml

@@ -1,46 +1,48 @@
 kraken:
     distribution: openshift                                # Distribution can be kubernetes or openshift
-    kubeconfig_path: ~/.kube/config                        # Path to kubeconfig
+    kubeconfig_path: /root/.kube/config                    # Path to kubeconfig
     exit_on_failure: False                                 # Exit when a post action scenario fails
+    port: 8081
     publish_kraken_status: True                            # Can be accessed at http://0.0.0.0:8081
     signal_state: RUN                                      # Will wait for the RUN signal when set to PAUSE before running the scenarios, refer docs/signal.md for more details
-    signal_address: 0.0.0.0                                # Signal listening address
-    port: 8081                                             # Signal port
-    chaos_scenarios:
-        # List of policies/chaos scenarios to load
-        - arcaflow_scenarios:
-            - scenarios/arcaflow/cpu-hog/input.yaml
-            - scenarios/arcaflow/memory-hog/input.yaml
-            - scenarios/arcaflow/io-hog/input.yaml
-        - application_outages:
-            - scenarios/openshift/app_outage.yaml
-        - container_scenarios:                             # List of chaos pod scenarios to load
+    litmus_version: v1.13.6                                # Litmus version to install
+    litmus_uninstall: False                                # If you want to uninstall litmus if failure
+    litmus_uninstall_before_run: True                      # If you want to uninstall litmus before a new run starts
+    chaos_scenarios:                                       # List of policies/chaos scenarios to load
+        -   container_scenarios:                                 # List of chaos pod scenarios to load
             - -    scenarios/openshift/container_etcd.yml
-        - plugin_scenarios:
-            - scenarios/openshift/etcd.yml
-            - scenarios/openshift/regex_openshift_pod_kill.yml
-            - scenarios/openshift/vmware_node_scenarios.yml
-            - scenarios/openshift/network_chaos_ingress.yml
-            - scenarios/openshift/prom_kill.yml
-        - node_scenarios:                                  # List of chaos node scenarios to load
+        -   pod_scenarios:
+            - -    scenarios/openshift/etcd.yml
+            - -    scenarios/openshift/regex_openshift_pod_kill.yml
+              -    scenarios/openshift/post_action_regex.py
+        -   node_scenarios:                                # List of chaos node scenarios to load
             -   scenarios/openshift/node_scenarios_example.yml
-        - plugin_scenarios:
-            - scenarios/openshift/openshift-apiserver.yml
-            - scenarios/openshift/openshift-kube-apiserver.yml
-        - time_scenarios:                                  # List of chaos time scenarios to load
+        -   pod_scenarios:
+            - -    scenarios/openshift/openshift-apiserver.yml
+            - -    scenarios/openshift/openshift-kube-apiserver.yml
+        -   time_scenarios:                                # List of chaos time scenarios to load
             - scenarios/openshift/time_scenarios_example.yml
-        - cluster_shut_down_scenarios:
+        -   litmus_scenarios:                              # List of litmus scenarios to load
+            - - scenarios/openshift/templates/litmus-rbac.yaml
+              - scenarios/openshift/node_cpu_hog_engine.yaml
+            - - scenarios/openshift/templates/litmus-rbac.yaml
+              - scenarios/openshift/node_mem_engine.yaml
+            - - scenarios/openshift/templates/litmus-rbac.yaml
+              - scenarios/openshift/node_io_engine.yaml
+        -   cluster_shut_down_scenarios:
             - - scenarios/openshift/cluster_shut_down_scenario.yml
               - scenarios/openshift/post_action_shut_down.py
-        - service_disruption_scenarios:
+        -   namespace_scenarios:
              - - scenarios/openshift/regex_namespace.yaml
              - - scenarios/openshift/ingress_namespace.yaml
                - scenarios/openshift/post_action_namespace.py
-        - zone_outages:
+        -   zone_outages:
             - scenarios/openshift/zone_outage.yaml
-        - pvc_scenarios:
+        -   application_outages:
+            - scenarios/openshift/app_outage.yaml
+        -   pvc_scenarios:
             - scenarios/openshift/pvc_scenario.yaml
-        - network_chaos:
+        -   network_chaos:
             - scenarios/openshift/network_chaos.yaml
 
 cerberus:
@@ -51,43 +53,17 @@ cerberus:
 performance_monitoring:
     deploy_dashboards: False                              # Install a mutable grafana and load the performance dashboards. Enable this only when running on OpenShift
     repo: "https://github.com/cloud-bulldozer/performance-dashboards.git"
+    kube_burner_binary_url: "https://github.com/cloud-bulldozer/kube-burner/releases/download/v0.9.1/kube-burner-0.9.1-Linux-x86_64.tar.gz"
     capture_metrics: False
+    config_path: config/kube_burner.yaml                  # Define the Elasticsearch url and index name in this config
     metrics_profile_path: config/metrics-aggregated.yaml
     prometheus_url:                                       # The prometheus url/route is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes.
     prometheus_bearer_token:                              # The bearer token is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes. This is needed to authenticate with prometheus.
     uuid:                                                 # uuid for the run is generated by default if not set
     enable_alerts: False                                  # Runs the queries specified in the alert profile and displays the info or exits 1 when severity=error
-    alert_profile: config/alerts.yaml                          # Path or URL to alert profile with the prometheus queries
-    check_critical_alerts: False                          # When enabled will check prometheus for critical alerts firing post chaos
+    alert_profile: config/alerts                          # Path to alert profile with the prometheus queries
+
 tunings:
     wait_duration: 60                                      # Duration to wait between each chaos scenario
     iterations: 1                                          # Number of times to execute the scenarios
     daemon_mode: False                                     # Iterations are set to infinity which means that the kraken will cause chaos forever
-telemetry:
-    enabled: False                                           # enable/disables the telemetry collection feature
-    api_url: https://ulnmf9xv7j.execute-api.us-west-2.amazonaws.com/production #telemetry service endpoint
-    username: username                                      # telemetry service username
-    password: password                                      # telemetry service password
-    prometheus_backup: True                                 # enables/disables prometheus data collection
-    full_prometheus_backup: False                           # if is set to False only the /prometheus/wal folder will be downloaded.
-    backup_threads: 5                                       # number of telemetry download/upload threads
-    archive_path: /tmp                                      # local path where the archive files will be temporarly stored
-    max_retries: 0                                          # maximum number of upload retries (if 0 will retry forever)
-    run_tag: ''                                             # if set, this will be appended to the run folder in the bucket (useful to group the runs)
-    archive_size: 500000                                     # the size of the prometheus data archive size in KB. The lower the size of archive is
-                                                            # the higher the number of archive files will be produced and uploaded (and processed by backup_threads
-                                                            # simultaneously).
-                                                            # For unstable/slow connection is better to keep this value low
-                                                            # increasing the number of backup_threads, in this way, on upload failure, the retry will happen only on the
-                                                            # failed chunk without affecting the whole upload.
-    logs_backup: True
-    logs_filter_patterns:
-     - "(\\w{3}\\s\\d{1,2}\\s\\d{2}:\\d{2}:\\d{2}\\.\\d+).+"         # Sep 9 11:20:36.123425532
-     - "kinit (\\d+/\\d+/\\d+\\s\\d{2}:\\d{2}:\\d{2})\\s+"          # kinit 2023/09/15 11:20:36 log
-     - "(\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}\\.\\d+Z).+"      # 2023-09-15T11:20:36.123425532Z log
-    oc_cli_path: /usr/bin/oc                                # optional, if not specified will be search in $PATH
-    events_backup: True                                     # enables/disables cluster events collection
-
-
-
-

config/config_kind.yaml

@@ -1,34 +0,0 @@
-kraken:
-    distribution: kubernetes                               # Distribution can be kubernetes or openshift
-    kubeconfig_path: ~/.kube/config                        # Path to kubeconfig
-    exit_on_failure: False                                 # Exit when a post action scenario fails
-    port: 8081
-    publish_kraken_status: True                            # Can be accessed at http://0.0.0.0:8081
-    signal_state: RUN                                      # Will wait for the RUN signal when set to PAUSE before running the scenarios, refer docs/signal.md for more details
-    signal_address: 0.0.0.0                                # Signal listening address
-   chaos_scenarios:                                       # List of policies/chaos scenarios to load
-        - plugin_scenarios:
-            - scenarios/kind/scheduler.yml
-        - node_scenarios:
-            - scenarios/kind/node_scenarios_example.yml        
-
-cerberus:
-    cerberus_enabled: False                                # Enable it when cerberus is previously installed
-    cerberus_url:                                          # When cerberus_enabled is set to True, provide the url where cerberus publishes go/no-go signal
-    check_applicaton_routes: False                         # When enabled will look for application unavailability using the routes specified in the cerberus config and fails the run
-
-performance_monitoring:
-    deploy_dashboards: False                              # Install a mutable grafana and load the performance dashboards. Enable this only when running on OpenShift
-    repo: "https://github.com/cloud-bulldozer/performance-dashboards.git"
-    capture_metrics: False
-    metrics_profile_path: config/metrics-aggregated.yaml
-    prometheus_url:                                       # The prometheus url/route is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes.
-    prometheus_bearer_token:                              # The bearer token is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes. This is needed to authenticate with prometheus.
-    uuid:                                                 # uuid for the run is generated by default if not set
-    enable_alerts: False                                  # Runs the queries specified in the alert profile and displays the info or exits 1 when severity=error
-    alert_profile: config/alerts.yaml                          # Path to alert profile with the prometheus queries
-
-tunings:
-    wait_duration: 60                                      # Duration to wait between each chaos scenario
-    iterations: 1                                          # Number of times to execute the scenarios
-    daemon_mode: False                                     # Iterations are set to infinity which means that the kraken will cause chaos forever

config/config_kubernetes.yaml

@@ -1,15 +1,18 @@
 kraken:
-    distribution: kubernetes                               # Distribution can be kubernetes or openshift
-    kubeconfig_path: ~/.kube/config                        # Path to kubeconfig
+    distribution: kubernetes                                # Distribution can be kubernetes or openshift
+    kubeconfig_path: /root/.kube/config                    # Path to kubeconfig
     exit_on_failure: False                                 # Exit when a post action scenario fails
     port: 8081
     publish_kraken_status: True                            # Can be accessed at http://0.0.0.0:8081
     signal_state: RUN                                      # Will wait for the RUN signal when set to PAUSE before running the scenarios, refer docs/signal.md for more details
+    litmus_version: v1.13.6                                # Litmus version to install
+    litmus_uninstall: False                                # If you want to uninstall litmus if failure
+    litmus_uninstall_before_run: True                      # If you want to uninstall litmus before a new run starts
     chaos_scenarios:                                       # List of policies/chaos scenarios to load
         -   container_scenarios:                                 # List of chaos pod scenarios to load
             - -    scenarios/kube/container_dns.yml
-        -   plugin_scenarios:
-            - scenarios/kube/scheduler.yml
+        -   pod_scenarios:
+            - -    scenarios/kube/scheduler.yml
 
 cerberus:
     cerberus_enabled: False                                # Enable it when cerberus is previously installed
@@ -19,14 +22,16 @@ cerberus:
 performance_monitoring:
     deploy_dashboards: False                              # Install a mutable grafana and load the performance dashboards. Enable this only when running on OpenShift
     repo: "https://github.com/cloud-bulldozer/performance-dashboards.git"
+    kube_burner_binary_url: "https://github.com/cloud-bulldozer/kube-burner/releases/download/v0.9.1/kube-burner-0.9.1-Linux-x86_64.tar.gz"
     capture_metrics: False
+    config_path: config/kube_burner.yaml                  # Define the Elasticsearch url and index name in this config
     metrics_profile_path: config/metrics-aggregated.yaml
     prometheus_url:                                       # The prometheus url/route is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes.
     prometheus_bearer_token:                              # The bearer token is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes. This is needed to authenticate with prometheus.
     uuid:                                                 # uuid for the run is generated by default if not set
     enable_alerts: False                                  # Runs the queries specified in the alert profile and displays the info or exits 1 when severity=error
-    alert_profile: config/alerts.yaml                         # Path to alert profile with the prometheus queries
-    check_critical_alerts: False                          # When enabled will check prometheus for critical alerts firing post chaos after soak time for the cluster to settle down
+    alert_profile: config/alerts                          # Path to alert profile with the prometheus queries
+
 tunings:
     wait_duration: 60                                      # Duration to wait between each chaos scenario
     iterations: 1                                          # Number of times to execute the scenarios

config/config_performance.yaml

@@ -1,27 +1,32 @@
 kraken:
     distribution: openshift                                # Distribution can be kubernetes or openshift
-    kubeconfig_path: ~/.kube/config                        # Path to kubeconfig
+    kubeconfig_path: /root/.kube/config                    # Path to kubeconfig
     exit_on_failure: False                                 # Exit when a post action scenario fails
+    port: 8081
     publish_kraken_status: True                            # Can be accessed at http://0.0.0.0:8081
     signal_state: RUN                                      # Will wait for the RUN signal when set to PAUSE before running the scenarios, refer docs/signal.md for more details
-    signal_address: 0.0.0.0                                # Signal listening address
-    port: 8081                                             # Signal port
+    litmus_version: v1.13.6                                # Litmus version to install
+    litmus_uninstall: False                                # If you want to uninstall litmus if failure
+    litmus_uninstall_before_run: True                      # If you want to uninstall litmus before a new run starts
     chaos_scenarios:                                       # List of policies/chaos scenarios to load
-        -   plugin_scenarios:                                 # List of chaos pod scenarios to load
-            - scenarios/openshift/etcd.yml
-            - scenarios/openshift/regex_openshift_pod_kill.yml
-            - scenarios/openshift/prom_kill.yml
+        -   pod_scenarios:                                 # List of chaos pod scenarios to load
+            - -    scenarios/openshift/etcd.yml
+            - -    scenarios/openshift/regex_openshift_pod_kill.yml
+              -    scenarios/openshift/post_action_regex.py
         -   node_scenarios:                                # List of chaos node scenarios to load
             -   scenarios/openshift/node_scenarios_example.yml
-        -   plugin_scenarios:
-            - scenarios/openshift/openshift-apiserver.yml
-            - scenarios/openshift/openshift-kube-apiserver.yml
+        -   pod_scenarios:
+            - -    scenarios/openshift/openshift-apiserver.yml
+            - -    scenarios/openshift/openshift-kube-apiserver.yml
         -   time_scenarios:                                # List of chaos time scenarios to load
             - scenarios/openshift/time_scenarios_example.yml
+        -   litmus_scenarios:                              # List of litmus scenarios to load
+            - - https://hub.litmuschaos.io/api/chaos/1.10.0?file=charts/generic/node-cpu-hog/rbac.yaml
+              - scenarios/openshift/node_cpu_hog_engine.yaml
         -   cluster_shut_down_scenarios:
             - - scenarios/openshift/cluster_shut_down_scenario.yml
               - scenarios/openshift/post_action_shut_down.py
-        -   service_disruption_scenarios:
+        -   namespace_scenarios:
             - scenarios/openshift/regex_namespace.yaml
             - scenarios/openshift/ingress_namespace.yaml
         -   zone_outages:
@@ -41,39 +46,17 @@ cerberus:
 performance_monitoring:
     deploy_dashboards: True                               # Install a mutable grafana and load the performance dashboards. Enable this only when running on OpenShift
     repo: "https://github.com/cloud-bulldozer/performance-dashboards.git"
+    kube_burner_binary_url: "https://github.com/cloud-bulldozer/kube-burner/releases/download/v0.9.1/kube-burner-0.9.1-Linux-x86_64.tar.gz"
     capture_metrics: True
+    config_path: config/kube_burner.yaml                  # Define the Elasticsearch url and index name in this config
     metrics_profile_path: config/metrics-aggregated.yaml
     prometheus_url:                                       # The prometheus url/route is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes.
     prometheus_bearer_token:                              # The bearer token is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes. This is needed to authenticate with prometheus.
     uuid:                                                 # uuid for the run is generated by default if not set
     enable_alerts: True                                   # Runs the queries specified in the alert profile and displays the info or exits 1 when severity=error
-    alert_profile: config/alerts.yaml                          # Path to alert profile with the prometheus queries
+    alert_profile: config/alerts                          # Path to alert profile with the prometheus queries
 
 tunings:
     wait_duration: 60                                      # Duration to wait between each chaos scenario
     iterations: 1                                          # Number of times to execute the scenarios
     daemon_mode: False                                     # Iterations are set to infinity which means that the kraken will cause chaos forever
-
-telemetry:
-    enabled: False                                           # enable/disables the telemetry collection feature
-    api_url: https://ulnmf9xv7j.execute-api.us-west-2.amazonaws.com/production #telemetry service endpoint
-    username: username                                      # telemetry service username
-    password: password                                      # telemetry service password
-    prometheus_backup: True                                 # enables/disables prometheus data collection
-    full_prometheus_backup: False                           # if is set to False only the /prometheus/wal folder will be downloaded.
-    backup_threads: 5                                       # number of telemetry download/upload threads
-    archive_path: /tmp                                      # local path where the archive files will be temporarly stored
-    max_retries: 0                                          # maximum number of upload retries (if 0 will retry forever)
-    run_tag: ''                                             # if set, this will be appended to the run folder in the bucket (useful to group the runs)
-    archive_size: 500000                                     # the size of the prometheus data archive size in KB. The lower the size of archive is
-                                                            # the higher the number of archive files will be produced and uploaded (and processed by backup_threads
-                                                            # simultaneously).
-                                                            # For unstable/slow connection is better to keep this value low
-                                                            # increasing the number of backup_threads, in this way, on upload failure, the retry will happen only on the
-                                                            # failed chunk without affecting the whole upload.
-    logs_backup: True
-    logs_filter_patterns:
-     - "(\\w{3}\\s\\d{1,2}\\s\\d{2}:\\d{2}:\\d{2}\\.\\d+).+"         # Sep 9 11:20:36.123425532
-     - "kinit (\\d+/\\d+/\\d+\\s\\d{2}:\\d{2}:\\d{2})\\s+"          # kinit 2023/09/15 11:20:36 log
-     - "(\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}\\.\\d+Z).+"      # 2023-09-15T11:20:36.123425532Z log
-    oc_cli_path: /usr/bin/oc                                # optional, if not specified will be search in $PATH

config/kube_burner.yaml

@@ -0,0 +1,15 @@
+---
+
+global:
+  writeToFile: true
+  metricsDirectory: collected-metrics
+  measurements:
+    - name: podLatency
+      esIndex: kraken
+
+  indexerConfig:
+    enabled: true
+    esServers: [http://0.0.0.0:9200]  # Please change this to the respective Elasticsearch in use if you haven't run the podman-compose command to setup the infrastructure containers
+    insecureSkipVerify: true
+    defaultIndex: kraken
+    type: elastic

config/metrics-aggregated.yaml

@@ -139,39 +139,6 @@ metrics:
   - query: histogram_quantile(0.99,sum(rate(etcd_request_duration_seconds_bucket[2m])) by (le,operation,apiserver)) > 0
     metricName: P99APIEtcdRequestLatency
 
-  - query: sum(grpc_server_started_total{namespace="openshift-etcd",grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"}) - sum(grpc_server_handled_total{namespace="openshift-etcd",grpc_service="etcdserverpb.Watch",grpc_type="bidi_stream"})
-    metricName: ActiveWatchStreams
-
-  - query: sum(grpc_server_started_total{namespace="openshift-etcd",grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"}) - sum(grpc_server_handled_total{namespace="openshift-etcd",grpc_service="etcdserverpb.Lease",grpc_type="bidi_stream"})
-    metricName: ActiveLeaseStreams
-
-  - query: sum(rate(etcd_debugging_snap_save_total_duration_seconds_sum{namespace="openshift-etcd"}[2m]))
-    metricName: snapshotSaveLatency
-
-  - query: sum(rate(etcd_server_heartbeat_send_failures_total{namespace="openshift-etcd"}[2m]))
-    metricName: HeartBeatFailures
-
-  - query: sum(rate(etcd_server_health_failures{namespace="openshift-etcd"}[2m]))
-    metricName: HealthFailures
-
-  - query: sum(rate(etcd_server_slow_apply_total{namespace="openshift-etcd"}[2m]))
-    metricName: SlowApplies
-
-  - query: sum(rate(etcd_server_slow_read_indexes_total{namespace="openshift-etcd"}[2m]))
-    metricName: SlowIndexRead
-
-  - query: sum(etcd_server_proposals_pending)
-    metricName: PendingProposals
-
-  - query: histogram_quantile(1.0, sum(rate(etcd_debugging_mvcc_db_compaction_pause_duration_milliseconds_bucket[1m])) by (le, instance))
-    metricName: CompactionMaxPause
-
-  - query: sum by (instance) (apiserver_storage_objects)
-    metricName: etcdTotalObjectCount 
-
-  - query: topk(500, max by(resource) (apiserver_storage_objects))
-    metricName: etcdTopObectCount    
-
 # Cluster metrics
   - query: count(kube_namespace_created)
     metricName: namespaceCount

config/recommender_config.yaml

@@ -1,29 +0,0 @@
-application: openshift-etcd
-namespace: openshift-etcd
-labels: app=openshift-etcd
-kubeconfig: ~/.kube/config.yaml
-prometheus_endpoint: <Prometheus_Endpoint>
-auth_token: <Auth_Token>
-scrape_duration: 10m
-chaos_library: "kraken"
-log_level: INFO
-
-# for output purpose only do not change if not needed
-chaos_tests:
-  GENERIC:
-    - pod_failure
-    - container_failure
-    - node_failure
-    - zone_outage
-    - time_skew
-    - namespace_failure
-    - power_outage
-  CPU:
-    - node_cpu_hog
-  NETWORK:
-    - application_outage
-    - node_network_chaos
-    - pod_network_chaos
-  MEM:
-    - node_memory_hog
-    - pvc_disk_fill

containers/Dockerfile

@@ -1,30 +1,28 @@
 # Dockerfile for kraken
 
-FROM mcr.microsoft.com/azure-cli:latest as azure-cli
+FROM quay.io/openshift/origin-tests:latest as origintests
 
-FROM registry.access.redhat.com/ubi8/ubi:latest
+FROM quay.io/centos/centos:stream9
 
 LABEL org.opencontainers.image.authors="Red Hat OpenShift Chaos Engineering"
 
 ENV KUBECONFIG /root/.kube/config
 
-# Copy azure client binary from azure-cli image
-COPY --from=azure-cli /usr/local/bin/az /usr/bin/az
+# Copy OpenShift CLI, Kubernetes CLI from origin-tests image
+COPY --from=origintests /usr/bin/oc /usr/bin/oc
+COPY --from=origintests /usr/bin/kubectl /usr/bin/kubectl
 
 # Install dependencies
-RUN yum install -y git python39 python3-pip jq gettext wget && \
-    python3.9 -m pip install -U pip && \
-    git clone https://github.com/redhat-chaos/krkn.git --branch v1.5.3 /root/kraken && \
+RUN yum install epel-release -y && \
+    yum install -y git python python3-pip jq gettext && \
+    python3 -m pip install -U pip && \
+    rpm --import https://packages.microsoft.com/keys/microsoft.asc && \
+    echo -e "[azure-cli]\nname=Azure CLI\nbaseurl=https://packages.microsoft.com/yumrepos/azure-cli\nenabled=1\ngpgcheck=1\ngpgkey=https://packages.microsoft.com/keys/microsoft.asc" > /etc/yum.repos.d/azure-cli.repo && yum install -y azure-cli && \
+    git clone https://github.com/openshift-scale/kraken /root/kraken && \
     mkdir -p /root/.kube && cd /root/kraken && \
-    pip3.9 install -r requirements.txt && \
-    pip3.9 install virtualenv && \
-    wget https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64 -O /usr/bin/yq && chmod +x /usr/bin/yq
-
-# Get Kubernetes and OpenShift clients from stable releases
-WORKDIR /tmp
-RUN wget https://mirror.openshift.com/pub/openshift-v4/clients/ocp/stable/openshift-client-linux.tar.gz && tar -xvf openshift-client-linux.tar.gz && cp oc /usr/local/bin/oc && cp kubectl /usr/local/bin/kubectl
+    pip3 install -r requirements.txt
 
 WORKDIR /root/kraken
 
-ENTRYPOINT ["python3.9", "run_kraken.py"]
+ENTRYPOINT ["python3", "run_kraken.py"]
 CMD ["--config=config/config.yaml"]

containers/Dockerfile-ppc64le

@@ -2,28 +2,24 @@
 
 FROM ppc64le/centos:8
 
-FROM mcr.microsoft.com/azure-cli:latest as azure-cli
-
-LABEL org.opencontainers.image.authors="Red Hat OpenShift Chaos Engineering"
+MAINTAINER Red Hat OpenShift Performance and Scale
 
 ENV KUBECONFIG /root/.kube/config
 
-# Copy azure client binary from azure-cli image
-COPY --from=azure-cli /usr/local/bin/az /usr/bin/az
+RUN curl -L -o kubernetes-client-linux-ppc64le.tar.gz https://dl.k8s.io/v1.19.0/kubernetes-client-linux-ppc64le.tar.gz \
+&& tar xf kubernetes-client-linux-ppc64le.tar.gz && mv kubernetes/client/bin/kubectl /usr/bin/ && rm -rf kubernetes-client-linux-ppc64le.tar.gz
+
+RUN curl -L -o openshift-client-linux.tar.gz https://mirror.openshift.com/pub/openshift-v4/ppc64le/clients/ocp/stable/openshift-client-linux.tar.gz \
+&& tar xf openshift-client-linux.tar.gz -C /usr/bin && rm -rf openshift-client-linux.tar.gz
 
 # Install dependencies
-RUN yum install -y git python39 python3-pip jq gettext wget && \
-    python3.9 -m pip install -U pip && \
-    git clone https://github.com/redhat-chaos/krkn.git --branch v1.5.3 /root/kraken && \
-    mkdir -p /root/.kube && cd /root/kraken && \
-    pip3.9 install -r requirements.txt && \
-    pip3.9 install virtualenv && \
-    wget https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64 -O /usr/bin/yq && chmod +x /usr/bin/yq
-
-# Get Kubernetes and OpenShift clients from stable releases
-WORKDIR /tmp
-RUN wget https://mirror.openshift.com/pub/openshift-v4/clients/ocp/stable/openshift-client-linux.tar.gz && tar -xvf openshift-client-linux.tar.gz && cp oc /usr/local/bin/oc && cp kubectl /usr/local/bin/kubectl
+RUN yum install epel-release -y && \
+yum install -y git python36 python3-pip gcc libffi-devel python36-devel openssl-devel gcc-c++ make jq gettext && \
+git clone https://github.com/cloud-bulldozer/kraken /root/kraken && \
+mkdir -p /root/.kube && cd /root/kraken && \
+pip3 install cryptography==3.3.2 && \
+pip3 install -r requirements.txt setuptools==40.3.0 urllib3==1.25.4
 
 WORKDIR /root/kraken
 
-ENTRYPOINT python3.9 run_kraken.py --config=config/config.yaml
+ENTRYPOINT python3 run_kraken.py --config=config/config.yaml

containers/README.md

@@ -1,46 +1,28 @@
-
 ### Kraken image
 
-Container image gets automatically built by quay.io at [Kraken image](https://quay.io/redhat-chaos/krkn).
-
+Container image gets automatically built by quay.io at [Kraken image](https://quay.io/chaos-kubox/krkn).
 
 ### Run containerized version
-
-Refer [instructions](https://github.com/redhat-chaos/krkn/blob/main/docs/installation.md#run-containerized-version) for information on how to run the containerized version of kraken.
+Refer [instructions](https://github.com/chaos-kubox/krkn/blob/main/docs/installation.md#run-containerized-version) for information on how to run the containerized version of kraken.
 
 
 ### Run Custom Kraken Image
-
-Refer to [instructions](https://github.com/redhat-chaos/krkn/blob/main/containers/build_own_image-README.md) for information on how to run a custom containerized version of kraken using podman.
+Refer to [instructions](https://github.com/chaos-kubox/krkn/blob/main/containers/build_own_image-README.md) for information on how to run a custom containerized version of kraken using podman.
 
 
-### Kraken as a KubeApp ( Unsupported and not recommended )
-
-#### GENERAL NOTES:
-
-- It is not generally recommended to run Kraken internal to the cluster as the pod which is running Kraken might get disrupted, the suggested use case to run kraken from inside k8s/OpenShift is to target **another** cluster (eg. to bypass network restrictions or to leverage cluster's computational resources)
-
-- your kubeconfig might contain several cluster contexts and credentials so be sure, before creating the ConfigMap, to keep **only** the credentials related to the destination cluster. Please refer to the [Kubernetes documentation](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) for more details
-- to add privileges to the service account you must be logged in the cluster with an highly privileged account (ideally kubeadmin)
-
-  
+### Kraken as a KubeApp
 
 To run containerized Kraken as a Kubernetes/OpenShift Deployment, follow these steps:
-
-1. Configure the [config.yaml](https://github.com/redhat-chaos/krkn/blob/main/config/config.yaml) file according to your requirements.
-
-**NOTE**: both the scenarios ConfigMaps are needed regardless you're running kraken in Kubernetes or OpenShift
-
+1. Configure the [config.yaml](https://github.com/chaos-kubox/krkn/blob/main/config/config.yaml) file according to your requirements.
 2. Create a namespace under which you want to run the kraken pod using `kubectl create ns <namespace>`.
 3. Switch to `<namespace>` namespace:
-- In Kubernetes, use `kubectl config set-context --current --namespace=<namespace>`
-- In OpenShift, use `oc project <namespace>`
-  
-4. Create a ConfigMap named kube-config using `kubectl create configmap kube-config --from-file=<path_to_kubeconfig>`  *(eg. ~/.kube/config)*
-5. Create a ConfigMap named kraken-config using `kubectl create configmap kraken-config --from-file=<path_to_kraken>/config`
-6. Create a ConfigMap named scenarios-config using `kubectl create configmap scenarios-config --from-file=<path_to_kraken>/scenarios`
-7. Create a ConfigMap named scenarios-openshift-config using `kubectl create configmap scenarios-openshift-config --from-file=<path_to_kraken>/scenarios/openshift`
-8. Create a ConfigMap named scenarios-kube-config using `kubectl create configmap scenarios-kube-config --from-file=<path_to_kraken>/scenarios/kube` 
-9. Create a service account to run the kraken pod `kubectl create serviceaccount useroot`.
-10.  In Openshift, add privileges to service account and execute `oc adm policy add-scc-to-user privileged -z useroot`.
-11.  Create a Job using `kubectl apply -f <path_to_kraken>/containers/kraken.yml` and monitor the status using `oc get jobs` and `oc get pods`.
+    - In Kubernetes, use `kubectl config set-context --current --namespace=<namespace>`
+    - In OpenShift, use `oc project <namespace>`
+4. Create a ConfigMap named kube-config using `kubectl create configmap kube-config --from-file=<path_to_kubeconfig>`
+5. Create a ConfigMap named kraken-config using `kubectl create configmap kraken-config --from-file=<path_to_kraken_config>`
+6. Create a ConfigMap named scenarios-config using `kubectl create configmap scenarios-config --from-file=<path_to_scenarios_folder>`
+7. Create a service account to run the kraken pod `kubectl create serviceaccount useroot`.
+8. In Openshift, add privileges to service account and execute `oc adm policy add-scc-to-user privileged -z useroot`.
+9. Create a Job using `kubectl apply -f kraken.yml` and monitor the status using `oc get jobs` and `oc get pods`.
+
+NOTE: It is not recommended to run Kraken internal to the cluster as the pod which is running Kraken might get disrupted.

containers/build_own_image-README.md

@@ -1,13 +1,13 @@
 # Building your own Kraken image
 
-1. Git clone the Kraken repository using `git clone https://github.com/redhat-chaos/krkn.git`.
+1. Git clone the Kraken repository using `git clone https://github.com/openshift-scale/kraken.git`.
 2. Modify the python code and yaml files to address your needs.
 3. Execute `podman build -t <new_image_name>:latest .` in the containers directory within kraken to build an image from a Dockerfile.
 4. Execute `podman run --detach --name <container_name> <new_image_name>:latest` to start a container based on your new image.
 
 # Building the Kraken image on IBM Power (ppc64le)
 
-1. Git clone the Kraken repository using `git clone https://github.com/redhat-chaos/krkn.git` on an IBM Power Systems server.
+1. Git clone the Kraken repository using `git clone https://github.com/cloud-bulldozer/kraken.git` on an IBM Power Systems server.
 2. Modify the python code and yaml files to address your needs.
 3. Execute `podman build -t <new_image_name>:latest -f Dockerfile-ppc64le` in the containers directory within kraken to build an image from the Dockerfile for Power.
 4. Execute `podman run --detach --name <container_name> <new_image_name>:latest` to start a container based on your new image.

containers/kraken.yml

@@ -16,9 +16,9 @@ spec:
         - name: kraken
           securityContext:
             privileged: true
-          image: quay.io/redhat-chaos/krkn
+          image: quay.io/chaos-kubox/krkn
           command: ["/bin/sh", "-c"]
-          args: ["python3.9 run_kraken.py -c config/config.yaml"]
+          args: ["python3 run_kraken.py -c config/config.yaml"]
           volumeMounts:
             - mountPath: "/root/.kube"
               name: config
@@ -26,10 +26,6 @@ spec:
               name: kraken-config
             - mountPath: "/root/kraken/scenarios"
               name: scenarios-config
-            - mountPath: "/root/kraken/scenarios/openshift"
-              name: scenarios-openshift-config
-            - mountPath: "/root/kraken/scenarios/kube"
-              name: scenarios-kube-config
       restartPolicy: Never
       volumes:
         - name: config
@@ -41,9 +37,3 @@ spec:
         - name: scenarios-config
           configMap:
             name: scenarios-config
-        - name: scenarios-openshift-config
-          configMap:
-            name: scenarios-openshift-config
-        - name: scenarios-kube-config
-          configMap:
-            name: scenarios-kube-config

docs/alerts.md

@@ -1,28 +1,18 @@
-## SLOs validation
+## Alerts
 
-Pass/fail based on metrics captured from the cluster is important in addition to checking the health status and recovery. Kraken supports:
-
-###  Checking for critical alerts post chaos 
-If enabled, the check runs at the end of each scenario ( post chaos ) and Kraken exits in case critical alerts are firing to allow user to debug. You can enable it in the config:
-
-```
-performance_monitoring:
-    check_critical_alerts: False                          # When enabled will check prometheus for critical alerts firing post chaos
-```
-
-### Validation and alerting based on the queries defined by the user during chaos
-Takes PromQL queries as input and modifies the return code of the run to determine pass/fail. It's especially useful in case of automated runs in CI where user won't be able to monitor the system. This feature can be enabled in the [config](https://github.com/redhat-chaos/krkn/blob/main/config/config.yaml) by setting the following:
+Pass/fail based on metrics captured from the cluster is important in addition to checking the health status and recovery. Kraken supports alerting based on the queries defined by the user and modifies the return code of the run to determine pass/fail. It's especially useful in case of automated runs in CI where user won't be able to monitor the system. It uses [Kube-burner](https://kube-burner.readthedocs.io/en/latest/) under the hood. This feature can be enabled in the [config](https://github.com/chaos-kubox/krkn/blob/main/config/config.yaml) by setting the following:
 
 ```
 performance_monitoring:
+    kube_burner_binary_url: "https://github.com/cloud-bulldozer/kube-burner/releases/download/v0.9.1/kube-burner-0.9.1-Linux-x86_64.tar.gz"
     prometheus_url:                                       # The prometheus url/route is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes.
     prometheus_bearer_token:                              # The bearer token is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes. This is needed to authenticate with prometheus.
     enable_alerts: True                                   # Runs the queries specified in the alert profile and displays the info or exits 1 when severity=error.
-    alert_profile: config/alerts.yaml                          # Path to alert profile with the prometheus queries.
+    alert_profile: config/alerts                          # Path to alert profile with the prometheus queries.
 ```
 
-#### Alert profile
-A couple of [alert profiles](https://github.com/redhat-chaos/krkn/tree/main/config) [alerts](https://github.com/redhat-chaos/krkn/blob/main/config/alerts.yaml) are shipped by default and can be tweaked to add more queries to alert on. User can provide a URL or path to the file in the [config](https://github.com/redhat-chaos/krkn/blob/main/config/config.yaml). The following are a few alerts examples:
+### Alert profile
+A couple of [alert profiles](https://github.com/chaos-kubox/krkn/tree/main/config) [alerts](https://github.com/chaos-kubox/krkn/blob/main/config/alerts) are shipped by default and can be tweaked to add more queries to alert on. The following are a few alerts examples:
 
 ```
 - expr: avg_over_time(histogram_quantile(0.99, rate(etcd_disk_wal_fsync_duration_seconds_bucket[2m]))[5m:]) > 0.01

docs/arcaflow_scenarios.md

@@ -1,70 +0,0 @@
-## Arcaflow Scenarios
-Arcaflow is a workflow engine in development which provides the ability to execute workflow steps in sequence, in parallel, repeatedly, etc. The main difference to competitors such as Netflix Conductor is the ability to run ad-hoc workflows without an infrastructure setup required.
-
-The engine uses containers to execute plugins and runs them either locally in Docker/Podman or remotely on a Kubernetes cluster. The workflow system is strongly typed and allows for generating JSON schema and OpenAPI documents for all data formats involved.
-
-### Available Scenarios
-#### Hog scenarios:
-- [CPU Hog](arcaflow_scenarios/cpu_hog.md)
-- [Memory Hog](arcaflow_scenarios/memory_hog.md)
-- [I/O Hog](arcaflow_scenarios/io_hog.md)
-
-
-### Prequisites
-Arcaflow supports three deployment technologies:
-- Docker
-- Podman
-- Kubernetes
-
-#### Docker
-In order to run Arcaflow Scenarios with the Docker deployer, be sure that:
-- Docker is correctly installed in your Operating System (to find instructions on how to install docker please refer to [Docker Documentation](https://www.docker.com/))
-- The Docker daemon is running
-
-#### Podman
-The podman deployer is built around the podman CLI and doesn't need necessarily to be run along with the podman daemon.
-To run Arcaflow Scenarios in your Operating system be sure that:
-- podman is correctly installed in your Operating System (to find instructions on how to install podman refer to [Podman Documentation](https://podman.io/))
-- the podman CLI is in your shell PATH
-
-#### Kubernetes
-The kubernetes deployer integrates directly the Kubernetes API Client and needs only a valid kubeconfig file and a reachable Kubernetes/OpenShift Cluster.
-
-### Usage
-
-To enable arcaflow scenarios edit the kraken config file, go to the section `kraken -> chaos_scenarios` of the yaml structure
-and add a new element to the list named `arcaflow_scenarios` then add the desired scenario
-pointing to the `input.yaml` file.
-```
-kraken:
-    ...
-    chaos_scenarios:
-        - arcaflow_scenarios:
-            - scenarios/arcaflow/cpu-hog/input.yaml
-```
-
-#### input.yaml
-The implemented scenarios can be found in *scenarios/arcaflow/<scenario_name>* folder.
-The entrypoint of each scenario is the *input.yaml* file. 
-In this file there are all the options to set up the scenario accordingly to the desired target 
-### config.yaml
-The arcaflow config file. Here you can set the arcaflow deployer and the arcaflow log level.
-The supported deployers are:
-- Docker
-- Podman (podman daemon not needed, suggested option)
-- Kubernetes
-
-The supported log levels are:
-- debug
-- info
-- warning
-- error
-### workflow.yaml
-This file contains the steps that will be executed to perform the scenario against the target.
-Each step is represented by a container that will be executed from the deployer and its options.
-Note that we provide the scenarios as a template, but they can be manipulated to define more complex workflows.
-To have more details regarding the arcaflow workflows architecture and syntax it is suggested to refer to the [Arcaflow Documentation](https://arcalot.io/arcaflow/).
-
-This edit is no longer in quay image
-Working on fix in ticket: https://issues.redhat.com/browse/CHAOS-494
-This will effect all versions 4.12 and higher of OpenShift

docs/arcaflow_scenarios/cpu_hog.md

@@ -1,19 +0,0 @@
-# CPU Hog
-This scenario is based on the arcaflow [arcaflow-plugin-stressng](https://github.com/arcalot/arcaflow-plugin-stressng) plugin. 
-The purpose of this scenario is to create cpu pressure on a particular node of the Kubernetes/OpenShift cluster for a time span.
-To enable this plugin add the pointer to the scenario input file `scenarios/arcaflow/cpu-hog/input.yaml` as described in the 
-Usage section.
-This scenario takes a list of objects named `input_list` with the following properties:
-
-- **kubeconfig :** *string* the kubeconfig needed by the deployer to deploy the sysbench plugin in the target cluster
-- **namespace :** *string* the namespace where the scenario container will be deployed
-**Note:** this parameter will be automatically filled by kraken if the `kubeconfig_path` property is correctly set
-- **node_selector :** *key-value map* the node label that will be used as `nodeSelector` by the pod to target a specific cluster node
-- **duration :** *string* stop  stress  test  after  N  seconds.  One  can  also specify the units of time in seconds, minutes, hours, days or years with the suffix s, m, h, d or y.
-- **cpu_count :** *int* the number of CPU cores to be used (0 means all)
-- **cpu_method :** *string* a fine-grained control of which cpu stressors to use (ackermann, cfloat etc. see [manpage](https://manpages.org/sysbench) for all the cpu_method options)
-- **cpu_load_percentage :** *int* the CPU load by percentage
-
-To perform several load tests in the same run simultaneously (eg. stress two or more nodes in the same run) add another item
-to the `input_list` with the same properties (and eventually different values eg. different node_selectors 
-to schedule the pod on different nodes). To reduce (or increase) the parallelism change the value `parallelism` in `workload.yaml` file 

docs/arcaflow_scenarios/io_hog.md

@@ -1,21 +0,0 @@
-# I/O Hog
-This scenario is based on the arcaflow [arcaflow-plugin-stressng](https://github.com/arcalot/arcaflow-plugin-stressng) plugin. 
-The purpose of this scenario is to create disk pressure on a particular node of the Kubernetes/OpenShift cluster for a time span.
-The scenario allows to attach a node path to the pod as a `hostPath` volume.
-To enable this plugin add the pointer to the scenario input file `scenarios/arcaflow/io-hog/input.yaml` as described in the 
-Usage section.
-This scenario takes a list of objects named `input_list` with the following properties:
-
-- **kubeconfig :** *string* the kubeconfig needed by the deployer to deploy the sysbench plugin in the target cluster
-- **namespace :** *string* the namespace where the scenario container will be deployed
-**Note:** this parameter will be automatically filled by kraken if the `kubeconfig_path` property is correctly set
-- **node_selector :** *key-value map* the node label that will be used as `nodeSelector` by the pod to target a specific cluster node
-- **duration :** *string* stop  stress  test  after  N  seconds.  One  can  also specify the units of time in seconds, minutes, hours, days or years with the suffix s, m, h, d or y.
-- **target_pod_folder :** *string* the path in the pod where the volume is mounted
-- **target_pod_volume :** *object* the `hostPath` volume definition in the [Kubernetes/OpenShift](https://docs.openshift.com/container-platform/3.11/install_config/persistent_storage/using_hostpath.html) format, that will be attached to the pod as a volume
-- **io_write_bytes :** *string* writes N bytes for each hdd process. The size can be expressed as % of free space on the file system or in units of Bytes, KBytes, MBytes and GBytes using the suffix b, k, m or g
-- **io_block_size :** *string* size of each write in bytes. Size can be from 1 byte to 4m.
-
-To perform several load tests in the same run simultaneously (eg. stress two or more nodes in the same run) add another item
-to the `input_list` with the same properties (and eventually different values eg. different node_selectors 
-to schedule the pod on different nodes). To reduce (or increase) the parallelism change the value `parallelism` in `workload.yaml` file 

docs/arcaflow_scenarios/memory_hog.md

@@ -1,18 +0,0 @@
-# Memory Hog
-This scenario is based on the arcaflow [arcaflow-plugin-stressng](https://github.com/arcalot/arcaflow-plugin-stressng) plugin. 
-The purpose of this scenario is to create Virtual Memory pressure on a particular node of the Kubernetes/OpenShift cluster for a time span.
-To enable this plugin add the pointer to the scenario input file `scenarios/arcaflow/memory-hog/input.yaml` as described in the 
-Usage section.
-This scenario takes a list of objects named `input_list` with the following properties:
-
-- **kubeconfig :** *string* the kubeconfig needed by the deployer to deploy the sysbench plugin in the target cluster
-- **namespace :** *string* the namespace where the scenario container will be deployed
-**Note:** this parameter will be automatically filled by kraken if the `kubeconfig_path` property is correctly set
-- **node_selector :** *key-value map* the node label that will be used as `nodeSelector` by the pod to target a specific cluster node
-- **duration :** *string* stop  stress  test  after  N  seconds.  One  can  also specify the units of time in seconds, minutes, hours, days or years with the suffix s, m, h, d or y.
-- **vm_bytes :** *string* N bytes per vm process or percentage of memory used (using the % symbol). The size can be expressed in units of Bytes, KBytes, MBytes and GBytes using the suffix b, k, m or g.
-- **vm_workers :** *int* Number of VM stressors to be run (0 means 1 stressor per CPU)
-
-To perform several load tests in the same run simultaneously (eg. stress two or more nodes in the same run) add another item
-to the `input_list` with the same properties (and eventually different values eg. different node_selectors 
-to schedule the pod on different nodes). To reduce (or increase) the parallelism change the value `parallelism` in `workload.yaml` file 

docs/cloud_setup.md

@@ -1,12 +1,10 @@
 Supported Cloud Providers:
 
-- [AWS](#aws)
-- [GCP](#gcp)
-- [Openstack](#openstack)
-- [Azure](#azure)
-- [Alibaba](#alibaba)
-- [VMware](#vmware)
-- [IBMCloud](#ibmcloud)
+* [AWS](#aws)
+* [GCP](#gcp)
+* [Openstack](#openstack)
+* [Azure](#azure)
+* [Alibaba](#alibaba)
 
 ## AWS
 
@@ -55,35 +53,3 @@ See the [Installation guide](https://www.alibabacloud.com/help/en/alibaba-cloud-
 Refer to [region and zone page](https://www.alibabacloud.com/help/en/elastic-compute-service/latest/regions-and-zones#concept-2459516) to get the region id for the region you are running on.
 
 Set cloud_type to either alibaba or alicloud in your node scenario yaml file.
-
-## VMware
-
-Set the following environment variables
-
-1. ```export VSPHERE_IP=<vSphere_client_IP_address>```
-
-2. ```export VSPHERE_USERNAME=<vSphere_client_username>```
-
-3. ```export VSPHERE_PASSWORD=<vSphere_client_password>```
-
-These are the credentials that you would normally use to access the vSphere client.
-
-
-## IBMCloud
-If no api key is set up with proper VPC resource permissions, use the following to create: 
-* Access group
-* Service id with the following access
-  * With policy **VPC Infrastructure Services**
-  * Resources = All
-  * Roles: 
-    * Editor
-    * Administrator 
-    * Operator  
-    * Viewer
-* API Key
-
-Set the following environment variables
-
-1. ```export IBMC_URL=https://<region>.iaas.cloud.ibm.com/v1```
-
-2. ```export IBMC_APIKEY=<ibmcloud_api_key>```

docs/cluster_shut_down_scenarios.md

@@ -1,5 +1,5 @@
 #### Kubernetes/OpenShift cluster shut down scenario
-Scenario to shut down all the nodes including the masters and restart them after specified duration. Cluster shut down scenario can be injected by placing the shut_down config file under cluster_shut_down_scenario option in the kraken config. Refer to [cluster_shut_down_scenario](https://github.com/redhat-chaos/krkn/blob/main/scenarios/cluster_shut_down_scenario.yml) config file.
+Scenario to shut down all the nodes including the masters and restart them after specified duration. Cluster shut down scenario can be injected by placing the shut_down config file under cluster_shut_down_scenario option in the kraken config. Refer to [cluster_shut_down_scenario](https://github.com/chaos-kubox/krkn/blob/main/scenarios/cluster_shut_down_scenario.yml) config file.
 
 Refer to [cloud setup](cloud_setup.md) to configure your cli properly for the cloud provider of the cluster you want to shut down.
 

docs/config.md

@@ -1,65 +1,4 @@
 ### Config
-Set the scenarios to inject and the tunings like duration to wait between each scenario in the config file located at [config/config.yaml](https://github.com/redhat-chaos/krkn/blob/main/config/config.yaml).
-
-**NOTE**: [config](https://github.com/redhat-chaos/krkn/blob/main/config/config_performance.yaml) can be used if leveraging the [automated way](https://github.com/redhat-chaos/krkn#setting-up-infrastructure-dependencies) to install the infrastructure pieces.
-
-Config components: 
-* [Kraken](#kraken)
-* [Cerberus](#cerberus)
-* [Performance Monitoring](#performance-monitoring)
-* [Tunings](#tunings)
-
-# Kraken 
-This section defines scenarios and specific data to the chaos run 
-
-## Distribution
-Either **openshift** or **kubernetes** depending on the type of cluster you want to run chaos on. 
-The prometheus url/route and bearer token are automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes.
-
-## Exit on failure
-**exit_on_failure**:  Exit when a post action check or cerberus run fails
-
-## Publish kraken status
-**publish_kraken_status**: Can be accessed at http://0.0.0.0:8081 (or what signal_address and port you set in signal address section)
-**signal_state**: State you want kraken to start at; will wait for the RUN signal to start running a chaos iteration. When set to PAUSE before running the scenarios, refer to [signal.md](signal.md) for more details
-
-## Signal Address 
-**signal_address**: Address to listen/post the signal state to
-**port**: port to listen/post the signal state to
-
-## Chaos Scenarios 
-
-**chaos_scenarios**: List of different types of chaos scenarios you want to run with paths to their specific yaml file configurations
-
-If a scenario has a post action check script, it will be run before and after each scenario to validate the component under test starts and ends at the same state
-
-Currently the scenarios are run one after another (in sequence) and will exit if one of the scenarios fail, without moving onto the next one
-
-Chaos scenario types: 
-- container_scenarios     
-- plugin_scenarios
-- node_scenarios
-- time_scenarios
-- cluster_shut_down_scenarios
-- namespace_scenarios
-- zone_outages
-- application_outages
-- pvc_scenarios
-- network_chaos
-
-
-# Cerberus 
-Parameters to set for enabling of cerberus checks at the end of each executed scenario. The given url will pinged after the scenario and post action check have been completed for each scenario and iteration.
-**cerberus_enabled**: Enable it when cerberus is previously installed
-**cerberus_url**: When cerberus_enabled is set to True, provide the url where cerberus publishes go/no-go signal
-**check_applicaton_routes**:  When enabled will look for application unavailability using the routes specified in the cerberus config and fails the run
-
-
-# Performance Monitoring 
-There are 2 main sections defined in this part of the config [metrics](metrics.md) and [alerts](alerts.md); read more about each of these configurations in their respective docs 
-
-# Tunings
-**wait_duration**: Duration to wait between each chaos scenario
-**iterations**: Number of times to execute the scenarios
-**daemon_mode**: True or False; If true, iterations are set to infinity which means that the kraken will cause chaos forever and number of iterations is ignored
+Set the scenarios to inject and the tunings like duration to wait between each scenario in the config file located at [config/config.yaml](https://github.com/chaos-kubox/krkn/blob/main/config/config.yaml).
 
+**NOTE**: [config](https://github.com/chaos-kubox/krkn/blob/main/config/config_performance.yaml) can be used if leveraging the [automated way](https://github.com/chaos-kubox/krkn#setting-up-infrastructure-dependencies) to install the infrastructure pieces.

docs/container_scenarios.md

@@ -8,15 +8,13 @@ The following are the components of Kubernetes/OpenShift for which a basic chaos
 
 ```
 scenarios:
-- name: "<name of scenario>"
+- name: "<Name of scenario>"
   namespace: "<specific namespace>" # can specify "*" if you want to find in all namespaces
   label_selector: "<label of pod(s)>"
   container_name: "<specific container name>"  # This is optional, can take out and will kill all containers in all pods found under namespace and label
   pod_names:  # This is optional, can take out and will select all pods with given namespace and label
   - <pod_name>
-  count: <number of containers to disrupt, default=1>
-  action: <kill signal to run. For example 1 ( hang up ) or 9. Default is set to 1>
-  expected_recovery_time: <number of seconds to wait for container to be running again> (defaults to 120seconds)
+  retry_wait: <number of seconds to wait for container to be running again> (defaults to 120seconds)
 ```
 
 #### Post Action
@@ -25,7 +23,7 @@ In all scenarios we do a post chaos check to wait and verify the specific compon
 Here there are two options:
 1. Pass a custom script in the main config scenario list that will run before the chaos and verify the output matches post chaos scenario.
 
-See [scenarios/post_action_etcd_container.py](https://github.com/redhat-chaos/krkn/blob/main/scenarios/post_action_etcd_container.py) for an example.
+See [scenarios/post_action_etcd_container.py](https://github.com/chaos-kubox/krkn/blob/main/scenarios/post_action_etcd_container.py) for an example.
 ```
 -   container_scenarios:                                 # List of chaos pod scenarios to load.
             - -    scenarios/container_etcd.yml
@@ -36,5 +34,5 @@ See [scenarios/post_action_etcd_container.py](https://github.com/redhat-chaos/kr
 containers that were killed as well as the namespaces and pods to verify all containers that were affected recover properly.
 
 ```
-expected_recovery_time: <seconds to wait for container to recover>
+retry_wait: <seconds to wait for container to recover>
 ```

docs/contribute.md

@@ -62,7 +62,7 @@ If changes go into the main repository while you're working on your code it is b
 
 If not already configured, set the upstream url for kraken.
 ```
- git remote add upstream https://github.com/redhat-chaos/krkn.git
+ git remote add upstream https://github.com/cloud-bulldozer/kraken.git
 ```
 
 Rebase to upstream master branch.

docs/getting_started.md

@@ -1,26 +1,52 @@
 ## Getting Started Running Chaos Scenarios
 
 #### Adding New Scenarios
-Adding a new scenario is as simple as adding a new config file under [scenarios directory](https://github.com/redhat-chaos/krkn/tree/main/scenarios) and defining it in the main kraken [config](https://github.com/redhat-chaos/krkn/blob/main/config/config.yaml#L8).
+Adding a new scenario is as simple as adding a new config file under [scenarios directory](https://github.com/chaos-kubox/krkn/tree/main/scenarios) and defining it in the main kraken [config](https://github.com/chaos-kubox/krkn/blob/main/config/config.yaml#L8).
 You can either copy an existing yaml file and make it your own, or fill in one of the templates below to suit your needs.
 
 ### Templates
 #### Pod Scenario Yaml Template
 For example, for adding a pod level scenario for a new application, refer to the sample scenario below to know what fields are necessary and what to add in each location:
 ```
-# yaml-language-server: $schema=../plugin.schema.json
-- id: kill-pods
-  config:
-    namespace_pattern: ^<namespace>$
-    label_selector: <pod label>
-    kill: <number of pods to kill>
-- id: wait-for-pods
-  config:
-    namespace_pattern: ^<namespace>$
-    label_selector: <pod label>
-    count: <expected number of pods that match namespace and label>
+config:
+  runStrategy:
+    runs: <number of times to execute the scenario>
+    #This will choose a random number to wait between min and max
+    maxSecondsBetweenRuns: 30
+    minSecondsBetweenRuns: 1
+scenarios:
+  - name: "delete pods example"
+    steps:
+    - podAction:
+        matches:
+          - labels:
+              namespace: "<namespace>"
+              selector: "<pod label>"  # This can be left blank.
+        filters:
+          - randomSample:
+              size: <number of pods to kill>
+        actions:
+          - kill:
+              probability: 1
+              force: true
+    - podAction:
+        matches:
+          - labels:
+              namespace: "<namespace>"
+              selector: "<pod label>"  # This can be left blank.
+        retries:
+          retriesTimeout:
+            # Amount of time to wait with retrying, before failing if pod count does not match expected
+            # timeout: 180.
+
+        actions:
+          - checkPodCount:
+              count: <expected number of pods that match namespace and label"
 ```
 
+More information on specific items that you can add to the pod killing scenarios can be found in the [powerfulseal policies](https://powerfulseal.github.io/powerfulseal/policies) documentation
+
+
 #### Node Scenario Yaml Template
 
 ```

docs/index.md

@@ -10,9 +10,7 @@
   * [Cluster recovery checks, metrics evaluation and pass/fail criteria](#cluster-recovery-checks-metrics-evaluation-and-passfail-criteria)
 * [Scenarios](#scenarios)
 * [Test Environment Recommendations - how and where to run chaos tests](#test-environment-recommendations---how-and-where-to-run-chaos-tests)
-* [Chaos testing in Practice](#chaos-testing-in-practice)
-  * [OpenShift oraganization](#openshift-organization)
-  * [startx-lab](#startx-lab)
+* [Chaos testing in Practice within the OpenShift Organization](#chaos-testing-in-practice-within-the-OpenShift-Organization)
 
 
 ### Introduction
@@ -48,7 +46,7 @@ Failures in production are costly. To help mitigate risk to service health, cons
 
 
 ### Best Practices
-Now that we understand the test methodology, let us take a look at the best practices for an Kubernetes cluster.  On that platform there are user applications and cluster workloads that need to be designed for stability and to provide the best user experience possible:
+Now that we understand the test methodology, let us take a look at the best practices for an OpenShift cluster.  On that platform there are user applications and cluster workloads that need to be designed for stability and to provide the best user experience possible:
 
 - Alerts with appropriate severity should get fired.
   - Alerts are key to identify when a component starts degrading, and can help focus the investigation effort on affected system components.
@@ -77,11 +75,11 @@ We want to look at this in terms of CPU, Memory, Disk, Throughput, Network etc.
   - The controller watching the component should recognize a failure as soon as possible. The component needs to have minimal initialization time to avoid extended downtime or overloading the replicas if it is a highly available configuration. The cause of failure can be because of issues with the infrastructure on top of which it is running, application failures, or because of service failures that it depends on.
 
 - High Availability deployment strategy.
-  - There should be multiple replicas ( both Kubernetes and application control planes ) running preferably in different availability zones to survive outages while still serving the user/system requests. Avoid single points of failure.
+  - There should be multiple replicas ( both OpenShift and application control planes ) running preferably in different availability zones to survive outages while still serving the user/system requests. Avoid single points of failure.
 - Backed by persistent storage
   - It is important to have the system/application backed by persistent storage. This is especially important in cases where the application is a database or a stateful application given that a node, pod, or container failure will wipe off the data.
 
-- There should be fallback routes to the backend in case of using CDN, for example, Akamai in case of console.redhat.com - a managed service deployed on top of Kubernetes dedicated:
+- There should be fallback routes to the backend in case of using CDN, for example, Akamai in case of console.redhat.com - a managed service deployed on top of OpenShift dedicated:
   - Content delivery networks (CDNs) are commonly used to host resources such as images, JavaScript files, and CSS. The average web page is nearly 2 MB in size, and offloading heavy resources to third-parties is extremely effective for reducing backend server traffic and latency. However, this makes each CDN an additional point of failure for every site that relies on it. If the CDN fails, its customers could also fail.
   - To test how the application reacts to failures, drop all network traffic between the system and CDN. The application should still serve the content to the user irrespective of the failure.
 
@@ -92,18 +90,18 @@ We want to look at this in terms of CPU, Memory, Disk, Throughput, Network etc.
 
 
 ### Tooling
-Now that we looked at the best practices, In this section, we will go through how [Kraken](https://github.com/redhat-chaos/krkn) - a chaos testing framework can help test the resilience of Kubernetes and make sure the applications and services are following the best practices.
+Now that we looked at the best practices, In this section, we will go through how [Kraken](https://github.com/chaos-kubox/krkn) - a chaos testing framework can help test the resilience of OpenShift and make sure the applications and services are following the best practices.
 
 #### Workflow
-Let us start by understanding the workflow of kraken: the user will start by running kraken by pointing to a specific Kubernetes cluster using kubeconfig to be able to talk to the platform on top of which the Kubernetes cluster is hosted. This can be done by either the oc/kubectl API or the cloud API. Based on the configuration of kraken, it will inject specific chaos scenarios as shown below, talk to [Cerberus](https://github.com/redhat-chaos/cerberus) to get the go/no-go signal representing the overall health of the cluster ( optional - can be turned off ), scrapes metrics from in-cluster prometheus given a metrics profile with the promql queries and stores them long term in Elasticsearch configured  ( optional - can be turned off ), evaluates the promql expressions specified in the alerts profile ( optional - can be turned off ) and aggregated everything to set the pass/fail i.e. exits 0 or 1. More about the metrics collection, cerberus and metrics evaluation can be found in the next section.
+Let us start by understanding the workflow of kraken: the user will start by running kraken by pointing to a specific OpenShift cluster using kubeconfig to be able to talk to the platform on top of which the OpenShift cluster is hosted. This can be done by either the oc/kubectl API or the cloud API. Based on the configuration of kraken, it will inject specific chaos scenarios as shown below, talk to [Cerberus](https://github.com/chaos-kubox/cerberus) to get the go/no-go signal representing the overall health of the cluster ( optional - can be turned off ), scrapes metrics from in-cluster prometheus given a metrics profile with the promql queries and stores them long term in Elasticsearch configured  ( optional - can be turned off ), evaluates the promql expressions specified in the alerts profile ( optional - can be turned off ) and aggregated everything to set the pass/fail i.e. exits 0 or 1. More about the metrics collection, cerberus and metrics evaluation can be found in the next section.
 
 ![Kraken workflow](../media/kraken-workflow.png)
 
 #### Cluster recovery checks, metrics evaluation and pass/fail criteria
-- Most of the scenarios have built in checks to verify if the targeted component recovered from the failure after the specified duration of time but there might be cases where other components might have an impact because of a certain failure and it’s extremely important to make sure that the system/application is healthy as a whole post chaos. This is exactly where [Cerberus](https://github.com/redhat-chaos/cerberus) comes to the rescue.
+- Most of the scenarios have built in checks to verify if the targeted component recovered from the failure after the specified duration of time but there might be cases where other components might have an impact because of a certain failure and it’s extremely important to make sure that the system/application is healthy as a whole post chaos. This is exactly where [Cerberus](https://github.com/chaos-kubox/cerberus) comes to the rescue.
 If the monitoring tool, cerberus is enabled it will consume the signal and continue running chaos or not based on that signal.
 
-- Apart from checking the recovery and cluster health status, it’s equally important to evaluate the performance metrics like latency, resource usage spikes, throughput, etcd health like disk fsync, leader elections etc. To help with this, Kraken has a way to evaluate promql expressions from the incluster prometheus and set the exit status to 0 or 1 based on the severity set for each of the query. Details on how to use this feature can be found [here](https://github.com/redhat-chaos/krkn#alerts).
+- Apart from checking the recovery and cluster health status, it’s equally important to evaluate the performance metrics like latency, resource usage spikes, throughput, etcd health like disk fsync, leader elections etc. To help with this, Kraken has a way to evaluate promql expressions from the incluster prometheus and set the exit status to 0 or 1 based on the severity set for each of the query. Details on how to use this feature can be found [here](https://github.com/chaos-kubox/krkn#alerts).
 
 - The overall pass or fail of kraken is based on the recovery of the specific component (within a certain amount of time), the cerberus health signal which tracks the health of the entire cluster and metrics evaluation from incluster prometheus.
 
@@ -112,19 +110,19 @@ If the monitoring tool, cerberus is enabled it will consume the signal and conti
 
 ### Scenarios
 
-Let us take a look at how to run the chaos scenarios on your Kubernetes clusters using Kraken-hub - a lightweight wrapper around Kraken to ease the runs by providing the ability to run them by just running container images using podman with parameters set as environment variables. This eliminates the need to carry around and edit configuration files and makes it easy for any CI framework integration. Here are the scenarios supported:
+Let us take a look at how to run the chaos scenarios on your OpenShift clusters using Kraken-hub - a lightweight wrapper around Kraken to ease the runs by providing the ability to run them by just running container images using podman with parameters set as environment variables. This eliminates the need to carry around and edit configuration files and makes it easy for any CI framework integration. Here are the scenarios supported:
 
-- Pod Scenarios ([Documentation](https://github.com/redhat-chaos/krkn-hub/blob/main/docs/pod-scenarios.md))
-  - Disrupts Kubernetes/Kubernetes and applications deployed as pods:
+- Pod Scenarios ([Documentation](https://github.com/chaos-kubox/krkn-hub/blob/main/docs/pod-scenarios.md))
+  - Disrupts OpenShift/Kubernetes and applications deployed as pods:
     - Helps understand the availability of the application, the initialization timing and recovery status.
   - [Demo](https://asciinema.org/a/452351?speed=3&theme=solarized-dark)
 
-- Container Scenarios ([Documentation](https://github.com/redhat-chaos/krkn-hub/blob/main/docs/container-scenarios.md))
-  - Disrupts Kubernetes/Kubernetes and applications deployed as containers running as part of a pod(s) using a specified kill signal to mimic failures:
+- Container Scenarios ([Documentation](https://github.com/chaos-kubox/krkn-hub/blob/main/docs/container-scenarios.md))
+  - Disrupts OpenShift/Kubernetes and applications deployed as containers running as part of a pod(s) using a specified kill signal to mimic failures:
     - Helps understand the impact and recovery timing when the program/process running in the containers are disrupted - hangs, paused, killed etc., using various kill signals, i.e. SIGHUP, SIGTERM, SIGKILL etc.
   - [Demo](https://asciinema.org/a/BXqs9JSGDSEKcydTIJ5LpPZBM?speed=3&theme=solarized-dark)
 
-- Node Scenarios ([Documentation](https://github.com/redhat-chaos/krkn-hub/blob/main/docs/node-scenarios.md))
+- Node Scenarios ([Documentation](https://github.com/chaos-kubox/krkn-hub/blob/main/docs/node-scenarios.md))
   - Disrupts nodes as part of the cluster infrastructure by talking to the cloud API. AWS, Azure, GCP, OpenStack and Baremetal are the supported platforms as of now. Possible disruptions include:
     - Terminate nodes
     - Fork bomb inside the node
@@ -133,18 +131,18 @@ Let us take a look at how to run the chaos scenarios on your Kubernetes clusters
     - etc.
   - [Demo](https://asciinema.org/a/ANZY7HhPdWTNaWt4xMFanF6Q5)
 
-- Zone Outages ([Documentation](https://github.com/redhat-chaos/krkn-hub/blob/main/docs/zone-outages.md))
-  - Creates outage of availability zone(s) in a targeted region in the public cloud where the Kubernetes cluster is running by tweaking the network acl of the zone to simulate the failure, and that in turn will stop both ingress and egress traffic from all nodes in a particular zone for the specified duration and reverts it back to the previous state.
-    - Helps understand the impact on both Kubernetes/Kubernetes control plane as well as applications and services running on the worker nodes in that zone.
+- Zone Outages ([Documentation](https://github.com/chaos-kubox/krkn-hub/blob/main/docs/zone-outages.md))
+  - Creates outage of availability zone(s) in a targeted region in the public cloud where the OpenShift cluster is running by tweaking the network acl of the zone to simulate the failure, and that in turn will stop both ingress and egress traffic from all nodes in a particular zone for the specified duration and reverts it back to the previous state.
+    - Helps understand the impact on both Kubernetes/OpenShift control plane as well as applications and services running on the worker nodes in that zone.
     - Currently, only set up for AWS cloud platform: 1 VPC and multiples subnets within the VPC can be specified.
     - [Demo](https://asciinema.org/a/452672?speed=3&theme=solarized-dark)
 
-- Application Outages ([Documentation](https://github.com/redhat-chaos/krkn-hub/blob/main/docs/application-outages.md))
+- Application Outages ([Documentation](https://github.com/chaos-kubox/krkn-hub/blob/main/docs/application-outages.md))
   - Scenario to block the traffic ( Ingress/Egress ) of an application matching the labels for the specified duration of time to understand the behavior of the service/other services which depend on it during the downtime.
     - Helps understand how the dependent services react to the unavailability.
     - [Demo](https://asciinema.org/a/452403?speed=3&theme=solarized-dark)
 
-- Power Outages ([Documentation](https://github.com/redhat-chaos/krkn-hub/blob/main/docs/power-outages.md))
+- Power Outages ([Documentation](https://github.com/chaos-kubox/krkn-hub/blob/main/docs/power-outages.md))
   - This scenario imitates a power outage by shutting down of the entire cluster for a specified duration of time, then restarts all the nodes after the specified time and checks the health of the cluster.
     - There are various use cases in the customer environments. For example, when some of the clusters are shutdown in cases where the applications are not needed to run in a particular time/season in order to save costs.
     - The nodes are stopped in parallel to mimic a power outage i.e., pulling off the plug
@@ -153,23 +151,24 @@ Let us take a look at how to run the chaos scenarios on your Kubernetes clusters
 - Resource Hog
   - Hogs CPU, Memory and IO on the targeted nodes
     - Helps understand if the application/system components have reserved resources to not get disrupted because of rogue applications, or get performance throttled.
-      - CPU Hog ([Documentation](https://github.com/redhat-chaos/krkn-hub/blob/main/docs/node-cpu-hog.md), [Demo](https://asciinema.org/a/452762))
-      - Memory Hog ([Documentation](https://github.com/redhat-chaos/krkn-hub/blob/main/docs/node-memory-hog.md), [Demo](https://asciinema.org/a/452742?speed=3&theme=solarized-dark))
+      - CPU Hog ([Documentation](https://github.com/chaos-kubox/krkn-hub/blob/main/docs/node-cpu-hog.md), [Demo](https://asciinema.org/a/452762))
+      - Memory Hog ([Documentation](https://github.com/chaos-kubox/krkn-hub/blob/main/docs/node-memory-hog.md), [Demo](https://asciinema.org/a/452742?speed=3&theme=solarized-dark))
+      - IO Hog ([Documentation](https://github.com/chaos-kubox/krkn-hub/blob/main/docs/node-io-hog.md))
 
-- Time Skewing ([Documentation](https://github.com/redhat-chaos/krkn-hub/blob/main/docs/time-scenarios.md))
+- Time Skewing ([Documentation](https://github.com/chaos-kubox/krkn-hub/blob/main/docs/time-scenarios.md))
   - Manipulate the system time and/or date of specific pods/nodes.
     - Verify scheduling of objects so they continue to work.
     - Verify time gets reset properly.
 
-- Namespace Failures ([Documentation](https://github.com/redhat-chaos/krkn-hub/blob/main/docs/namespace-scenarios.md))
+- Namespace Failures ([Documentation](https://github.com/chaos-kubox/krkn-hub/blob/main/docs/namespace-scenarios.md))
   - Delete namespaces for the specified duration.
     - Helps understand the impact on other components and tests/improves recovery time of the components in the targeted namespace.
 
-- Persistent Volume Fill ([Documentation](https://github.com/redhat-chaos/krkn-hub/blob/main/docs/pvc-scenarios.md))
+- Persistent Volume Fill ([Documentation](https://github.com/chaos-kubox/krkn-hub/blob/main/docs/pvc-scenarios.md))
   - Fills up the persistent volumes, up to a given percentage, used by the pod for the specified duration.
     - Helps understand how an application deals when it is no longer able to write data to the disk. For example, kafka’s behavior when it is not able to commit data to the disk.
 
-- Network Chaos ([Documentation](https://github.com/redhat-chaos/krkn-hub/blob/main/docs/network-chaos.md))
+- Network Chaos ([Documentation](https://github.com/chaos-kubox/krkn-hub/blob/main/docs/network-chaos.md))
   - Scenarios supported includes:
     - Network latency
     - Packet loss
@@ -200,7 +199,7 @@ Let us take a look at few recommendations on how and where to run the chaos test
 - Enable Observability:
   - Chaos Engineering Without Observability ... Is Just Chaos.
   - Make sure to have logging and monitoring installed on the cluster to help with understanding the behaviour as to why it is happening. In case of running the tests in the CI where it is not humanly possible to monitor the cluster all the time, it is recommended to leverage Cerberus to capture the state during the runs and metrics collection in Kraken to store metrics long term even after the cluster is gone.
-  - Kraken ships with dashboards that will help understand API, Etcd and Kubernetes cluster level stats and performance metrics.
+  - Kraken ships with dashboards that will help understand API, Etcd and OpenShift cluster level stats and performance metrics.
   - Pay attention to Prometheus alerts. Check if they are firing as expected.
 
 - Run multiple chaos tests at once to mimic the production outages:
@@ -208,9 +207,8 @@ Let us take a look at few recommendations on how and where to run the chaos test
   - You might have existing test cases, be it related to Performance, Scalability or QE. Run the chaos in the background during the test runs to observe the impact. Signaling feature in Kraken can help with coordinating the chaos runs i.e., start, stop, pause the scenarios based on the state of the other test jobs.
 
 
-#### Chaos testing in Practice
+#### Chaos testing in Practice within the OpenShift Organization
 
-##### OpenShift organization
 Within the OpenShift organization we use kraken to perform chaos testing throughout a release before the code is available to customers.
 
     1. We execute kraken during our regression test suite.
@@ -228,83 +226,3 @@ Within the OpenShift organization we use kraken to perform chaos testing through
         iii. This test can be seen here: https://github.com/openshift/svt/tree/master/reliability-v2
 
     3. We are starting to add in test cases that perform chaos testing during an upgrade (not many iterations of this have been completed).
-
-
-##### startx-lab
-
-**NOTE**: Requests for enhancements and any issues need to be filed at the mentioned links given that they are not natively supported in Kraken.
-
-The following content covers the implementation details around how Startx is leveraging Kraken:
-
-* Using kraken as part of a tekton pipeline
-
-You can find on [artifacthub.io](https://artifacthub.io/packages/search?kind=7&ts_query_web=kraken) the 
-[kraken-scenario](https://artifacthub.io/packages/tekton-task/startx-tekton-catalog/kraken-scenario) `tekton-task`
-which can be used to start a kraken chaos scenarios as part of a chaos pipeline.
-
-To use this task, you must have :
-
-  - Openshift pipeline enabled (or tekton CRD loaded for Kubernetes clusters)
-  - 1 Secret named `kraken-aws-creds` for scenarios using aws
-  - 1 ConfigMap named `kraken-kubeconfig` with credentials to the targeted cluster
-  - 1 ConfigMap named `kraken-config-example` with kraken configuration file (config.yaml)
-  - 1 ConfigMap named `kraken-common-example` with all kraken related files
-  - The `pipeline` SA with be autorized to run with priviveged SCC
-
-You can create theses resources using the following sequence :
-
-```bash
-oc project default
-oc adm policy add-scc-to-user privileged -z pipeline
-oc apply -f https://github.com/startxfr/tekton-catalog/raw/stable/task/kraken-scenario/0.1/samples/common.yaml
-```
-
-Then you must change content of `kraken-aws-creds` secret, `kraken-kubeconfig` and `kraken-config-example` configMap
-to reflect your cluster configuration. Refer to the [kraken configuration](https://github.com/redhat-chaos/krkn/blob/main/config/config.yaml)
-and [configuration examples](https://github.com/startxfr/tekton-catalog/blob/stable/task/kraken-scenario/0.1/samples/) 
-for details on how to configure theses resources.
-
-* Start as a single taskrun
-
-```bash
-oc apply -f https://github.com/startxfr/tekton-catalog/raw/stable/task/kraken-scenario/0.1/samples/taskrun.yaml
-```
-
-* Start as a pipelinerun
-
-```yaml
-oc apply -f https://github.com/startxfr/tekton-catalog/raw/stable/task/kraken-scenario/0.1/samples/pipelinerun.yaml
-```
-
-* Deploying kraken using a helm-chart
-
-You can find on [artifacthub.io](https://artifacthub.io/packages/search?kind=0&ts_query_web=kraken) the
-[chaos-kraken](https://artifacthub.io/packages/helm/startx/chaos-kraken) `helm-chart`
-which can be used to deploy a kraken chaos scenarios.
-
-Default configuration create the following resources :
-
-  - 1 project named **chaos-kraken**
-  - 1 scc with privileged context for kraken deployment
-  - 1 configmap with kraken 21 generic scenarios, various scripts and configuration
-  - 1 configmap with kubeconfig of the targeted cluster
-  - 1 job named kraken-test-xxx
-  - 1 service to the kraken pods
-  - 1 route to the kraken service
-
-```bash
-# Install the startx helm repository
-helm repo add startx https://startxfr.github.io/helm-repository/packages/
-# Install the kraken project
-helm install --set project.enabled=true chaos-kraken-project  startx/chaos-kraken
-# Deploy the kraken instance
-helm install \
---set kraken.enabled=true \
---set kraken.aws.credentials.region="eu-west-3" \
---set kraken.aws.credentials.key_id="AKIAXXXXXXXXXXXXXXXX" \
---set kraken.aws.credentials.secret="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
---set kraken.kubeconfig.token.server="https://api.mycluster:6443" \
---set kraken.kubeconfig.token.token="sha256~XXXXXXXXXX_PUT_YOUR_TOKEN_HERE_XXXXXXXXXXXX" \
--n chaos-kraken \
-chaos-kraken-instance startx/chaos-kraken
-```

docs/installation.md

@@ -3,52 +3,55 @@
 The following ways are supported to run Kraken:
 
 - Standalone python program through Git.
-- Containerized version using either Podman or Docker as the runtime via [Krkn-hub](https://github.com/redhat-chaos/krkn-hub)
-- Kubernetes or OpenShift deployment ( unsupported )
+- Containerized version using either Podman or Docker as the runtime.
+- Kubernetes or OpenShift deployment.
 
 **NOTE**: It is recommended to run Kraken external to the cluster ( Standalone or Containerized ) hitting the Kubernetes/OpenShift API as running it internal to the cluster might be disruptive to itself and also might not report back the results if the chaos leads to cluster's API server instability.
 
 **NOTE**: To run Kraken on Power (ppc64le) architecture, build and run a containerized version by following the
- instructions given [here](https://github.com/redhat-chaos/krkn/blob/main/containers/build_own_image-README.md).
-
-**NOTE**: Helper functions for interactions in Krkn are part of [krkn-lib](https://github.com/redhat-chaos/krkn-lib). 
-Please feel free to reuse and expand them as you see fit when adding a new scenario or expanding 
-the capabilities of the current supported scenarios.
-
+ instructions given [here](https://github.com/chaos-kubox/krkn/blob/main/containers/build_own_image-README.md).
 
 ### Git
 
 #### Clone the repository
-Pick the latest stable release to install [here](https://github.com/redhat-chaos/krkn/releases).
 ```
-$ git clone https://github.com/redhat-chaos/krkn.git --branch <release version>
+$ git clone https://github.com/openshift-scale/krkn.git
 $ cd kraken
 ```
 
 #### Install the dependencies
 ```
-$ python3.9 -m venv chaos
+$ python3 -m venv chaos
 $ source chaos/bin/activate
-$ pip3.9 install -r requirements.txt
+$ pip3 install -r requirements.txt
 ```
 
 **NOTE**: Make sure python3-devel and latest pip versions are installed on the system. The dependencies install has been tested with pip >= 21.1.3 versions.
 
 #### Run
 ```
-$ python3.9 run_kraken.py --config <config_file_location>
+$ python3 run_kraken.py --config <config_file_location>
 ```
 
 ### Run containerized version
-[Krkn-hub](https://github.com/redhat-chaos/krkn-hub) is a wrapper that allows running Krkn chaos scenarios via podman or docker runtime with scenario parameters/configuration defined as environment variables.
+Assuming that the latest docker ( 17.05 or greater with multi-build support ) is installed on the host, run:
+```
+$ docker pull quay.io/chaos-kubox/krkn:latest
+$ docker run --name=kraken --net=host -v <path_to_kubeconfig>:/root/.kube/config:Z -v <path_to_kraken_config>:/root/kraken/config/config.yaml:Z -d quay.io/chaos-kubox/krkn:latest
+$ docker run --name=kraken --net=host -v <path_to_kubeconfig>:/root/.kube/config:Z -v <path_to_kraken_config>:/root/kraken/config/config.yaml:Z -v <path_to_scenarios_directory>:/root/kraken/scenarios:Z -d quay.io/chaos-kubox/krkn:latest #custom or tweaked scenario configs
+$ docker logs -f kraken
+```
 
-Refer [instructions](https://github.com/redhat-chaos/krkn-hub#supported-chaos-scenarios) to get started.
+Similarly, podman can be used to achieve the same:
+```
+$ podman pull quay.io/chaos-kubox/krkn
+$ podman run --name=kraken --net=host -v <path_to_kubeconfig>:/root/.kube/config:Z -v <path_to_kraken_config>:/root/kraken/config/config.yaml:Z -d quay.io/chaos-kubox/krkn:latest
+$ podman run --name=kraken --net=host -v <path_to_kubeconfig>:/root/.kube/config:Z -v <path_to_kraken_config>:/root/kraken/config/config.yaml:Z -v <path_to_scenarios_directory>:/root/kraken/scenarios:Z -d quay.io/chaos-kubox/krkn:latest #custom or tweaked scenario configs
+$ podman logs -f kraken
+```
+
+If you want to build your own kraken image see [here](https://github.com/chaos-kubox/krkn/blob/main/containers/build_own_image-README.md)
 
 
-### Run Kraken as a Kubernetes deployment ( unsupported option - standalone or containerized deployers are recommended )
-Refer [Instructions](https://github.com/redhat-chaos/krkn/blob/main/containers/README.md) on how to deploy and run Kraken as a Kubernetes/OpenShift deployment.
-
-
-Refer to the [chaos-kraken chart manpage](https://artifacthub.io/packages/helm/startx/chaos-kraken)
-and especially the [kraken configuration values](https://artifacthub.io/packages/helm/startx/chaos-kraken#chaos-kraken-values-dictionary) 
-for details on how to configure this chart.
+### Run Kraken as a Kubernetes deployment
+Refer [Instructions](https://github.com/chaos-kubox/krkn/blob/main/containers/README.md) on how to deploy and run Kraken as a Kubernetes/OpenShift deployment.

docs/litmus_scenarios.md

@@ -0,0 +1,41 @@
+### Litmus Scenarios
+Kraken consumes [Litmus](https://github.com/litmuschaos/litmus) under the hood for some scenarios
+
+Official Litmus documentation and specifics of Litmus resources can be found [here](https://docs.litmuschaos.io/docs/next/getstarted/)
+
+
+#### Litmus Chaos Custom Resources
+There are 3 custom resources that are created during each Litmus scenario. Below is a description of the resources:
+* ChaosEngine: A resource to link a Kubernetes application or Kubernetes node to a ChaosExperiment. ChaosEngine is watched by Litmus' Chaos-Operator which then invokes Chaos-Experiments.
+* ChaosExperiment: A resource to group the configuration parameters of a chaos experiment. ChaosExperiment CRs are created by the operator when experiments are invoked by ChaosEngine.
+* ChaosResult : A resource to hold the results of a chaos-experiment. The Chaos-exporter reads the results and exports the metrics into a configured Prometheus server.
+
+### Understanding Litmus Scenarios
+
+To run Litmus scenarios we need to apply 3 different resources/yaml files to our cluster.
+1. **Chaos experiments** contain the actual chaos details of a scenario.
+
+    i. This is installed automatically by Kraken (does not need to be specified in kraken scenario configuration).
+
+2. **Service Account**: should be created to allow chaosengine to run experiments in your application namespace. Usually it sets just enough permissions to a specific namespace to be able to run the experiment properly.
+
+    i. This can be defined using either a link to a yaml file or a downloaded file in the scenarios' folder.
+
+3. **Chaos Engine** connects the application instance to a Chaos Experiment. This is where you define the specifics of your scenario; i.e.: the node or pod name you want to cause chaos within.
+
+    i. This is a downloaded yaml file in the scenarios' folder. A full list of scenarios can be found [here](https://hub.litmuschaos.io/)
+
+**NOTE**: By default, all chaos experiments will be installed based on the version you give in the config file.
+
+Adding a new Litmus based scenario is as simple as adding references to 2 new yaml files (the Service Account and Chaos engine files for your scenario ) in the Kraken config.
+
+
+### Supported scenarios
+
+The following are the start of scenarios for which a chaos scenario config exists today.
+
+Scenario                 | Description                                                                             | Working
+------------------------ |-----------------------------------------------------------------------------------------| ------------------------- |
+[Node CPU Hog](https://github.com/chaos-kubox/krkn/blob/main/scenarios/node_cpu_hog_engine.yaml)             | Chaos scenario that hogs up the CPU on a defined node for a specific amount of time.    | :heavy_check_mark:        |
+[Node Memory Hog](https://github.com/chaos-kubox/krkn/blob/main/scenarios/node_mem_engine.yaml)          | Chaos scenario that hogs up the memory on a defined node for a specific amount of time. | :heavy_check_mark:        |
+[Node IO Hog](https://github.com/chaos-kubox/krkn/blob/main/scenarios/node_io_engine.yaml)                   | Chaos scenario that hogs up the IO on a defined node for a specific amount of time.     | :heavy_check_mark:        |

docs/managedcluster_scenarios.md

@@ -1,36 +0,0 @@
-### ManagedCluster Scenarios
-
-[ManagedCluster](https://open-cluster-management.io/concepts/managedcluster/) scenarios provide a way to integrate kraken with [Open Cluster Management (OCM)](https://open-cluster-management.io/) and [Red Hat Advanced Cluster Management for Kubernetes (ACM)](https://www.redhat.com/en/technologies/management/advanced-cluster-management).
-
-ManagedCluster scenarios leverage [ManifestWorks](https://open-cluster-management.io/concepts/manifestwork/) to inject faults into the ManagedClusters.
-
-The following ManagedCluster chaos scenarios are supported:
-
-1. **managedcluster_start_scenario**: Scenario to start the ManagedCluster instance.
-2. **managedcluster_stop_scenario**: Scenario to stop the ManagedCluster instance.
-3. **managedcluster_stop_start_scenario**: Scenario to stop and then start the ManagedCluster instance.
-4. **start_klusterlet_scenario**: Scenario to start the klusterlet of the ManagedCluster instance.
-5. **stop_klusterlet_scenario**: Scenario to stop the klusterlet of the ManagedCluster instance.
-6. **stop_start_klusterlet_scenario**: Scenario to stop and start the klusterlet of the ManagedCluster instance.
-
-ManagedCluster scenarios can be injected by placing the ManagedCluster scenarios config files under `managedcluster_scenarios` option in the Kraken config. Refer to [managedcluster_scenarios_example](https://github.com/redhat-chaos/krkn/blob/main/scenarios/kube/managedcluster_scenarios_example.yml) config file.
-
-```
-managedcluster_scenarios:
-  - actions:                                                        # ManagedCluster chaos scenarios to be injected
-    - managedcluster_stop_start_scenario
-    managedcluster_name: cluster1                                   # ManagedCluster on which scenario has to be injected; can set multiple names separated by comma
-    # label_selector:                                               # When managedcluster_name is not specified, a ManagedCluster with matching label_selector is selected for ManagedCluster chaos scenario injection
-    instance_count: 1                                               # Number of managedcluster to perform action/select that match the label selector
-    runs: 1                                                         # Number of times to inject each scenario under actions (will perform on same ManagedCluster each time)
-    timeout: 420                                                    # Duration to wait for completion of ManagedCluster scenario injection
-                                                                    # For OCM to detect a ManagedCluster as unavailable, have to wait 5*leaseDurationSeconds
-                                                                    # (default leaseDurationSeconds = 60 sec)
-  - actions:
-    - stop_start_klusterlet_scenario
-    managedcluster_name: cluster1
-    # label_selector:
-    instance_count: 1
-    runs: 1
-    timeout: 60
-```

docs/metrics.md

@@ -1,12 +1,14 @@
 ## Scraping and storing metrics for the run
 
-There are cases where the state of the cluster and metrics on the cluster during the chaos test run need to be stored long term to review after the cluster is terminated, for example CI and automation test runs. To help with this, Kraken supports capturing metrics for the duration of the scenarios defined in the config.
+There are cases where the state of the cluster and metrics on the cluster during the chaos test run need to be stored long term to review after the cluster is terminated, for example CI and automation test runs. To help with this, Kraken supports capturing metrics for the duration of the scenarios defined in the config and indexes them into Elasticsearch. The indexed metrics can be visualized with the help of Grafana.
 
-The metrics to capture need to be defined in a metrics profile which Kraken consumes to query prometheus with the start and end timestamp of the run. Each run has a unique identifier ( uuid ). The uuid is generated automatically if not set in the config. This feature can be enabled in the [config](https://github.com/redhat-chaos/krkn/blob/main/config/config.yaml) by setting the following:
+It uses [Kube-burner](https://github.com/cloud-bulldozer/kube-burner) under the hood. The metrics to capture need to be defined in a metrics profile which Kraken consumes to query prometheus ( installed by default in OpenShift ) with the start and end timestamp of the run. Each run has a unique identifier ( uuid ) and all the metrics/documents in Elasticsearch will be associated with it. The uuid is generated automatically if not set in the config. This feature can be enabled in the [config](https://github.com/chaos-kubox/krkn/blob/main/config/config.yaml) by setting the following:
 
 ```
 performance_monitoring:
+    kube_burner_binary_url: "https://github.com/cloud-bulldozer/kube-burner/releases/download/v0.9.1/kube-burner-0.9.1-Linux-x86_64.tar.gz"
     capture_metrics: True
+    config_path: config/kube_burner.yaml                  # Define the Elasticsearch url and index name in this config.
     metrics_profile_path: config/metrics-aggregated.yaml
     prometheus_url:                                       # The prometheus url/route is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes.
     prometheus_bearer_token:                              # The bearer token is automatically obtained in case of OpenShift, please set it when the distribution is Kubernetes. This is needed to authenticate with prometheus.
@@ -14,7 +16,7 @@ performance_monitoring:
 ```
 
 ### Metrics profile
-A couple of [metric profiles](https://github.com/redhat-chaos/krkn/tree/main/config), [metrics.yaml](https://github.com/redhat-chaos/krkn/blob/main/config/metrics.yaml), and [metrics-aggregated.yaml](https://github.com/redhat-chaos/krkn/blob/main/config/metrics-aggregated.yaml) are shipped by default and can be tweaked to add more metrics to capture during the run. The following are the API server metrics for example:
+A couple of [metric profiles](https://github.com/chaos-kubox/krkn/tree/main/config), [metrics.yaml](https://github.com/chaos-kubox/krkn/blob/main/config/metrics.yaml), and [metrics-aggregated.yaml](https://github.com/chaos-kubox/krkn/blob/main/config/metrics-aggregated.yaml) are shipped by default and can be tweaked to add more metrics to capture during the run. The following are the API server metrics for example:
 
 ```
 metrics:
@@ -29,3 +31,21 @@ metrics:
     metricName: APIInflightRequests
 ```
 
+### Indexing
+Define the Elasticsearch and index to store the metrics/documents in the kube_burner config:
+
+```
+global:
+  writeToFile: true
+  metricsDirectory: collected-metrics
+  measurements:
+    - name: podLatency
+      esIndex: kube-burner
+
+  indexerConfig:
+    enabled: true
+    esServers: [https://elastic.example.com:9200]
+    insecureSkipVerify: true
+    defaultIndex: kraken
+    type: elastic
+```

docs/namespace_scenarios.md

@@ -1,6 +1,6 @@
-###  Service Disruption Scenarios (Previously Delete Namespace Scenario)
+###  Delete Namespace Scenarios
 
-Using this type of scenario configuration one is able to delete crucial objects in a specific namespace, or a namespace matching a certain regex string.
+Using this type of scenario configuration one is able to delete a specific namespace, or a namespace matching a certain regex string.
 
 Configuration Options:
 
@@ -16,7 +16,7 @@ Set to '^.*$' and label_selector to "" to randomly select any namespace in your
 
 **sleep:** Number of seconds to wait between each iteration/count of killing namespaces. Defaults to 10 seconds if not set
 
-Refer to [namespace_scenarios_example](https://github.com/redhat-chaos/krkn/blob/main/scenarios/regex_namespace.yaml) config file.
+Refer to [namespace_scenarios_example](https://github.com/chaos-kubox/krkn/blob/main/scenarios/regex_namespace.yaml) config file.
 
 ```
 scenarios:
@@ -27,20 +27,12 @@ scenarios:
   sleep: 15
 ```
 
-
-### Steps
-
-This scenario will select a namespace (or multiple) dependent on the configuration and will kill all of the below object types in that namespace and will wait for them to be Running in the post action 
-1. Services 
-2. Daemonsets
-3. Statefulsets
-4. Replicasets
-5. Deployments 
-
+**NOTE:** Many openshift namespaces have finalizers built that protect the namespace from being fully deleted: see documentation [here](https://kubernetes.io/blog/2021/05/14/using-finalizers-to-control-deletion/).
+The namespaces that do have finalizers enabled will be in left in a terminating state but all the pods running on that namespace will get deleted.
 
 #### Post Action
 
-We do a post chaos check to wait and verify the specific objects in each namespace are Ready
+In all scenarios we do a post chaos check to wait and verify the specific component.
 
 Here there are two options:
 
@@ -55,8 +47,8 @@ See [scenarios/post_action_namespace.py](https://github.com/cloud-bulldozer/krak
 ```
 
 
-1. Allow kraken to wait and check all killed objects in the namespaces become 'Running' again. Kraken keeps a list of the specific
-objects in namespaces that were killed to verify all that were affected recover properly.
+2. Allow kraken to wait and check the killed namespaces become 'Active' again. Kraken keeps a list of the specific
+namespaces that were killed to verify all that were affected recover properly.
 
 ```
 wait_time: <seconds to wait for namespace to recover>

docs/network_chaos.md

@@ -1,7 +1,7 @@
 ### Network chaos
 Scenario to introduce network latency, packet loss, and bandwidth restriction in the Node's host network interface. The purpose of this scenario is to observe faults caused by random variations in the network.
 
-##### Sample scenario config for egress traffic shaping
+##### Sample scenario config
 ```
 network_chaos:                                    # Scenario to create an outage by simulating random variations in the network.
   duration: 300                                   # In seconds - duration network chaos will be applied.
@@ -12,34 +12,11 @@ network_chaos:                                    # Scenario to create an outage
   - "ens5"                                        # Interface name would be the Kernel host network interface name.
   execution: serial|parallel                      # Execute each of the egress options as a single scenario(parallel) or as separate scenario(serial).
   egress:
-    latency: 500ms
-    loss: 50%                                    # percentage
-    bandwidth: 10mbit
+    latency: 50ms
+    loss: 0.02                                    # percentage
+    bandwidth: 100mbit
 ```
 
-##### Sample scenario config for ingress traffic shaping (using a plugin)
-'''
-- id: network_chaos
-  config:
-    node_interface_name:                            # Dictionary with key as node name(s) and value as a list of its interfaces to test
-      ip-10-0-128-153.us-west-2.compute.internal:
-        - ens5
-        - genev_sys_6081
-    label_selector: node-role.kubernetes.io/master  # When node_interface_name is not specified, nodes with matching label_selector is selected for node chaos scenario injection
-    instance_count: 1                               # Number of nodes to perform action/select that match the label selector
-    kubeconfig_path: ~/.kube/config                 # Path to kubernetes config file. If not specified, it defaults to ~/.kube/config
-    execution_type: parallel                        # Execute each of the ingress options as a single scenario(parallel) or as separate scenario(serial).
-    network_params:
-        latency: 500ms
-        loss: '50%'
-        bandwidth: 10mbit
-    wait_duration: 120
-    test_duration: 60
-  '''
-
-  Note: For ingress traffic shaping, ensure that your node doesn't have any [IFB](https://wiki.linuxfoundation.org/networking/ifb) interfaces already present. The scenario relies on creating IFBs to do the shaping, and they are deleted at the end of the scenario.
-
-
 ##### Steps
  - Pick the nodes to introduce the network anomaly either from node_name or label_selector.
  - Verify interface list in one of the nodes or use the interface with a default route, as test interface, if no interface is specified by the user.

docs/node_scenarios.md

@@ -4,7 +4,7 @@ The following node chaos scenarios are supported:
 
 1. **node_start_scenario**: Scenario to stop the node instance.
 2. **node_stop_scenario**: Scenario to stop the node instance.
-3. **node_stop_start_scenario**: Scenario to stop and then start the node instance. Not supported on VMware.
+3. **node_stop_start_scenario**: Scenario to stop and then start the node instance.
 4. **node_termination_scenario**: Scenario to terminate the node instance.
 5. **node_reboot_scenario**: Scenario to reboot the node instance.
 6. **stop_kubelet_scenario**: Scenario to stop the kubelet of the node instance.
@@ -12,14 +12,13 @@ The following node chaos scenarios are supported:
 8. **node_crash_scenario**: Scenario to crash the node instance.
 9. **stop_start_helper_node_scenario**: Scenario to stop and start the helper node and check service status.
 
-
 **NOTE**: If the node does not recover from the node_crash_scenario injection, reboot the node to get it back to Ready state.
 
 **NOTE**: node_start_scenario, node_stop_scenario, node_stop_start_scenario, node_termination_scenario
 , node_reboot_scenario and stop_start_kubelet_scenario are supported only on AWS, Azure, OpenStack, BareMetal, GCP
-, VMware and Alibaba as of now.
+, and Alibaba as of now.
 
-**NOTE**: Node scenarios are supported only when running the standalone version of Kraken until https://github.com/redhat-chaos/krkn/issues/106 gets fixed.
+**NOTE**: Node scenarios are supported only when running the standalone version of Kraken until https://github.com/chaos-kubox/krkn/issues/106 gets fixed.
 
 
 #### AWS
@@ -38,14 +37,6 @@ See the example node scenario or the example below.
 
 **NOTE**: Baremetal machines are fragile. Some node actions can occasionally corrupt the filesystem if it does not shut down properly, and sometimes the kubelet does not start properly.
 
-#### Docker
-
-The Docker provider can be used to run node scenarios against kind clusters.
-
-[kind](https://kind.sigs.k8s.io/) is a tool for running local Kubernetes clusters using Docker container "nodes".
-
-kind was primarily designed for testing Kubernetes itself, but may be used for local development or CI.
-
 #### GCP
 How to set up GCP cli to run node scenarios is defined [here](cloud_setup.md#gcp).
 
@@ -73,53 +64,13 @@ How to set up Alibaba cli to run node scenarios is defined [here](cloud_setup.md
 . Releasing a node is 2 steps, stopping the node and then releasing it.
 
 
-#### VMware
-How to set up VMware vSphere to run node scenarios is defined [here](cloud_setup.md#vmware)
-
-This cloud type uses a different configuration style, see actions below and [example config file](../scenarios/openshift/vmware_node_scenarios.yml)
-
-*vmware-node-terminate, vmware-node-reboot, vmware-node-stop, vmware-node-start*
-
-#### IBMCloud
-How to set up IBMCloud to run node scenarios is defined [here](cloud_setup.md#ibmcloud)
-
-This cloud type uses a different configuration style, see actions below and [example config file](../scenarios/openshift/ibmcloud_node_scenarios.yml)
-
-*ibmcloud-node-terminate, ibmcloud-node-reboot, ibmcloud-node-stop, ibmcloud-node-start
-*
-
-
-#### IBMCloud and Vmware example 
-
-
-```
-- id: ibmcloud-node-stop
-  config:
-    name: "<node_name>"        
-    label_selector: "node-role.kubernetes.io/worker"    # When node_name is not specified, a node with matching label_selector is selected for node chaos scenario injection 
-    runs: 1                             # Number of times to inject each scenario under actions (will perform on same node each time)                                                           
-    instance_count: 1                   # Number of nodes to perform action/select that match the label selector                                             
-    timeout: 30                        # Duration to wait for completion of node scenario injection
-    skip_openshift_checks: False       # Set to True if you don't want to wait for the status of the nodes to change on OpenShift before passing the scenario 
-- id: ibmcloud-node-start
-  config:
-    name: "<node_name>" #Same name as before       
-    label_selector: "node-role.kubernetes.io/worker"    # When node_name is not specified, a node with matching label_selector is selected for node chaos scenario injection 
-    runs: 1                             # Number of times to inject each scenario under actions (will perform on same node each time)                                                           
-    instance_count: 1                   # Number of nodes to perform action/select that match the label selector                                             
-    timeout: 30                        # Duration to wait for completion of node scenario injection
-    skip_openshift_checks: False       # Set to True if you don't want to wait for the status of the nodes to change on OpenShift before passing the scenario 
-    ```
-
-
-
 #### General
 
 **NOTE**: The `node_crash_scenario` and `stop_kubelet_scenario` scenario is supported independent of the cloud platform.
 
 Use 'generic' or do not add the 'cloud_type' key to your scenario if your cluster is not set up using one of the current supported cloud types.
 
-Node scenarios can be injected by placing the node scenarios config files under node_scenarios option in the kraken config. Refer to [node_scenarios_example](https://github.com/redhat-chaos/krkn/blob/main/scenarios/node_scenarios_example.yml) config file.
+Node scenarios can be injected by placing the node scenarios config files under node_scenarios option in the kraken config. Refer to [node_scenarios_example](https://github.com/chaos-kubox/krkn/blob/main/scenarios/node_scenarios_example.yml) config file.
 
 
 ```

docs/pod_network_scenarios.md

@@ -1,46 +0,0 @@
-## Pod network Scenarios
-
-### Pod outage
-Scenario to block the traffic ( Ingress/Egress ) of a pod matching the labels for the specified duration of time to understand the behavior of the service/other services which depend on it during downtime. This helps with planning the requirements accordingly, be it improving the timeouts or tweaking the alerts etc.
-With the current network policies, it is not possible to explicitly block ports which are enabled by allowed network policy rule. This chaos scenario addresses this issue by using OVS flow rules to block ports related to the pod. It supports OpenShiftSDN and OVNKubernetes based networks.
-
-##### Sample scenario config (using a plugin)
-```
-- id: pod_network_outage
-  config:
-    namespace: openshift-console   # Required - Namespace of the pod to which filter need to be applied
-    direction:                     # Optioinal - List of directions to apply filters
-        - ingress                  # Blocks ingress traffic, Default both egress and ingress
-    ingress_ports:                 # Optional - List of ports to block traffic on
-        - 8443                     # Blocks 8443, Default [], i.e. all ports.
-    label_selector: 'component=ui' # Blocks access to openshift console
-```
-### Pod Network shaping
-Scenario to introduce network latency, packet loss, and bandwidth restriction in the Pod's network interface. The purpose of this scenario is to observe faults caused by random variations in the network.
-
-##### Sample scenario config for egress traffic shaping (using plugin)
-```
-- id: pod_egress_shaping
-  config:
-    namespace: openshift-console   # Required - Namespace of the pod to which filter need to be applied.
-    label_selector: 'component=ui' # Applies traffic shaping to access openshift console.
-    network_params:
-        latency: 500ms             # Add 500ms latency to egress traffic from the pod.
-```
-##### Sample scenario config for ingress traffic shaping (using plugin)
-```
-- id: pod_ingress_shaping
-  config:
-    namespace: openshift-console   # Required - Namespace of the pod to which filter need to be applied.
-    label_selector: 'component=ui' # Applies traffic shaping to access openshift console.
-    network_params:
-        latency: 500ms             # Add 500ms latency to egress traffic from the pod.
-```
-
-##### Steps
- - Pick the pods to introduce the network anomaly either from label_selector or pod_name.
- - Identify the pod interface name on the node.
- - Set traffic shaping config on pod's interface using tc and netem.
- - Wait for the duration time.
- - Remove traffic shaping config on pod's interface.
- - Remove the job that spawned the pod.

docs/pod_scenarios.md

@@ -1,40 +1,14 @@
 ### Pod Scenarios
-
-Krkn recently replaced PowerfulSeal with its own internal pod scenarios using a plugin system. You can run pod scenarios by adding the following config to Krkn:
-
-```yaml
-kraken:
-  chaos_scenarios:
-    - plugin_scenarios:
-      - path/to/scenario.yaml
-```
-
-You can then create the scenario file with the following contents:
-
-```yaml
-# yaml-language-server: $schema=../plugin.schema.json
-- id: kill-pods
-  config:
-    namespace_pattern: ^kube-system$
-    label_selector: k8s-app=kube-scheduler
-- id: wait-for-pods
-  config:
-    namespace_pattern: ^kube-system$
-    label_selector: k8s-app=kube-scheduler
-    count: 3
-```
-
-Please adjust the schema reference to point to the [schema file](../scenarios/plugin.schema.json). This file will give you code completion and documentation for the available options in your IDE.
+Kraken consumes [Powerfulseal](https://github.com/powerfulseal/powerfulseal) under the hood to run the pod scenarios.
+These scenarios are in a simple yaml format that you can manipulate to run your specific tests or use the pre-existing scenarios to see how it works.
 
 #### Pod Chaos Scenarios
-
 The following are the components of Kubernetes/OpenShift for which a basic chaos scenario config exists today.
 
-| Component                | Description | Working  |
-| ------------------------ |-------------| -------- |
-| [Basic pod scenario](../scenarios/kube/pod.yml) | Kill a pod. | :heavy_check_mark: |
-| [Etcd](../scenarios/openshift/etcd.yml) | Kills a single/multiple etcd replicas. | :heavy_check_mark: |
-| [Kube ApiServer](../scenarios/openshift/openshift-kube-apiserver.yml)| Kills a single/multiple kube-apiserver replicas. | :heavy_check_mark: |
-| [ApiServer](../scenarios/openshift/openshift-apiserver.yml) | Kills a single/multiple apiserver replicas. | :heavy_check_mark: |
-| [Prometheus](../scenarios/openshift/prometheus.yml) | Kills a single/multiple prometheus replicas. | :heavy_check_mark: |
-| [OpenShift System Pods](../scenarios/openshift/regex_openshift_pod_kill.yml) | Kills random pods running in the OpenShift system namespaces. | :heavy_check_mark: |
+Component                | Description                                                                                  | Working
+------------------------ |----------------------------------------------------------------------------------------------| ------------------------- |
+[Etcd](https://github.com/chaos-kubox/krkn/blob/main/scenarios/etcd.yml)                     | Kills a single/multiple etcd replicas for the specified number of times in a loop.           | :heavy_check_mark:        |
+[Kube ApiServer](https://github.com/chaos-kubox/krkn/blob/main/scenarios/openshift-kube-apiserver.yml)           | Kills a single/multiple kube-apiserver replicas for the specified number of times in a loop. | :heavy_check_mark:        |
+[ApiServer](https://github.com/chaos-kubox/krkn/blob/main/scenarios/openshift-apiserver.yml)              | Kills a single/multiple apiserver replicas for the specified number of times in a loop.      | :heavy_check_mark:        |
+[Prometheus](https://github.com/chaos-kubox/krkn/blob/main/scenarios/prometheus.yml)               | Kills a single/multiple prometheus replicas for the specified number of times in a loop.     | :heavy_check_mark:        |
+[OpenShift System Pods](https://github.com/chaos-kubox/krkn/blob/main/scenarios/regex_openshift_pod_kill.yml)    | Kills random pods running in the OpenShift system namespaces.                                | :heavy_check_mark:        |

docs/time_scenarios.md

@@ -16,7 +16,7 @@ Configuration Options:
 
 **object_name:** List of the names of pods or nodes you want to skew.
 
-Refer to [time_scenarios_example](https://github.com/redhat-chaos/krkn/blob/main/scenarios/time_scenarios_example.yml) config file.
+Refer to [time_scenarios_example](https://github.com/chaos-kubox/krkn/blob/main/scenarios/time_scenarios_example.yml) config file.
 
 ```
 time_scenarios:

docs/zone_outage.md

@@ -1,5 +1,5 @@
 ### Zone outage scenario
-Scenario to create outage in a targeted zone in the public cloud to understand the impact on both Kubernetes/OpenShift control plane as well as applications running on the worker nodes in that zone. It tweaks the network acl of the zone to simulate the failure and that in turn will stop both ingress and egress traffic from all the nodes in a particular zone for the specified duration and reverts it back to the previous state. Zone outage can be injected by placing the zone_outage config file under zone_outages option in the [kraken config](https://github.com/redhat-chaos/krkn/blob/main/config/config.yaml). Refer to [zone_outage_scenario](https://github.com/redhat-chaos/krkn/blob/main/scenarios/zone_outage.yaml) config file for the parameters that need to be defined.
+Scenario to create outage in a targeted zone in the public cloud to understand the impact on both Kubernetes/OpenShift control plane as well as applications running on the worker nodes in that zone. It tweaks the network acl of the zone to simulate the failure and that in turn will stop both ingress and egress traffic from all the nodes in a particular zone for the specified duration and reverts it back to the previous state. Zone outage can be injected by placing the zone_outage config file under zone_outages option in the [kraken config](https://github.com/chaos-kubox/krkn/blob/main/config/config.yaml). Refer to [zone_outage_scenario](https://github.com/chaos-kubox/krkn/blob/main/scenarios/zone_outage.yaml) config file for the parameters that need to be defined.
 
 Refer to [cloud setup](cloud_setup.md) to configure your cli properly for the cloud provider of the cluster you want to shut down.
 

kraken/application_outage/actions.py

@@ -4,43 +4,25 @@ import time
 import kraken.cerberus.setup as cerberus
 from jinja2 import Template
 import kraken.invoke.command as runcommand
-from krkn_lib.telemetry.k8s import KrknTelemetryKubernetes
-from krkn_lib.models.telemetry import ScenarioTelemetry
-from krkn_lib.utils.functions import get_yaml_item_value, log_exception
 
 
 # Reads the scenario config, applies and deletes a network policy to
 # block the traffic for the specified duration
-def run(scenarios_list, config, wait_duration, telemetry: KrknTelemetryKubernetes) -> (list[str], list[ScenarioTelemetry]):
+def run(scenarios_list, config, wait_duration):
     failed_post_scenarios = ""
-    scenario_telemetries: list[ScenarioTelemetry] = []
-    failed_scenarios = []
     for app_outage_config in scenarios_list:
-        scenario_telemetry = ScenarioTelemetry()
-        scenario_telemetry.scenario = app_outage_config
-        scenario_telemetry.startTimeStamp = time.time()
-        telemetry.set_parameters_base64(scenario_telemetry, app_outage_config)
         if len(app_outage_config) > 1:
-            try:
-                with open(app_outage_config, "r") as f:
-                    app_outage_config_yaml = yaml.full_load(f)
-                    scenario_config = app_outage_config_yaml["application_outage"]
-                    pod_selector = get_yaml_item_value(
-                        scenario_config, "pod_selector", "{}"
-                    )
-                    traffic_type = get_yaml_item_value(
-                        scenario_config, "block", "[Ingress, Egress]"
-                    )
-                    namespace = get_yaml_item_value(
-                        scenario_config, "namespace", ""
-                    )
-                    duration = get_yaml_item_value(
-                        scenario_config, "duration", 60
-                    )
+            with open(app_outage_config, "r") as f:
+                app_outage_config_yaml = yaml.full_load(f)
+                scenario_config = app_outage_config_yaml["application_outage"]
+                pod_selector = scenario_config.get("pod_selector", "{}")
+                traffic_type = scenario_config.get("block", "[Ingress, Egress]")
+                namespace = scenario_config.get("namespace", "")
+                duration = scenario_config.get("duration", 60)
 
-                    start_time = int(time.time())
+                start_time = int(time.time())
 
-                    network_policy_template = """---
+                network_policy_template = """---
 apiVersion: networking.k8s.io/v1
 kind: NetworkPolicy
 metadata:
@@ -49,38 +31,28 @@ spec:
   podSelector:
     matchLabels: {{ pod_selector }}
   policyTypes: {{ traffic_type }}
-                    """
-                    t = Template(network_policy_template)
-                    rendered_spec = t.render(pod_selector=pod_selector, traffic_type=traffic_type)
-                    # Write the rendered template to a file
-                    with open("kraken_network_policy.yaml", "w") as f:
-                        f.write(rendered_spec)
-                    # Block the traffic by creating network policy
-                    logging.info("Creating the network policy")
-                    runcommand.invoke(
-                        "kubectl create -f %s -n %s --validate=false" % ("kraken_network_policy.yaml", namespace)
-                    )
+                """
+                t = Template(network_policy_template)
+                rendered_spec = t.render(pod_selector=pod_selector, traffic_type=traffic_type)
+                # Write the rendered template to a file
+                with open("kraken_network_policy.yaml", "w") as f:
+                    f.write(rendered_spec)
+                # Block the traffic by creating network policy
+                logging.info("Creating the network policy")
+                runcommand.invoke(
+                    "kubectl create -f %s -n %s --validate=false" % ("kraken_network_policy.yaml", namespace)
+                )
 
-                    # wait for the specified duration
-                    logging.info("Waiting for the specified duration in the config: %s" % (duration))
-                    time.sleep(duration)
+                # wait for the specified duration
+                logging.info("Waiting for the specified duration in the config: %s" % (duration))
+                time.sleep(duration)
 
-                    # unblock the traffic by deleting the network policy
-                    logging.info("Deleting the network policy")
-                    runcommand.invoke("kubectl delete -f %s -n %s" % ("kraken_network_policy.yaml", namespace))
+                # unblock the traffic by deleting the network policy
+                logging.info("Deleting the network policy")
+                runcommand.invoke("kubectl delete -f %s -n %s" % ("kraken_network_policy.yaml", namespace))
 
-                    logging.info("End of scenario. Waiting for the specified duration: %s" % (wait_duration))
-                    time.sleep(wait_duration)
-
-                    end_time = int(time.time())
-                    cerberus.publish_kraken_status(config, failed_post_scenarios, start_time, end_time)
-            except Exception as e :
-                scenario_telemetry.exitStatus = 1
-                failed_scenarios.append(app_outage_config)
-                log_exception(app_outage_config)
-            else:
-                scenario_telemetry.exitStatus = 0
-            scenario_telemetry.endTimeStamp = time.time()
-            scenario_telemetries.append(scenario_telemetry)
-    return failed_scenarios, scenario_telemetries
+                logging.info("End of scenario. Waiting for the specified duration: %s" % (wait_duration))
+                time.sleep(wait_duration)
 
+                end_time = int(time.time())
+                cerberus.publish_kraken_status(config, failed_post_scenarios, start_time, end_time)

kraken/arcaflow_plugin/__init__.py

@@ -1,2 +0,0 @@
-from .arcaflow_plugin import *
-from .context_auth import ContextAuth

kraken/arcaflow_plugin/arcaflow_plugin.py

@@ -1,178 +0,0 @@
-import time
-import arcaflow
-import os
-import yaml
-import logging
-from pathlib import Path
-from typing import List
-from .context_auth import ContextAuth
-from krkn_lib.telemetry.k8s import KrknTelemetryKubernetes
-from krkn_lib.models.telemetry import ScenarioTelemetry
-
-
-def run(scenarios_list: List[str], kubeconfig_path: str, telemetry: KrknTelemetryKubernetes) -> (list[str], list[ScenarioTelemetry]):
-    scenario_telemetries: list[ScenarioTelemetry] = []
-    failed_post_scenarios = []
-    for scenario in scenarios_list:
-        scenario_telemetry = ScenarioTelemetry()
-        scenario_telemetry.scenario = scenario
-        scenario_telemetry.startTimeStamp = time.time()
-        telemetry.set_parameters_base64(scenario_telemetry,scenario)
-        engine_args = build_args(scenario)
-        status_code = run_workflow(engine_args, kubeconfig_path)
-        scenario_telemetry.endTimeStamp = time.time()
-        scenario_telemetry.exitStatus = status_code
-        scenario_telemetries.append(scenario_telemetry)
-        if status_code != 0:
-            failed_post_scenarios.append(scenario)
-    return failed_post_scenarios, scenario_telemetries
-
-
-def run_workflow(engine_args: arcaflow.EngineArgs, kubeconfig_path: str) -> int:
-    set_arca_kubeconfig(engine_args, kubeconfig_path)
-    exit_status = arcaflow.run(engine_args)
-    return exit_status
-
-
-def build_args(input_file: str) -> arcaflow.EngineArgs:
-    """sets the kubeconfig parsed by setArcaKubeConfig as an input to the arcaflow workflow"""
-    context = Path(input_file).parent
-    workflow = "{}/workflow.yaml".format(context)
-    config = "{}/config.yaml".format(context)
-    if not os.path.exists(context):
-        raise Exception(
-            "context folder for arcaflow workflow not found: {}".format(
-                context)
-        )
-    if not os.path.exists(input_file):
-        raise Exception(
-            "input file for arcaflow workflow not found: {}".format(input_file))
-    if not os.path.exists(workflow):
-        raise Exception(
-            "workflow file for arcaflow workflow not found: {}".format(
-                workflow)
-        )
-    if not os.path.exists(config):
-        raise Exception(
-            "configuration file for arcaflow workflow not found: {}".format(
-                config)
-        )
-
-    engine_args = arcaflow.EngineArgs()
-    engine_args.context = context
-    engine_args.config = config
-    engine_args.input = input_file
-    return engine_args
-
-
-def set_arca_kubeconfig(engine_args: arcaflow.EngineArgs, kubeconfig_path: str):
-
-    context_auth = ContextAuth()
-    if not os.path.exists(kubeconfig_path):
-        raise Exception("kubeconfig not found in {}".format(kubeconfig_path))
-
-    with open(kubeconfig_path, "r") as stream:
-        try:
-            kubeconfig = yaml.safe_load(stream)
-            context_auth.fetch_auth_data(kubeconfig)
-        except Exception as e:
-            logging.error("impossible to read kubeconfig file in: {}".format(
-                    kubeconfig_path))
-            raise e
-
-    kubeconfig_str = set_kubeconfig_auth(kubeconfig, context_auth)
-
-    with open(engine_args.input, "r") as stream:
-        input_file = yaml.safe_load(stream)
-        if "input_list" in input_file and isinstance(input_file["input_list"],list):
-            for index, _ in enumerate(input_file["input_list"]):
-                if isinstance(input_file["input_list"][index], dict):
-                    input_file["input_list"][index]["kubeconfig"] = kubeconfig_str
-        else:
-            input_file["kubeconfig"] = kubeconfig_str
-        stream.close()
-    with open(engine_args.input, "w") as stream:
-        yaml.safe_dump(input_file, stream)
-
-    with open(engine_args.config, "r") as stream:
-        config_file = yaml.safe_load(stream)
-    if config_file["deployers"]["image"]["deployer_name"] == "kubernetes":
-        kube_connection = set_kubernetes_deployer_auth(config_file["deployers"]["image"]["connection"], context_auth)
-        config_file["deployers"]["image"]["connection"]=kube_connection
-        with open(engine_args.config, "w") as stream:
-            yaml.safe_dump(config_file, stream,explicit_start=True, width=4096)
-
-
-def set_kubernetes_deployer_auth(deployer: any, context_auth: ContextAuth) -> any:
-    if context_auth.clusterHost is not None :
-        deployer["host"] = context_auth.clusterHost
-    if context_auth.clientCertificateData is not None :
-        deployer["cert"] = context_auth.clientCertificateData
-    if context_auth.clientKeyData is not None:
-        deployer["key"] = context_auth.clientKeyData
-    if context_auth.clusterCertificateData is not None:
-        deployer["cacert"] = context_auth.clusterCertificateData
-    if context_auth.username is not None:
-        deployer["username"] = context_auth.username
-    if context_auth.password is not None:
-        deployer["password"] = context_auth.password
-    if context_auth.bearerToken is not None:
-        deployer["bearerToken"] = context_auth.bearerToken
-    return deployer
-
-
-def set_kubeconfig_auth(kubeconfig: any, context_auth: ContextAuth) -> str:
-    """
-    Builds an arcaflow-compatible kubeconfig representation and returns it as a string.
-    In order to run arcaflow plugins in kubernetes/openshift the kubeconfig must contain client certificate/key
-    and server certificate base64 encoded within the kubeconfig file itself in *-data fields. That is not always the
-    case, infact kubeconfig may contain filesystem paths to those files, this function builds an arcaflow-compatible
-    kubeconfig file and returns it as a string that can be safely included in input.yaml 
-    """
-
-    if "current-context" not in kubeconfig.keys():
-        raise Exception(
-            "invalid kubeconfig file, impossible to determine current-context"
-        )
-    user_id = None
-    cluster_id = None
-    user_name = None
-    cluster_name = None
-    current_context = kubeconfig["current-context"]
-    for context in kubeconfig["contexts"]:
-        if context["name"] == current_context:
-            user_name = context["context"]["user"]
-            cluster_name = context["context"]["cluster"]
-    if user_name is None:
-        raise Exception(
-            "user not set for context {} in kubeconfig file".format(current_context)
-        )
-    if cluster_name is None:
-        raise Exception(
-            "cluster not set for context {} in kubeconfig file".format(current_context)
-        )
-
-    for index, user in enumerate(kubeconfig["users"]):
-        if user["name"] == user_name:
-            user_id = index
-    for index, cluster in enumerate(kubeconfig["clusters"]):
-        if cluster["name"] == cluster_name:
-            cluster_id = index
-
-    if cluster_id is None:
-        raise Exception(
-            "no cluster {} found in kubeconfig users".format(cluster_name)
-        )
-    if "client-certificate" in kubeconfig["users"][user_id]["user"]:
-        kubeconfig["users"][user_id]["user"]["client-certificate-data"] = context_auth.clientCertificateDataBase64
-        del kubeconfig["users"][user_id]["user"]["client-certificate"]
-
-    if "client-key" in kubeconfig["users"][user_id]["user"]:
-        kubeconfig["users"][user_id]["user"]["client-key-data"] = context_auth.clientKeyDataBase64
-        del kubeconfig["users"][user_id]["user"]["client-key"]
-
-    if "certificate-authority" in kubeconfig["clusters"][cluster_id]["cluster"]:
-        kubeconfig["clusters"][cluster_id]["cluster"]["certificate-authority-data"] = context_auth.clusterCertificateDataBase64
-        del kubeconfig["clusters"][cluster_id]["cluster"]["certificate-authority"]
-    kubeconfig_str = yaml.dump(kubeconfig)
-    return kubeconfig_str

kraken/arcaflow_plugin/context_auth.py

@@ -1,142 +0,0 @@
-import yaml
-import os
-import base64
-
-
-class ContextAuth:
-    clusterCertificate: str = None
-    clusterCertificateData: str = None
-    clusterHost: str = None
-    clientCertificate: str = None
-    clientCertificateData: str = None
-    clientKey: str = None
-    clientKeyData: str = None
-    clusterName: str = None
-    username: str = None
-    password: str = None
-    bearerToken: str = None
-    # TODO: integrate in krkn-lib-kubernetes in the next iteration
-
-    @property
-    def clusterCertificateDataBase64(self):
-        if self.clusterCertificateData is not None:
-            return base64.b64encode(bytes(self.clusterCertificateData,'utf8')).decode("ascii")
-        return
-
-    @property
-    def clientCertificateDataBase64(self):
-        if self.clientCertificateData is not None:
-            return base64.b64encode(bytes(self.clientCertificateData,'utf8')).decode("ascii")
-        return
-
-    @property
-    def clientKeyDataBase64(self):
-        if self.clientKeyData is not None:
-            return base64.b64encode(bytes(self.clientKeyData,"utf-8")).decode("ascii")
-        return
-
-
-
-    def fetch_auth_data(self, kubeconfig: any):
-        context_username = None
-        current_context = kubeconfig["current-context"]
-        if current_context is None:
-            raise Exception("no current-context found in kubeconfig")
-
-        for context in kubeconfig["contexts"]:
-            if context["name"] == current_context:
-                context_username = context["context"]["user"]
-                self.clusterName = context["context"]["cluster"]
-        if context_username is None:
-            raise Exception("user not found for context {0}".format(current_context))
-        if self.clusterName is None:
-            raise Exception("cluster not found for context {0}".format(current_context))
-        cluster_id = None
-        user_id = None
-        for index, user in enumerate(kubeconfig["users"]):
-            if user["name"] == context_username:
-                user_id = index
-        if user_id is None :
-            raise Exception("user {0} not found in kubeconfig users".format(context_username))
-
-        for index, cluster in enumerate(kubeconfig["clusters"]):
-            if cluster["name"] == self.clusterName:
-                cluster_id = index
-
-        if cluster_id is None:
-            raise Exception(
-                "no cluster {} found in kubeconfig users".format(self.clusterName)
-            )
-
-        user = kubeconfig["users"][user_id]["user"]
-        cluster = kubeconfig["clusters"][cluster_id]["cluster"]
-        # sets cluster api URL
-        self.clusterHost = cluster["server"]
-        # client certificates
-
-        if "client-key" in user:
-            try:
-                self.clientKey = user["client-key"]
-                self.clientKeyData = self.read_file(user["client-key"])
-            except Exception as e:
-                raise e
-
-        if "client-key-data" in user:
-            try:
-                self.clientKeyData = base64.b64decode(user["client-key-data"]).decode('utf-8')
-            except Exception as e:
-                raise Exception("impossible to decode client-key-data")
-
-        if "client-certificate" in user:
-            try:
-                self.clientCertificate = user["client-certificate"]
-                self.clientCertificateData = self.read_file(user["client-certificate"])
-            except Exception as e:
-                raise e
-
-        if "client-certificate-data" in user:
-            try:
-                self.clientCertificateData = base64.b64decode(user["client-certificate-data"]).decode('utf-8')
-            except Exception as e:
-                raise Exception("impossible to decode client-certificate-data")
-
-        # cluster certificate authority
-
-        if "certificate-authority" in cluster:
-            try:
-                self.clusterCertificate = cluster["certificate-authority"]
-                self.clusterCertificateData = self.read_file(cluster["certificate-authority"])
-            except Exception as e:
-                raise e
-
-        if "certificate-authority-data" in cluster:
-            try:
-                self.clusterCertificateData = base64.b64decode(cluster["certificate-authority-data"]).decode('utf-8')
-            except Exception as e:
-                raise Exception("impossible to decode certificate-authority-data")
-
-        if "username" in user:
-            self.username = user["username"]
-
-        if "password" in user:
-            self.password = user["password"]
-
-        if "token" in user:
-            self.bearerToken = user["token"]
-
-    def read_file(self, filename:str) -> str:
-        if not os.path.exists(filename):
-            raise Exception("file not found {0} ".format(filename))
-        with open(filename, "rb") as file_stream:
-            return file_stream.read().decode('utf-8')
-
-
-
-
-
-
-
-
-
-
-

kraken/arcaflow_plugin/fixtures/ca.crt

@@ -1,19 +0,0 @@
------BEGIN CERTIFICATE-----
-MIIDBjCCAe6gAwIBAgIBATANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwptaW5p
-a3ViZUNBMB4XDTIzMDMxMzE1NDAxM1oXDTMzMDMxMTE1NDAxM1owFTETMBEGA1UE
-AxMKbWluaWt1YmVDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnz
-U/gIbJBRGOgNYVKX2fV03ANOwnM4VjquR28QMAdxURqgOFZ6IxYNysHEyxxE9I+I
-DAm9hi4vQPbOX7FlxUezuzw+ExEfa6RRJ+n+AGJOV1lezCVph6OaJxB1+L1UqaDZ
-eM3B4cUf/iCc5Y4bs927+CBG3MJL/jmCVPCO+MiSn/l73PXSFNJAYMvRj42zkXqD
-CVG9CwY2vWgZnnzl01l7jNGtie871AmV2uqKakJrQ2ILhD+8fZk4jE5JBDTCZnqQ
-pXIc+vERNKLUS8cvjO6Ux8dMv/Z7+xonpXOU59LlpUdHWP9jgCvMTwiOriwqGjJ+
-pQJWpX9Dm+oxJiVOJzsCAwEAAaNhMF8wDgYDVR0PAQH/BAQDAgKkMB0GA1UdJQQW
-MBQGCCsGAQUFBwMCBggrBgEFBQcDATAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQW
-BBQU9pDMtbayJdNM6bp0IG8dcs15qTANBgkqhkiG9w0BAQsFAAOCAQEAtl9TVKPA
-hTnPODqv0AGTqreS9kLg4WUUjZRaPUkPWmtCoTh2Yf55nRWdHOHeZnCWDSg24x42
-lpt+13IdqKew1RKTpKCTkicMFi090A01bYu/w39Cm6nOAA5h8zkgSkV5czvQotuV
-SoN2vB+nbuY28ah5PkdqjMHEZbNwa59cgEke8wB1R1DWFQ/pqflrH2v9ACAuY+5Q
-i673tA6CXrb1YfaCQnVBzcfvjGS1MqShPKpOLMF+/GccPczNimaBxMnKvYLvf3pN
-qEUrJC00mAcein8HmxR2Xz8wredbMUUyrQxW29pZJwfGE5GU0olnlsA0lZLbTwio
-xoolo5y+fsK/dA==
------END CERTIFICATE-----

kraken/arcaflow_plugin/fixtures/client.crt

@@ -1,19 +0,0 @@
------BEGIN CERTIFICATE-----
-MIIDITCCAgmgAwIBAgIBAjANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwptaW5p
-a3ViZUNBMB4XDTIzMDUwMTA4NTc0N1oXDTI2MDUwMTA4NTc0N1owMTEXMBUGA1UE
-ChMOc3lzdGVtOm1hc3RlcnMxFjAUBgNVBAMTDW1pbmlrdWJlLXVzZXIwggEiMA0G
-CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC0b7uy9nQYrh7uC5NODve7dFNLAgo5
-pWRS6Kx13ULA55gOpieZiI5/1jwUBjOz0Hhl5QAdHC1HDNu5wf4MmwIEheuq3kMA
-mfuvNxW2BnWSDuXyUMlBfqlwg5o6W8ndEWaK33D7wd2WQsSsAnhQPJSjnzWKvWKq
-+Kbcygc4hdss/ZWN+SXLTahNpHBw0sw8AcJqddNeXs2WI5GdZmbXL4QZI36EaNUm
-m4xKmKRKYIP9wYkmXOV/D2h1meM44y4lul5v2qvo6I+umJ84q4W1/W1vVmAzyVfL
-v1TQCUx8cpKMHzw3ma6CTBCtU3Oq9HKHBnf8GyHZicmV7ESzf/phJu4ZAgMBAAGj
-YDBeMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUH
-AwIwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBQU9pDMtbayJdNM6bp0IG8dcs15
-qTANBgkqhkiG9w0BAQsFAAOCAQEABNzEQQMYUcLsBASHladEjr46avKn7gREfaDl
-Y5PBvgCPP42q/sW/9iCNY3UpT9TJZWM6s01+0p6I96jYbRQER1NX7O4OgQYHmFw2
-PF6UOG2vMo54w11OvL7sbr4d+nkE6ItdM9fLDIJ3fEOYJZkSoxhOL/U3jSjIl7Wu
-KCIlpM/M/gcZ4w2IvcLrWtvswbFNUd+dwQfBGcQTmSQDOLE7MqSvzYAkeNv73GLB
-ieba7gs/PmoTFsf9nW60iXymDDF4MtODn15kqT/y1uD6coujmiEiIomBfxqAkUCU
-0ciP/KF5oOEMmMedm7/peQxaRTMdRSk4yu7vbj/BxnTcj039Qg==
------END CERTIFICATE-----

kraken/arcaflow_plugin/fixtures/client.key

@@ -1,27 +0,0 @@
------BEGIN RSA PRIVATE KEY-----
-MIIEowIBAAKCAQEAtG+7svZ0GK4e7guTTg73u3RTSwIKOaVkUuisdd1CwOeYDqYn
-mYiOf9Y8FAYzs9B4ZeUAHRwtRwzbucH+DJsCBIXrqt5DAJn7rzcVtgZ1kg7l8lDJ
-QX6pcIOaOlvJ3RFmit9w+8HdlkLErAJ4UDyUo581ir1iqvim3MoHOIXbLP2Vjfkl
-y02oTaRwcNLMPAHCanXTXl7NliORnWZm1y+EGSN+hGjVJpuMSpikSmCD/cGJJlzl
-fw9odZnjOOMuJbpeb9qr6OiPrpifOKuFtf1tb1ZgM8lXy79U0AlMfHKSjB88N5mu
-gkwQrVNzqvRyhwZ3/Bsh2YnJlexEs3/6YSbuGQIDAQABAoIBAQCdJxPb8zt6o2zc
-98f8nJy378D7+3LccmjGrVBH98ZELXIKkDy9RGqYfQcmiaBOZKv4U1OeBwSIdXKK
-f6O9ZuSC/AEeeSbyRysmmFuYhlewNrmgKyyelqsNDBIv8fIHUTh2i9Xj8B4G2XBi
-QGR5vcnYGLqRdBGTx63Nb0iKuksDCwPAuPA/e0ySz9HdWL1j4bqpVSYsOIXsqTDr
-CVnxUeSIL0fFQnRm3IASXQD7zdq9eEFX7vESeleZoz8qNcKb4Na/C3N6crScjgH7
-qyNZ2zNLfy1LT84k8uc1TMX2KcEVEmfdDv5cCnUH2ic12CwXMZ0vgId5LJTaHx4x
-ytIQIe5hAoGBANB+TsRXP4KzcjZlUUfiAp/pWUM4kVktbsfZa1R2NEuIGJUxPk3P
-7WS0WX5W75QKRg+UWTubg5kfd0f9fklLgofmliBnY/HrpgdyugJmUZBgzIxmy0k+
-aCe0biD1gULfyyrKtfe8k5wRFstzhfGszlOf2ebR87sSVNBuF2lEwPTvAoGBAN2M
-0/XrsodGU4B9Mj86Go2gb2k2WU2izI0cO+tm2S5U5DvKmVEnmjXfPRaOFj2UUQjo
-cljnDAinbN+O0+Inc35qsEeYdAIepNAPglzcpfTHagja9mhx2idLYTXGhbZLL+Ei
-TRzMyP27NF+GVVfYU/cA86ns6NboG6spohmnqh13AoGAKPc4aNGv0/GIVnHP56zb
-0SnbdR7PSFNp+fCZay4Slmi2U9IqKMXbIjdhgjZ4uoDORU9jvReQYuzQ1h9TyfkB
-O8yt4M4P0D/6DmqXa9NI4XJznn6wIMMXWf3UybsTW913IQBVgsjVxAuDjBQ11Eec
-/sdg3D6SgkZWzeFjzjZJJ5cCgYBSYVg7fE3hERxhjawOaJuRCBQFSklAngVzfwkk
-yhR9ruFC/l2uGIy19XFwnprUgP700gIa3qbR3PeV1TUiRcsjOaacqKqSUzSzjODL
-iNxIvZHHAyxWv+b/b38REOWNWD3QeAG2cMtX1bFux7OaO31VPkxcZhRaPOp05cE5
-yudtlwKBgDBbR7RLYn03OPm3NDBLLjTybhD8Iu8Oj7UeNCiEWAdZpqIKYnwSxMzQ
-kdo4aTENA/seEwq+XDV7TwbUIFFJg5gDXIhkcK2c9kiO2bObCAmKpBlQCcrp0a5X
-NSBk1N/ZG/Qhqns7z8k01KN4LNcdpRoNiYYPgY+p3xbY8+nWhv+q
------END RSA PRIVATE KEY-----

kraken/arcaflow_plugin/test_context_auth.py

@@ -1,100 +0,0 @@
-import os
-import unittest
-
-from context_auth import ContextAuth
-
-
-class TestCurrentContext(unittest.TestCase):
-
-    def get_kubeconfig_with_data(self) -> str:
-        """
-        This function returns a test kubeconfig file as a string.
-    
-        :return: a test kubeconfig file in string format (for unit testing purposes)
-        """  # NOQA
-        return """apiVersion: v1
-clusters:
-- cluster:
-    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM5ekNDQWQrZ0F3SUJBZ0lVV01PTVBNMVUrRi9uNXN6TSthYzlMcGZISHB3d0RRWUpLb1pJaHZjTkFRRUwKQlFBd0hqRWNNQm9HQTFVRUF3d1RhM1ZpZFc1MGRTNXNiMk5oYkdSdmJXRnBiakFlRncweU1URXlNRFl4T0RBdwpNRFJhRncwek1URXlNRFF4T0RBd01EUmFNQjR4SERBYUJnTlZCQU1NRTJ0MVluVnVkSFV1Ykc5allXeGtiMjFoCmFXNHdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDNExhcG00SDB0T1NuYTNXVisKdzI4a0tOWWRwaHhYOUtvNjUwVGlOK2c5ZFNQU3VZK0V6T1JVOWVONlgyWUZkMEJmVFNodno4Y25rclAvNysxegpETEoxQ3MwRi9haEV3ZDQxQXN5UGFjbnRiVE80dGRLWm9POUdyODR3YVdBN1hSZmtEc2ZxRGN1YW5UTmVmT1hpCkdGbmdDVzU5Q285M056alB1eEFrakJxdVF6eE5GQkgwRlJPbXJtVFJ4cnVLZXo0aFFuUW1OWEFUNnp0M21udzMKWUtWTzU4b2xlcUxUcjVHNlRtVFQyYTZpVGdtdWY2N0cvaVZlalJGbkw3YkNHWmgzSjlCSTNMcVpqRzE4dWxvbgpaVDdQcGQrQTlnaTJOTm9UZlI2TVB5SndxU1BCL0xZQU5ZNGRoZDVJYlVydDZzbmViTlRZSHV2T0tZTDdNTWRMCmVMSzFBZ01CQUFHakxUQXJNQWtHQTFVZEV3UUNNQUF3SGdZRFZSMFJCQmN3RllJVGEzVmlkVzUwZFM1c2IyTmgKYkdSdmJXRnBiakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBQTVqUHVpZVlnMExySE1PSkxYY0N4d3EvVzBDNApZeFpncVd3VHF5VHNCZjVKdDlhYTk0SkZTc2dHQWdzUTN3NnA2SlBtL0MyR05MY3U4ZWxjV0E4UXViQWxueXRRCnF1cEh5WnYrZ08wMG83TXdrejZrTUxqQVZ0QllkRzJnZ21FRjViTEk5czBKSEhjUGpHUkl1VHV0Z0tHV1dPWHgKSEg4T0RzaG9wZHRXMktrR2c2aThKaEpYaWVIbzkzTHptM00xRUNGcXAvMEdtNkN1RFphVVA2SGpJMWRrYllLdgpsSHNVZ1U1SmZjSWhNYmJLdUllTzRkc1YvT3FHcm9iNW5vcmRjaExBQmRDTnc1cmU5T1NXZGZ1VVhSK0ViZVhrCjVFM0tFYzA1RGNjcGV2a1NTdlJ4SVQrQzNMOTltWGcxL3B5NEw3VUhvNFFLTXlqWXJXTWlLRlVKV1E9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
-    server: https://127.0.0.1:6443
-  name: default
-contexts:
-- context:
-    cluster: default
-    namespace: default
-    user: testuser
-  name: default
-current-context: default
-kind: Config
-preferences: {}
-users:
-- name: testuser
-  user:
-    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM5ekNDQWQrZ0F3SUJBZ0lVV01PTVBNMVUrRi9uNXN6TSthYzlMcGZISHB3d0RRWUpLb1pJaHZjTkFRRUwKQlFBd0hqRWNNQm9HQTFVRUF3d1RhM1ZpZFc1MGRTNXNiMk5oYkdSdmJXRnBiakFlRncweU1URXlNRFl4T0RBdwpNRFJhRncwek1URXlNRFF4T0RBd01EUmFNQjR4SERBYUJnTlZCQU1NRTJ0MVluVnVkSFV1Ykc5allXeGtiMjFoCmFXNHdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDNExhcG00SDB0T1NuYTNXVisKdzI4a0tOWWRwaHhYOUtvNjUwVGlOK2c5ZFNQU3VZK0V6T1JVOWVONlgyWUZkMEJmVFNodno4Y25rclAvNysxegpETEoxQ3MwRi9haEV3ZDQxQXN5UGFjbnRiVE80dGRLWm9POUdyODR3YVdBN1hSZmtEc2ZxRGN1YW5UTmVmT1hpCkdGbmdDVzU5Q285M056alB1eEFrakJxdVF6eE5GQkgwRlJPbXJtVFJ4cnVLZXo0aFFuUW1OWEFUNnp0M21udzMKWUtWTzU4b2xlcUxUcjVHNlRtVFQyYTZpVGdtdWY2N0cvaVZlalJGbkw3YkNHWmgzSjlCSTNMcVpqRzE4dWxvbgpaVDdQcGQrQTlnaTJOTm9UZlI2TVB5SndxU1BCL0xZQU5ZNGRoZDVJYlVydDZzbmViTlRZSHV2T0tZTDdNTWRMCmVMSzFBZ01CQUFHakxUQXJNQWtHQTFVZEV3UUNNQUF3SGdZRFZSMFJCQmN3RllJVGEzVmlkVzUwZFM1c2IyTmgKYkdSdmJXRnBiakFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBQTVqUHVpZVlnMExySE1PSkxYY0N4d3EvVzBDNApZeFpncVd3VHF5VHNCZjVKdDlhYTk0SkZTc2dHQWdzUTN3NnA2SlBtL0MyR05MY3U4ZWxjV0E4UXViQWxueXRRCnF1cEh5WnYrZ08wMG83TXdrejZrTUxqQVZ0QllkRzJnZ21FRjViTEk5czBKSEhjUGpHUkl1VHV0Z0tHV1dPWHgKSEg4T0RzaG9wZHRXMktrR2c2aThKaEpYaWVIbzkzTHptM00xRUNGcXAvMEdtNkN1RFphVVA2SGpJMWRrYllLdgpsSHNVZ1U1SmZjSWhNYmJLdUllTzRkc1YvT3FHcm9iNW5vcmRjaExBQmRDTnc1cmU5T1NXZGZ1VVhSK0ViZVhrCjVFM0tFYzA1RGNjcGV2a1NTdlJ4SVQrQzNMOTltWGcxL3B5NEw3VUhvNFFLTXlqWXJXTWlLRlVKV1E9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
-    client-key-data: LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2QUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktZd2dnU2lBZ0VBQW9JQkFRQzRMYXBtNEgwdE9TbmEKM1dWK3cyOGtLTllkcGh4WDlLbzY1MFRpTitnOWRTUFN1WStFek9SVTllTjZYMllGZDBCZlRTaHZ6OGNua3JQLwo3KzF6RExKMUNzMEYvYWhFd2Q0MUFzeVBhY250YlRPNHRkS1pvTzlHcjg0d2FXQTdYUmZrRHNmcURjdWFuVE5lCmZPWGlHRm5nQ1c1OUNvOTNOempQdXhBa2pCcXVRenhORkJIMEZST21ybVRSeHJ1S2V6NGhRblFtTlhBVDZ6dDMKbW53M1lLVk81OG9sZXFMVHI1RzZUbVRUMmE2aVRnbXVmNjdHL2lWZWpSRm5MN2JDR1poM0o5QkkzTHFaakcxOAp1bG9uWlQ3UHBkK0E5Z2kyTk5vVGZSNk1QeUp3cVNQQi9MWUFOWTRkaGQ1SWJVcnQ2c25lYk5UWUh1dk9LWUw3Ck1NZExlTEsxQWdNQkFBRUNnZ0VBQ28rank4NW5ueVk5L2l6ZjJ3cjkzb2J3OERaTVBjYnIxQURhOUZYY1hWblEKT2c4bDZhbU9Ga2tiU0RNY09JZ0VDdkx6dEtXbmQ5OXpydU5sTEVtNEdmb0trNk5kK01OZEtKRUdoZHE5RjM1Qgpqdi91R1owZTIyRE5ZLzFHNVdDTE5DcWMwQkVHY2RFOTF0YzJuMlppRVBTNWZ6WVJ6L1k4cmJ5K1NqbzJkWE9RCmRHYWRlUFplbi9UbmlHTFlqZWhrbXZNQjJvU0FDbVMycTd2OUNrcmdmR1RZbWJzeGVjSU1QK0JONG9KS3BOZ28KOUpnRWJ5SUxkR1pZS2pQb2lLaHNjMVhmSy8zZStXSmxuYjJBaEE5Y1JMUzhMcDdtcEYySWp4SjNSNE93QTg3WQpNeGZvZWFGdnNuVUFHWUdFWFo4Z3BkWmhQMEoxNWRGdERjajIrcngrQVFLQmdRRDFoSE9nVGdFbERrVEc5bm5TCjE1eXYxRzUxYnJMQU1UaWpzNklEMU1qelhzck0xY2ZvazVaaUlxNVJsQ3dReTlYNDdtV1RhY0lZRGR4TGJEcXEKY0IydjR5Wm1YK1VleGJ3cDU1OWY0V05HdzF5YzQrQjdaNFF5aTRFelN4WmFjbldjMnBzcHJMUFVoOUFXRXVNcApOaW1vcXNiVGNnNGs5QWRxeUIrbWhIWmJRUUtCZ1FEQUNzU09qNXZMU1VtaVpxYWcrOVMySUxZOVNOdDZzS1VyCkprcjdCZEVpN3N2YmU5cldRR2RBb0xkQXNzcU94aENydmtPNkpSSHB1YjlRRjlYdlF4Riszc2ZpZm4yYkQ0ZloKMlVsclA1emF3RlNrNDNLbjdMZzRscURpaVUxVGlqTkJBL3dUcFlmbTB4dW5WeFRWNDZpNVViQW1XRk12TWV0bQozWUZYQmJkK2RRS0JnRGl6Q1B6cFpzeEcrazAwbUxlL2dYajl4ekNwaXZCbHJaM29teTdsVWk4YUloMmg5VlBaCjJhMzZNbVcyb1dLVG9HdW5xcCtibWU1eUxRRGlFcjVQdkJ0bGl2V3ppYmRNbFFMY2Nlcnpveml4WDA4QU5WUnEKZUpZdnIzdklDSGFFM25LRjdiVjNJK1NlSk1ra1BYL0QrV1R4WTQ5clZLYm1FRnh4c1JXRW04ekJBb0dBWEZ3UgpZanJoQTZqUW1DRmtYQ0loa0NJMVkwNEorSHpDUXZsY3NGT0EzSnNhUWduVUdwekl5OFUvdlFiLzhpQ0IzZ2RZCmpVck16YXErdnVkbnhYVnRFYVpWWGJIVitPQkVSdHFBdStyUkprZS9yYm1SNS84cUxsVUxOVWd4ZjA4RkRXeTgKTERxOUhKOUZPbnJnRTJvMU9FTjRRMGpSWU81U041dXFXODd0REEwQ2dZQXpXbk1KSFgrbmlyMjhRRXFyVnJKRAo4ZUEwOHIwWTJRMDhMRlcvMjNIVWQ4WU12VnhTUTdwcUwzaE41RXVJQ2dCbEpGVFI3TndBREo3eDY2M002akFMCm1DNlI4dWxSZStwa08xN2Y0UUs3MnVRanJGZEhESnlXQmdDL0RKSkV6d1dwY0Q4VVNPK3A5bVVIbllLTUJTOEsKTVB1ejYrZ3h0VEtsRU5pZUVacXhxZz09Ci0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0K
-    username: testuser
-    password: testpassword
-    token: sha256~fFyEqjf1xxFMO0tbEyGRvWeNOd7QByuEgS4hyEq_A9o
-    """  # NOQA
-
-    def get_kubeconfig_with_paths(self) -> str:
-        """
-        This function returns a test kubeconfig file as a string.
-
-        :return: a test kubeconfig file in string format (for unit testing purposes)
-        """  # NOQA
-        return """apiVersion: v1
-clusters:
-- cluster:
-    certificate-authority: fixtures/ca.crt
-    server: https://127.0.0.1:6443
-  name: default
-contexts:
-- context:
-    cluster: default
-    namespace: default
-    user: testuser
-  name: default
-current-context: default
-kind: Config
-preferences: {}
-users:
-- name: testuser
-  user:
-    client-certificate: fixtures/client.crt
-    client-key: fixtures/client.key
-    username: testuser
-    password: testpassword
-    token: sha256~fFyEqjf1xxFMO0tbEyGRvWeNOd7QByuEgS4hyEq_A9o
-    """  # NOQA
-
-    def test_current_context(self):
-        cwd = os.getcwd()
-        current_context_data = ContextAuth()
-        current_context_data.fetch_auth_data(self.get_kubeconfig_with_data())
-        self.assertIsNotNone(current_context_data.clusterCertificateData)
-        self.assertIsNotNone(current_context_data.clientCertificateData)
-        self.assertIsNotNone(current_context_data.clientKeyData)
-        self.assertIsNotNone(current_context_data.username)
-        self.assertIsNotNone(current_context_data.password)
-        self.assertIsNotNone(current_context_data.bearerToken)
-        self.assertIsNotNone(current_context_data.clusterHost)
-
-        current_context_no_data = ContextAuth()
-        current_context_no_data.fetch_auth_data(self.get_kubeconfig_with_paths())
-        self.assertIsNotNone(current_context_no_data.clusterCertificate)
-        self.assertIsNotNone(current_context_no_data.clusterCertificateData)
-        self.assertIsNotNone(current_context_no_data.clientCertificate)
-        self.assertIsNotNone(current_context_no_data.clientCertificateData)
-        self.assertIsNotNone(current_context_no_data.clientKey)
-        self.assertIsNotNone(current_context_no_data.clientKeyData)
-        self.assertIsNotNone(current_context_no_data.username)
-        self.assertIsNotNone(current_context_no_data.password)
-        self.assertIsNotNone(current_context_no_data.bearerToken)
-        self.assertIsNotNone(current_context_data.clusterHost)
-
-
-
-
-
-

kraken/cerberus/setup.py

@@ -1,136 +0,0 @@
-import logging
-import requests
-import sys
-import json
-
-
-def get_status(config, start_time, end_time):
-    """
-    Get cerberus status
-    """
-    cerberus_status = True
-    check_application_routes = False
-    application_routes_status = True
-    if config["cerberus"]["cerberus_enabled"]:
-        cerberus_url = config["cerberus"]["cerberus_url"]
-        check_application_routes = \
-            config["cerberus"]["check_applicaton_routes"]
-        if not cerberus_url:
-            logging.error(
-                "url where Cerberus publishes True/False signal "
-                "is not provided."
-            )
-            sys.exit(1)
-        cerberus_status = requests.get(cerberus_url, timeout=60).content
-        cerberus_status = True if cerberus_status == b"True" else False
-
-        # Fail if the application routes monitored by cerberus
-        # experience downtime during the chaos
-        if check_application_routes:
-            application_routes_status, unavailable_routes = application_status(
-                cerberus_url,
-                start_time,
-                end_time
-            )
-            if not application_routes_status:
-                logging.error(
-                    "Application routes: %s monitored by cerberus "
-                    "encountered downtime during the run, failing"
-                    % unavailable_routes
-                )
-            else:
-                logging.info(
-                    "Application routes being monitored "
-                    "didn't encounter any downtime during the run!"
-                )
-
-        if not cerberus_status:
-            logging.error(
-                "Received a no-go signal from Cerberus, looks like "
-                "the cluster is unhealthy. Please check the Cerberus "
-                "report for more details. Test failed."
-            )
-
-        if not application_routes_status or not cerberus_status:
-            sys.exit(1)
-        else:
-            logging.info(
-                "Received a go signal from Ceberus, the cluster is healthy. "
-                "Test passed."
-            )
-    return cerberus_status
-
-
-def publish_kraken_status(config, failed_post_scenarios, start_time, end_time):
-    """
-    Publish kraken status to cerberus
-    """
-    cerberus_status = get_status(config, start_time, end_time)
-    if not cerberus_status:
-        if failed_post_scenarios:
-            if config["kraken"]["exit_on_failure"]:
-                logging.info(
-                    "Cerberus status is not healthy and post action scenarios "
-                    "are still failing, exiting kraken run"
-                )
-                sys.exit(1)
-            else:
-                logging.info(
-                    "Cerberus status is not healthy and post action scenarios "
-                    "are still failing"
-                )
-    else:
-        if failed_post_scenarios:
-            if config["kraken"]["exit_on_failure"]:
-                logging.info(
-                    "Cerberus status is healthy but post action scenarios "
-                    "are still failing, exiting kraken run"
-                )
-                sys.exit(1)
-            else:
-                logging.info(
-                    "Cerberus status is healthy but post action scenarios "
-                    "are still failing"
-                )
-
-
-def application_status(cerberus_url, start_time, end_time):
-    """
-    Check application availability
-    """
-    if not cerberus_url:
-        logging.error(
-            "url where Cerberus publishes True/False signal is not provided."
-        )
-        sys.exit(1)
-    else:
-        duration = (end_time - start_time) / 60
-        url = "{baseurl}/history?loopback={duration}".format(
-            baseurl=cerberus_url,
-            duration=str(duration)
-        )
-        logging.info(
-            "Scraping the metrics for the test "
-            "duration from cerberus url: %s" % url
-        )
-        try:
-            failed_routes = []
-            status = True
-            metrics = requests.get(url, timeout=60).content
-            metrics_json = json.loads(metrics)
-            for entry in metrics_json["history"]["failures"]:
-                if entry["component"] == "route":
-                    name = entry["name"]
-                    failed_routes.append(name)
-                    status = False
-                else:
-                    continue
-        except Exception as e:
-            logging.error(
-                "Failed to scrape metrics from cerberus API at %s: %s" % (
-                    url,
-                    e
-                )
-            )
-            sys.exit(1)
-    return status, set(failed_routes)

kraken/chaos_recommender/__init__.py

@@ -1,3 +0,0 @@
-from .analysis import *
-from .kraken_tests import *
-from .prometheus import *

kraken/chaos_recommender/analysis.py

@@ -1,90 +0,0 @@
-import logging
-
-import pandas as pd
-import kraken.chaos_recommender.kraken_tests as kraken_tests
-import time
-
-threshold = .7  # Adjust the threshold as needed
-heatmap_cpu_threshold = .5
-heatmap_mem_threshold = .5
-
-KRAKEN_TESTS_PATH = "./kraken_chaos_tests.txt"
-
-#Placeholder, this should be done with topology
-def return_critical_services():
-    return ["web", "cart"]
-
-
-def load_telemetry_data(file_path):
-    data = pd.read_csv(file_path, delimiter=r"\s+")
-    return data
-
-def calculate_zscores(data):
-    zscores = pd.DataFrame()
-    zscores["Service"] = data["service"]
-    zscores["CPU"] = (data["CPU"] - data["CPU"].mean()) / data["CPU"].std()
-    zscores["Memory"] = (data["MEM"] - data["MEM"].mean()) / data["MEM"].std()
-    zscores["Network"] = (data["NETWORK"] - data["NETWORK"].mean()) / data["NETWORK"].std()
-    return zscores
-
-def identify_outliers(data):
-    outliers_cpu = data[data["CPU"] > threshold]["Service"].tolist()
-    outliers_memory = data[data["Memory"] > threshold]["Service"].tolist()
-    outliers_network = data[data["Network"] > threshold]["Service"].tolist()
-
-    return outliers_cpu, outliers_memory, outliers_network
-
-
-def get_services_above_heatmap_threshold(dataframe, cpu_threshold, mem_threshold):
-    # Filter the DataFrame based on CPU_HEATMAP and MEM_HEATMAP thresholds
-    filtered_df = dataframe[((dataframe['CPU']/dataframe['CPU_LIMITS']) > cpu_threshold)]
-    # Get the lists of services
-    cpu_services = filtered_df['service'].tolist()
-
-    filtered_df = dataframe[((dataframe['MEM']/dataframe['MEM_LIMITS']) > mem_threshold)]
-    mem_services = filtered_df['service'].tolist()
-
-    return cpu_services, mem_services
-
-
-def analysis(file_path, chaos_tests_config):
-    # Load the telemetry data from file
-    data = load_telemetry_data(file_path)
-
-    # Calculate Z-scores for CPU, Memory, and Network columns
-    zscores = calculate_zscores(data)
-
-    # Identify outliers
-    outliers_cpu, outliers_memory, outliers_network = identify_outliers(zscores)
-    cpu_services, mem_services = get_services_above_heatmap_threshold(data, heatmap_cpu_threshold, heatmap_mem_threshold)
-
-    # Display the identified outliers
-    logging.info("======================== Profiling ==================================")
-    logging.info(f"CPU outliers: {outliers_cpu}")
-    logging.info(f"Memory outliers: {outliers_memory}")
-    logging.info(f"Network outliers: {outliers_network}")
-    logging.info("===================== HeatMap Analysis ==============================")
-
-    if cpu_services:
-        logging.info("Services with CPU_HEATMAP above threshold:", cpu_services)
-    else:
-        logging.info("There are no services that are using siginificant CPU compared to their assigned limits (infinite in case no limits are set).")
-    if mem_services:
-        logging.info("Services with MEM_HEATMAP above threshold:", mem_services)
-    else:
-        logging.info("There are no services that are using siginificant MEMORY compared to their assigned limits (infinite in case no limits are set).")
-    time.sleep(2)
-    logging.info("======================= Recommendations =============================")
-    if cpu_services:
-        logging.info(f"Recommended tests for {str(cpu_services)}  :\n {chaos_tests_config['CPU']}")
-        logging.info("\n")
-    if mem_services:
-        logging.info(f"Recommended tests for {str(mem_services)}  :\n {chaos_tests_config['MEM']}")
-        logging.info("\n")
-
-    if outliers_network:
-        logging.info(f"Recommended tests for  str(outliers_network)  :\n {chaos_tests_config['NETWORK']}")
-        logging.info("\n")
-
-    logging.info("\n")
-    logging.info("Please check data in utilisation.txt for further analysis")

kraken/chaos_recommender/kraken_tests.py

@@ -1,30 +0,0 @@
-def get_entries_by_category(filename, category):
-    # Read the file
-    with open(filename, 'r') as file:
-        content = file.read()
-
-    # Split the content into sections based on the square brackets
-    sections = content.split('\n\n')
-
-    # Define the categories
-    valid_categories = ['CPU', 'NETWORK', 'MEM', 'GENERIC']
-
-    # Validate the provided category
-    if category not in valid_categories:
-        return []
-
-    # Find the section corresponding to the specified category
-    target_section = None
-    for section in sections:
-        if section.startswith(f"[{category}]"):
-            target_section = section
-            break
-
-    # If the category section was not found, return an empty list
-    if target_section is None:
-        return []
-
-    # Extract the entries from the category section
-    entries = [entry.strip() for entry in target_section.split('\n') if entry and not entry.startswith('[')]
-
-    return entries

kraken/chaos_recommender/prometheus.py

@@ -1,96 +0,0 @@
-import logging
-
-import pandas
-from prometheus_api_client import PrometheusConnect
-import pandas as pd
-import urllib3
-
-
-saved_metrics_path = "./utilisation.txt"
-
-def convert_data_to_dataframe(data, label):
-    df = pd.DataFrame()
-    df['service'] = [item['metric']['pod'] for item in data]
-    df[label] = [item['value'][1] for item in data]
-
-    return df
-
-
-def convert_data(data, service):
-
-    result = {}
-    for entry in data:
-        pod_name = entry['metric']['pod']
-        value = entry['value'][1]
-        result[pod_name] = value
-    return result.get(service, '100000000000') # for those pods whose limits are not defined they can take as much resources, there assigning a very high value
-
-def save_utilization_to_file(cpu_data, cpu_limits_result, mem_data, mem_limits_result, network_data, filename):
-    df_cpu = convert_data_to_dataframe(cpu_data, "CPU")
-    merged_df = pd.DataFrame(columns=['service','CPU','CPU_LIMITS','MEM','MEM_LIMITS','NETWORK'])
-    services = df_cpu.service.unique()
-    logging.info(services)
-
-    for s in services:
-
-        new_row_df = pd.DataFrame( {"service": s, "CPU" : convert_data(cpu_data, s),
-                    "CPU_LIMITS" : convert_data(cpu_limits_result, s),
-                    "MEM" : convert_data(mem_data, s), "MEM_LIMITS" : convert_data(mem_limits_result, s),
-                    "NETWORK" : convert_data(network_data, s)}, index=[0])
-        merged_df = pd.concat([merged_df, new_row_df], ignore_index=True)
-
-
-
-    # Convert columns to string
-    merged_df['CPU'] = merged_df['CPU'].astype(str)
-    merged_df['MEM'] = merged_df['MEM'].astype(str)
-    merged_df['CPU_LIMITS'] = merged_df['CPU_LIMITS'].astype(str)
-    merged_df['MEM_LIMITS'] = merged_df['MEM_LIMITS'].astype(str)
-    merged_df['NETWORK'] = merged_df['NETWORK'].astype(str)
-
-    # Extract integer part before the decimal point
-    merged_df['CPU'] = merged_df['CPU'].str.split('.').str[0]
-    merged_df['MEM'] = merged_df['MEM'].str.split('.').str[0]
-    merged_df['CPU_LIMITS'] = merged_df['CPU_LIMITS'].str.split('.').str[0]
-    merged_df['MEM_LIMITS'] = merged_df['MEM_LIMITS'].str.split('.').str[0]
-    merged_df['NETWORK'] = merged_df['NETWORK'].str.split('.').str[0]
-
-    merged_df.to_csv(filename, sep='\t', index=False)
-
-def fetch_utilization_from_prometheus(prometheus_endpoint, auth_token, namespace, scrape_duration):
-    urllib3.disable_warnings()
-    prometheus = PrometheusConnect(url=prometheus_endpoint, headers={'Authorization':'Bearer {}'.format(auth_token)}, disable_ssl=True)
-
-    # Fetch CPU utilization
-    cpu_query = 'sum (rate (container_cpu_usage_seconds_total{image!="", namespace="%s"}[%s])) by (pod) *1000' % (namespace,scrape_duration)
-    logging.info(cpu_query)
-    cpu_result = prometheus.custom_query(cpu_query)
-    cpu_data = cpu_result
-
-
-    cpu_limits_query = '(sum by (pod) (kube_pod_container_resource_limits{resource="cpu", namespace="%s"}))*1000' %(namespace)
-    logging.info(cpu_limits_query)
-    cpu_limits_result = prometheus.custom_query(cpu_limits_query)
-
-
-    mem_query = 'sum by (pod) (avg_over_time(container_memory_usage_bytes{image!="", namespace="%s"}[%s]))' % (namespace, scrape_duration)
-    logging.info(mem_query)
-    mem_result = prometheus.custom_query(mem_query)
-    mem_data = mem_result
-
-    mem_limits_query = 'sum by (pod) (kube_pod_container_resource_limits{resource="memory", namespace="%s"})  ' %(namespace)
-    logging.info(mem_limits_query)
-    mem_limits_result = prometheus.custom_query(mem_limits_query)
-
-
-    network_query = 'sum by (pod) ((avg_over_time(container_network_transmit_bytes_total{namespace="%s"}[%s])) + \
-    (avg_over_time(container_network_receive_bytes_total{namespace="%s"}[%s])))' % (namespace, scrape_duration, namespace, scrape_duration)
-    network_result = prometheus.custom_query(network_query)
-    logging.info(network_query)
-    network_data = network_result
-
-
-    save_utilization_to_file(cpu_data, cpu_limits_result, mem_data, mem_limits_result, network_data, saved_metrics_path)
-    return saved_metrics_path
-
-

kraken/health/cerberus/config.py

@@ -0,0 +1,6 @@
+from dataclasses import dataclass
+
+
+@dataclass
+class CerberusConfig:
+    cerberus_url:     str

kraken/health/cerberus/healthcheck.py

@@ -0,0 +1,13 @@
+import requests as requests
+
+from kraken.health.cerberus.config import CerberusConfig
+from kraken.health.health import HealthChecker, HealthCheckDecision
+
+
+class CerberusHealthChecker(HealthChecker):
+    def __init__(self, config: CerberusConfig):
+        self._config = config
+
+    def check(self) -> HealthCheckDecision:
+        cerberus_status = requests.get(self._config.cerberus_url, timeout=60).content
+        return HealthCheckDecision.GO if cerberus_status == b"True" else HealthCheckDecision.STOP

kraken/health/cerberus/setup.py

@@ -4,24 +4,8 @@ import sys
 import json
 
 
+# Get cerberus status
 def get_status(config, start_time, end_time):
-    """
-    Function to get Cerberus status
-    
-    Args:
-        config
-            - Kraken config dictionary
-
-        start_time
-            - The time when chaos is injected
-        
-        end_time
-            - The time when chaos is removed
-
-    Returns:
-        Cerberus status
-    """
-    
     cerberus_status = True
     check_application_routes = False
     application_routes_status = True
@@ -59,24 +43,8 @@ def get_status(config, start_time, end_time):
     return cerberus_status
 
 
+# Function to publish kraken status to cerberus
 def publish_kraken_status(config, failed_post_scenarios, start_time, end_time):
-    """
-    Function to publish Kraken status to Cerberus
-    
-    Args:
-        config
-            - Kraken config dictionary
-        
-        failed_post_scenarios
-            - String containing the failed post scenarios
-
-        start_time
-            - The time when chaos is injected
-        
-        end_time
-            - The time when chaos is removed
-    """
-
     cerberus_status = get_status(config, start_time, end_time)
     if not cerberus_status:
         if failed_post_scenarios:
@@ -98,24 +66,8 @@ def publish_kraken_status(config, failed_post_scenarios, start_time, end_time):
                 logging.info("Cerberus status is healthy but post action scenarios " "are still failing")
 
 
+# Check application availability
 def application_status(cerberus_url, start_time, end_time):
-    """
-    Function to check application availability
-    
-    Args:
-        cerberus_url
-            - url where Cerberus publishes True/False signal
-
-        start_time
-            - The time when chaos is injected
-        
-        end_time
-            - The time when chaos is removed
-
-    Returns:
-        Application status and failed routes
-    """
-    
     if not cerberus_url:
         logging.error("url where Cerberus publishes True/False signal is not provided.")
         sys.exit(1)

kraken/health/health.py

@@ -0,0 +1,14 @@
+from abc import ABC, abstractmethod
+from enum import Enum
+
+
+class HealthCheckDecision(Enum):
+    GO = "GO"
+    PAUSE = "PAUSE"
+    STOP = "STOP"
+
+
+class HealthChecker(ABC):
+    @abstractmethod
+    def check(self) -> HealthCheckDecision:
+        pass

kraken/kube_burner/client.py

@@ -0,0 +1,102 @@
+import subprocess
+import logging
+import urllib.request
+import shutil
+import sys
+import kraken.prometheus.client as prometheus
+
+
+def setup(url):
+    """
+    Downloads and unpacks kube-burner binary
+    """
+
+    filename = "kube_burner.tar"
+    try:
+        logging.info("Fetching kube-burner binary")
+        urllib.request.urlretrieve(url, filename)
+    except Exception as e:
+        logging.error("Failed to download kube-burner binary located at %s" % url, e)
+        sys.exit(1)
+    try:
+        logging.info("Unpacking kube-burner tar ball")
+        shutil.unpack_archive(filename)
+    except Exception as e:
+        logging.error("Failed to unpack the kube-burner binary tarball: %s" % e)
+        sys.exit(1)
+
+
+def scrape_metrics(
+    distribution, uuid, prometheus_url, prometheus_bearer_token, start_time, end_time, config_path, metrics_profile
+):
+    """
+    Scrapes metrics defined in the profile from Prometheus and indexes them into Elasticsearch
+    """
+
+    if not prometheus_url:
+        if distribution == "openshift":
+            logging.info("Looks like prometheus_url is not defined, trying to use the default instance on the cluster")
+            prometheus_url, prometheus_bearer_token = prometheus.instance(
+                distribution, prometheus_url, prometheus_bearer_token
+            )
+        else:
+            logging.error("Looks like proemtheus url is not defined, exiting")
+            sys.exit(1)
+    command = (
+        "./kube-burner index --uuid "
+        + str(uuid)
+        + " -u "
+        + str(prometheus_url)
+        + " -t "
+        + str(prometheus_bearer_token)
+        + " -m "
+        + str(metrics_profile)
+        + " --start "
+        + str(start_time)
+        + " --end "
+        + str(end_time)
+        + " -c "
+        + str(config_path)
+    )
+    try:
+        logging.info("Running kube-burner to capture the metrics: %s" % command)
+        logging.info("UUID for the run: %s" % uuid)
+        subprocess.run(command, shell=True, universal_newlines=True)
+    except Exception as e:
+        logging.error("Failed to run kube-burner, error: %s" % (e))
+        sys.exit(1)
+
+
+def alerts(distribution, prometheus_url, prometheus_bearer_token, start_time, end_time, alert_profile):
+    """
+    Scrapes metrics defined in the profile from Prometheus and alerts based on the severity defined
+    """
+
+    if not prometheus_url:
+        if distribution == "openshift":
+            logging.info("Looks like prometheus_url is not defined, trying to use the default instance on the cluster")
+            prometheus_url, prometheus_bearer_token = prometheus.instance(
+                distribution, prometheus_url, prometheus_bearer_token
+            )
+        else:
+            logging.error("Looks like proemtheus url is not defined, exiting")
+            sys.exit(1)
+    command = (
+        "./kube-burner check-alerts "
+        + " -u "
+        + str(prometheus_url)
+        + " -t "
+        + str(prometheus_bearer_token)
+        + " -a "
+        + str(alert_profile)
+        + " --start "
+        + str(start_time)
+        + " --end "
+        + str(end_time)
+    )
+    try:
+        logging.info("Running kube-burner to capture the metrics: %s" % command)
+        subprocess.run(command, shell=True, universal_newlines=True)
+    except Exception as e:
+        logging.error("Failed to run kube-burner, error: %s" % (e))
+        sys.exit(1)