-
Notifications
You must be signed in to change notification settings - Fork 167
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
Add P0 OOTB connection types #3335
Add P0 OOTB connection types #3335
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3335 +/- ##
=======================================
Coverage ? 85.12%
=======================================
Files ? 1337
Lines ? 30117
Branches ? 8265
=======================================
Hits ? 25638
Misses ? 4479
Partials ? 0
Continue to review full report in Codecov by Sentry.
|
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.
While the Edit
action is disabled, i can select the duplicate action, then edit the URL from /duplicate/
to /edit/
and then I can save any changes. I believe the operator should just revert the change, however I don't think the user should be able to perform this action from the ui.
The delete action should not be enabled either. Should it be hidden? @simrandhaliw
Do we know if we should allow the admin to disable these connection types?
manifests/common/connection-types/oci-compliant-registry-v1.yaml
Outdated
Show resolved
Hide resolved
2c0e398
to
5bc94a5
Compare
d43ce05
to
c211947
Compare
/hold Since we are not yet releasing this feature, I want to be absolutely sure these resources are correct because I'm also unsure how these resources would be reconciled if we need to make additional changes. |
openshift.io/display-name: S3 compatible object storage - v1 | ||
data: | ||
category: '["Object storage"]' | ||
fields: '[{"type":"short-text","name":"Access key","envVar":"AWS_ACCESS_KEY_ID","properties":{},"required":true},{"type":"hidden","name":"Secret key","envVar":"AWS_SECRET_ACCESS_KEY","required":true,"properties":{}},{"type":"short-text","name":"Endpoint","envVar":"AWS_S3_ENDPOINT","required":true,"properties":{}},{"type":"short-text","name":"Region","envVar":"AWS_DEFAULT_REGION","required":false,"properties":{}},{"type":"short-text","name":"Bucket","envVar":"AWS_S3_BUCKET","required":false,"properties":{}},{"type":"short-text","name":"Path","envVar":"AWS_S3_PATH","properties":{}}]' |
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.
path
is not part of data connections today. I do not believe it should be part of the the connection type. Will start a discussion on 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.
Agreed -- we should make sure that field pops up when selecting an S3-esk connection in the Model Serving modal.
if (existingConnectionType && ownedByDSC(existingConnectionType)) { | ||
return ( | ||
<ApplicationsPage | ||
loaded={isLoaded} | ||
errorMessage="Unable to edit" | ||
loadError={new Error('This connection type is not editable')} | ||
empty | ||
/> | ||
); | ||
} |
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 feel like we should just redirect the user back to /conectionTypes
instead of displaying this page. The only way they can get here is by direct URL anyways.
c211947
to
da01542
Compare
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.
Since we are not yet releasing this feature, I want to be absolutely sure these resources are correct because I'm also unsure how these resources would be reconciled if we need to make additional changes.
Can we make sure we can do this no matter what -- We'll need to do updates almost guaranteed to these resources at some point on upgrade. Can we not make this a first-class feature to allow for manifests (eg. devflags) to change?
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.
Do we have support for this in the UI yet?
openshift.io/display-name: S3 compatible object storage - v1 | ||
data: | ||
category: '["Object storage"]' | ||
fields: '[{"type":"short-text","name":"Access key","envVar":"AWS_ACCESS_KEY_ID","properties":{},"required":true},{"type":"hidden","name":"Secret key","envVar":"AWS_SECRET_ACCESS_KEY","required":true,"properties":{}},{"type":"short-text","name":"Endpoint","envVar":"AWS_S3_ENDPOINT","required":true,"properties":{}},{"type":"short-text","name":"Region","envVar":"AWS_DEFAULT_REGION","required":false,"properties":{}},{"type":"short-text","name":"Bucket","envVar":"AWS_S3_BUCKET","required":false,"properties":{}},{"type":"short-text","name":"Path","envVar":"AWS_S3_PATH","properties":{}}]' |
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.
Agreed -- we should make sure that field pops up when selecting an S3-esk connection in the Model Serving modal.
@andrewballantyne these resources will be updated on upgrade like the other resources. However they aren't reconciled immediately on change in case a privileged user alters them. Seems like some churn is still happening on the definition side of these resources. |
@christianvogt Sorry, I'm not clear what you mean by "a privileged user alters them"... either they are reconciled by the operator or they are not I thought 🤔 If you oc apply these resources, they are not quite the same as if you used devFlags or an operator upgrade (which I believe to be the same if memory serves). |
@andrewballantyne we found out that the resources are not reconciled on change by the operator but only on upgrade or when the operator controller is restarted. So what I was getting at is if a privileged user happens to change the resource, it doesn't get reset until one of those scenarios hit. This is something @lucferbux and I found strange and would need some further looking into if we wanted to change that behavior. |
opendatahub.io/connection-type: 'true' | ||
opendatahub.io/dashboard: 'true' | ||
annotations: | ||
opendatahub.io/enabled: 'true' |
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.
Remove all opendatahub.io/enabled
annotations.
da01542
to
aca6c4c
Compare
/hold cancel |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: christianvogt The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
RHOAIENG-13105
Description
Adds yaml files for OOTB connection types. Updates the connection type page to not allow editing of the OOTB connection types. Fixes an issue where the connection types table does not update when new connections are added or modified.
How Has This Been Tested?
Run the UI and navigate to Settings -> Connection types
Install the connection types:
oc project opendatahub
Verify the connection types are shown in the UI without needing to refresh the page within 30 seconds
From the OpenShift Console, go to Administrator -> Home -> Search
jupyter
OdhApplication and copy itsownerReference
section of the Yaml fileownerReference
section to each of themPre-installed
for thecreator
columnEdit
action in the kebab is disabled for each.Test Impact
None, test already covered this functionality
Screen shots
Request review criteria:
Self checklist (all need to be checked):
/cc @simrandhaliw