UI-FRONTEND-IMPLEMENTATION

What happens:

• Adding a "JOIN US ON SLACK" which directs us to slack channel

What you expected to happen:

• The button goes in bottom-right corner when we open any window and should redirect to https://app.slack.com/client/T09NY5SBT/CNXNB0ZTN. The button will look like something like this :- https://www.stickpng.com/img/icons-logos-emojis/tech-companies/slack-new-logo-icon Anything else we need to know?:

• Issue related to Repository : https://github.com/litmuschaos/charthub.litmuschaos.io

• Rewrite/Refactor the authentication server to make it lightweight and modular so that
  • It can be moved into a separate repository
  • Handle different authentication modules
    • Local
    • Gmail Auth (Mandatory)
    • Github (Optional)
• Need a feature to reset the existing password.

What happened: I tried to follow several documentations now: first, second and none of the chaos experiments works. Nothing happens.

What you expected to happen: The documentation actually describes steps that match the code basis in the git repos (links do not work, resources are named differently, yaml files have different content). I really wanted to give litmus a try as it seems to be a cool project. But if you cannot even use it as a noob following a simple documentation, it really is no good. What worked for me was this (external!) guide.

How to reproduce it (as minimally and precisely as possible): Simply follow any of your documentations and tutorials step by step and try to understand what is (not) happening from the perspective of a noob.

Anything else we need to know?: I cannot file any PRs because I do not understand the code basis and currently have no time to work myself into it. I really want to give Litmus a try though. How can I help?

What this PR does / why we need it:

Code refactoring of header and BreadCrumbs.

Which issue this PR fixes:

fixes #1785

Checklist

• [x] Does this PR have a corresponding GitHub issue?
• [ ] Have you included relevant README for the chaoslib/experiment with details?
• [x] Have you added debug messages where necessary?
• [x] Have you added task comments where necessary?
• [x] Have you tested the changes for possible failure conditions?
• [ ] Have you provided the positive & negative test logs for the litmusbook execution?
• [ ] Does the litmusbook ensure idempotency of cluster state?, i.e., is cluster restored to original state?
• [ ] Have you used non-shell/command modules for Kubernetes tasks?
• [ ] Have you (jinja) templatized custom scripts that is run by the litmusbook, if any?
• [ ] Have you (jinja) templatized Kubernetes deployment manifests used by the litmusbook, if any?
• [ ] Have you reused/created util functions instead of repeating tasks in the litmusbook?
• [x] Do the artifacts follow the appropriate directory structure?
• [ ] Have you isolated storage (eg: OpenEBS) specific implementations, checks?
• [ ] Have you isolated platform (eg: baremetal kubeadm/openshift/aws/gcloud) specific implementations, checks?
• [ ] Are the ansible facts well defined? Is the scope explicitly set for playbook & included utils?
• [ ] Have you ensured minimum/careful usage of shell utilities (awk, grep, sed, cut, xargs etc.,)?
• [ ] Can the limtusbook be executed both from within & outside a container (configurable paths, no hardcode)?
• [ ] Can you suggest the minimal resource requirements for the litmusbook execution?
• [ ] Does the litmusbook job artifact carry comments/default options/range for the ENV tunables?
• [ ] Has the litmusbooks been linted?

Special notes for your reviewer:

What this PR does / why we need it:

Updated Redux, Community Page, SideBar and BreadCrumbs. Added profile icon, time series plots for community page, header, profile drop-down and notifications drop-down.

Which issue this PR fixes:

fixes #1571 fixes partially #1607

Checklist

• [ ] Does this PR have a corresponding GitHub issue?
• [ ] Have you included relevant README for the chaoslib/experiment with details?
• [ ] Have you added debug messages where necessary?
• [ ] Have you added task comments where necessary?
• [ ] Have you tested the changes for possible failure conditions?
• [ ] Have you provided the positive & negative test logs for the litmusbook execution?
• [ ] Does the litmusbook ensure idempotency of cluster state?, i.e., is cluster restored to original state?
• [ ] Have you used non-shell/command modules for Kubernetes tasks?
• [ ] Have you (jinja) templatized custom scripts that is run by the litmusbook, if any?
• [ ] Have you (jinja) templatized Kubernetes deployment manifests used by the litmusbook, if any?
• [ ] Have you reused/created util functions instead of repeating tasks in the litmusbook?
• [ ] Do the artifacts follow the appropriate directory structure?
• [ ] Have you isolated storage (eg: OpenEBS) specific implementations, checks?
• [ ] Have you isolated platform (eg: baremetal kubeadm/openshift/aws/gcloud) specific implementations, checks?
• [ ] Are the ansible facts well defined? Is the scope explicitly set for playbook & included utils?
• [ ] Have you ensured minimum/careful usage of shell utilities (awk, grep, sed, cut, xargs etc.,)?
• [ ] Can the limtusbook be executed both from within & outside a container (configurable paths, no hardcode)?
• [ ] Can you suggest the minimal resource requirements for the litmusbook execution?
• [ ] Does the litmusbook job artifact carry comments/default options/range for the ENV tunables?
• [ ] Has the litmusbooks been linted?

Special notes for your reviewer:

Proposed changes

• CSS bugs fixed
• Minor bug fixes for UI

Types of changes

What types of changes does your code introduce to Litmus? Put an x in the boxes that apply

• [x] Bugfix (non-breaking change which fixes an issue)

Checklist

• [x] I have read the CONTRIBUTING doc
• [x] I have signed the commit for DCO to be passed.
• [x] Lint and unit tests pass locally with my changes

Special notes for your reviewer:

Bug-fix PR

What happened:

When connecting the LitmusPortal agent, the following occurs in the log of the subscriber pod:

The fatal error is │ time="2021-07-13T01:54:30Z" level=fatal msg="invalid character 'p' after top-level value"

This happens every time.

The agent does not connect and every time, my subscriber fails on a CrashBackLoop. Could anyone advise?

│ time="2021-07-13T02:05:14Z" level=info msg="Go OS/Arch: linux/amd64"                                                                                                                              │
│ time="2021-07-13T02:05:14Z" level=info msg="all deployments up"                                                                                                                                   │
│ time="2021-07-13T02:05:14Z" level=info msg="all components live...starting up subscriber"                                                                                                         │
│ time="2021-07-13T02:05:14Z" level=fatal msg="invalid character 'p' after top-level value"                                                                                          

What you expected to happen:

The subscriber should start normally.

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

Connect the litmusctl agent with the portal.

Anything else we need to know?:

Proposed changes

This PR adds namespace scope installation configuration and required code changes for it to litmus-portal and also adds Okteto cloud dev environment setup.

fixes #2185 and #2186

Types of changes

What types of changes does your code introduce to Litmus? Put an x in the boxes that apply

• [x] New feature (non-breaking change which adds functionality)
• [x] Bugfix (non-breaking change which fixes an issue)
• [x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [x] Documentation Update (if none of the other choices applies)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• [x] I have read the CONTRIBUTING doc
• [x] I have signed the commit for DCO to be passed.
• [x] Lint and unit tests pass locally with my changes
• [x] I have added tests that prove my fix is effective or that my feature works (if appropriate)
• [x] I have added necessary documentation (if appropriate)

Dependency

• None.

Special notes for your reviewer:

Namespace mode for Litmus portal with Okteto cloud dev env setup and integration.

Litmus docs website has only black & white colors. It can be changed to attractive color combinations.

Note: It is recommended to use 2-3 color only

(ui-frontend-implementation): fixing the spacing in the side panel of the charts and link styling changes

What happens:

• The labels don't have equal spacings. Requires changes in css :

• Also the repository link clips through the side panel div. This needs a fix as well.

Anything else we need to know?:

• Issue related to Repository :https://github.com/litmuschaos/charthub.litmuschaos.io)
• Please raise a PR linking this issue to it and also attach the screenshot of your fix.

What happened: Executed Pod Network Latency Experiment, i do not see latency injected into the application

What you expected to happen: I have a very simple application deployed tom y K8S cluster. The demo application is based on this docker image

How to reproduce it (as minimally and precisely as possible): Created a basic deployment file that includes the above mentioned image. Created a service account based exactly as specified in this link. Chaos engine manifest also exactly looks like what was in the above mentioned link. I have replaced the app labels wherever appropriate. When I apply my chaos engine manifest, i can see that k8s creates a pod-network-latency pod as expected. When i look at the logs for the network latency pod, it is able to find the Application pod to inject latency into. Pumba pod appears to get created successfully. I have verified that the network interface of my application pod is eth0. The log files from network latency pod appear to be normal. Here is a sample from it

W0810 16:13:26.444004 1 client_config.go:541] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work. time="2020-08-10T16:13:26Z" level=info msg="[PreReq]: Getting the ENV for the experiment" time="2020-08-10T16:13:26Z" level=info msg="[PreReq]: Updating the chaos result of pod-network-latency experiment (SOT)" time="2020-08-10T16:13:26Z" level=info msg="The application informations are as follows\n" Namespace=MyNameSPace Label="app=kuard" Ramp Time=0 time="2020-08-10T16:13:26Z" level=info msg="[Status]: Verify that the AUT (Application Under Test) is running (pre-chaos)" time="2020-08-10T16:13:26Z" level=info msg="[Status]: Checking whether application pods are in running state" time="2020-08-10T16:13:26Z" level=info msg="The running status of Pods are as follows" Pod=kuard-deployment-6c65d5c8fb-trllp Status=Running time="2020-08-10T16:13:26Z" level=info msg="[Status]: Checking whether application containers are in running state" time="2020-08-10T16:13:26Z" level=info msg="The running status of container are as follows" container=kuard Pod=kuard-deployment-6c65d5c8fb-trllp Status=Running time="2020-08-10T16:13:26Z" level=info msg="[Info]: Details of application under chaos injection" NodeName=ip-10-98-83-22.ec2.internal ContainerName=kuard PodName=kuard-deployment-6c65d5c8fb-trllp time="2020-08-10T16:13:26Z" level=info msg="[Status]: Checking the status of the helper pod" time="2020-08-10T16:13:26Z" level=info msg="[Status]: Checking whether application pods are in running state" time="2020-08-10T16:13:28Z" level=info msg="The running status of Pods are as follows" Status=Running Pod=pumba-netem-judhlx time="2020-08-10T16:13:28Z" level=info msg="[Status]: Checking whether application containers are in running state" time="2020-08-10T16:13:28Z" level=info msg="The running status of container are as follows" container=pumba Pod=pumba-netem-judhlx Status=Running time="2020-08-10T16:13:28Z" level=info msg="[Wait]: Waiting for 300s till the completion of the helper pod" time="2020-08-10T16:13:28Z" level=info msg="helper pod status: Running" time="2020-08-10T16:13:29Z" level=info msg="helper pod status: Running" time="2020-08-10T16:13:30Z" level=info msg="helper pod status: Running" time="2020-08-10T16:13:31Z" level=info msg="helper pod status: Running" time="2020-08-10T16:13:32Z" level=info msg="helper pod status: Running" time="2020-08-10T16:13:33Z" level=info msg="helper pod status: Running" time="2020-08-10T16:13:34Z" level=info msg="helper pod status: Running" time="2020-08-10T16:13:35Z" level=info msg="helper pod status: Running"

I have port-forwarded my application on port 8080. When I access the website localhost:8080, i expect to see network latency, but i don't seem to see any. All XHR requests, that happens as part of the application are able to execute within 50 ms. Is this expected?

Anything else we need to know?:

What happened: Container kill experiment failed with error err: application container is not in running state, unable to find the pod with name -776cb96ff6-gktkk, err: pods "-776cb96ff6-gktkk" not found" as pod suffix will change once pod got killed and new pod has been created.

What you expected to happen: Experiment should pick newly created pod of set by ignoring pod suffix

Where can this issue be corrected? (optional)

How to reproduce it (as minimally and precisely as possible): By passing pod with suffix which changes when you kill the container into container kill experiment chaos engine

Anything else we need to know?:

This PR was automatically created by Snyk using the credentials of a real user.

Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.

Changes included in this PR

• Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
  • litmus-portal/frontend/package.json
  • litmus-portal/frontend/package-lock.json

Vulnerabilities that will be fixed

With an upgrade:

Severity | Priority Score (*) | Issue | Breaking Change | Exploit Maturity :-------------------------:|-------------------------|:-------------------------|:-------------------------|:------------------------- | 713/1000
Why? Proof of Concept exploit, Recently disclosed, Has a fix available, CVSS 6.4 | Prototype Pollution
SNYK-JS-JSON5-3182856 | Yes | Proof of Concept

(*) Note that the real score may have changed since the PR was raised.

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information: 🧐 View latest project report

🛠 Adjust project settings

📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:

🦉 Prototype Pollution

I am currently using litmus Chaos 2.14.0 . Wanted to know how can I add toleration in image specification for kind: ChaosExperiment. https://litmuschaos.github.io/litmus/experiments/concepts/chaos-resources/chaos-experiment/contents/#experiment-scopeI am facing issue while starting the job using go runner coz of taints.

For kind: Chaosengine the Runner Specification has the detail for toleration. but not able to see for ChaosExperiment. https://litmuschaos.github.io/litmus/experiments/concepts/chaos-resources/chaos-experiment/contents/#experiment-scope

Any suggestion?

Proposed changes

To implement the scenario name validation rules in the CreateChaosWorkflow function ,we can add a check for the validity of the scenario name before processing the workflow.

Types of changes

What types of changes does your code introduce to Litmus? Put an x in the boxes that apply

• [ ] New feature (non-breaking change which adds functionality)
• [ x] Bugfix (non-breaking change which fixes an issue)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Documentation Update (if none of the other choices applies)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• [ x] I have read the CONTRIBUTING doc
• [ ] I have signed the commit for DCO to be passed.
• [ ] Lint and unit tests pass locally with my changes
• [ ] I have added tests that prove my fix is effective or that my feature works (if appropriate)
• [ ] I have added necessary documentation (if appropriate)

Dependency

• Please add the links to the dependent PR need to be merged before this (if any).

Special notes for your reviewer:

This PR was automatically created by Snyk using the credentials of a real user.

Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.

Changes included in this PR

• Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
  • litmus-portal/frontend/package.json
  • litmus-portal/frontend/package-lock.json

Vulnerabilities that will be fixed

With an upgrade:

Severity | Priority Score (*) | Issue | Breaking Change | Exploit Maturity :-------------------------:|-------------------------|:-------------------------|:-------------------------|:------------------------- | 713/1000
Why? Proof of Concept exploit, Recently disclosed, Has a fix available, CVSS 6.4 | Prototype Pollution
SNYK-JS-JSON5-3182856 | Yes | Proof of Concept

(*) Note that the real score may have changed since the PR was raised.

Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information: 🧐 View latest project report

🛠 Adjust project settings

📚 Read more about Snyk's upgrade and patch logic

Learn how to fix vulnerabilities with free interactive lessons:

🦉 Prototype Pollution

Bumps jsonwebtoken from 8.5.1 to 9.0.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.