rename and repurpose this repository #2171
Comments
|
Great to hear about the simplification. What about the builds that currently come out of the ceph-container repo? For example, in Rook we rely on these tags to test against the latest merges to the various branches:
When the images are build from the |
|
@travisn good question. Personally, I think it makes sense to go one of two ways:
Probably the latter is best. I think all the different builds can be handled by the configuration of GitHub actions, combined with any special changes needed in release branches. In the main branch, the Dockerfile will use the latest main build of Ceph, and the GitHub action will publish to In release branches, Dockerfiles will use the latest corresponding release build of Ceph, and the GitHub action will still publish to When a particular Ceph version on GitHub is tagged as a release, it should be given a tag like One of the other things that GitHub actions should probably do is to regularly re-build tagged, released images with the latest base image. The base image (stream8, stream9-minimal, etc.) will have regular, ongoing security fixes that some users may want. A GH action cron that runs daily on |
|
I think renaming this repo to |
I assume however we move forward we'll continue building regular images of the stable branches. We already do daily builds of the pacific onward stable branches to make sure they can be nuilt and used in baseline runs. Those are currently pushed to |
|
I really like this idea. I think it has the potential to simplify processes involved in testing and building ceph containers downstream as well as upstream. |
|
hear, hear! I'm all for simplifying how the container image(s) are built. I've felt for a while that this code is too complex for the result it produces. I might have some quibbles with the exact structure or location for this Containerfile but that can be handled elsewhere. As for repos and tagging, I feel obligated to mention that ceph produces release containers at quay.io/ceph/ceph as well as ci/testing containers at quay.ceph.io/ceph-ci/ceph. The 'go-ceph' project uses both in it's ci - the former for required tests against major releases and the latter for integration tests against unreleased branches. If the latter is suitable for the rook use case, perhaps no new repos need to be created? |
|
I think |
|
As you note, this has been proposed before. All the issues above are valid; I'm paranoid about finding all the users of ceph-container, but I think the time is right to simplify (having just spent another few hours trying to understand make macros in ceph-container) |
|
Great idea! I propose to consider to use https://github.com/GoogleContainerTools/distroless images as base images. |
|
FYI: Starting to set up the skeleton of the new Containerfile and github actions builds here: ceph/ceph#54575 |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically closed due to inactivity. Please re-open if this still requires investigation. |
|
I wish github didn't close as "completed". :/ |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically closed due to inactivity. Please re-open if this still requires investigation. |
|
Looks like this is work: ceph/ceph#54575, so why to close? |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions. |
|
This issue has been automatically closed due to inactivity. Please re-open if this still requires investigation. |
|
@guits would you please re-open this? I still think we should rename this repository and edit the README to make it clear to new contributors. @dmick, what's the next step to use the https://github.com/ceph/ceph/blob/main/container/Containerfile for releases? |
|
working on a branch. I have a few changes to build.sh and several more to make-manifest-list.py, a Jenkins job to run the manifest-image build on demand, and need to get skopeo installed on builders. I think it's mostly working, just takes a multi-stage changeover. |
|
This is my current hopefully-close-to-final step for release container building to replace ceph-container: ceph/ceph#60755 |
|
@dmick With the completion of this, are daemon-base devel images effectively deprecated and we should start using |
|
@travisn I'm gonna say a guarded "yes", but let's chat briefly about rook CI and release processes and make sure I'm accommodating your needs |
|
I am in favor of archiving ceph-container whenever it makes sense for the Ceph project. It's been a long time coming. My biggest concern around this general topic is regular ARM builds. That doesn't have to be an immediate need, nor does it have to hold up archiving this repo, but I hope it's something we can work toward if it's not set up today. I don't think we need ARM builds for every Ceph PR or commit merge. Those could be good on occasion, but I can imagine drawbacks for Ceph CI processes. A nightly-ish build will get us far. Rook runs a nightly suite on ARM, and we ideally want to run a nightly build check there too. If that isn't happening right this minute, we can limit our ARM nightly to use released Ceph versions that do have ARM variants. Having regular ARM images is also of importance as more of the Rook developers are using Apple silicon macbooks. There are times when we need to get a devel image to test a fix or work on a fresh feature, and having to set up emulation is a pain when we do end up needing that. |
|
@BlaineEXE the intent with the new code in ceph.git:src/container is that a container is built whenever a build is done. I believe CI containers are built any time a ceph branch is built, for either arch; that is certainly the intent and it's a bug if not. |
The "ceph-container" GitHub project started as an experiment to containerize Ceph and make it integrate with Kubernetes. It has met this goal. I'm opening this ticket to propose how to containerize Ceph in the future.
Years ago, ceph-container provided a lot of extra experimental code (the different "flavors" like "ceph demo", the "sree" app, confd stuff, etc) and supported a wide variety of operating systems (Ubuntu, CentOS, Alpine, etc). Neither of these things are true today. Guillaume has simplified the code now so that it is almost a simple
Dockerfileand entrypoint script. We also only publish Ceph images with a single OS (CentOS 8 Stream), greatly simplifying QE effort.The templating system introduced in 2018 does not provide value today.
I suggest that we have a single
Dockerfileat the root of https://github.com/ceph/ceph that will be "the" Ceph container image. (see ceph/ceph#43292). Users who deploy Ceph withcephadmor Rook will use those stable sets of images. This ceph-container GitHub repository will no longer host theDockerfilefor that.There are a few people in the Ceph community who have discussed maintaining Ubuntu- or Debian-based container images. To provide a common place for these, I suggest renaming this GitHub repo from
ceph-containertoceph-containersoralt-containers, and rewrite the README to explain that this is now the location for the non-official or "alternative" container images. You could store simple, untemplatedDockerfiles within subdirectories likeubuntu,debian, etc.The text was updated successfully, but these errors were encountered: