Add ebs loss scenario #692
Conversation
jtydlack
force-pushed
the
detach_ebs_volumes
branch
2 times, most recently
from
6da4afc
to
0fc21a1
Compare
config/config.yaml
Outdated
| @@ -46,6 +46,8 @@ kraken: | |||
| - scenarios/kube/service_hijacking.yaml | |||
| - syn_flood: | |||
| - scenarios/kube/syn_flood.yaml | |||
| - aws: | |||
There was a problem hiding this comment.
lets try to put a clearer name of the scenario here, think this current name can get confusing
| @@ -0,0 +1,9 @@ | |||
| aws_access_key_id: # only if system-wide credentials are not | |||
There was a problem hiding this comment.
We might want to add a reference around setting up aws secrets similar to node scenarios: https://github.com/krkn-chaos/krkn/blob/main/docs/node_scenarios.md#aws. This way they do not get exposed in the stdout. Thoughts?
There was a problem hiding this comment.
agree on this, we currently configure aws connection just based on enviornment variables we should see if we can do the same set up here
There was a problem hiding this comment.
...and maybe drop the ebs from the name to make it CSP-agnostic?
There was a problem hiding this comment.
If the aws cli is configured it should take those credentials if other are not specified so I will put the reference how to setup the credentials in documentation and will remove the option to put there different credentials
| @@ -0,0 +1,9 @@ | |||
| aws_access_key_id: # only if system-wide credentials are not | |||
| aws_secret_access_key: # configured or using different credentials | |||
There was a problem hiding this comment.
We might want to introduce a cloud_type variable which is set to aws in this case as we will be adding support for Azure and GCP as well for this scenario. For example: https://github.com/krkn-chaos/krkn/blob/main/scenarios/openshift/aws_node_scenarios.yml#L10
There was a problem hiding this comment.
The goal is to use the same config and load things differently based on the cloud_type.
|
Is there any reason why this functionality shouldn't be implemented as a new scenario of |
Agree with @pablomh that we can make it as an additional action in the node-scenarios - https://github.com/krkn-chaos/krkn/blob/main/scenarios/openshift/aws_node_scenarios.yml where the parameters are similar for aws, gcp, azure - node name to target, volume id etc and we run the detach logic based on cloud_provider set ( aws, gcp etc. ) |
- Added scenario config - Added new folder containing scenarion scripts - Added scenario in run_kraken.py and kraken config Resolves krkn-chaos#678 Signed-off-by: jtydlack <[email protected]> # Conflicts: # run_kraken.py
- Added excetions - Supporting multiple regions - Volume selection by volume id or node/instance id - Aws access key id and aws secret access key not needed if system wide credentials configured Signed-off-by: jtydlack <[email protected]>
Signed-off-by: jtydlack <[email protected]>
Signed-off-by: jtydlack <[email protected]>
Signed-off-by: jtydlack <[email protected]>
Signed-off-by: jtydlack <[email protected]>
jtydlack
force-pushed
the
detach_ebs_volumes
branch
from
0fc21a1
to
76e5d76
Compare
| @@ -36,6 +36,16 @@ def helper_node_stop_start_scenario(self, instance_kill_count, node, timeout): | |||
| self.helper_node_start_scenario(instance_kill_count, node, timeout) | |||
| logging.info("helper_node_stop_start_scenario has been successfully injected!") | |||
|
|
|||
| # Node scenario to detach and attach the disk | |||
| def disk_detach_attach_scenario(self, instance_kill_count, node, timeout, duration): | |||
| logging.info("Starting node_stop_start_scenario injection") | |||
There was a problem hiding this comment.
let's be sure the logging information here matches the action we are doing, should be something like "Starting to detach disk"
Resolves #678