On Wed, 23 Oct 2019, Dimitri Savineau wrote:

Hi,

...

Is there a reason for the difference?

The build process between ceph/ceph and ceph/{daemon,daemon-base} is different.

What is the content difference between them? IIRC daemon-base has *just* packages installed, while ceph/ceph has all the bash scripts needed by ceph-nano and ansible.. is that still the case?

ceph/ceph container images are only built when: - a new ceph release is available (like next 14.2.5) - a new base image is available (like centos:7 update)

ceph/{daemon,daemon-base} container images are only built on ceph/ceph-container.git project changes.

Can we simplify all of this to have a more consistent/streamlined approach, and/or reduce the # of images? It seems like we could have just 2 images: ceph/daemon-base -- just the daemons + packages ceph/ceph -- daemon-base + the extra scripts (just for compat w/ existing users) and then have tags like v14 - latest nautilus v14.2 - latest stable nautilus (same as above unless we are pre-release) v14.2.3 - specific point release and then also v14-tip - latest dev branch (daily) ...although the latter could actually come from quay.io/cephci if we fix the stupid ceph-build issue that is making it *only* build containers for wip-* branches. In cephci, there'd be tags like nautilus octopus wip-foo-bar-baz-$date-$distro-$arch-devel When ceph-container.git updates, we could either do nothing or push a big button to rebuild everything? I'm unclear on how often older images need to be rebuilt... sage

...

Should we be using ceph/ceph or ceph/daemon-base? What's the difference?

I think it depends on what you are looking for. If you need stable images that follow the ceph releases then ceph/ceph is the way to go. Rook project is using them. If you need devel images then ceph/{daemon,daemon-base} images is maybe more appropriate. As an example, you don't have octopus container images on ceph/ceph. Or if you want what is present in a stable branch but not released yet.

...

It also seems to me "latest-" is unclear. Someone may think that "latest-nautilus" means the most recent release but it probably means (??) whatever ceph.git:heads/nautilus is. I'd recommend that be "dev-nautilus" instead. "nautilus" should be an alias for whatever the most recent release is.

Agreed it's unclear. The main confusion here is that it's not based on the ceph/ceph.git content but on ceph/ceph-container.git content. So latest-nautilus container tag doesn't mean the latest ceph nautilus content but the latest build system based on nautilus. Worth to mention it but the latest-xxxx tags are based on the stable ceph release from download.ceph.com except the master one based on chacra bits. That's why you can't have latest ceph/ceph content from a stable branch with latest-xxxx tag.

...

Hmm, also, what's the difference between latest-master and latest-master-devel? Because the latest-xxxx are based on the stable ceph release (except master) some people would like to test the unreleased code on a stable branch. That's why there's the latest-xxxx-devel tag. The ceph bits come from chacra and we're using a nightly job to build the container image.

Regards,

Dimitri

On Wed, Oct 23, 2019 at 11:42 AM Sage Weil <sweil@redhat.com> wrote:

...

On Wed, 23 Oct 2019, Sage Weil wrote:

...

I noticed that ceph/ceph has tags like

v14 v14.2 v14.2.2 v14.2.2-20190830

whereas ceph/daemon-base has tags like

latest-master latest-nautilus latest-mimic

but no version tags.

Hmm, also, what's the difference between latest-master and latest-master-devel?

$ sudo ../src/ceph-daemon --image ceph/daemon-base:latest-master version ceph version 15.0.0-6216-g2502df3 (2502df3084999edf8b19ced16fae7b862b91a827) octopus (dev) $ sudo ../src/ceph-daemon --image ceph/daemon-base:latest-master-devel version ceph version 15.0.0-5629-g2ab601a (2ab601ac0131a19ca93c743d95e83cc8eec59fcb) octopus (dev)

...

Is there a reason for the difference?

Should we be using ceph/ceph or ceph/daemon-base? What's the

difference?

...

That tags for ceph/ceph seem more intuitive/useful for users, although it seems like we really want both latest-* and v* tags.

Thanks! sage

_______________________________________________ Dev mailing list -- dev@ceph.io To unsubscribe send an email to dev-leave@ceph.io

On Wed, 30 Oct 2019, Dimitri Savineau wrote:

...

What is the content difference between them? IIRC daemon-base has *just* packages installed, while ceph/ceph has all the bash scripts needed by ceph-nano and ansible.. is that still the case?

ceph/daemon-base has only packages installed ceph/daemon is based from daemon-base and adds bash scripts and other tools.

ceph/ceph is actually an alias to ceph/daemon-base but with different tags (based on ceph/ceph.git releases)

...

Can we simplify all of this to have a more consistent/streamlined approach, and/or reduce the # of images? It seems like we could have just 2 images:

ceph/daemon-base -- just the daemons + packages ceph/ceph -- daemon-base + the extra scripts (just for compat w/ existing users)

We could probably remove daemon-base and use ceph/ceph as a base image. This requires to add ceph@master support to ceph/ceph build system.

...

and then have tags like

v14 - latest nautilus v14.2 - latest stable nautilus (same as above unless we are pre-release) v14.2.3 - specific point release

We already have this tags (except the z release) on ceph/ceph

Oh! Okay, that sounds like it's mostly what we want (except that having daemon-base around too is sort of confusing). I'll switch all the defaults to be ceph/ceph:v14 (or v15 or whatever). I think my only question/suggestion is whether we should have a default tag (does such a think exist? e.g., if you do podman pull ceph/ceph what do you get?) or maybe 'stable' tag that just tracks the latest stable release (v14 alias currently; would switch to v15 once octopus is out, etc.)

...

and then also

v14-tip - latest dev branch (daily)

...although the latter could actually come from quay.io/cephci if we fix the stupid ceph-build issue that is making it *only* build containers for wip-* branches. In cephci, there'd be tags like

There's probably something that can be improved [1]

Aha... yeah, that's helpful, thanks! In my perfect world you'd be able to do cephci/ceph:$branch (e.g. cephci/ceph:master or cephci/ceph:nautilus). Right now those tag names have a bunch of other stuff in them too (and are only wip-*). Thanks! sage