remove litmus links

Signed-off-by: Pallavi-PH <pallaviph02@gmail.com>
openebs · satyapriyamishra222 · Sep 2, 2021 · Aug 31, 2021 · Sep 1, 2021 · Sep 1, 2021
commit da4d14427305540af1cb00cfd461716acfa8f302
diff --git a/website/src/blogs/ha-vs-dr-and-ha-c2-b2-for-your-db.md b/website/src/blogs/ha-vs-dr-and-ha-c2-b2-for-your-db.md
@@ -85,7 +85,7 @@ So what should you do? A common pattern we have noticed involves letting the ind
 
 Here is where the ability to snapshot and move entire applications may be a good solution. We have seen OpenEBS itself being used in this way quite often with the help of Heptio’s Velero (Formerly Ark) plug-in. We are now adding capabilities to make the management of the entire workflow simpler so that each team has the necessary control to decide their approach while the broader organization can see their approaches in aggregate. This is the so-called DMaaS subproject, due for initial release in OpenEBS 0.9.
 
-Another pattern that I heard about occurred at Netflix many years ago, and is now known as chaos engineering. At MayaData, we employ a flavor of chaos engineering in our CI/CD end to end pipelines. For instance, we publish every commit to the OpenEBS master on [OpenEBS.ci](http://openebs.ci/) and subject them to chaos engineering under a variety of stateful workloads and across a number of environments from OpenShift to managed Kubernetes services like AKS. We have open-sourced all of this, enabling tooling for stateful workloads called Litmus ([https://openebs.io/litmus ](https://openebs.io/litmus))
+Another pattern that I heard about occurred at Netflix many years ago, and is now known as chaos engineering. At MayaData, we employ a flavor of chaos engineering in our CI/CD end to end pipelines. For instance, we publish every commit to the OpenEBS master on [OpenEBS.ci](http://openebs.ci/) and subject them to chaos engineering under a variety of stateful workloads and across a number of environments from OpenShift to managed Kubernetes services like AKS. We have open-sourced all of this, enabling tooling for stateful workloads called Litmus.
 
 The point here is to *apply chaos engineering to your HA and DR approaches so that you can actually see them work and fail*. Everything fails occasionally , including the systems that are intended to help you survive failure. What’s important is understanding the blast radius and determining how hard or easy it is to continue operation and recover with time?
 

diff --git a/website/src/blogs/openebs-0-6-serves-ios-amidst-chaos-and-much-more.md b/website/src/blogs/openebs-0-6-serves-ios-amidst-chaos-and-much-more.md
@@ -51,7 +51,7 @@ However, we wanted to solve as many of these issues as possible with the right a
 
 ## Solution : Chaos Engineered OpenEBS, the birth of Litmus.
 
-If you would like an introduction to the Litmus project, which we open sourced at KubeCon in Denmark, visit the following link: [https://openebs.io/litmus](https://openebs.io/litmus?__hstc=216392137.386b1bc3a48de21192b74b07a4e27366.1580120418429.1580120418429.1580120418429.1&__hssc=216392137.1.1580120418429&__hsfp=3765904294) or [https://github.com/openebs/litmus](https://github.com/openebs/litmus)
+If you would like an introduction to the Litmus project, which we open sourced at KubeCon in Denmark, visit the following link:  [https://github.com/openebs/litmus](https://github.com/openebs/litmus)
 
 We are also working on operators to add additional autonomic function into OpenEBS, leveraging improved metrics and advancements in CSI around node daemonsets and the mount-propagation feature. In the meantime, we use Litmus to increase automated real-world scenario testing to ensure improvements in every release. In this regard, a lot of effort has gone towards beefing up the tests that can simulate Chaos at Node, Network, Storage, RAM, and CPU. These typically contribute to Volume Pods switching nodes and, if not careful, interrupted IOs.
 

diff --git a/website/src/posts.json b/website/src/posts.json