Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding Config Wizard Script #70

Open
wants to merge 8 commits into
base: main
Choose a base branch
from
Open

Conversation

javajason
Copy link

Adding Config Wizard script to facilitate initial configuration of AST, and added several improvements to Config Wizard to improve usability.

javajason and others added 8 commits December 18, 2024 14:53
Added options to start "configuration generator" container and to start docker compose service.
Fixed some minor bugs.
Added detection of Docker (or Podman) and Docker Compose (or Podman Compose) to script before running these commands.
Fixed minor bug in checking for installation of docker-compose.
Adding logic to validate IP address format that the user enters.
Added additional instructions to be printed when the script starts.
Removed "set -e" since this appears to make script exit immediately when the test for the installation of Docker (command -v docker) fails.
@javajason javajason requested a review from a team as a code owner December 23, 2024 15:55
@mikempw
Copy link
Collaborator

mikempw commented Jan 3, 2025

Any issues with this @clhain ?

@clhain
Copy link
Collaborator

clhain commented Jan 6, 2025

Thanks for the contribution Jason, this is good and timely stuff. I'd been planning to add a make file with some additional helper commands similar to some of what you have here e.g. 'make config' (to run the config script), 'make start' plus some additional e.g. 'make support-logs', etc, etc.

Implementation specifics of make vs bash script aside, I guess my main concern is whether we want to encourage people to manage their deployment configurations (specifically the configuration files, not the commands to run the configurator or the stack - which are definitely useful) with an additional abstraction over the existing abstraction. I don't love the idea of encouraging people to re-run the whole script to change a single bigip parameter for instance - obviously that's not good for anything but the smallest deployments - e.g. labs (which maybe is the intent).

Obviously you guys are the ones handholding folks through this so you can make the call, but for my money I'd rather be directing people to the yaml files directly for edits from the jump, and then just some helper commands to make the config script execution and docker stuff more friendly.

If we do want to go this route, would need to see some documentation for how we want people to approach configs with this alternate option included.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants