-
Notifications
You must be signed in to change notification settings - Fork 55
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
Bump mysql container image to one with an aarch64 image #267
base: main
Are you sure you want to change the base?
Conversation
Ahhh... yay the old "it worked on my laptop" scenario 🤦 I guess the new image isn't being loaded into kind on the CI jobs. |
isn't MR using MariaDB not mySQL that too a version that is matched with KFP? |
I believe we had to stick with the currently used version, as that's the one tested to be working with MLMD. Let me know your thoughts :) |
@tarilabs thanks for taking a look, I believe it will solve my issues, as I'm trying to deploy model registry without kubeflow (full explanation of what I'm trying to do on the ticket) - granted I've only run a few curl requests against the MR API on my local kind deployment, so there could be some hidden issue I'm not aware of, but so far they work as expected using the modified manifests on my fork. Let me know if I've misunderstood the core problem you described :) |
I was under impression that KFP team use MariaDB for writing some windowing functions over it which were only supported in MariaDB and working fine for them. May be this only used for Red Hat's distribution. |
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 was under impression that KFP team use MariaDB for writing some windowing functions over it which were only supported in MariaDB and working fine for them. May be this only used for Red Hat's distribution.
I believe the latter (and I believe the "window function" should have parity between mysql and mariadb).
this is as far as I can see KF 1.8:
KF 1.9:
and default branch "master":
Always mysql:8.0.3
.
My recommendation is as follows:
- send a PR first to KFP/manifest proposing this change, so we can gauge if pipeline team is in favour of aligning on this version (otherwise, we would be diverging from the common configuration)
- for DX, which is the goal of this PR, this could be handled by a different overlay for "dev"
- assess why tests are failing (condition on DB is not met)
* implement Go core changes * add test coverage * refactoring * minor message change * nit: renamed function
I want to augment the comment in #267 (review) 👉 |
Signed-off-by: Alex Creasy <[email protected]>
I still wonder why it fails at
|
@tarilabs I'm not sure, I haven't looked into it yet - it's strange, I can deploy this to kind locally. I'll dig into this next week and see what I can find. |
I wonder if it's some issue with pulling the image? At a guess (and this is a complete guess) I wonder if the db image needs to be manually loaded into kind for the deployment to be able to use it. |
Maybe, but this looks not being a problem for mysql 8.0.3 🤔 |
Signed-off-by: Matteo Mortari <[email protected]>
[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 |
let's see if 7a8bded is of any help in digging further into the actual error 🧐 |
Signed-off-by: Matteo Mortari <[email protected]>
with the log extraction, locate the following:
which brings up:
so the solution appears to be removing the AppArmor profile for mysql in the GHA runner... |
Signed-off-by: Matteo Mortari <[email protected]>
All green now, awesome 🚀 Now, if only we had some answer on... |
btw, I assume this resolves #266 |
btw, this also should be of great advantage to #327 (comment) |
Description
Bumps the version of the MySQL container image in the overlays/db kustomization to 8.0.39 which is multi-arch (amd64 / aarch64)
How Has This Been Tested?
Deployed to a local
kind
cluster on an apple silicon MacBook, using official instructions to deploy usingkind
on macOS.*https://www.kubeflow.org/docs/components/pipelines/legacy-v1/installation/localcluster-deployment/#kind
*https://www.kubeflow.org/docs/components/model-registry/installation/#standalone-installation
The only variation of above was that I deployed to kind using my branch of the manifest:
kubectl apply -k "https://github.com/alexcreasy/model-registry/manifests/kustomize/overlays/db?ref=kind"
I've verified I'm able to deploy as above, create a port forward to the service, and query the rest endpoint as indicated in the example above and receive a 200 response.
Merge criteria: