Why are we creating this? Is the intent to supplant ceph-container.git?

Why are we creating this? Is the intent to supplant ceph-container.git?

ceph-container used to make sense, but nowadays it's just a super complicated way to write a Dockerfile. Especially the overall maintenance burden is significantly reduced by adding the file here directly. Especially when dealing with changed between Ceph versions.

I think it's a fair point that ceph-container is a little too complicated for what is strictly needed to produce Ceph images, and I think this is a good change. Since Rook (and all Rook's user-base) is also a major consumer of these images, I want to make sure we have input into what is happening here. I also want to make sure we aren't losing features that the ceph-container build gets us that are useful.

Building Ceph binaries and creating a container from them should allow us to build any Ceph version by going back to the git tag, branch, or hash and doing the build.

I think that starting the build for this just for master is the ideal case. Let's incrementally work toward replacing the build/release process for ceph/ceph. Currently, for testing the the latest Ceph master build (or latest-pacific/latest-octopus builds), we have ceph/daemon-base. It is nice to have Ceph's development images on a separate repo so that the images users will use don't get cluttered with all the latest images. It's probably best to create a new repo like ceph/devel for the new versions of these images so that ceph-container doesn't break what it does outside of the ceph/ceph builds. Also, daemon-base doesn't really give a very good idea of what the image is for or does.

Once we are producing latest-master images, I think backporting this to octopus and pacific to produce latest-octopus and latest-pacific images is the next logical step. I think that will also show a little bit of what kind of work will be needed to produce full ceph/ceph images (noted more below). The step after that, I would say would be to make sure we are building images automatically for at least x86 and ARM.

Thinking longer term, If we are replacing the build for ceph/ceph images, the bottom line of it is that we want to make sure the images that get produced have the same release tag structure unless there is something that really needs to be changed. I also want to clarify that I originally wrote the ceph-container scripts that produce the ceph/ceph images, and @leseb and @dmick had a big hand in the feedback for that.

• Currently, we get both x86 and ARM versions of images, and there is a manifest image that combines the two.
• The images are date-stamped with their creation date (the simplest way to make a monotonically increasing build number for docker builds) (e.g., v16.2.5-20210924). They also get tags like v16, v16.2, and v16.2.5 to allow for easier use in test scenarios.
• Of note, docker now has an experimental multi-arch build with the docker manifest command. This might help do the first item I mentioned a little easier.
• Once a release container image is produced, it should never be deleted. Only the higher-level tags can be moved to point to new images.

make sure cephadm can use the ceph version label on the container (instead of running ceph --version inside) to speed up cephadm ls

I'm not sure this is a good idea. It's not that much harder to run a container and run ceph --version in it than to check a container's images. This also prevents the case where users take a ceph image and then modify it with a new ceph version without updating the labels. Or just create their own ceph image and don't even apply the label to the build. In Rook, even though it's more work, we use ceph versions to see the versions of running daemons, and we always get the ceph version from running ceph --version in a pod.

This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
If you are a maintainer or core committer, please follow-up on this pull request to identify what steps should be taken by the author to move this proposed change forward.
If you are the author of this pull request, thank you for your proposed contribution. If you believe this change is still appropriate, please ensure that any feedback has been addressed and ask for a code review.

This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved

This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
If you are a maintainer or core committer, please follow-up on this pull request to identify what steps should be taken by the author to move this proposed change forward.
If you are the author of this pull request, thank you for your proposed contribution. If you believe this change is still appropriate, please ensure that any feedback has been addressed and ask for a code review.

This pull request has been automatically closed because there has been no activity for 90 days. Please feel free to reopen this pull request (or open a new one) if the proposed change is still appropriate. Thank you for your contribution!

This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days.
If you are a maintainer or core committer, please follow-up on this pull request to identify what steps should be taken by the author to move this proposed change forward.
If you are the author of this pull request, thank you for your proposed contribution. If you believe this change is still appropriate, please ensure that any feedback has been addressed and ask for a code review.

This pull request has been automatically closed because there has been no activity for 90 days. Please feel free to reopen this pull request (or open a new one) if the proposed change is still appropriate. Thank you for your contribution!