Refactor service bus stress tests to use stress test package format

[benbp]

More details on the stress test package layout: https://github.com/Azure/azure-sdk-tools/blob/main/tools/stress-cluster/chaos/README.md#creating-a-stress-test

This PR or a follow-on could use some replacement docs/links that outline how to build/test, since I deleted the current ones which were mostly specific to the prior script/container infrastructure.

I don't intend to merge this yet, but I wanted to put it up as an example of the stress test package format written for a real stress test, instead of just the examples in the tools repo.

The stress tests can be built and deployed via either the pipeline (to the prod cluster), or to the test cluster with eng/common/scripts/stress-testing/deploy-stress-tests.ps1 -Repository 'javascript/service-bus' -PushImages -Login

[richardpark-msft]

We should bring back the sample.env file - even if the resource creation is automated it's still good to see what the automation creates so you can easily fill it in with your pre-existing resources.

This is looking great though!

[richardpark-msft]

A comment in this file would useful, just to give some context on where this file gets consumed, etc..

[chradek]

This says optional list of scenarios, but I'm not sure I understand why it's optional for service bus. This just ensures that helm will create 1 instance of the job for each scenario, right? (Is it just optional because someone using this as an example may not need it?)

[benbp]

Correct, you don't need to supply a list of scenarios, you can just define the job and we don't to the foreach loop. The yaml comment is more intended for what I predict is the next stress test author copy/pasting from this one.

[richardpark-msft]

Not familiar with this - does .helmignore complement .gitignore?

If not, then we probably also want to avoid accidentally packaging up .env files, for instance.

[benbp]

Added it to be safe. Normally helmignore is just for helm package, which we don't do in this context. However, running helm upgrade|install|template will do a recursive walk, which creates annoying messages when there are symlinks in the node_modules directory:

walk.go:74: found symbolic link in path: /home/ben/sdk/azure-sdk-for-js/sdk/servicebus/service-bus/test/stress/node_modules/.bin/semver resolves to /home/
ben/sdk/azure-sdk-for-js/sdk/servicebus/service-bus/test/stress/node_modules/semver/bin/semver

[benbp]

I updated the helm ignore to just ignore app/ since I moved things in there related to your other comment (given the manifests only reference the docker file, which contains the files).

[benbp]

We should bring back the sample.env file - even if the resource creation is automated it's still good to see what the automation creates so you can easily fill it in with your pre-existing resources.

I created one with only the keys/values used by the tests so it's easier to fill in for a local context. There's also an example of the container injected env file here.

[benbp]

/check-enforcer reset

[benbp]

/check-enforcer evaluate

[chradek]

I think this looks great, and should be merged. I just had one question that's really just for my own clarification about the values.yaml file that I posted there.

[benbp]

/check-enforcer override