-
Notifications
You must be signed in to change notification settings - Fork 11
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
UPSTREAM: <carry>: Move Data Science Pipelines Dockerfiles to a different path #119
base: master
Are you sure you want to change the base?
Conversation
Commit Checker results:
|
ee206cc
to
1806d20
Compare
Commit Checker results:
|
1806d20
to
0457fe0
Compare
Commit Checker results:
|
0457fe0
to
06d8697
Compare
Commit Checker results:
|
Commit Checker results:
|
32ba29d
to
fb771c2
Compare
Commit Checker results:
|
backend/Dockerfile.driver
Outdated
|
||
LABEL name="ds-pipelines-driver" \ | ||
summary="DSP Driver" | ||
ENTRYPOINT [ "/bin/driver" ] |
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.
nitpick: Fix EoF here.
# 1. Build api server application | ||
FROM golang:1.21.7-bookworm as builder | ||
RUN apt-get update && apt-get install -y cmake clang musl-dev openssl | ||
WORKDIR /go/src/github.com/kubeflow/pipelines |
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.
this path needs to be pointing to where the odh/dsp APIServer code is, and not kubeflow/pipelines, I believe.
That might be causing this CI failure: https://github.com/opendatahub-io/data-science-pipelines/actions/runs/11960604493/job/33344984082?pr=119
Error from server (BadRequest): container "ml-pipeline-api-server" in pod "ml-pipeline-6cc48b7b9-zc785" is waiting to start: trying and failing to pull image
It's looking for an ml-pipeline-
apiserver pod, which we find in a KFP deployment. Corresponding APIServer pod in DSP would have ds-pipelines-
prefix.
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.
From https://github.com/opendatahub-io/data-science-pipelines/pull/119/files#r1852961305:
We want to leave the upstream Dockerfiles unchanged to avoid merge conflicts during rebase. Instead, we relocated the DSP Dockerfiles to the odh_images folder
That said, it seems like we should leave the original Dockerfiles identical to upstream.
If it's causing any errors, we may need to figure out how to work around these errors without having to change the Dockerfiles that come from upstream.
Does my point of view make sense?
backend/Dockerfile.driver
Outdated
|
||
LABEL name="ds-pipelines-driver" \ | ||
summary="DSP Driver" | ||
ENTRYPOINT [ "/bin/driver" ] |
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.
Nitpick to fix EoF :)
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Commit Checker results:
|
Commit Checker results:
|
e2c264b
to
26f2320
Compare
Commit Checker results:
|
9cc1191
to
58d3b66
Compare
Commit Checker results:
|
Commit Checker results:
|
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.
@VaniHaripriya I saw recently that Helber introduced a change in the Dockerfiles (see kubeflow#11348), and this will end up in merge conflicts when we rebase to 2.3.0.
I think it's safer if you copy the upstream Dockerfiles from 2.3.0 tag instead of master.
Commit Checker results:
|
Commit Checker results:
|
Commit Checker results:
|
@VaniHaripriya Don't forget that the commit messages should follow by this template:
|
Commit Checker results:
|
b8c80bf
to
3066dd2
Compare
Commit Checker results:
|
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.
@VaniHaripriya looks good in general.
I just left a few comments asking for more clarification.
Also, I'm worried about how we're going to track upstream changes and reflect them on the new Dockerfiles, if needed. Changes on those files may pass unnoticed in future rebases.
Maybe we need to add a step for reviewing changes in upstream Dockerfiles to https://github.com/opendatahub-io/data-science-pipelines/blob/master/REBASE.opendatahub.md.
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.
Why are you changing the original Dockerfiles? Is that to reflect the upstream ones?
Well, I think https://github.com/opendatahub-io/data-science-pipelines/pull/119/files#r1852961305 answers this question.
Please let me know, otherwise.
# 1. Build api server application | ||
FROM golang:1.21.7-bookworm as builder | ||
RUN apt-get update && apt-get install -y cmake clang musl-dev openssl | ||
WORKDIR /go/src/github.com/kubeflow/pipelines |
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.
From https://github.com/opendatahub-io/data-science-pipelines/pull/119/files#r1852961305:
We want to leave the upstream Dockerfiles unchanged to avoid merge conflicts during rebase. Instead, we relocated the DSP Dockerfiles to the odh_images folder
That said, it seems like we should leave the original Dockerfiles identical to upstream.
If it's causing any errors, we may need to figure out how to work around these errors without having to change the Dockerfiles that come from upstream.
Does my point of view make sense?
+1. I'm not a fan of this change for that reason (I think it's better to just deal with the rebasing / conflicts), but I'm out of the loop, so carry on :) |
…ent path Signed-off-by: VaniHaripriya <[email protected]>
3066dd2
to
4859079
Compare
Commit Checker results:
|
@hbelmiro @gregsheremeta I don't think the change rate for the Dockerfiles is substantial enough that we should track changes. After all, the base images used between upstream and downstream makes us change almost the whole Dockerfile. Working on resolving conflicts in these files during rebase is meaningless and we should avoid. |
Description of your changes:
This PR resolves RHOAIENG-12124
Checklist: