litmuschaos / litmus-docs Goto Github PK

BUG REPORT

What Happened: Chaos Operator and Chaos Runner Diagrams not showing in the Architecture/Chaos Execution Plane Docs for v2.1 and v2.2

What You Expected to Happen: Chaos Operator and Chaos Runner Diagrams should be appearing in the Architecture/Chaos Execution Plane Docs for v2.1 and v2.2, just as it is in master and v2.0

How to Reproduce It (as minimally and precisely as possible): Check Architecture/Chaos Execution Plane docs for v2.1 and v2.2

BUG REPORT

What happened:

Google search for Litmus Version 1 docs lead to pages that gives a status code of 404.

The issue is caused due to the change in the URL of the Litmus v1 documentation.

Google Search Result: https://docs.litmuschaos.io/docs/1.7.0/openshift-litmus/ (404 error)

Corrected Link found on browsing the Docs: https://v1-docs.litmuschaos.io/docs/1.7.0/openshift-litmus/ (Working)

What you expected to happen:

There should be a redirection from the older URL to the newer URL.

How to reproduce it (as minimally and precisely as possible):

• Perform a Google Search: litmus chaos openshift
• Selecting the First Search Result

Incorrect Architecture Summary Diagram

What happened: The architecture summary diagram is incorrect as it fails to properly depict the flow of information between the Chaos Control Plane, and the Chaos Execution Plane via the single-sided arrow between the GraphQL server and the Subscriber, since the Subscriber as well as the Event Tracker can send data to the GraphQL server.

What you expected to happen: A double-ended arrow between the GraphQL server and the Litmus Agent Infra should be present.

Is this a BUG REPORT

What happened:
I followed the instructions to use Dex for litmus chaos center but it did not work when following the documentation. Apparently, the litmus-server deployment requires some more environmental variables to be set which are not described in the how-to. Those are:

    DEX_OAUTH_CLIENT_SECRET: <client secret for dex static client>
    DEX_OAUTH_CLIENT_ID: <client ID of dex static client>

The two ENV vars are required in the oauth2 config:
https://github.com/litmuschaos/litmus/blob/2.6.0/litmus-portal/authentication/api/handlers/rest/dex_auth_handler.go#L26-L27

What you expected to happen:
The litmus docs to include all the required details to make litmus <-> dex integration work

How to reproduce it (as minimally and precisely as possible):
Following the documentation will lead to an error page when trying to authenticate via the /auth/dex/login endpoint complaining about the client_id to be empty ("").

Anything else we need to know?:
There had been some more bugs that seem to be fixed in master already like the change of ENV var names (DEX_SERVER -> DEX_ENABLED, etc.)

What happened:
Installed litmusctl and executed it. I got a MacOS system dialog that said 'we could not verify that the binary is free from malware' or something along those lines.

What you expected to happen:
litmusctl executes.

How to reproduce it (as minimally and precisely as possible):
As above, just download and execute. MacOS 10.15.7

Anything else we need to know?:
Fix is to run xattr -d com.apple.quarantine <path-to-binary>

Is this a BUG REPORT or FEATURE REQUEST?

Choose one: BUG REPORT or FEATURE REQUEST

Issue Type
FEATURE REQUEST

Description
We would like to suggest LitmusChaos to define the following details about $subject.

• Target endpoint:port details which will be essential when the agent cluster is private and has restrictions imposed on inbound and outbound communication.
• Complete details of the authentication and authorisation process between the Litmus Agent and the Control Plane.

Advanced details of the above topics can be obtained from this Slack Channel thread.

What happened:
Links for ChaosCenter and ChaosAgent are missing to get detailed information

What you expected to happen:
Clicking on ChaosCenter should open: https://docs.litmuschaos.io/docs/getting-started/resources#chaoscenter
Clicking on ChaosAgent should open: https://docs.litmuschaos.io/docs/getting-started/resources#chaosagents

How to reproduce it (as minimally and precisely as possible):

• open chaos-workflow
• Under Prerequisites heading, check ChaosCenter & ChaosAgent (links are missing)

What happened:
Edit Page option redirects to the wrong GitHub source page (which results to an error 404)

What you expected to happen:
Should open a correct GitHub source page.

How to reproduce it (as minimally and precisely as possible):

• Open what-is-litmus
• Scroll down to the bottom of the page
• Click on Edit Page
• Should redirect to GitHub page (Instead it opens wrong source page)

What happened:
Typo on Resources page

What you expected to happen:
Typo under ChaosAgents heading. Word is written as atleast . Should be at least

How to reproduce it (as minimally and precisely as possible):

• Open ChaosAgents
• Word is written as atleast

FEATURE REQUEST

What happened: There is a Lack of Clarity On the Behaviour of GitOps on Adding a new Workflow to the Repo

What you expected to happen: The User Guide on GitOps should properly clarify the exact behaviour when a new workflow manifest is added to an existing repository with GitOps configured.

There are two installation modes(Cluster and namespaced mode). The documentation does not state what the difference between the two modes is or when it is beneficial to use either of them. This might be somewhat confusing to a first time reader who is a beginner.

Is this a BUG REPORT or FEATURE REQUEST?

BUG REPORT

What happened:
I went through the litmus-docs documentation and would like to discuss an issue so when we go through the Getting started guide under the Run-your-first-workflow section the katacoda link present under various-ways-of-learning-litmus does works since is no longer accessible due to the closure of the Katacoda platform.

What you expected to happen:
Due to the closure of the Katacoda platform, the scenario and its associated content are no longer accessible. As a result, users like me are unable to follow the scenario as intended and benefit from the hands-on experience it offered.

How to reproduce it (as minimally and precisely as possible):
I recommend removing the link labeled "Learn by Running a Sample Katacoda Scenario" from the "Run Your First Workflow" section. Additionally, the text referencing the Katacoda scenario should also be removed to avoid confusion for users who may attempt to access it. By removing this link and associated text, we can ensure that users are not directed to inaccessible content and that our documentation remains accurate and reliable.

Anything else we need to know?:

When going to docs from mainpage I visit a broken link

https://docs.litmuschaos.io/docs/getstarted/

The pre-requisite section states the versions of Kubernetes needed, and the amount of storage needed to get started but it does not state the pre-requisite knowledge that might be good to acquire before learning Litmus.

This can include but is not Limited to Kubernetes, Understanding what Chaos Engineering is and why it’s important, Cloud Native technologies, etc.

For example, taking a look at the Chaos Engineering Resources section of this amazing resources page before learning Litmus can be quite helpful to anyone who has never done Chaos Engineering but is looking at getting started with it using Litmus. It pretty much helped me understand the important of Chaos Engineering too.

What happened:
Link written in a wrong manner for ChaosAgent on run-your-first-workflow page.

What you expected to happen:
Presently it is written as resources#chaosagents. Should be resources.md#chaosagents

How to reproduce it (as minimally and precisely as possible):

• Click on run-your-first-workflow
• Below schedule-your-first-workflow check the link for ChaosAgent

The “Install with Helm” section does not have an “Install with Helm” title on the Control Plane(Cluster Mode) installation section.

Is this a BUG REPORT or FEATURE REQUEST?

BUG REPORT

What happened:
The search in the docs shows nothing even if we search keywords present in the docs.

What you expected to happen:
The search results according to the keyword.

How to reproduce it (as minimally and precisely as possible):

BUG REPORT

FAQ link in the website footer is broken; it leads to a URL that gives a 404 response

What happened: The FAQ link in the website footer is broken and redirects to https://docs.litmuschaos.io/docs/faq-general/

What you expected to happen: The FAQ link in the website footer should redirect to https://docs.litmuschaos.io/docs/faq/

How to reproduce it (as minimally and precisely as possible): Access the FAQ link in the website footer

Is this a BUG REPORT or FEATURE REQUEST?

BUG REPORT

What happened:
The podMonitor example under the "Prometheus community version (helm) - kube-prometheus-stack with pod monitor" section will scrap the metric from all the pods which port is TCP and the pod with target label.

What you expected to happen:
It should only scrape the metric from the target pod by combining two array items under the podMetricsEndpoints into a single item.

FEATURE REQUEST

Add m-agent user documentation for the following items:

• Why do we need m-agent
• How to install and uninstall m-agent
• How to use m-agent

Is this a BUG REPORT or FEATURE REQUEST?

Choose one: BUG REPORT or FEATURE REQUEST

What happened:

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Taking a look at the Pull Request & Issue templates, it doesn't quite suite the needs of this repository. Here's why;

Issue Template

• This repository does(or will) not take code contributions actively, the website code is auto-generated by Docusaurus and there's rarely a need to update the documentation's "code".
• Majority of the updates(if not all) would be the contents of the documentation being updated mostly by editing, modifying or adding new markdown files.
• This repository would majorly take improvements to the existing documentations, updates that conform with new releases, or addition of new pages/contents but would rarely ever fix bugs or add features.

With this in mind, I do not think the focus of the issue templates should be bug reports, or feature requests as these are more related to code than they are to documentation.

According to the contribution guide, Litmus documentation contributors are expected to:

• Improve existing content
• Create new content
• Maintain documentation framework
• Keep documentation builds healthy
• Manage and publish documentation as part of the Litmus release cycle

I think the issue templates should reflect the above and focus more on how to report issues that actual documentations face, documentation request, clarity, etc rather than issues that would mostly be encountered with regular codebases.

Pull Request

The pull request templates is as shown below;

<!--  Thanks for sending a pull request!  Here are some tips for you -->

**What this PR does / why we need it**:

**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #

**Special notes for your reviewer**:

**Checklist:**
-   [ ] Fixes #<issue number>
-   [ ] Signed the commit for DCO to be passed
-   [ ] Labelled this PR & related issue with `documentation` tag

This PR template looks good as it references an issue that already states the problem. But quite often, these issues might not state the solution the PR referenced. It might be helpful to add more context and ask actionable questions on what parts of the documentation changed and what changes were made to it.

❌ Deploy Preview for litmus-docs-411023 failed.

🔨 Explore the source changes: c6f49e4

🔍 Inspect the deploy log: https://app.netlify.com/sites/litmus-docs-411023/deploys/616967e2ee1dbe0007998d50

Originally posted by @netlify[bot] in #137 (comment)

What happened:
There is a typo on chaos-workflow page (word: imapact)

What you expected to happen:
There exists a word imapact which should be impact

How to reproduce it (as minimally and precisely as possible):

• Open chaos-workflow
• Read the very first line.

Is this a BUG REPORT or FEATURE REQUEST?

Choose one: BUG REPORT

https://docs.litmuschaos.io/docs/architecture/chaos-control-plane in dark mode shows the unreadable img.

This can be solved by changing the transparent png with white bg as below:

What happened:
Link for the Sign your work should be this and not this. Current link will just open the CONTRIBUTING.md

What you expected to happen:
Clicking on Sign you work should open: https://github.com/litmuschaos/litmus/blob/master/CONTRIBUTING.md#sign-your-work-with-developer-certificate-of-origin

How to reproduce it (as minimally and precisely as possible):

• Open what-is-litmus page
• Scroll down to the bottom
• Click on Sign your work (Will open the correct page but the won't redirect to actual content)

FEATURE REQUEST?

Dex also supports other connectors besides GitHub and Google. I've tried to use Microsoft Azure AD and it is working fine. Can we add a note that other connectors are supported too or include them in the sample configuration.

This is a working configuration for Microsoft connector

    connectors:
      - type: microsoft
        id: microsoft
        name: Microsoft
        config:
          clientID: # Add your Microsoft Azure Client ID here
          clientSecret: # Add your Microsoft Azure Client Secret here
          redirectURI: http://<NODE_IP>:32000/callback
          tenant: # Add your Microsoft Azure Tenant ID here (if applicable)

There are a few errors around typography, punctuations, and ordering of items in a few places across the documentation. Also, I think the formatting can be improved;

• Using headers where necessary.
• Dividing parts of the documentation using sub-header.
• etc

The documentation assumes that I, as a first-time reader(or beginner), have pre-requisite knowledge of certain terms and concepts widely used across the documentations. For example, I saw the use of terms like “GitOps”, “CRDs”, "CRs", “Operators”, “Schedulers”, “kubeconfig”, etc in different places. I am familiar with some of this terms, but I had to Google my way through some of them or reference the 1.x docs.

It would be useful to add hyperlinks to such terms, these hyperlinks would link to a page explaining these terms.

Additionally, if no such pages exist(yet). We could create a glossary page that lists all of these terms and gives a short and concise explanation of what they mean with possible links to where you could read more about them.

Is this a BUG REPORT or FEATURE REQUEST?

BUG REPORT

What happened:
Difficulty in readability of certain names
Non-uniform text highlights and font sizes
Changing to dark mode readability of purple text boxes reduces
What you expected to happen:
Renaming of chaos-infrastructure-installation to Chaos Infrastructure Installation
Highlighting entire text "continuously verifying if your service is resilient against faults"
Uniformity in font size
Dark mode toggle should not change the box/text color for Note
How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

This section starts with the sentence, “Click on the Schedule your first workflow button on the home page to get started....”. I think it would be useful to show screenshot(s) of what is to be clicked. The same issue occurred across this section and it might be useful to add screenshots of actions to be taken and/or a video explanation in this section and every other section where it is needed.

BUG REPORT

What Happened: Architecture Section Diagrams are Not Properly Visible in Dark Mode

What you expected to happen: Architecture section diagrams should have a white contrast to be properly visible in dark mode

How to reproduce it (as minimally and precisely as possible): View the architecture section diagrams in dark mode.

BUG REPORT

What happened:
The release name prom on Prometheus helm installation details on this page: https://docs.litmuschaos.io/docs/integrations/prometheus/#prometheus-community-version-helm---kube-prometheus-stack-with-pod-monitor doesn't match with the provided PodMonitor release name prometheus-stack.

The service discovery never discover the podmonitor because is looking for a podmonitor with a label release: prom instead of release: prometheus-stack

What you expected to happen:

helm install prom prometheus-community/kube-prometheus-stack --namespace monitoring

should be

helm install prometheus-stack prometheus-community/kube-prometheus-stack --namespace monitoring

How to reproduce it (as minimally and precisely as possible):

1. Run:

helm install prom prometheus-community/kube-prometheus-stack --namespace monitoring

2. Apply the PodMonitor:

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: chaos-exporter-monitor
  namespace: monitoring
  labels:
    release: prometheus-stack
spec:
  selector:
    matchLabels:
      app: chaos-exporter
  namespaceSelector:
    matchNames:
      - litmus
  podMetricsEndpoints:
    - port: tcp
    - interval: 1s
      metricRelabelings:
        - targetLabel: instance
          replacement: 'chaos-exporter-service'

Anything else we need to know?:
I suggest using a release name prometheus-stack with helm install because is following the naming convention used in the rest of the repository instead of changing the release name of the PodMonitor to prom.

Is this a BUG REPORT or FEATURE REQUEST?

BUG REPORT

What happened:
The ingress is not working without modifying the deployment and service names in the doc.

What you expected to happen:
The ingress should work

How to reproduce it (as minimally and precisely as possible):
In fresh k8s cluster (like kind) deploy nginx-ingress-controller.
Follow documentation for litmus helm chart deployment with ingress.
Try to access the chaos center from your browser (it should not work)
Fix deployment and service names and test again. You should be able to access the chaos center.

Anything else we need to know?:
I open pull request #137 with my working config.