Skip to content

Update OAuth App to Use The RemoteRepositoryRelation Model #7675

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

Conversation

saadmk11
Copy link
Member

This does not take into account for duplicate RemoteRepository for now.

@saadmk11 saadmk11 changed the title Update OAuth Services to Use The RemoteRepositoryRelation Model Update OAuth App to Use The RemoteRepositoryRelation Model Nov 21, 2020
@saadmk11 saadmk11 requested a review from humitos November 23, 2020 11:14
@saadmk11 saadmk11 marked this pull request as ready for review November 23, 2020 11:14
Copy link
Member

@humitos humitos left a comment

Choose a reason for hiding this comment

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

Changes look GOOD! I left some comments to keep talking, but there isn't anything too big to change.

This does not take into account for duplicate RemoteRepository for now.

Is this comment old now? The code seems to handle duplicated RemoteRepository properly now.

@@ -155,15 +165,18 @@ def create_repository(self, fields, privacy=None, organization=None):

repo.html_url = fields['links']['html']['href']
repo.vcs = fields['scm']
repo.account = self.account
Copy link
Member

Choose a reason for hiding this comment

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

It may be good to start populating remote_id here as well. I think we already added to the modeling.

It will be easier to populate it first, and after that do the switch to start using it.

Copy link
Member

Choose a reason for hiding this comment

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

This comment is valid for all the services we support.

Copy link
Member Author

Choose a reason for hiding this comment

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

Actually, I think we talked about adding the remote_id fields later, but now that I think of it it would be better to do it now, but I'll add it in another PR after this is merged.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah. I said that in our conversation. However, I think it's better to have it before we do the initial resync so we already populate this data from the beginning and then we can start making use of it. I'm fine if it's in another PR.

@saadmk11
Copy link
Member Author

This does not take into account for duplicate RemoteRepository for now.

Is this comment old now? The code seems to handle duplicated RemoteRepository properly now.

Unfortunately, it does not handle it. We can only filter RemoteRepository with the full name so that there is no duplication in the future, but the old/current duplication is still there so this will return multiple objects on get_or_create() which will result in an error

repo, _ = RemoteRepository.objects.get_or_create(
    full_name=fields['full_name']
)

We need to figure out a way to remove the current DB duplicates

@saadmk11 saadmk11 requested a review from humitos November 24, 2020 08:18
@humitos
Copy link
Member

humitos commented Nov 24, 2020

We can only filter RemoteRepository with the full name so that there is no duplication in the future, but the old/current duplication is still there so this will return multiple objects on get_or_create() which will result in an error

I understand. We may not need to care about this anymore, if the what I'm going to describe next makes sense 😅

Talking to Eric last week, we thought that we can deploy all of these changes in a slightly different way than we originally described in #7536 (comment):

  • between point 4 and 5 we could spin up a new instance with the new Python code and modelling (using RemoteRepository.Meta.db_table = "oauth_remoterepositoy_202011" so it creates a new table and doesn't touch the current one) and re-sync from VCS providers into that table. This new instance won't attend users requests, it will be used only for fetching data from VCS providers.
  • after some days, once the re-sync is finished and we have all the data in the new table, we can dump the Project <-> RemoteRepository relations and load into the new table oauth_remoterepository202011. * finally, we do a full deploy for all our production instances with the new Python code and modelling

@saadmk11
Copy link
Member Author

I understand. We may not need to care about this anymore, if the what I'm going to describe next makes sense

Talking to Eric last week, we thought that we can deploy all of these changes in a slightly different way than we originally described in #7536 (comment):

  • between point 4 and 5 we could spin up a new instance with the new Python code and modelling (using RemoteRepository.Meta.db_table = "oauth_remoterepositoy_202011" so it creates a new table and doesn't touch the current one) and re-sync from VCS providers into that table. This new instance won't attend users requests, it will be used only for fetching data from VCS providers.
  • after some days, once the re-sync is finished and we have all the data in the new table, we can dump the Project <-> RemoteRepository relations and load into the new table oauth_remoterepository202011. * finally, we do a full deploy for all our production instances with the new Python code and modelling

Sounds good 💯

@saadmk11 saadmk11 requested a review from humitos November 24, 2020 17:17
@humitos humitos force-pushed the remote-repository-normalization branch from 2c74027 to 2df6a4e Compare November 25, 2020 10:14
Copy link
Member

@humitos humitos left a comment

Choose a reason for hiding this comment

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

I re-review this PR and everything looks fine to me. Thanks for your help on this! We can now move forward with the similar changes required for RemoteOrganization

]

operations = [
migrations.RunPython(move_data_to_remote_relations),
migrations.RunPython(move_data_to_remote_repository_relations),
Copy link
Member

Choose a reason for hiding this comment

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

This won't probably be required in the end as we may resync everything (pull down from VCS providers) a week in advance, but we can create a note and remove it later if needed.

@humitos humitos merged commit 69df3d8 into readthedocs:remote-repository-normalization Dec 1, 2020
@saadmk11 saadmk11 deleted the update-oauth-services branch December 1, 2020 16:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants