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

Dictionaries in Alembic block ch_admin password changes #553

Closed
bmtcril opened this issue Jan 3, 2024 · 3 comments
Closed

Dictionaries in Alembic block ch_admin password changes #553

bmtcril opened this issue Jan 3, 2024 · 3 comments
Assignees
Labels
aspects beta aspects v1 Issues blocking Aspects v1 release bug Report of or fix for something that isn't working as intended

Comments

@bmtcril
Copy link
Contributor

bmtcril commented Jan 3, 2024

Because the admin password gets baked into Alembic migrations for dictionaries, when you change the ch_admin password those dictionaries break until you downgrade and re-upgrade, which is not a viable path. :)

I'm opening a support ticket to see if there's some undocumented or better way to manage these dictionaries so that we don't have to put the password in there, since we don't want to be doing that anyway. This ticket is just for record keeping.

@bmtcril bmtcril self-assigned this Jan 3, 2024
@bmtcril bmtcril added aspects v1 Issues blocking Aspects v1 release aspects beta labels Jan 3, 2024
@bmtcril
Copy link
Contributor Author

bmtcril commented Jan 3, 2024

I think we should be able to do this by using a named collection that can be updated independently: https://clickhouse.com/docs/en/operations/named-collections#named-collections-for-accessing-a-remote-clickhouse-database

We would probably have to handle that as part of the pre-Alembic bootstrap process like we do with the other credentials, which I actually like better.

@bmtcril bmtcril added the bug Report of or fix for something that isn't working as intended label Jan 12, 2024
@bmtcril
Copy link
Contributor Author

bmtcril commented Jan 12, 2024

I think I've hit a dead end on named collections:

  • There is a special setting (named_collection_control) required to manage them via DDL, which needs to be set on a per-user basis to bootstrap a user who can grant this to others
  • This setting can only be done via XML file in the users dir (until 23.11, where it was made on by default for the default user), but it’s impossible to bootstrap a user in all of our target platforms because…
  • Setting user XML on K8s doesn’t work because ClickHouse actually writes to this directory, and mounting it makes it read only. The setting won't be read from any other config file / directory.
  • We can make it work on k8s, local, and dev by defining the named collections themselves in XML and writing that to the config dir but…
  • We can’t do that on CH Cloud or Altinity. Altinity actually has this setting on by default, so we can use DDL there, but…
  • CH Cloud doesn’t support this feature at all yet so none of this matters.

This should be in the next CH LTS, which is maybe... March? We can revisit then, but for now our hopes rest on #565

@bmtcril
Copy link
Contributor Author

bmtcril commented Mar 26, 2024

@SoryRawyer has gotten a PR merged to dbt-clickhouse that will allow us to move this to dbt. The rest of this work will happen in #565

@bmtcril bmtcril closed this as completed Mar 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
aspects beta aspects v1 Issues blocking Aspects v1 release bug Report of or fix for something that isn't working as intended
Projects
None yet
Development

No branches or pull requests

1 participant