-
Notifications
You must be signed in to change notification settings - Fork 103
[sql-41] firewalldb: add migration code for kvstores from kvdb to SQL #1079
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
base: master
Are you sure you want to change the base?
[sql-41] firewalldb: add migration code for kvstores from kvdb to SQL #1079
Conversation
In preparation for upcoming migration tests from a kvdb to an SQL store, this commit updates the NewTestDB function to return the Store interface rather than a concrete store implementation. This change ensures that migration tests can call NewTestDB under any build tag while receiving a consistent return type.
When a session has a MacaroonRecipe set, which has a nil value set for either the `Permissions` or the `Caveats` field, the kvdb session store would return that field as nil, while the sql prior to this commit would return an empty array. When the we migrate the session store from kvdb to sql, that will cause the kvdb and the migrate session store to differ when comparing them, which will cause the migration to fail. This commit fixes that by ensuring that the sql session store returns a nil value for those fields in that scenario, rather than an empty array.
This commit introduces the migration logic for transitioning the sessions store from kvdb to SQL. Note that as of this commit, the migration is not yet triggered by any production code, i.e. only tests execute the migration logic.
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 this doesnt need to be based on the sessions pr right? yes order of merge matters, but i think we dont need to base this one off of that one or at least can change the base branch here so that we can review both migrations in parallel
func processRuleBucket(ctx context.Context, sqlTx SQLQueries, perm bool, | ||
ruleSqlId int64, ruleBucket *bbolt.Bucket) error { | ||
|
||
err := ruleBucket.ForEach(func(k, v []byte) error { |
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.
return ruleBucket.ForEach(...
"rule-name bucket") | ||
} | ||
|
||
if bytes.Equal(k, globalKVStoreBucketKey) { |
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.
switch
🙏
migratedValue, err := sqlTx.GetGlobalKVStoreRecord( | ||
ctx, | ||
sqlc.GetGlobalKVStoreRecordParams{ | ||
Key: globalInsertParams.EntryKey, | ||
Perm: globalInsertParams.Perm, | ||
RuleID: globalInsertParams.RuleID, | ||
}, | ||
) | ||
if err != nil { | ||
return fmt.Errorf("retreiving of migrated global kv "+ |
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 it may be worth only doing these read-checks after all the writes are complete. Else we may miss if we accidentally overwrite it later
"%s bucket", string(sessKVStoreBucketKey)) | ||
} | ||
|
||
groupId := k |
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.
just call the argument groupID?
} | ||
|
||
return groupBucket.ForEach(func(k, v []byte) error { | ||
if v != nil { |
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.
switch
🙏
Value: v, | ||
Perm: perm, | ||
RuleID: ruleSqlId, | ||
SessionID: sql.NullInt64{ |
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.
sqldb.SQLInt64
Based on #1051
This PR introduces the migration logic for transitioning the kv stores from kvdb to SQL.
Note that as of this PR, the migration is not yet triggered by any production code, i.e. only tests execute the migration logic.
Once #1051 is merged, I will rebase this PR and request reviews.
Part of #917