Comments (21)
FYI: Starting to set up the skeleton of the new Containerfile and github actions builds here: ceph/ceph#54575
from ceph-container.
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)
from ceph-container.
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:
quay.io/ceph/daemon-base:latest-quincy-devel
quay.io/ceph/daemon-base:latest-reef-devel
When the images are build from the ceph/ceph
repo, can we get these tags also built? Even better if we could just get these tags in the quay.io/ceph/ceph
repo, it has always been confusing having the daemon-base
repo.
from ceph-container.
@travisn good question.
Personally, I think it makes sense to go one of two ways:
- Use
quay.io/ceph/ceph
for all images including dev builds, OR - Use a new
quay.io/ceph/devel
library for the dev builds
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 quay.io/ceph/devel:latest-main
as well as the commithash version.
In release branches, Dockerfiles will use the latest corresponding release build of Ceph, and the GitHub action will still publish to quay.io/ceph/devel:latest-<release>
as well as the commithash version.
When a particular Ceph version on GitHub is tagged as a release, it should be given a tag like v18.2.1
using GitHub's "Releases" feature. When the GitHub action sees a tag like this, it should publish an image with that tag to quay.io/ceph/ceph:<tag>
, plus quay.io/ceph/ceph:<tag>-<date>
(in addition to the regular commithash and latest-<release>
publish to quay.io/ceph/devel
). This process can also be used for release candidates with tags like v18.2.1-RC0
if desired.
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 v*
tags can do this, and there is a github action that should make it easy to only publish new image versions when there are base image changes: https://www.flypenguin.de/2021/07/30/auto-rebuild-docker-images-if-base-image-changes-using-github-actions/
from ceph-container.
I think renaming this repo to alt-containers
might be good to signify that its purpose is changed dramatically. I suspect that it is not widely used, and that we won't see many changes or much interest in it after the move Ken is proposing.
from ceph-container.
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:
quay.io/ceph/daemon-base:latest-quincy-devel
quay.io/ceph/daemon-base:latest-reef-devel
When the images are build from the
ceph/ceph
repo, can we get these tags also built? Even better if we could just get these tags in thequay.io/ceph/ceph
repo, it has always been confusing having thedaemon-base
repo.
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 quay.ceph.io/ceph-ci/ceph:<release>
e.g. quay.ceph.io/ceph-ci/ceph:reef
and it would be detrimental to lose those. I'm not sure how the naming would be moving forward but I don't see a world where people are happy with us not making regular builds of the stable branches.
from ceph-container.
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.
from ceph-container.
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?
from ceph-container.
I think quay.ceph.io/ceph-ci/ceph
is a good option for what I proposed above as quay.io/ceph/devel
. I didn't know about those images.
from ceph-container.
Great idea! I propose to consider to use https://github.com/GoogleContainerTools/distroless images as base images.
from ceph-container.
Related Issues (20)
- Is there any plan to support Mariner as base OS in future. HOT 2
- Unable to download image HOT 2
- Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist HOT 6
- I want ceph-container to support packaging private images HOT 2
- ceph uses normal users for ssh connections HOT 3
- Ceph container build failed with centos stream8 image HOT 3
- /opt/ceph-container/bin/osd_disk_prepare.sh: line 46: ceph-disk: command not found HOT 7
- Need fix for CVE-2022-21797 HOT 4
- Bootstrap process hangs up for hours HOT 2
- not found /var/lib/ceph/osd/ceph-2//keyring HOT 2
- dnf update in ceph v18 container image is failing HOT 2
- RocksDBStore - cannot set permissions: Operation not permitted HOT 2
- /usr/bin/ceph: stderr Error EIO: Module 'cephadm' has experienced an error and cannot handle commands: ContainerInspectInfo HOT 2
- add ceph-mgr-callhome to IBM downstream container HOT 2
- cephadm has failed ContainerInspectInfo HOT 2
- populate_kvstore error HOT 1
- reef builds don't work HOT 12
- Question about osd directory HOT 2
- docker-compose setup dose not run as expected mds and osd HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ceph-container.