-
Notifications
You must be signed in to change notification settings - Fork 350
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 support for COS public endpoint to Kubeflow Pipelines runtime config #2887
Conversation
This commit aims to introduce support for a public endpoint to a Cloud Object Storage. It adds a new property to the schema JSON to be shown in the Runtime configuration section During the pipeline creation, it try to gets that variable if defined otherwise uses the api one.
Thanks for making a pull request to Elyra! To try out this branch on binder, follow this link: |
Conceptually this is looking good! I haven't tried the code yet but wanted to bring up a few things we need to add to close the loop:
I tagged this as a Kubeflow Pipelines feature for now. We can always extend this to Apache Airflow in a follow-up PR (or have somebody with access to an Airflow deployment augment your PR since the new functionality is not runtime specific). |
Code changes look good and work as expected:
Last remaining item is to fix the broken integration test |
Oh thanks. I was looking for that. fixing |
If you can make the final change by tomorrow we'll include the PR in the upcoming release, otherwise we might have to defer. |
Co-authored-by: Patrick Titzler <ptitzler@us.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.
LGTM
Thank you for your contribution. Much appreciated!
@ptitzler thank you us for the project. sorry busy morning, i tried to run the tests, with what you said, but they failed with the error: |
@portellaa - Were there additional non committed changes you were testing against locally? The CI tests here seems to have passed without issue. |
When I run the cypress tests in my environment I occasionally see 'random' errors that are totally unrelated to the code changes. The same behavior can be observed in some of the official CI runs that fail only to succeed the next time without any changes in between. We've also confirmed through manual testing that the code works as expected. Unless there is a clear pattern I wouldn't worry about it. |
no no i didn't. they fail at different steps, but probably some configuration or bad package on my conda env 🤷 |
What changes were proposed in this pull request?
This aims to introduce a new property to configure the public endpoint for the Cloud Objecte Storage if necessary.
In some cases (ours for example) we run separate services with separate policies for access, so we use a private endpoint for the API (which normally writes or it's meant to be used by automated components) and a public endpoint only for read that is meant to be provided to the user.
This is the result of this change
How was this pull request tested?
This change is very easy, no "new logic", well apart of creating a variable that tries to get the configured value from the runtime configuration an if doesn't exists uses the API endpoint that is mandatory.
Make sure that the pre change works well:
object storage
link and open the private oneMake sure that the new public endpoint works
object storage
link and open the public oneDeveloper's Certificate of Origin 1.1