-
Notifications
You must be signed in to change notification settings - Fork 0
#2: Implemented lifecycle of an EC2 instance #6
Conversation
2. moved method STACK_NAME into class CloudFormationStack
…key_file_manager.py
exasol_script_languages_developer_sandbox/lib/random_string_generator.py
Outdated
Show resolved
Hide resolved
exasol_script_languages_developer_sandbox/templates/ec2_cloudformation.jinja.yaml
Show resolved
Hide resolved
2. Changed implementation of random_string_generator.py 3. renamed function execute_setup_ec2() => run_lifecycle_for_ec2() 4. minor changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some questions and thoughts. Should we use aws localstack for testing the aws_access class. And can we refactor things, such that we have the context manager for keys and cloud formation, but on the other hand, use creation and closing idependently as CLI. Means the create CLI stores everything necessary on disk and close loads this and then closes everything. Reason is, I need the exact functionalities for handling ec2 instances also for GPU tests and development.
Another question, could we add the Key creation into the cloud formation template.
It is possible, see here, but I there are a few reasons to not do this:
|
Of, course, I am happy if the code will be reused. But the question is if you want to use it from within Python code, or via CLI. Let's discuss offline. |
I added new tests which use |
…er()/CloudformationStack()
2. For EC2 Key use full uuid string 3. For Cloudformation stack check if stack name exists
fixes #2