Conversation
…ning Adds Textual screens to input 1. bootstrap credentials 2. which apps to create auth0 client for 3. deployment inputs 4. final run/summary screen. Adds sequencing in orchestrator.run_wizard() and the 'wizard' CLI subcommand. Adds module yaml_writer.py: - apply_auth0_client_results_to_config() writes Auth0 API results (auth0_domain, per-app client id/secret) - apply_deployment_metadata_to_config() writes community_name/root_domain/admin_email, which are separate inputs from `DeploymentInputsScreen` (never sent to Auth0).
e038d6e to
dd58df3
Compare
The screen walks through the manual GCP OAuth client setup
Community name and Superset admin email are removed from scope. The root domain is still required since every app client's Auth0 callback and origin URLs derive from it, and the screen previews those per-app URLs.
dd58df3 to
7f6bf00
Compare
7f6bf00 to
7daec8d
Compare
The wizard never needs it: client secrets come back in the create response.
rudokemper
left a comment
rudokemper
left a comment
There was a problem hiding this comment.
Really great, thank you.
I did not test this, but we can test drive to achieve https://github.com/ConservationMetrics/gc-forge/issues/127 next sprint.
Noting the four 429 errors in your screenshot of the logs, should we increase wait time before making additional requests?
This does create auth0 clients for Windmill and GC-Metrics, but only logs them. We could do a better job of persisting them or alerting the operator they need to copy these down!
I know you plan to work on this in #158, but could leave a comment with the issue just to be super clear for this interim stage. Or skip this, either is fine by me.
I feel like "wizard" is far too generic a name for this. Once we've proven out the functionality here, let's re-visit the entire gc-stack-deploy flow (including init and deploy) and see whether we want to connect those, how we want to name things...
I agree. Can you create an issue as a future container for this? Blocked by #158. I think this should be something we do as part of our work towards https://github.com/ConservationMetrics/gc-roadmap/issues/8 this year.
| yield Header() | ||
| with Vertical(id="form"): | ||
| yield Static( | ||
| "Enter the root domain your Guardian Connector stack will be served at." |
There was a problem hiding this comment.
| "Enter the root domain your Guardian Connector stack will be served at." | |
| "Enter the root domain your Guardian Connector stack will be served at (without https protocol prefix)." |
I know it's implied in the examples and the placeholder, but just to be crystal clear.
| """The run_wizard function dictates the end-to-end wizard order: | ||
| 1. provisioning of auth0 configs | ||
| 2. writes the auth0 credentials to stack.yaml. | ||
| """ |
There was a problem hiding this comment.
Is it a good idea to add a README to this directory?
|
|
||
| logger = logging.getLogger("gc-stack-deploy.wizard") | ||
|
|
||
| # Scope lists are copied verbatim from auth0/README.md. |
There was a problem hiding this comment.
I feel like there is a risk of drift if we change auth0 scopes in the future. How do we make a note to ourselves to update scopes in both places? Maybe redundancy is the best strategy - a helpful note here and in auth0/README?
This branch has not been deployed
2 participants
Goal
Expose the Auth0 provisioning code from #179 via a TUI runnable as
gc-stack-deploy wizard.The Textual UI walks the operator through auth0 configuration and writes the auth0 apps' IDs & Credentials to
stack.yaml.Closes #157
Screenshots
After completion:
What I changed and why
gc_stack_deploy/wizard/screens.pyis uninteresting TUI code, the 4 screens.gc_stack_deploy/wizard/orchestrator.pyinvokes the auth0 code to do all the setup as described in auth0/README.mdgc_stack_deploy/wizard/yaml_writer.pywrites the auth0 client IDs and secrets back to stack.yaml. Also wrietsgc_landing_page.root_domain, which was provided to us in this wizard.Note for reviewers
The runtime flow is:
Now that you know that, skip all the uninteresting TUI code and just focus on
orchestrator.py.Diff stats
What I'm not doing here
All these are still manual
caproverUrlandcaproverPasswordThis does create auth0 clients for Windmill and GC-Metrics, but only logs them. We could do a better job of persisting them or alerting the operator they need to copy these down!
I feel like "wizard" is far too generic a name for this. Once we've proven out the functionality here, let's re-visit the entire gc-stack-deploy flow (including init and deploy) and see whether we want to connect those, how we want to name things...