DEV Community: Vedant Shrotria

Logging using EFK for LitmusChaos

Vedant Shrotria — Tue, 05 Jul 2022 12:58:10 +0000

Hi Folks!!

In this article, we are going to discuss how we can set up logging using the EFK stack (Elastic-Search+FluentD+Kibana) for Litmuschaos experiments.

Firstly we will be doing a standard EFK setup on our k8s cluster and then we will see what filters we can use for fetching logs of a particular experiment run.

If you already have the EFK setup in your cluster which can fetch logs for all pods (or at least logs of pods in the Agent namespace), then you can skip to the logs filtering part through Kibana UI.

let us look at the components in this stack -

Elasticsearch is a real-time, distributed, and scalable search engine which allows for full-text and structured search, as well as for analytics. We will be using ElasticSearch for storing, filtering, and indexing our logs.

Kibana is a powerful data visualization frontend and dashboard for Elasticsearch. Kibana allows us to explore our Elasticsearch log data through a web interface, and build dashboards and queries to quickly answer questions and gain insight into your Kubernetes applications.

FluentD is a popular open-source data collector, that can be used to tail container log files, filter and transform the log data, and deliver it to the Elasticsearch cluster, where it can be indexed and stored.

Okay Okay, no more theory, without any further waiting let’s jump into it!!

EFK Stack configuration steps

The required manifests for fluentd and updated values.yml according to 7.17.1 version of ElasticSearch and Kibana are available here for reference.

For making sure while we are trying to implement this setup, we are using the same version as this blog, we can go ahead and clone the provided repository.

git clone git@github.com:Jonsy13/EFK-Setup.git
cd EFK-Setup

Creating separate namespaces for EFK setup

It’s generally a good practice to have the application deployed in separate namespaces that have different concerns concerning functionalities and behavior.

In our case, we are creating different namespaces for EFK to separate the setup from Litmus components so that we can reduce the risk of disaster to our EFK setup. We will be installing Kibana and ElasticSearch in elastic-kibana namespace and Fluentd in fluentd namespace.

kubectl create ns elastic-kibana 
kubectl create ns fluentd

Installing Elasticsearch cluster for data/logs for indexing and storage

We will be using the official helm chart for installing Elasticsearch.
Firstly, we will have to add Elastic helm repo using the below command

helm repo add elastic https://helm.elastic.co

Next, we can install the ElasticSearch using above added helm repository as below

cd ElasticSearch
helm install — values values.yaml elasticsearch elastic/elasticsearch -n elastic-kibana

For verifying the successful installation, we can check pods of our elastic-search cluster -

kubectl get pods -n elastic-kibana — selector=”app=elasticsearch-master”

Just after the installation, you might find the output of the above command below -

It can take some time for all pods to come in a ready state, as there is a Readiness probe configured for all pods of elastic-search cluster for configuration of the cluster.

Once the Readiness probe finishes and gets satisfied, all the pods will come in a Ready state.

Installing Kibana for checking/filtering logs using Web Interface

The above-provided official elastic helm repository, we added earlier also provides a chart for Kibana. So, we will use the official chart to install Kibana using the below command

cd Kibana
helm install — values values.yaml kibana elastic/kibana -n elastic-kibana

For verifying the successful installation, we can go ahead and check if all kibana resources are created successfully.

Installing FluentD for fetching logs, indexing, and storing

We will be installing FluentD as a Daemonset so that we can get logs for all pods scheduled on different nodes from the /var/log/ directory mounted on all the nodes.

cd FluentD
kubectl apply -f ./

There are 3 files present in FluentD directory.

manifest.yml — Manifest for deploying fluentd as daemonset, fetching logs from nodes, and exporting them to elasticsearch.

rbac.yml— Manifest for applying clusterRole, ClusterRoleBinding, and Service Account for fluentD.

config-map.yml — This configmap contains a configuration file for fluentD as its data which is mounted in all pods of the fluentD daemonset.

If we look at the data, we can see that we are adding an index_name to our logs which are getting filtered through this configuration file as fluentd-k8s. This index_name will be used for making our logs unique for filtering sources in Kibana UI.

  index_name fluentd-k8s

Complete configmap is available here

Accessing Logs on Kibana Web Interface

Now, with the current setup, fluentD will be fetching logs from all nodes and sending them to ElasticSearch. Now, for visualizing the stored logs from ElasticSearch, we will be using Kibana UI. So, Let’s open Kibana UI and check what are we getting there!!

When we open Kibana for the first time, we will be presented with a Welcome screen as below.

Since we already have our Elastic-Search setup, we don’t have to go for adding any new integrations. We can click on Explore on my own button for moving forward to the Homepage.

As we want to explore the logs that we are getting from ElasticSearch, we will have to create an index pattern to identify the logs which we want to explore. (You may want to only explore only some parts of logs according to the use case).

Let’s click on Discover Card and create an index pattern. After clicking on the Discover card, you will get a screen as below.

It can take some time for ElasticSearch to get filled up the logs. Once there are some logs available in ElasticSearch, we can proceed further and click on create index pattern button.

In the above screen, we can add a pattern for identifying our logs. I have added the pattern as fluentd-k8s* as we had the same tag added in the fluentd configuration for filtration. On the right side, if your added index pattern matches a source coming from ElasticSearch then it will also show us Your index pattern matches 1 source, which means that Kibana can match the pattern with logs and filter them out.

After adding the Name, we can click on create index pattern button for saving it. After saving the pattern, it will show you what are the different fields, that we can get from the log details in the table.

Now, once we have added our index pattern, we can click on Discover button in the sidebar for seeing the logs we are getting from ElasticSearch based on our index pattern.

Now, as we can see that we are getting logs for all the available pods. But we want to filter logs for fetching logs for specific pods, for that we will be using label filters.

Agent Plane Components pod logs

We have 5 components which are part of agent plane, lets look at the required filters for all of them one by one.

chaos-operator — For chaos-operator, we can use below label as filter kubernetes.labels.app.kubernetes.io/component=operator

chaos-exporter — For chaos-exporter, we can use below label as filter kubernetes.labels.app=chaos-exporter

subscriber — For subscriber, we can use below label as filter kubernetes.labels.app=subscriber

event-tracker — For event-tracker, we can use below label as filter kubernetes.labels.app=event-tracker

workflow-controller — For workflow-controller, we can use below label as filter kubernetes.labels.app=workflow-controller

Experiment pods logs —

So, for experiment run, All the experiment related pods for that particular run are labeled with a unique chaosUID i.e. kubernetes.labels.chaosUID.

So, how will you get the value of this label?

Well, once an experiment is completed, We can get chaosUID of that experiment run from the chaos results tab as can be seen below image.

So, using this label kubernetes.labels.chaosUID , we will be able to get logs for that experiment run. But it will be giving combined logs of experiment, runner and helper with this one label only as all chaos pods related to one experiment run are labelled with this label. but we want to distinguish between experiment, runner and helper pods logs also, right?

We will have to use one more labels which will be unique to particular Experiment pod, Runner pod & Helper pod. Let’s see how to achieve this.

For Experiment pod logs, we can use the below labels —

    1. kubernetes.labels.chaosUID: <chaosUID>

    2. kubernetes.labels.name: <experiment_name>

For Runner pod logs, we can use below labels -


    1. kubernetes.labels.chaosUID: <chaosUID>

    2. kubernetes.labels.app_kubernetes_io/component: ”chaos-runner”

For Helper pod logs, we can use the below labels -


    1. kubernetes.labels.chaosUID: <chaosUID>

    2. kubernetes.labels.name: <experiment-name>-helper-*

Let’s take an example of a pod-network-loss experiment,

In my case, the chaosUID is 839d4a33–8e3a-4df5-b05a-2d136160c90d

Now, for filtering logs of only the experiment pod, we will use these 2 labels -

1. kubernetes.labels.chaosUID: 839d4a33–8e3a-4df5-b05a-2d136160c90d

2. kubernetes.labels.name: pod-network-loss

For filtering logs of only helper pod, we will use these 2 labels -

1. kubernetes.labels.chaosUID: 839d4a33–8e3a-4df5-b05a-2d136160c90d

2. kubernetes.labels.name: pod-network-loss-helper-*

For filtering logs of only the runner pod, we will use these 2 labels -

1. kubernetes.labels.chaosUID: 839d4a33–8e3a-4df5-b05a-2d136160c90d
2. kubernetes.labels.app_kubernetes_io/component: ”chaos-runner”

So, as we can see now we can index our logs with a tag, store them in ElasticSearch and view & filter them on Kibana.

Well, this was my first try with EFK and that’s all I got to know about it’s working. Will be writing more as I get to work more on this. Thanks for checking this blog out!!

Conclusion

Feel free to check out our ongoing project — Chaos Center and do let us know if you have any suggestions or feedback regarding the same. You can always submit a PR if you find any required changes.

Make sure to reach out to us if you have any feedback or queries. Hope you found the blog informative!

If chaos engineering is something that excites you or if you want to know more about cloud-native chaos engineering, don’t forget to check out our LitmusChaos website, ChaosHub, and the LitmusChaos repo. Do leave a star if you find it insightful. 😊

I would love to invite you to our community to stay connected with us and get your Chaos Engineering doubts cleared.
To join our slack please follow the following steps!

Step 1: Join the Kubernetes slack using the following link: https://slack.k8s.io/

Step 2: Join the #litmus channel on the Kubernetes slack or use this link after joining the Kubernetes slack: https://slack.litmuschaos.io/

Cheers!

E2E Dashboard at LitmusChaos

Vedant Shrotria — Thu, 09 Jun 2022 12:27:58 +0000

In this article, we are going to discuss the dashboard we use for tracking our e2e-testing pipelines and how it is integrated with github-action pipelines.

Even before starting with the functionalities, you can check out the dashboard here.

Why?

Firstly, why do we need an E2E dashboard? Isn’t the github actions showing everything we needed or were there some more requirements that we had apart from what github actions offer?

So, when we started, we had just 2–3 pipelines with which it was easy to go through different pipeline runs and check how our nightly pipelines are working or what is the test coverage of our pipelines. But now when we have around 12–15 pipelines, it became difficult to understand the behavior of pipelines just by looking at some of the latest runs. As the main purpose of all pipelines is to help us understand our builds, find out issues before they happen, or find them as soon as possible even after release so that they can be fixed at the earliest. You can’t afford a bug that was added last month to be in the current month’s pipeline as debugging the same can take a very long time.

Now, the answer to all the above problems was to have some type of dashboard through which we can see the historical data of our pipelines whether it is nightly built or manually builds before release candidates or on-demand run. We wanted to see all the details like logs of the pipeline, name of pipeline run, last commit in the repository & the tag of LitmusChaos with which particular pipeline ran, Verdict of the pipeline, steps in the pipeline, etc. Having all these details in one place in UI as a dashboard would help us to have transparency between the developers as well as for checking the health of our product before any release candidate making us more confident in our product.

How is the progress going?

Okay no more waiting, Let’s have a walk-through of the dashboard and its different functionalities.

Firstly, let’s talk about the Homepage, which gives the Gods-Eye look at all the E2E pipelines. This screen contains all the pipelines (Manual & Nightly) along with their current status, last running timestamp & name of the repository where that pipeline is running.

The header contains buttons for navigating to only manual runs and nightly runs. This helps to distinguish between manual & nightly runs.

Nightly pipelines are running on daily basis automatically so that we can check status of all builds daily without having to manually trigger the pipelines.

Manual runs are done before/after release for checking the health of release builds and also in cases when we want to run E2E manually for testing any feature.

Deep dive into a Pipeline

When we click on Go to details on a particular pipeline card, It will navigate us to a new screen showing pipeline runs of that particular pipeline.

In the above screen, we can see the overall test coverage as well as see historical data of that particular pipeline. The tables show the pipeline-run ID, last running time, description (showing the last commit of the repository after which the pipeline was run), and Pipeline status.

If we click on a pipeline run id in the table, It will open a side modal showing pipeline details like jobs, steps running as part of jobs, the status of jobs, the status of steps, and the total time taken for that particular pipeline run.

Clicking on a Job will show steps running as part of that Job.

For checking the logs of a step, we can click on a step name and it will expand and shows logs for that step.

So, as we can see that this dashboard provides us everything in one place that we need to check status/health of our product. If we look at the tech-stack of this dashboard, The frontend is implemented using React JS & backend is implemented using Golang. The source code for the same is available here.

There are still some of the functionalities that are needed such as graphical UI for visualising historical data of pipelines, slack notifications/alerts & many more like this.

Conclusion

Feel free to check out our ongoing project — Chaos Center and do let us know if you have any suggestions or feedback regarding the same. You can always submit a PR if you find any required changes.

Make sure to reach out to us if you have any feedback or queries. Hope you found the blog informative!

I would love to invite you to our community to stay connected with us and get your Chaos Engineering doubts cleared.
To join our slack please follow the following steps!

Step 1: Join the Kubernetes slack using the following link: https://slack.k8s.io/

Step 2: Join the #litmus channel on the Kubernetes slack or use this link after joining the Kubernetes slack: https://slack.litmuschaos.io/

Cheers!

Cloud Native Application & Testing Automation

Vedant Shrotria — Mon, 14 Mar 2022 09:19:09 +0000

Hi Folks!!

In this article, we are going to discuss how we can create an automated pipeline using Github-Actions for a cloud-native application & use Cypress for testing the same.

If you are not much familiar with Cypress, you can also check my previous blog on End-To-End Testing Using Cypress for the same.

Okay, before starting with automation & pipeline, let's talk about some of the things that should be considered while choosing an environment for testing...

1. How does your application work & what are the resources it needs to be fully functional?

Here, we should think about how our application works as well as its functionalities. Well, the reason for this is that Your application can be cloud-native/monolithic & we might be able to run the same using docker/docker-compose or using k8s cluster as well.

If we can't run that application using docker/docker-compose, we need to look into the Kubernetes testing tools available.

In our case, ChaosCenter is a cloud-native application and also there is a chaos-agent component, which needs to run as a part of a k8s cluster. Simulation/Mocking of functionality is good for unit/integration testing, for end-to-end testing, we should try to have our testing environment as realistic as possible.

As we are planning more on the E2E testing and our application is also cloud-native, we chose to have a Kubernetes cluster on which we can deploy our application.

2. The testing environment will be transient or always running & which tool to use for provisioning the same?

Well, having a test environment that is always running helps to debug issues faster in the pipeline but at the same time as it is always running, it will be more costly. That cost can also be reduced by using spot instances on cloud providers like AWS. ( If you are using them :-) )

On the other side, if we automate the creation/deletion of the test environment as a part of the pipeline, it helps us to reduce the cost automatically, but at the same time, we have to pay in terms of time consumed for creation/deletion of our environment. Here, when we talk about debugging efforts, so yes we can create another pipeline that will automate the creation of the environment as well as testing but won't tear down the setup so that we can do debugging later and delete the environment manually.

With the above considerations, We finalized that we will be using a transient k8s cluster as our test environment. There are many tools like Minikube, KIND, K3s, K3D & many others which can be used as per requirements/use-case. In case you are using cloud providers, Tools like eksctl, gcloud, az, Terraform, Ansible & many other tools can also be used for the same.

After analyzing some of the tools mentioned above, we chose to go with K3d. The main reason behind choosing K3d is that we can create Loadbalancer services very easily in the K3d cluster without any extra configuration, Which on another side also allows us to have Ingress configuration as realistic as possible like cloud providers. This helped us when we wanted to test our application over loadBalancer & Ingress.

Okay okay, No more theory let's jump into steps....

Automation of Creation/Deletion of Clusters

As we discussed above, we don't want to have our testing cluster always running. So we need to automate the same as part of our pipeline.

As we are using Github-Actions workflows, K3d already has its GitHub-Action AbsaOSS/k3d-action@v2 that can be used for creating a transient cluster.

We can add this github-action as a step in our testing job as below.

- uses: AbsaOSS/k3d-action@v2
  name: Create 1st Cluster
  with:
    cluster-name: My-Test-Cluster
    args: >
       --agents 3
       --k3s-arg "--no-deploy=traefik, metrics server@server:*"

This will create a local cluster on GitHub-Runner VM and will be destroyed once the pipeline is completed.

Now, as you have created the cluster, let's also add one more step for basic checks of the cluster configuration.

- name: Configuring and Testing the Cluster Installation
  run: |
    kubectl cluster-info --context k3d-${{ env.SELF_AGENT }}
    kubectl get nodes
    kubectl get pods -n kube-system

This will do basic checks like checking nodes & pods in kube-system namespace. (You don't want to create a cluster locally just to check why is it not getting created, right?)

Application Setup

Well, we have created our test cluster & also added some validation checks. Let's automate the installation of our application in the pipeline.

For installing ChaosCenter, we use the k8s manifest which has all the components declared. Well, we could have added 2 simple commands for the same -

curl https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-portal/cluster-k8s-manifest.yml --output litmus-portal-setup.yml

kubectl apply -f litmus-portal-setup.yml

The above approach would have worked, but it's not flexible or scalable, right? What if there are more commands required for installation? I mean, we don't want to make our pipeline configuration very complex by adding the long list of commands, right?

We can use a bash script for the same. This will help in isolating all instructions related to the installation of the application. Also, future instructions can be added to the same script.

#application-installation.sh
#!/bin/bash

function install() {

    echo -e "\n---------------Installing Litmus-Portal in Cluster Scope----------\n"
    curl https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-portal/cluster-k8s-manifest.yml --output litmus-portal-setup.yml

    kubectl apply -f litmus-portal-setup.yml
}

install

Now, we can add a step in our pipeline workflow for executing this bash script.

- name: Deploying Litmus-Portal using **k8s-manifest**
  run: |
    chmod 755 ./litmus/application-installation.sh
    ./litmus/application-installation.sh

Now, coming to the issue here, If you have worked with a cloud-native application, you know it takes time for all pods to come in the Running state. So, we need to have some logic to wait for all pods to be ready before starting testing, otherwise, your tests will fail if the application is not ready.

We will extend our installation script to have some validation checks for application as well as to wait for all pods to be ready like we did for our k8s cluster.

#application-installation.sh
#!/bin/bash

function install() {

    echo -e "\n---------------Installing Litmus-Portal in Cluster Scope----------\n"
    curl https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-portal/cluster-k8s-manifest.yml --output litmus-portal-setup.yml

    kubectl apply -f litmus-portal-setup.yml
}

function wait_for_portal_to_be_ready(){

    echo -e "\n---------------Pods running in litmus Namespace---------------\n"
    kubectl get pods -n litmus

    echo -e "\n---------------Waiting for all pods to be ready---------------\n"
    # Waiting for pods to be ready (timeout - 360s)
    wait_for_pods litmus 360

    echo -e "\n------------- Verifying Namespace, Deployments, pods and Images for Litmus-Portal ------------------\n"
    # Namespace verification
    verify_namespace litmus

    # Deployments verification
    verify_all_components litmusportal-frontend,litmusportal-server litmus

    # Pods verification
    verify_pod litmusportal-frontend litmus
    verify_pod litmusportal-server litmus
    verify_pod mongo litmus
}

install
wait_for_portal_to_be_ready

Above bash-script will install or application as well as will make sure that the application is ready for testing by validating the status of pods as well as the existence of different resources like pods/deployments/namespaces.

If you are testing an static website/application, you can use

npm start &

And for docker-compose based applications -

docker-compose up &

Accessing the Application

Till now, we have automated the configuration of the Kubernetes cluster as well as our application setup. The next step is to automate the part, where we get access URL for the application & use it for E2E-Testing.

So, if you have already worked with k8s, you must already know that we can access an application on k8s using multiple types of services or even using port-forwarding.

Let's start with port-forwarding -

So, for accessing our application using port-forwarding, we can use this command -

kubectl port-forward svc/litmusportal-frontend-service 9091:9091 -n litmus

This will open a port-forwarded pipe from the port (9091) on the host machine to the port (9091, where our frontend pod is listening) of the pod deployed on a k8s cluster and allow us to access our frontend on port 9091 on localhost.

We can test the same by opening http://localhost:9091 & checking if we can access our frontend on the browser.

Well, this will work fine, but there is one issue.

If you run the above command, then you will no longer be able to access that terminal until and unless we stop the port-forwarding, this will hang our pipeline as this command will never complete.

That's where the ampersand symbol (&) comes to help. If we run the same command accompanied with a &, then it will start the port-forwarding process in the background & continue with other commands.

Well, we added the same in our pipeline & it started working fine for us.

Running Tests with generated Access Endpoint -

Finally, This part is easy with Cypress. As we are using Github-Actions, Cypress also provides a github-action, which can be used in the pipeline workflow very easily. Let's take a look at the step for the same.

- name: Running basic tests (Login and Onboarding Tests)
  uses: cypress-io/github-action@v2
  continue-on-error: false
  with:
    spec: cypress/integration/Basic_Setup/**/*.spec.js
    working-directory: Cypress/
    config-file: cypress.prod.json
    env: true
  env:
    CYPRESS_BASE_URL: ${{ env.URL }}

If we closely look at the above snippet, we can see that we are using cypress-io/github-action@v2 provided by Cypress & we are also providing some configurations.

Here,

spec - For the tests files we want to run, we can give the exact path or regex.
working-directory - Root directory where Cypress is installed or set up.
config-file - configuration file we want to use for testing. This is beneficial when we have multiple environments we want to test. In our case, We provide 2 modes of installation of LitmusChaos, so we created 2 different configurations for the same.

Last environment variables, We are providing BASE_URL as env CYPRESS_BASE_URL. This helps us not to hardcode the Access endpoint in our tests and take it according to the environment, so the same tests can be used for different environments.

With this setup, we completed our minimal complete automated testing pipeline.

Now, as a bonus, as I had said in starting that we are going to use the K3d cluster, Let's also look at why we chose to do so.

As we were using port-forwarding for accessing our frontend in the pipeline, there was one issue that we faced. Our tests were having little flakiness. After looking into the issue, we found the culprit. The tests were fine, but the port-forwarding pipe was getting closed in between sometimes. That was because of large chunks getting transferred through the pipe while testing through the frontend. The port-forwarding pipe is having a limit for timeout as well as the size of data/chunks getting transferred. Take a look at this issue for more details.

This was the time, we shifted from port-forwarding & started looking into other approaches like accessing the same using NodePort/LoadBalancer/Ingress from the k8s cluster while testing.

Now, for automating the above, we created custom functions in the bash script itself and used the same.

# Function to get Access point of ChaosCenter based on Service type(mode) deployed in given namespace
function get_access_point(){
    namespace=$1
    accessType=$2

    if [[ "$accessType" == "LoadBalancer" ]];then

        kubectl patch svc litmusportal-frontend-service -p '{"spec": {"type": "LoadBalancer"}}' -n ${namespace}
        export loadBalancer=$(kubectl get services litmusportal-frontend-service -n ${namespace} -o jsonpath="{.status.loadBalancer.ingress[0].ip}")
        wait_for_pods ${namespace} 360
        wait_for_loadbalancer litmusportal-frontend-service ${namespace}
        export loadBalancerIP=$(kubectl get services litmusportal-frontend-service -n ${namespace} -o jsonpath="{.status.loadBalancer.ingress[0].ip}")
        export AccessURL="http://$loadBalancerIP:9091"
        wait_for_url $AccessURL
        echo "URL=$AccessURL" >> $GITHUB_ENV

    elif [[ "$accessType" == "Ingress" ]];then

        setup_ingress ${namespace}
        # Ingress IP for accessing Portal
        export AccessURL=$(kubectl get ing litmus-ingress -n ${namespace} -o=jsonpath='{.status.loadBalancer.ingress[0].ip}' | awk '{print $1}')
        echo "URL=http://$AccessURL" >> $GITHUB_ENV

    else 
        # By default NodePort will be used. 
        export NODE_NAME=$(kubectl -n ${namespace} get pod  -l "component=litmusportal-frontend" -o=jsonpath='{.items[*].spec.nodeName}')
        export NODE_IP=$(kubectl -n ${namespace} get nodes $NODE_NAME -o jsonpath='{.status.addresses[?(@.type=="InternalIP")].address}')
        export NODE_PORT=$(kubectl -n ${namespace} get -o jsonpath="{.spec.ports[0].nodePort}" services litmusportal-frontend-service)
        export AccessURL="http://$NODE_IP:$NODE_PORT"
        echo "URL=$AccessURL" >> $GITHUB_ENV

    fi
}

Now, we called this function in our installation script and took accessType as env in bash script & passed it to this function.

If you are interested in learning more about the different custom functions that we used as in the above bash script, you can take a look at this utility bash script & also complete pipeline configuration can be found here

Conclusion

Feel free to check out our ongoing project - Chaos Center and do let us know if you have any suggestions or feedback regarding the same. You can always submit a PR if you find any required changes.

Make sure to reach out to us if you have any feedback or queries. Hope you found the blog informative!

If chaos engineering is something that excites you or if you want to know more about cloud-native chaos engineering, don’t forget to check out our Litmus website, ChaosHub, and the Litmus repo. Do leave a star if you find it insightful. 😊

I would love to invite you to our community to stay connected with us and get your Chaos Engineering doubts cleared.
To join our slack please follow the following steps!

Step 1: Join the Kubernetes slack using the following link: https://slack.k8s.io/

Step 2: Join the #litmus channel on the Kubernetes slack or use this link after joining the Kubernetes slack: https://slack.litmuschaos.io/

Cheers!

litmuschaos / litmus

Litmus helps SREs and developers practice chaos engineering in a Cloud-native way. Chaos experiments are published at the ChaosHub (https://hub.litmuschaos.io). Community notes is at https://hackmd.io/a4Zu_sH4TZGeih-xCimi3Q

LitmusChaos

Open Source Chaos Engineering Platform

Read this in other languages.

🇰🇷 🇨🇳 🇧🇷 🇮🇳

Overview

LitmusChaos is an open source Chaos Engineering platform that enables teams to identify weaknesses & potential outages in infrastructures by inducing chaos tests in a controlled way. Developers & SREs can practice Chaos Engineering with LitmusChaos as it is easy to use, based on modern Chaos Engineering principles & community collaborated. It is 100% open source & a CNCF project.

LitmusChaos takes a cloud-native approach to create, manage and monitor chaos. The platform itself runs as a set of microservices and uses Kubernetes custom resources (CRs) to define the chaos intent, as well as the steady state hypothesis.

At a high-level, Litmus comprises of:

Chaos Control Plane: A centralized chaos management tool called chaos-center, which helps construct, schedule and visualize Litmus chaos workflows
Chaos Execution Plane Services: Made up of a…

View on GitHub

Frontend Optimization at LitmusChaos

Vedant Shrotria — Tue, 01 Mar 2022 12:00:00 +0000

Hi Folks!!

Hmm, So you have already developed an application & you are looking at how to optimize it?

In this article, We will be taking you through the journey that we followed while working on frontend optimization at LitmusChaos.

Firstly, Why did we have to work on optimization for our frontend?

So, as we all know, first impressions make sure how further things are going to move forward, right? The same thing goes with your Software. And as we are talking about Software, When your client is going to open that great application you made, What if that application takes a very long time to load & they are waiting just to log in. And that even when that application is not even at its peak level or I would say it is not having a huge load on itself.

Well, the same thing happened to us. We have been working on ChaosCenter for quite a long time now and it has grown to a very large extent. Last year, We found that our application was taking around 50 seconds just to load a login page. This motivated us to look into it deeply.

Well, as a developer you always start with Developer-tools, right? We also did the same & started looking at chunks getting transferred while loading a single page. We found that it was transferring around ~5MBs when a user was just trying to load the login page for logging in.

Now, that is a problem, right? Your application shouldn't be taking that much time to load or even that much of a big chunk shouldn't be getting transferred just for a single page.

So, Are you ready for this journey?

Well, with the benchmarking numbers we had, we started digging into the working/bundling process of React JS & different ways of optimizing that. And Oh!, by the way, I forgot to tell you, Our application is built using React. So, many things are already taken care of.

While looking into the bundling process of Webpack, we got to know different styles of importing components (Static/Dynamic). Well, if your application is small, it doesn't matter which style you pick but an application like ours does matter.

This leads us to the concept of Lazy-loading & code-splitting.

Lazy-Loading & Code-splitting

Fortunately, we had written our codebase in such a way that all components are well isolated & implemented. The only problem there was that we were using static imports everywhere, due to which all the components were getting loaded, whichever was imported in a file. And when we started looking into our codebase, we found that we had a central file, which has the routing logic & all the pages/views were getting imported there.

Let's look at the below example snippet from our Router file.

import CreateWorkflow from '../../pages/CreateWorkflow';
import LoginPage from '../../pages/LoginPage';
import GetStarted from '../../pages/GetStartedPage';
import WorkflowDetails from '../../pages/WorkflowDetails'

# Router component
<Router history={history}>
  {/* <Routes /> */}
  <Routes />
</Router>

So If you see here, the router was working as intended, whenever a user started the app, it was routed to the sign-in page. But if we check the background, it was loading all the pages/views & then redirecting to the sign-in page.
Here, what we wanted was to just load the sign-in page & route to it.

So we started with Router-based code-splitting. We changed all static imports from static to dynamic imports using built-in lazy-loading from Webpack & React.

const CreateWorkflow = lazy(() => import('../../pages/CreateWorkflow'));
const LoginPage = lazy(() => import('../../pages/LoginPage'));
const GetStarted = lazy(() => import('../../pages/GetStartedPage'));
const WorkflowDetails = lazy(() => import('../../pages/WorkflowDetails'));

# Router component
<Suspense fallback={<Loader />} >
  <Router history={history}>
     {/* <Routes /> */}
     <Routes />
  </Router>
</Suspense>

With the above changes, On trying to login to the application, Webpack will fetch the Router component chunk & then only the Login-page chunk as only that is required.

Now, at this time, we tried to build our frontend. And believe me, we knew that we had something because we had divided our build chunks from having size 3MBs to 1.5-2MBs.

Moving ahead, We also followed the same approach at the components level & changed all component imports in our pages by analyzing user stories to dynamic ones.

Well, you might be having a question why would a component imported on a page be imported as dynamic?

Let's take an example, you can have a page, where on clicking on a button, you show a modal or in our case a complete Code Editor. Well, a code editor is a big component and users might not even click on that button. So, We changed the imports everywhere to dynamic ones. I think with this you must have got the point here.

The previous exercise had a great impact on our number of chunks (~98 chunks) & their sizes, (Obviously on load time as well) as you can see in the below screenshot.

Sources Tab, Your good friend?

We started digging more into different functionalities of Chrome, lighthouse & other tools. We found that Chrome provides a sources tab in Developer tools. Whenever we open an application or website, Source Tab provides us with all resources imported to that instance for having that software/website/app working as ideal. We saw that when we were just trying to open the Login page, It was importing all components from our component library, even though no other page/screen was getting loaded.

Okay okay, I didn't tell you, we also have our Component library (litmus-ui) built upon Rollup. This is a very well maintained & optimized component library that we use for our different products.

Well, interestingly, if you see in the above image, Our Login page was only using text-boxes & buttons. But, other components including analytics-related graphical components, icons & even lab components were getting loaded in the browser, which was not getting used or imported into the login page.

So, we started looking deeply in our Library, tried making some changes here & there, and tested with a small React App (Well, you don't want to wait for a build just for a single change, right). In all cases, it was importing all components from our library.

After looking into other component libraries, we found one pattern and that was for every component, they were having default exports along with named exports.

This ensured that no redundant code/components were loaded whenever a single component was imported from the library and also helped us in allowing path-based imports from our library as shown below.

# Previously only this was possible
import {ButtonFilled} from "litmus-ui";

# Now, all below given imports are possible
import { ButtonFilled } from "litmus-ui";
import { ButtonFilled } from "litmus-ui/core";
import { ButtonFilled } from "litmus-ui/core/Button";
import { ButtonFilled } from "litmus-ui/core/Button/ButtonFilled";
import ButtonFilled from "litmus-ui/core/Button/ButtonFilled";

What about Tree-shaking at the Components-library level?

Well, with the above analysis we were sure that tree-shaking in our library wasn't working as expected. We started looking into tree-shaking more at the library level.

We stepped inside node_modules, after many hits & trials and comparing other libraries, we found that our library wasn't even supporting tree-shaking. Let's see the reason in the below picture as well as rollup.config.js that we had earlier -

  output: [
    {
      dir: "dist",
      format: "cjs",
      sourcemap: true,
    },
  ],

In the above picture, if you see, our library was only bundled to cjs (commonJS) format, which doesn't support tree-shaking.

Then we started looking into what we can do to achieve it. Well, this was the time when we found that esm (ES Modules) format is the one that supports this. So we changed our configuration file of the library to create the bundle in esm format.

  output: [
    {
      dir: "dist",
      format: "cjs",
      sourcemap: true,
    },
    {
      dir: "dist",
      format: "esm",
      sourcemap: true,
    },
  ],

Well, in the above configuration, we had made one mistake i.e. we had given the same destination directory as dist in both outputs, which in return was overriding each other and we were only getting cjs format.

So we changed the output dir for esm to dist/esm, with this in place, we had our esm bundle generated.

Now, our rollup.config.js was looking like below -

  output: [
    {
      dir: "dist",
      format: "cjs",
      sourcemap: true,
    },
    {
      dir: "dist/esm",
      format: "esm",
      sourcemap: true,
    },
  ],

Still, the same result, React wasn't using the esm module in our application. And we were also having one question in our mind, well we have bundled our library in 2 formats but how are we going to tell React to use esm format?

After a little research, we found that we have to provide a path for esm bundle in the module field in package.json of our component library.

So, we added both paths for cjs & esm in package.json in the fields main & module respectively.

The above configuration made our library be used easily by both traditional bundlers as well as modern bundlers like webpack.

NOTE: Traditional bundlers who don't understand the esm type can make use of cjs with this configuration.

Well, while we were looking into this, we got our eyes on the build output of the library, we saw that it was creating only one chunk because we were giving only one entry-point in config.

We tried with an array of entry points (One root & one for only one of the components). And well, guess what we had achieved what we wanted. We tried importing the same component, and only that component was loaded.

input: ["./src/index.ts","./src/core/Button/ButtonFilled/index.ts" ],

So, now we had all the things with us and we knew what we had to do. Firstly we thought let's just make a rule for every developer to add an entry-point in an array whenever he/she adds a new component. But then we thought this can have issues as we can forget to do so every time, After all, We all are Humans :-).

So, we made a script in JS which would go through all components and extract their relative paths & provide them as an array to the entry point in the config input.

# scripts/inputs.js
const fs = require("fs");
const path = require("path");

const getAllEntryPoints = function (dirPath, arrayOfFiles) {
  let files = fs.readdirSync(dirPath);
  arrayOfFiles = arrayOfFiles || [];

  files.forEach(function (file) {
    if (fs.statSync(dirPath + "/" + file).isDirectory()) {
      arrayOfFiles = getAllEntryPoints(dirPath + "/" + file, arrayOfFiles);
    } else {
      if (file === "index.ts") {
        arrayOfFiles.push(path.join(dirPath, "/", file));
      }
    }
  });

  return arrayOfFiles;
};

export default getAllEntryPoints;


# In rollup.config.js

import getAllEntryPoints from "./scripts/inputs";
const input = getAllEntryPoints("./src");

And with this, we were able to make our library Tree-shakable & still developer-friendly at the same time.

Well, After this whole exercise & brain-storming, what we saw -

And with help of different compression techniques using brotli & gzip, we were able to achieve the below results -

This was a great exercise for us as we got to know more about the bundling process, optimization techniques as well as the working of component libraries.

Well, This is it for now, Thanks for staying with me till here, Will be sharing more..as this is going to be continued, let's see what can be done to go below 2 MBs without compression.

Conclusion

Feel free to check out our ongoing project - Chaos Center and do let us know if you have any suggestions or feedback regarding the same. You can always submit a PR if you find any required changes.

Make sure to reach out to us if you have any feedback or queries. Hope you found the blog informative!

I would love to invite you to our community to stay connected with us and get your Chaos Engineering doubts cleared.
To join our slack please follow the following steps!

Step 1: Join the Kubernetes slack using the following link: https://slack.k8s.io/

Step 2: Join the #litmus channel on the Kubernetes slack or use this link after joining the Kubernetes slack: https://slack.litmuschaos.io/

Cheers!

litmuschaos / litmus

Litmus helps SREs and developers practice chaos engineering in a Cloud-native way. Chaos experiments are published at the ChaosHub (https://hub.litmuschaos.io). Community notes is at https://hackmd.io/a4Zu_sH4TZGeih-xCimi3Q

LitmusChaos

Open Source Chaos Engineering Platform

Read this in other languages.

🇰🇷 🇨🇳 🇧🇷 🇮🇳

Overview

At a high-level, Litmus comprises of:

Chaos Control Plane: A centralized chaos management tool called chaos-center, which helps construct, schedule and visualize Litmus chaos workflows
Chaos Execution Plane Services: Made up of a…

View on GitHub

End-To-End Testing Using Cypress

Vedant Shrotria — Thu, 21 Jan 2021 06:29:44 +0000

Hello Everyone, I hope you all are rocking in your digital world. So, Here is my first blog, I will be sharing my experience and what i learned while working on end-to-end testing for Litmus-Portal. we will be going through how to get started with End-to-End testing with Cypress in any of your project and how litmus-Portal is using Cypress for testing different scenarios.Stay tuned till the end, you will get to know many awesome things.

Litmus-Portal provides console and UI experience for managing, monitoring, and events around chaos workflows. Chaos workflows consist of a sequence of experiments run together to achieve the objective of introducing some kind of fault into an application or the Kubernetes platform.Using Litmus-Portal, you can make your projects or products more resilient.

For doing all this and providing resiliency to your product, Litmus-Portal has to be resilient itself.That's where Cypress comes which helps us to test Litmus-Portal in different scenarios and makes it more resilient.

Cypress

Cypress is a modern frontend End-to-End testing tool using which we can write our tests in javascript as well as Typescript. It simplifies how we write our tests, makes our tests less flaky, and helps us in reducing maintenance cost of our project.

Why Cypress?

Well, we could have used some other framework for our purpose but, we wanted the one, which is easy to setup and reliable.There are many advantages of using Cypress -

Easy to setup, documentation is more than sufficient.
It helps us in adapting best practices for testing with it's documentation.
As Cypress shows all logs side by side to AUT (Application Under Test), it is very easy to debug our projects.
A plugins catalog provided by Cypress and it's community, which is very helpful to test different scenarios.
It is very easy to adapt, as it build on top of Mocha, Chai, chai-jQuery and many other libraries.

Installing Cypress

Cypress is an NPM package. We can install Cypress as a development dependency like

npm install cypress --save-dev

We can use Cypress in two modes -

Browser mode

For using Cypress in Browser Mode, we can make use of this command -

npx cypress open

This will open a browser for you, showing different default-test scripts. We can click on different scripts to execute them.

Headless mode

For using Cypress in Headless Mode, we can make use of this command -

npx cypress run

This will open a terminal for you, and start to execute the tests present in the Test scripts path (By default, Integration directory).

After executing this command,you will observe that some predefined directories and files have been added in your project -

-cypress
  |_fixtures
  |_integration
  |_plugins
  |_support
-cypress.json

Here, cypress is the directory that contains everything required for testing using Cypress.

fixtures/ - This directory contains all the static data (data you want to use for setting your Databases between tests or you want to input on your different screens) to be used while testing in form of JSON files.

An example of User.json (fixture file for users) is given below -

{
    "projectname":"litmus",
    "AdminName":"John",
    "AdminPassword":"admin1234",
    "AdminEmail":"admin@gmail.com",
    "NewName":"John",
    "NewPassword":"John123",
    "NewEmail":"John@gmail.com"
}

integration/ - This directory contains all the test scripts. We can configure a different location for storing our test scripts in cypress.json.
plugins/index.js - This file can contain configuration for all plugins installed.
support/commands.js - It will contain all the custom functions that we might need while writing our test so that we don't repeat ourselves.
support/index.js - This file contains any configurations for test cases. for e.g. by default cookies are not preserved between tests. They can be preserved add following code in this file -

// For preserving cookies between tests.
Cypress.Cookies.defaults({
    preserve: 'token'
});

cypress.json - This is a configuration file for Cypress.

An example of cypress.json is given below -

{
  "baseUrl": "http://localhost:3001",
  "experimentalFetchPolyfill": true,
  "viewportWidth": 1800,
  "viewportHeight": 1200,
  "defaultCommandTimeout": 10000,
  "chromeWebSecurity": false,
  "video": false,
  "experimentalNetworkStubbing":true,
  "env": {
    "authURL" : "http://localhost:3000",

  }
}

You will get to know more about them, as we proceed with testing different scenarios.

Let's have something in our pocket before moving on further -

DOM Selector - It is a selector that is used for selecting different objects in DOM for testing or automation. A Selector can be any CSS property, Ids, and Classes. But let me tell you when you make a product your CSS properties, ids, and classes keep changing, which might break our tests.

The best practice is to use a unique identifier which is not much subjected to change also which is unique on a particular page for identifying an element. While using Cypress, we have the support to use data-* attributes with our elements.

As a best-practice. we enforce everyone working on Litmus-Portal to use data-cy=<selector> selector to every different component, so that it can targeted easily by Cypress while testing. This practice is also preferred by Cypress test runner

In Cypress, We can query an element on DOM using the command cy.get(<Your_Selector>)

In Cypress, data-* are given high priority while querying, so it is a bit fast as well.

for example, If there is button like this,

<button class="btn1">Save</button>

We can inject a unique identifier like this

<button class="btn1" data-cy="save">Save</button>

Now, we can access this button like this

cy.get('[data-cy=save]');

Okay, now I think we are good with testing and Cypress, we will go deep while working with live scripts, but let's get our hands dirty a bit.

Firstly, for testing an App, We need an endpoint of our WebApp.

Let's say the endpoint of our web app is https://localhost:3001

In Cypress, We can visit this link by using the function visit()

cy.visit("https://localhost:3001");

But being a lazy person, we don't want to write this bigger link again and again in every test or even in different test scripts.

You will be happy to know, we can also set the endpoint in cypress.json for universal use in test scripts.

In cypress.json,

{
   "baseUrl":"https://localhost:3001"
}

Now, anywhere in the test script, we want to visit the link, we can just do

cy.visit("/");

Well, this setup will work well in local setup. But when we are working on different CI's, we won't be able to use it because every time we setup the full stack web app in CI, A dynamic Link will be getting generated.

As Litmus-Portal is a cloud native web application, we have to deploy it on kubernetes while testing on different CI's. Everytime we generate a new dynamic link using loadbalancer for accessing the frontend.So, for this we needed a better approach as we can't provide access link before deploying Litmus-Portal.

But Hurray, I have something for you, We can provide the link as an environment variable to cypress while starting testing using command -

CYPRESS_BASE_URL=$link npx cypress run

So, Cypress will use this URL as BaseURL while executing our test scripts.

Now, as we know how to query an element and how to open our web app to be tested, the Next thing is how we write tests for our app.

We will be using Litmus-portal as our web app for Testing.

Starting with login Page for Litmus-Portal.

While writing tests for the Login Page, we have to consider all scenarios including positive and negative tests.

A Positive scenario can be like this -

Visit the login page.
Find the input for the name and type our correct name in it.
Find the input for the password and type our correct password in it.
Click on the login button.
Check if we are landing on welcome modal after clicking on the login button.

A Negative scenario can be like this -

Visit the login page.
Find the input for the name and type a wrong name in it.
Find the input for the password and type a wrong password in it.
Click on the login button.
Check if we are prompted with the error "Wrong Credentials".

Let me give you a small script for login page testing,

This was what I wrote on my first try. So don't laugh.

describe("Checking functionality of Login Page",()=>{

    it("Testing the only single input sign in [ Should not be possible ]",()=>{
        cy.visit("/");
        cy.get('[data-cy=inputName] input').type(" ");
        cy.get('[data-cy=inputPassword] input').type("John123");
        cy.get('[data-cy=loginButton]').click();
        cy.contains("Wrong Credentials").should('be.visible');
    })

    it("Testing with wrong details [ Should not be possible ]",()=>{
        cy.visit("/");
        cy.get('[data-cy=inputName] input').type("Johnce");
        cy.get('[data-cy=inputPassword] input').type("John123");
        cy.get('[data-cy=loginButton]').click();
        cy.url().should('include','/login');
        cy.contains("Wrong Credentials").should('be.visible');
    })

    it("Testing with Correct details [ Must redirect to Welcome modal ]",()=>{
        cy.visit("/");
        cy.get('[data-cy=inputName] input').type("John");
        cy.get('[data-cy=inputPassword] input').type("John123");
        cy.get('[data-cy=loginButton]').click(); //Correct Details
        cy.contains("Welcome to Portal");
    })
})

If you have worked with Mocha before, then you must be knowing that it's BDD interface provide describe(), it(), beforeEach(), afterEach() and many other functions. If you don't, don't worry we will discuss all of them as we use them.

Here, describe() is mainly used for collecting all tests under a single umbrella (Test-suite) which are related to each other or similar in objective.

it() is the function which signifies one test or one scenario.

Also, you must be seeing some new interactive functions as well.
Let me explain what we are doing here.

cy.visit("/"); visits the login page.
cy.get("[data-cy=inputName]") finds the input field for name and type(<data_to_be_typed>) is used to type in the selected input field.
cy.contains(<text>) is used to search text on page.

You must be seeing that we are visiting the login page again and again and also writing the same functions many times.

Let's refactor it a bit with one more BDD function i.e. beforeEach().

beforeEach() is used when we want to do something before every test scenario or if something is common before every scenario.

describe("Checking functionality of Login Page",()=>{

    beforeEach(Visiting the login Page,()=>{
        cy.visit("/");
    });

    it("Testing the only single input sign in [ Should not be possible ]",()=>{
        cy.get('[data-cy=inputName] input').type(" ");
        cy.get('[data-cy=inputPassword] input').type("John123");
        cy.get('[data-cy=loginButton]').click();
        cy.contains("Wrong Credentials").should('be.visible');
    })

    it("Testing with wrong details [ Should not be possible ]",()=>{
        cy.get('[data-cy=inputName] input').type("Johnce");
        cy.get('[data-cy=inputPassword] input').type("John123");
        cy.get('[data-cy=loginButton]').click();
        cy.url().should('include','/login');
        cy.contains("Wrong Credentials").should('be.visible');
    })

    it("Testing with Correct details [ Must redirect to Welcome modal ]",()=>{
        cy.get('[data-cy=inputName] input').type("John");
        cy.get('[data-cy=inputPassword] input').type("John123");
        cy.get('[data-cy=loginButton]').click(); //Correct Details
        cy.contains("Welcome to Portal");
    })
})

One problem is solved, but we are still writing functions for logging in many times which are the same, just the value provided is different.

So here, we take the help of the Custom Commands facility provided by Cypress.

Now, we will create a custom function which will take username and password as arguments and login the user. We can add that function in commands.js inside Support directory.

In your support/commands.js file inside the support folder,

// Custom login function for logging In which takes username and password as parameters.
Cypress.Commands.add('login',(Username,Password)=>{
    cy.get('[data-cy=inputName] input').type(Username);
    cy.get('[data-cy=inputPassword] input').type(Password);
    cy.get('[data-cy=loginButton]').click();
})

Your test script will look like this,

// Here in the script, we can just call the custom login function that we made just by using cy.login(username, password). 
describe("Checking functionality of Login Page",()=>{

    beforeEach(Visiting the login Page,()=>{
        cy.visit("/");
    });

    it("Testing the only single input sign in [ Should not be possible ]",()=>{
        cy.login("John"," ");
        cy.contains("Wrong Credentials").should('be.visible');
    })

    it("Testing with wrong details [ Should not be possible ]",()=>{
        cy.login("Vedant","1234");
        cy.url().should('include','/login');
        cy.contains("Wrong Credentials").should('be.visible');
    })

    it("Testing with Correct details [ Must redirect to Welcome modal ]",()=>{
        cy.login("John","John123");
        cy.contains("Welcome to Portal");
    })
})

Currently, the above script will work fine if we are testing locally, but when we work on a production server or CI, There might be delays in response from backend server, Cypress might get timed out waiting for homepage to load.

For dealing with this situation, we can use one command i.e,

cy.wait(8000);

Here, cy.wait() will wait make the test to wait for constant time given as argument to wait() function.

But this will make our test slower when we wait for constant time.

So, the better approach here is to use aliases for waiting for request to get resolved.
Here is an example -

// Custom login function for logging In which takes username and password as parameters and also waits for data from server.
Cypress.Commands.add('login',(Username,Password)=>{
    cy.server();
    cy.route("POST", Cypress.env('apiURL')+"/query").as("detailsResponse");
    cy.get('[data-cy=inputName] input').type(Username);
    cy.get('[data-cy=inputPassword] input').type(Password);
    cy.get('[data-cy=loginButton]').click();
    cy.wait("@detailsResponse").its("status").should("eq", 200); //Request Done.
})

In above example, cy.server() will start a mock server and will be intercepting all requests from frontend. cy.route() will tell Cypress to intercept a request going on a particular route. We can mock response, status and many other parameters while intercepting a request using cy.route().

Now, for waiting for a request to get resolved, we have to make alias for that route using as(). as() makes alias of any route with given name, which the Cypress will remember for us.

cy.route("POST", Cypress.env('apiURL')+"/query").as("detailsResponse");

Now, we can wait for this request using cy.wait() by giving alias name to it and checking it's status property using its() function after executing our steps.

cy.wait("@detailsResponse").its("status").should("eq", 200); //Request Done.

Thanks for staying with me till here, In my next article, we will be discussing more about how to test other scenarios that we face in a project.Till then, you can always check their documentation here

If you are interested in learning more about different test scenarios in Litmus-Portal, Checkout our Litmus-Portal-E2E Repository here

Conclusion

Feel free to check out our ongoing project - Litmus Portal and do let us know if you have any suggestions or feedback regarding the same. You can always submit a PR if you find any required changes.

Make sure to reach out to us if you have any feedback or queries. Hope you found the blog informative!

I would love to invite you to our community to stay connected with us and get your Chaos Engineering doubts cleared.
To join our slack please follow the following steps!

Step 1: Join the Kubernetes slack using the following link: https://slack.k8s.io/

Step 2: Join the #litmus channel on the Kubernetes slack or use this link after joining the Kubernetes slack: https://slack.litmuschaos.io/

Cheers!

litmuschaos / litmus

Litmus helps SREs and developers practice chaos engineering in a Cloud-native way. Chaos experiments are published at the ChaosHub (https://hub.litmuschaos.io). Community notes is at https://hackmd.io/a4Zu_sH4TZGeih-xCimi3Q

LitmusChaos

Open Source Chaos Engineering Platform

Read this in other languages.

🇰🇷 🇨🇳 🇧🇷 🇮🇳

Overview

At a high-level, Litmus comprises of:

Chaos Control Plane: A centralized chaos management tool called chaos-center, which helps construct, schedule and visualize Litmus chaos workflows
Chaos Execution Plane Services: Made up of a…

View on GitHub