-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Remove Old Enclave Code #8969
Remove Old Enclave Code #8969
Conversation
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
@@ -299,7 +300,7 @@ class UserCodeV4(SyncableSyftObject): | |||
|
|||
|
|||
@serializable() | |||
class UserCode(SyncableSyftObject): | |||
class UserCodeV5(SyncableSyftObject): |
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 for my understanding, is there a reason we keep old versions around? I'm more used to alembic kind of model where you specify the diffs for migrations and doing it this way looks like you have to keep around some constructs like EnclaveMetadata that aren't being used anywhere after the rest of this code gets deleted.
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.
We keep the old versions mainly for the upgradeability.
You are correct, when we delete specific attributes in a object which in itself is a python class and if do not we use the object elsewhere, we would have to keep it around for upgradeability.
In our case , we deleted enclave_metadata field in the new version of UserCode
Since enclave_metadata is a python Class: EnclaveMetadata, I think we still need to keep the class for upgradeability even if it not being used elsewhere.
cc: @shubham3121 @koenvanderveen is there a better way to solve this?
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.
So currently we keep the last version of the class along with the latest version of the class. The thing we're missing for UserCodeV5 is the function that allows to migrate up/down. e.g. we have functions migrate_usercode_v4_to_v5
and migrate_usercode_v5_to_v4
that do that for user code v4->v5 and vice-versa. We need to update these for usercode v5 <-> v6. For ease of simplicity we can rename these functions to:
@migrate(UserCodeV4, UserCode) @migrate(UserCodeV5, UserCode)
def migrate_usercode_v4_to_v5 ----> def upgrade_usercode
and
@migrate(UserCodeV4, UserCode) @migrate(UserCodeV5, UserCode)
def migrate_usercode_v5_to_v4 -> def downgrade_usercode
and then define the respective defaults to convert one object version to another.
Description
To be added
Affected Dependencies
List any dependencies that are required for this change.
How has this been tested?
Existing tests
Checklist