Skip to content
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

TODO: Create architectural decision record issue to summarize why we want to use latest images: #508

Open
ckadner opened this issue May 30, 2024 · 4 comments
Assignees

Comments

@ckadner
Copy link
Member

ckadner commented May 30, 2024

TODO: Create architectural decision record issue to summarize why we want to use latest images:

Cons of using latest:

  • MM image builds might fail unexpectedly
  • hard to debug/trace back when failing changes happened
  • last working image may not be possible to recreate for a new MM release without any changes
  • last working image might not be available even if identified
  • even if builds succeed, there might be unexpected changes in behavior which happens quite often with 3rd party dependencies of Python packages (on a tangent: when we update to Go 1.19 a while ago, the go get CLI tools install commands "succeed" but no longer installed executables, though we would not use ubi8/go-toolset:latest)

Pros of using latest:

  • keeping specific version tag, we keep outdated code, old vulnerabilities
  • we don't have to keep updating to newer patched versions of base images when upstream base images get updated frequently

Builder vs final images:

  • using latest on a final build stage (not builder image) should be fairly "safe", no 3rd party libraries are installed, just files copied from builder image.
  • however, it's the base of the builder images where most problems/vulnerabilities are coming in/need to be fixed, are getting fixed upstream,
  • so really, all build stages need to build on a latest upstream (UBI) base image

Finally, we should follow the same strategy for all MM images consistently.

Originally posted by @ckadner in kserve/rest-proxy#43 (comment)

@ckadner
Copy link
Member Author

ckadner commented May 30, 2024

@ckadner ckadner self-assigned this May 30, 2024
@ckadner
Copy link
Member Author

ckadner commented Jun 4, 2024

We could add a nightly build to keep updated about the build status -- to not be surprised by failing builds when we start working on a release.

Additionally, failing builds could trigger notifications to be send to the "modelmesh-build" team. Team to be created.

Have a build matrix even to build several versions of UBI 8/9

@ckadner
Copy link
Member Author

ckadner commented Jun 11, 2024

@spolti with respect to FIPS we stay with UBI 8 for the time being. All the remaining MM images use UBI 8 latest for final build stage. Thanks!

@spolti
Copy link
Contributor

spolti commented Jun 12, 2024

About the FIPS, there is no public document yet, but the work still on going.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants