Bypass prompts when installing SOCA with existing resources
Closed this issue · 5 comments
Is your feature request related to a problem? Please describe.
Running the SOCA installer is slow/manual/error prone, especially when passing in existing resources
Describe the feature you'd like
Before I being making changes to our forked version of this repo, I'd like to see if there is a relatively simple way to pass these parameters directly into the SOCA installer, so I can pass in all of my own existing resources with a single CLI command
Additional context
I started digging into this, and noticed that there's some base
Greetings @mission-coliveros,
Thank-you for the feature-request!
As you point out - there are a few areas where some of the options can be over-ridden.
The current options are spread over a few areas:
- Config file driven - with config file passed to
soca_installer.sh(e.g../soca_installer.sh --config=filename.yml) Defaults are indefault_config.yml. soca_installer.shcommand line argument directly (e.g.--bucket=<bucket_name>)soca_installer.sh"Override" style arguments - (e.g. ---override 'Config.scheduler.instance_type,str,m5.2xlarge').
The current installer doesn't allow for al_ the options to be specified in this manner. This means it isn't currently as friendly to single CLI or CI/CD as we would like it to be. For example - specifying the full suite of existing-resources that will be used (VPC, Filesystems, IAM, SG, etc).
During the current installer some of the functions are tightly coupled to the prompting, polling, and validation of the resources (e.g. filesystems) all at once.
The path forward would be to decouple some of these areas and add awareness of a config-driven/argument of each item (e.g. specifying a VPC-ID , plus a filesystem provider type and Filesystem-ID for filesystems). Those options would then be detected and validated prior to deployment. (but at least it won't prompt you and you could automate the deployment).
SOCA 2.7.5 will be coming out shortly - (Est before EOY 2024) - and after that we have some other plans for revamping some of these areas that need an overhaul for better CI/CD interactions.
We will keep this issue open for awareness/tracking on this topic , feel free to add any more information or how you would like to see this implemented.
The first time you run installer/soca_installer.sh it installs the pyenv, nvm, and CDK dependencies then it calls installer/resources/src/install_soca.py.
For subsequent runs (assuming the dependencies are installed), you can directly call installer/resources/src/install_soca.py with --skip-config-message to skip the first question to review the default configuration. Also, you can run installer/resources/src/install_soca.py -h to see the various command line options available that you can pass directly to it.
Greetings @mission-coliveros,
Thank-you for the feature-request!
As you point out - there are a few areas where some of the options can be over-ridden.
The current options are spread over a few areas:
- Config file driven - with config file passed to
soca_installer.sh(e.g../soca_installer.sh --config=filename.yml) Defaults are indefault_config.yml.soca_installer.shcommand line argument directly (e.g.--bucket=<bucket_name>)soca_installer.sh"Override" style arguments - (e.g. ---override 'Config.scheduler.instance_type,str,m5.2xlarge').The current installer doesn't allow for al_ the options to be specified in this manner. This means it isn't currently as friendly to single CLI or CI/CD as we would like it to be. For example - specifying the full suite of existing-resources that will be used (VPC, Filesystems, IAM, SG, etc).
During the current installer some of the functions are tightly coupled to the prompting, polling, and validation of the resources (e.g. filesystems) all at once.
The path forward would be to decouple some of these areas and add awareness of a config-driven/argument of each item (e.g. specifying a VPC-ID , plus a filesystem provider type and Filesystem-ID for filesystems). Those options would then be detected and validated prior to deployment. (but at least it won't prompt you and you could automate the deployment).
SOCA 2.7.5will be coming out shortly - (Estbefore EOY 2024) - and after that we have some other plans for revamping some of these areas that need an overhaul for better CI/CD interactions.We will keep this issue open for awareness/tracking on this topic , feel free to add any more information or how you would like to see this implemented.
Thanks @jsynack, can you clarify you meant EOY 2024, not EOY 2023? I'm trying to set expectations with a customer, and I wouldn't consider EOY 2024 to be relatively soon. We were initially planning to migrate to RES, but there are some blockers there that have brought us back to making SOCA work
Hello @mission-coliveros - SOCA 2.7.5 has been released. Let us know if you need anything else.
Closing ticket. Feel free to re-open if needed.