Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Superset deployment #3715
Superset deployment #3715
Changes from 16 commits
ada360a
58ea963
60f9772
63658f6
28a8cc4
83c08f4
9f59337
fd9c467
cb6c089
b52ab53
d967142
ac5144d
642fd66
30dfb04
75e6875
1039512
fbbfb2b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
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.
I need to figure out how to use the Cloud Auth Proxy to make changes to the production database. Also, how can we protect against people making changes to the production database when they are just experimenting with the local deployment?
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.
How did you make changes to the Cloud SQL database for the initial deploy?
I think we can use the Docker version of the Cloud SQL Auth Proxy in a
mutate-prod
docker compose file. That would just be the same as our dev docker-compose, but with the Cloud SQL proxy standing in for the postgres service. Then executingsuperset db-upgrade
or whatever, within thepudl-superset
docker-compose service, would point at prod Cloud SQL.We'd need to make a new service account to give that Cloud SQL Auth Proxy. To stop people from accidentally changing the prod DB, we could restrict the ability to create a key for that SA to only a subset of Catalyst. So it'd require a fair amount of effort/oversight to be able to make a change to prod DB.
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.
What should the deployment flow be for superset? I can think of a few reasons to trigger a new deployment:
When do we want to update superset
superset_config.py
nightly
orstable
?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.
I think redeploying Superset for nightly builds is a good way to test that our deployment infrastructure still works, and has the benefit of catching all these other changes too - so long as the cloud build doesn't cost a ton I think that's the easiest way forward.
I also think that eventually we probably want both
nightly
andstable
to be on Superset - we can default to usingstable
, but have the option to connect tonightly
in the database selector if people want.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.
Love a 1 line redeploy :)
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.
Do we want to try to track the role definitions in git so our local deployments can use the roles we're using in production?
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.
Yeah, that makes a ton of sense to me :)
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.
This is run for the dev superset instance, right? What happens in production?
Separately, should we be passing these username/name/email/password as arguments to this script? In prod, we'd have all the secrets set as env vars at this point, right?
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.
This seems fine - even the docs seem to just use string URIs.
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.
Unfortunately, this didn't resolve the HTTP redirect issue. I think the issue might be related to the auth0 Oauth development tokens we're using.
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.
Hmm, nothing in that list looks suspicious to me, I'd love to see the authentication logs and see if there are specific errors showing up, or what the callback URL is being parsed as, etc.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.