Skip to content
This repository was archived by the owner on Sep 30, 2024. It is now read-only.

oobmigration: derive subscription account number and extract license key fields#39344

Merged
unknwon merged 6 commits into
mainfrom
jc/subscriptions-licenses-oob-migration
Jul 27, 2022
Merged

oobmigration: derive subscription account number and extract license key fields#39344
unknwon merged 6 commits into
mainfrom
jc/subscriptions-licenses-oob-migration

Conversation

@unknwon

@unknwon unknwon commented Jul 25, 2022

Copy link
Copy Markdown
Contributor

This PR adds two OOB migrations:

  1. Attempt to extract the account number from the associated user of subscriptions, sister PR: https://github.com/sourcegraph/sourcegraph/pull/39209
  2. Extract license fields from the license key text and store them to dedicated columns, sister PR: https://github.com/sourcegraph/sourcegraph/pull/39215

Test plan

Manually e2e tested locally.


Part of https://github.com/sourcegraph/sourcegraph/issues/38661

Comment on lines -64 to +63
uuid, userID, dbutil.NewNullString(accountNumber),
uuid, userID, accountNumber,

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we continue inserting NULL values for subscriptions that don't have an account number, it confuses the OOB migration progress checking. Admittedly this is a shortcut, but I think it is fine, since having the account_number column NULL-able was for the sake of backward compatibility.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could add a column “is_migrated boolean” or something like that to circumvent it. I think it would be good practice to actually write nulls instead of empty strings, wdyt?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically we could, and agree with you in general!

But frankly speaking for this particular task, I think even an OOB migration is somewhat an overkill because this only matters for the dotcom instance and I could have just written a script that writes to update the DB (but that's super risky so... OOB migration seems safer with code review and less error-prone).

I'm not incentivized enough to make this part of the migration long-lasting. 😅 WDYT?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is okay, I’m just thinking about when we can deprecate the migrator and how we would eventually get to 1 state for “not set” again, preferably NULL.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not saying that's the optimal approach, but by that time, a sync migration that does update product_subscription set account_number = null where account_number = '' would solve it 🤫 OR maybe we have migrated license management out of the dotcom (completely rewritten).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good :) I don't believe in the latter yet, but the former satisfies me enough 😆

@unknwon unknwon marked this pull request as ready for review July 25, 2022 06:39
@unknwon unknwon requested review from a team and efritz July 25, 2022 06:39
@sourcegraph-bot

sourcegraph-bot commented Jul 25, 2022

Copy link
Copy Markdown
Contributor

Codenotify: Notifying subscribers in CODENOTIFY files for diff fd4f511...6b7654b.

Notify File(s)
@efritz enterprise/cmd/worker/main.go
internal/oobmigration/oobmigrations.yaml

@eseliger eseliger left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving but one open question whether one of them has to be OOB and would be nice to see a test for this :)

Comment on lines -64 to +63
uuid, userID, dbutil.NewNullString(accountNumber),
uuid, userID, accountNumber,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could add a column “is_migrated boolean” or something like that to circumvent it. I think it would be good practice to actually write nulls instead of empty strings, wdyt?


var accountNumber string
if i := strings.LastIndex(username, "-"); i > -1 {
accountNumber = username[i+1:]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is all the logic it takes, it feels like this migration could get away with a simple synchronous DB migration, as on prem won’t ever have entries in this table and dotcom only has a couple thousand, it doesn’t feel like unbearable load. Negative effect of an OOB
migrator is that you can never assume the data is in a certain shape until it’s been deprecated.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cc @efritz for some more thoughts.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Negative effect of an OOB
migrator is that you can never assume the data is in a certain shape until it’s been deprecated.

Yes, but I think this negative effect is fine in this case, the Sales data pipeline does not have this assumption (given the history of multiple broken states for license data) thus supporting continuously filling data gaps (even if this happens). 🤣

Comment thread internal/oobmigration/oobmigrations.yaml Outdated
Comment thread internal/oobmigration/oobmigrations.yaml Outdated
@@ -0,0 +1,221 @@
package productsubscription

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A test for each of these would be appreciated to prove they report progress correctly (especially on non-dotcom) and to check if it properly decodes the license.

@unknwon unknwon Jul 26, 2022

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a good example of how to write the test for OOB migrations? 🙏

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh NVM, I think these tests should be easy to write!

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think some of the migrators have a good test suite attached! (I know some in batches should, at least)

@efritz efritz left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@unknwon A few questions I didn't get quickly from resources in this PR:

  • I'm not familiar with the tables in question here. What writes to them (in particular, are they writing only the new format according to this migration, or are they still writing an old format that must be caught by this process)?
  • Does this apply only to the dotcom instance? Why (Maybe answering what fills this table also answers this question)?

Comment thread enterprise/internal/productsubscription/migrations.go Outdated
@unknwon

unknwon commented Jul 27, 2022

Copy link
Copy Markdown
Contributor Author

@efritz:

  • I'm not familiar with the tables in question here. What writes to them (in particular, are they writing only the new format according to this migration, or are they still writing an old format that must be caught by this process)?

All writes to them are only using the new format (changes made in the linked sister PRs), these OOB migrations only intend to deal with existing data.

  • Does this apply only to the dotcom instance? Why (Maybe answering what fills this table also answers this question)?

Yes, only the dotcom Postgres stores product subscriptions and licenses.

@unknwon unknwon merged commit b4bb2d2 into main Jul 27, 2022
@unknwon unknwon deleted the jc/subscriptions-licenses-oob-migration branch July 27, 2022 08:14
@unknwon

unknwon commented Jul 27, 2022

Copy link
Copy Markdown
Contributor Author

Thanks everyone! Merging as-is, happy to address any post-merge comments!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants