-
Notifications
You must be signed in to change notification settings - Fork 52
⚠️ Change FybrikStorageAccount CRD #1855
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
Signed-off-by: Shlomit Koyfman <shlomitk@il.ibm.com>
Signed-off-by: Shlomit Koyfman <shlomitk@il.ibm.com>
Signed-off-by: Shlomit Koyfman <shlomitk@il.ibm.com>
Signed-off-by: Shlomit Koyfman <shlomitk@il.ibm.com>
Signed-off-by: Shlomit Koyfman <shlomitk@il.ibm.com>
Meantime, I have several small style related comments, and need to read the code more. However, this PR breaks backward compatibility and requires uninstallation of an old Fybrik deployment and installation of a new one. Another option is to leave the old v1beta1.FybrikStorageAccount CRD, add the v1beta2.FybrikStorageAccount CRD, and provide a script/tool to transfer instances of v1beta1 to v1beta2. |
Signed-off-by: Shlomit Koyfman <shlomitk@il.ibm.com>
OK. Leaving v1beta1 along with v1beta2. UnmarshalJSON takes care of the conversion to the expected structure. |
Signed-off-by: Shlomit Koyfman <shlomitk@il.ibm.com>
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.
As @roytman pointed out, this PR has backward compatibility implications. 1) It should be marked as such 2) The storage CRDs in the quick start examples need to be updated, as does the kfp sample 3) Does this affect any of the OPA policies in any of our examples?
delete(items, secretRefKey) | ||
typeVal, exists := items[typeKey] | ||
if !exists { | ||
// conversion from v1beta1 is required: |
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.
Should the backward compatibility to v1beta1 be done here? Shouldn't this be handled by a webhook or some other mechanism addressing backward compatibility?
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.
What was decided about this @shlomitk1 @roytman ? I see you took the code out, but I don't see the handling of the backward compatibility anyplace else.
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.
It still happens during the object construction. Webhooks can come on top of that, but a default conversion is required if no webhooks are running.
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.
Given that no one uses the vibeta1 version yet, I suggest adding the following properties into its definition:
versions.served: false # this prevents creation of new instances of v1beta1, but do not return any errors if there are instances of the version. (just in case)
versions.storage: false # this is defined in the PR
versions.deprecated: true
versions.deprecationWarning: "a text describe that the version is deprecated, unsupported, will be removed soon, and suggest to use v1beta2
And do not add any conversions.
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.
Done. Served is set to true because otherwise deprecated warnings are not displayed.
It is marked with |
I'm not sure that it is properly done, can you elaborate ? |
After the automatic conversion takes place (no webhooks exist), I get the following spec structure converted from beta1 to beta2:
The code converts this structure to beta2 scheme:
Not regarding the version management, UnmarshalJSON is necessary here because the default unmarshal does not understand unstructured data (there are parts in the spec that are not in the scheme, allowing unknown fields). I added the conversion to the right version during the json decoding to the structure. |
Signed-off-by: Shlomit Koyfman <shlomitk@il.ibm.com>
Signed-off-by: Shlomit Koyfman <shlomitk@il.ibm.com>
Signed-off-by: Shlomit Koyfman <shlomitk@il.ibm.com>
https://github.com/fybrik/kfp-components/tree/main/samples/house_price_estimates |
Once this PR is merged, I'll open a PR in kfp-components repo to replace the CR. |
manager/controllers/app/fybrikapplication_controller_unit_test.go
Outdated
Show resolved
Hide resolved
delete(items, secretRefKey) | ||
typeVal, exists := items[typeKey] | ||
if !exists { | ||
// conversion from v1beta1 is required: |
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.
Given that no one uses the vibeta1 version yet, I suggest adding the following properties into its definition:
versions.served: false # this prevents creation of new instances of v1beta1, but do not return any errors if there are instances of the version. (just in case)
versions.storage: false # this is defined in the PR
versions.deprecated: true
versions.deprecationWarning: "a text describe that the version is deprecated, unsupported, will be removed soon, and suggest to use v1beta2
And do not add any conversions.
Signed-off-by: Shlomit Koyfman <shlomitk@il.ibm.com>
Signed-off-by: Shlomit Koyfman <shlomitk@il.ibm.com>
The review comments are addressed. We decided to display a warning about the version being deprecated, not support v1beta1 and move the conversion code out.
Closes #1744
FybrikStorageAccount structure has been changed:
Type
Region
->Geography
Endpoint
Structures are defined in pkg/storage/apis.
Example of the spec: