23 Jun
2021
23 Jun
'21
7:15 p.m.
Hi Dimitri,
Right now we're using CentOS for the base image for Ceph containers.
Now that CentOS is moving to a rolling-upgrade-esque style release
with CentOS Stream, it's an open question if we should stick with it.
A more stable base image that gets reliable security fixes would be
preferable. One thought is to use Red Hat's Universal Base Image (UBI)
[1] which is just RHEL-lite with a target audience of upstream
projects. Or perhaps we can select another base image.
What do you think?
[1] https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image
--
Patrick Donnelly, Ph.D.
He / Him / His
Principal Software Engineer
Red Hat Sunnyvale, CA
GPG: 19F28A586F808C2402351B93C3301A3E258DD79D
23 Jun
23 Jun
7:32 p.m.
I like the idea of using RH's UBI for having a more lightweight image. I doubt it will
make a whole lot of difference once Ceph is installed, but who knows. Ultimately, I think
choosing the option that will get the most reliable security fixes is the best option for
users. I think UBI probably fits that bill, but if that turns out to be CentOS Stream,
then we can do that as well.
This might be a good time to think about creating a new repo to build the image as well.
I'm not sure how much of ceph-container's complexity we really need to have for
building those images. IMO, having something a little more transparent might be better.
Blaine
7:33 p.m.
Adding so people can read about the EULA associated with this
particular choice: https://developers.redhat.com/articles/ubi-faq
On Wed, Jun 23, 2021 at 12:16 PM Patrick Donnelly <pdonnell(a)redhat.com> wrote:
>
> Hi Dimitri,
>
> Right now we're using CentOS for the base image for Ceph containers.
> Now that CentOS is moving to a rolling-upgrade-esque style release
> with CentOS Stream, it's an open question if we should stick with it.
> A more stable base image that gets reliable security fixes would be
> preferable. One thought is to use Red Hat's Universal Base Image (UBI)
> [1] which is just RHEL-lite with a target audience of upstream
> projects. Or perhaps we can select another base image.
>
> What do you think?
>
> [1] https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image
>
> --
> Patrick Donnelly, Ph.D.
> He / Him / His
> Principal Software Engineer
> Red Hat Sunnyvale, CA
> GPG: 19F28A586F808C2402351B93C3301A3E258DD79D
> _______________________________________________
> Dev mailing list -- dev(a)ceph.io
> To unsubscribe send an email to dev-leave(a)ceph.io
24 Jun
24 Jun
8:56 a.m.
ceph-container already supports UBI
https://github.com/ceph/ceph-container/tree/master/ceph-releases/ALL/ubi8
for downstream builds.
So it should be simple to change the build system to use a different base image.
Also, Dimitri is on paternity leave and will resume next week.
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Wed, Jun 23, 2021 at 7:34 PM David Orman <ormandj(a)corenode.com> wrote:
Adding so people can read about the EULA associated with this
particular choice: https://developers.redhat.com/articles/ubi-faq
On Wed, Jun 23, 2021 at 12:16 PM Patrick Donnelly <pdonnell(a)redhat.com> wrote:
Hi Dimitri,
Right now we're using CentOS for the base image for Ceph containers.
Now that CentOS is moving to a rolling-upgrade-esque style release
with CentOS Stream, it's an open question if we should stick with it.
A more stable base image that gets reliable security fixes would be
preferable. One thought is to use Red Hat's Universal Base Image (UBI)
[1] which is just RHEL-lite with a target audience of upstream
projects. Or perhaps we can select another base image.
What do you think?
[1] https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image
--
Patrick Donnelly, Ph.D.
He / Him / His
Principal Software Engineer
Red Hat Sunnyvale, CA
GPG: 19F28A586F808C2402351B93C3301A3E258DD79D
_______________________________________________
Dev mailing list -- dev(a)ceph.io
To unsubscribe send an email to dev-leave(a)ceph.io
_______________________________________________
Dev mailing list -- dev(a)ceph.io
To unsubscribe send an email to dev-leave(a)ceph.io
2:53 p.m.
I have a related question about how we currently build release
containers. Clearly when an actual release is made we build a fresh
container for that release, based on the latest version of the base
image (with all of the latest security updates).
When the base image is updated, do we also rebuild past release
containers? Which ones?
sage
3:16 p.m.
AFAIR for each stable release of Nautilus/Octopus/Pacific available on
download.ceph.com we will check if the base image changed and rebuild
in consequence.
On rebuild the suffix with the build date will be appended, resulting
in an image called: ceph/ceph-amd64:v14.2.6-20201116
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, Jun 24, 2021 at 2:53 PM Sage Weil <sage(a)newdream.net> wrote:
I have a related question about how we currently build release
containers. Clearly when an actual release is made we build a fresh
container for that release, based on the latest version of the base
image (with all of the latest security updates).
When the base image is updated, do we also rebuild past release
containers? Which ones?
sage
3:35 p.m.
Does this happen for all dot releases, or just the most recent one?
On Thu, Jun 24, 2021 at 8:16 AM Sebastien Han <shan(a)redhat.com> wrote:
>
> AFAIR for each stable release of Nautilus/Octopus/Pacific available on
> download.ceph.com we will check if the base image changed and rebuild
> in consequence.
> On rebuild the suffix with the build date will be appended, resulting
> in an image called: ceph/ceph-amd64:v14.2.6-20201116
>
> Thanks!
> –––––––––
> Sébastien Han
> Senior Principal Software Engineer, Storage Architect
>
> "Always give 100%. Unless you're giving blood."
>
> On Thu, Jun 24, 2021 at 2:53 PM Sage Weil <sage(a)newdream.net> wrote:
> >
> > I have a related question about how we currently build release
> > containers. Clearly when an actual release is made we build a fresh
> > container for that release, based on the latest version of the base
> > image (with all of the latest security updates).
> >
> > When the base image is updated, do we also rebuild past release
> > containers? Which ones?
> >
> > sage
> >
>
3:38 p.m.
All dot releases from Nautilus to Pacific.
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, Jun 24, 2021 at 3:35 PM Sage Weil <sage(a)newdream.net> wrote:
Does this happen for all dot releases, or just the most recent one?
On Thu, Jun 24, 2021 at 8:16 AM Sebastien Han <shan(a)redhat.com> wrote:
AFAIR for each stable release of Nautilus/Octopus/Pacific available on
download.ceph.com we will check if the base image changed and rebuild
in consequence.
On rebuild the suffix with the build date will be appended, resulting
in an image called: ceph/ceph-amd64:v14.2.6-20201116
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, Jun 24, 2021 at 2:53 PM Sage Weil <sage(a)newdream.net> wrote:
I have a related question about how we currently build release
containers. Clearly when an actual release is made we build a fresh
container for that release, based on the latest version of the base
image (with all of the latest security updates).
When the base image is updated, do we also rebuild past release
containers? Which ones?
sage
28 Jun
28 Jun
4:01 p.m.
Hi,
Thanks Sebastien for answering some questions.
Right now we're using CentOS for the base image
for Ceph containers.
Now that CentOS is moving to a rolling-upgrade-esque style release
with CentOS Stream, it's an open question if we should stick with it.
A more stable base image that gets reliable security fixes would be
preferable. One thought is to use Red Hat's Universal Base Image (UBI)
[1] which is just RHEL-lite with a target audience of upstream
projects. Or perhaps we can select another base image.
That's a question I started to think about at the start of this year
(before my parental leave).
And the answer is really tied with the decision about how we will ship el8
packages.
Before thinking about the base container image, we should decide what we
should use as a base distro for building the el8 packages.
The solution for the container image will likely follow the same path.
As of today, here are my thoughts on the possible solutions:
- centos stream : could be the easiest solution but with a rolling release
distro, we might have more issues with recent distro updates.
I guess centos stream will be a good choice to start testing el9 earlier.
- ubi8 : I guess that's a no go even if this is close to the Red Hat
downstream image.
The ubi repositories available from the image aren't enough for installing
the ceph packages.
You still need to deal with subscription manager or other.
- almalinux [1][2] / rockylinux [3][4] : both are really CentOS clones and
available as a base container image on x86_64 and arm64.
When I made some tests few months ago, the almalinux image (rockylinux
wasn't released yet) only required a one line patch to the ceph-container
project.
[1] https://almalinux.org/
[2] https://hub.docker.com/_/almalinux
[3] https://rockylinux.org/
[4] https://hub.docker.com/r/rockylinux/rockylinux
Regards,
Dimitri
On Thu, Jun 24, 2021 at 9:38 AM Sebastien Han <shan(a)redhat.com> wrote:
All dot releases from Nautilus to Pacific.
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, Jun 24, 2021 at 3:35 PM Sage Weil <sage(a)newdream.net> wrote:
Does this happen for all dot releases, or just the most recent one?
On Thu, Jun 24, 2021 at 8:16 AM Sebastien Han <shan(a)redhat.com> wrote:
AFAIR for each stable release of Nautilus/Octopus/Pacific available on
download.ceph.com we will check if the base image changed and rebuild
in consequence.
On rebuild the suffix with the build date will be appended, resulting
in an image called: ceph/ceph-amd64:v14.2.6-20201116
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, Jun 24, 2021 at 2:53 PM Sage Weil <sage(a)newdream.net> wrote:
I have a related question about how we currently build release
containers. Clearly when an actual release is made we build a fresh
container for that release, based on the latest version of the base
image (with all of the latest security updates).
When the base image is updated, do we also rebuild past release
containers? Which ones?
sage
1 Jul
1 Jul
11:01 a.m.
Hi Dimitri
Am 28.06.21 um 16:01 schrieb Dimitri Savineau:
Hi,
Thanks Sebastien for answering some questions.
We could stay for a while on stream and decide later on, if the pain of
a rolling release is too big. AFAIK there is
nothing that forces us to decide on anything at this point, right? If it
turns out we have good reasons to choose
a different base, we could re-iterate on this.
Right now we're using CentOS for the base
image for Ceph containers.
Now that CentOS is moving to a rolling-upgrade-esque style release
with CentOS Stream, it's an open question if we should stick with it.
A more stable base image that gets reliable security fixes would be
preferable. One thought is to use Red Hat's Universal Base Image (UBI)
[1] which is just RHEL-lite with a target audience of upstream
projects. Or perhaps we can select another base image.
That's a question I started to think about at the start of this year
(before my parental leave).
And the answer is really tied with the decision about how we will ship
el8 packages.
Before thinking about the base container image, we should decide what
we should use as a base distro for building the el8 packages.
The solution for the container image will likely follow the same path.
As of today, here are my thoughts on the possible solutions:
- centos stream : could be the easiest solution but with a rolling
release distro, we might have more issues with recent distro updates.
I guess centos stream will be a good choice to start testing el9 earlier.
- ubi8 : I guess that's a no go even if this is close to the Red Hat
downstream image.
The ubi repositories available from the image aren't enough for
installing the ceph packages.
You still need to deal with subscription manager or other.
- almalinux [1][2] / rockylinux [3][4] : both are really CentOS clones
and available as a base container image on x86_64 and arm64.
When I made some tests few months ago, the almalinux image (rockylinux
wasn't released yet) only required a one line patch to the
ceph-container project.
[1] https://almalinux.org/ <https://almalinux.org/>
[2] https://hub.docker.com/_/almalinux
<https://hub.docker.com/_/almalinux>
[3] https://rockylinux.org/ <https://rockylinux.org/>
[4] https://hub.docker.com/r/rockylinux/rockylinux
<https://hub.docker.com/r/rockylinux/rockylinux>
Regards,
Dimitri
On Thu, Jun 24, 2021 at 9:38 AM Sebastien Han <shan(a)redhat.com
<mailto:shan@redhat.com>> wrote:
All dot releases from Nautilus to Pacific.
Thanks!
–––––––––
Sébastien Han
Senior Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
On Thu, Jun 24, 2021 at 3:35 PM Sage Weil <sage(a)newdream.net
<mailto:sage@newdream.net>> wrote:
Does this happen for all dot releases, or just the most recent one?
On Thu, Jun 24, 2021 at 8:16 AM Sebastien Han <shan(a)redhat.com
<mailto:shan@redhat.com>> wrote:
>
> AFAIR for each stable release of Nautilus/Octopus/Pacific
available on
> download.ceph.com
<http://download.ceph.com> we will check if
the base image changed and
rebuild
> in consequence.
> On rebuild the suffix with the build date will be appended,
resulting
> in an image called:
ceph/ceph-amd64:v14.2.6-20201116
>
> Thanks!
> –––––––––
> Sébastien Han
> Senior Principal Software Engineer, Storage Architect
>
> "Always give 100%. Unless you're giving blood."
>
> On Thu, Jun 24, 2021 at 2:53 PM Sage Weil <sage(a)newdream.net
<mailto:sage@newdream.net>> wrote:
> >
> > I have a related question about how we currently build release
> > containers. Clearly when an actual release is made we build
a
fresh
> > container for that release, based on
the latest version of
the base
image (with all of the latest security updates).
When the base image is updated, do we also rebuild past release
containers? Which ones?
sage
1023
days inactive
1031
days old
9 comments
7 participants
participants (7)
-
blaine.gardner＠redhat.com -
David Orman -
Dimitri Savineau -
Patrick Donnelly -
Sage Weil -
Sebastian Wagner -
Sebastien Han