Sync DO API keys between clouds #16205
Conversation
|
This pull request has been linked to Clubhouse Story #132964: Sync API keys both in on-prem and associated cloud instance. |
amiedes
changed the title
| def create_remote_do_api_key | ||
| cartodb_central_topic.publish( | ||
| :create_remote_do_api_key, | ||
| { type: type, token: token, user_id: user_id, username: user.username } |
There was a problem hiding this comment.
Note to myself: sending both user_id and username, important to relay remote creation messages
…prem-and-associated-fix-specs-3
…prem-and-associated-fix-specs-3
| @@ -65,15 +68,19 @@ class ApiKey < ActiveRecord::Base | |||
| validate :valid_default_public_key, if: :default_public? | |||
|
|
|||
| after_create :setup_db_role, if: ->(k) { k.needs_setup? && !k.skip_role_setup } | |||
| after_create :create_remote_do_api_key, if: ->(api_key) { api_key.master? } | |||
There was a problem hiding this comment.
just an opinion: I like more the syntax we use in Central
after_create(:create_remote_do_api_key, if: :master?)(I understand you do need a block or a new function predicate for the check below (regenerate callback))
(as an opinion and likes and dislikes you're entitled to completely ignore it)
There was a problem hiding this comment.
Thanks for the suggestion 👍 . I agree with you and will try to remember this for the next time, but for (lazyness? 😅 ) I'm going to deploy it like it's now to avoid having to wait for the build again and potentially having to do a retry
| ) | ||
| end | ||
|
|
||
| def regenerate_remote_do_api_key |
There was a problem hiding this comment.
Sorry, but we need a specific message here: there's no guarantee on the order of the messages, and the likelihood of the "create" to overtake the "destroy" is pretty high in this case.
I think it is safer to have a specific message/command :regenerate_remote_do_api_key almost for the same price.
There was a problem hiding this comment.
After our chat and for the record: it is OK as worst case scenario is having an old api key in redis for a short while, as old and new have different redis keys.
OTOH that triggered the need for this: https://github.com/CartoDB/data-observatory/pull/1010
amiedes
deleted the
feature/ch132964/sync-api-keys-both-in-on-prem-and-associated-fix-specs-3
branch
Related to: https://app.clubhouse.io/cartoteam/story/132964/sync-api-keys-both-in-on-prem-and-associated-cloud-instance