Re: [atomic-devel] a better place for system container images?

[Stephen Milner <smilner redhat com>]

On Mon, Nov 6, 2017 at 10:50 AM, Dusty Mabe <dusty dustymabe com> wrote:
>
>
> On 11/06/2017 08:29 AM, Giuseppe Scrivano wrote:
>> Hi Dusty,
>>
>> Dusty Mabe <dusty dustymabe com> writes:
>>
>>> On 11/06/2017 03:57 AM, Giuseppe Scrivano wrote:
>>>> Hi,
>>>>
>>>> I'd like to find a better place where to move the system container[1]
>>>> images that I am currently building under docker.io/gscrivano.
>>>>
>>>> CRI-O and Docker them are already used by the OpenShift installer to get
>>>> the latest version available.
>>>
>>> Are you saying the openshift installer uses docker.io/gscrivano now?
>>
>> yes, docker.io/gscrivano/cri-o-centos and docker.io/gscrivano/cri-o-fedora
>> are used for the CRI-O system container.
>>
>>
>>> I understand that we want upstream images for "latest" content in an upstream
>>> repository but we have to be careful that people know they shouldn't use it in
>>> production or otherwise rely on these images long term. I think putting them under
>>> projectatomic/ on docker hub might not be clear enough. Ideas:
>>>
>>> - create a projectatomic-devel organization and put them under there
>>> - put them under projectatomic/ but add devel or upstream in the name of each image.
>>
>> would a tag be enough?
>
> My personal opinion is no. Not many people inspect tags when using images.

Maybe we should find out how OpenShift solves this with their image
builds? Or, if the worry is people just use latest all the time, we
could keep latest tag as the latest non-dev release with dev images
tagged with dev in the name, or alpha/beta/0.X/etc..

>>
>>
>>> Openshift has a set of images they put out to the hub but they also have a
>>> team of people that do release engineering. One option would be to try to
>>> get them to agree to own the images and pushes to docker hub under the openshift
>>> namespace.
>>>> The goal is to build the images automatically on every PR merged.
>>>> Occasional builds (maybe daily?) will prevent to miss changes in the
>>>> base layers or in the installed rpms.
>>>
>>> Having the latest build pushed automatically to a registry is super useful,
>>> but mostly for the developers, not as much for users.
>>>
>>> I really don't want someone reading a blog post where the author uses these images
>>> and the reader then running them forever. Having "devel" in the name of the image
>>> URI will certainly help with that. Maybe I'm being too difficult.
>>
>> I don't think these images should get into the openshift namespace, as
>> most of them are not really connected to openshift.
>
> OK.
>
>
>>
>> Most of the time, changes to the image are bug fixes.  There is not
>> really much development happening in the system container itself, so I
>> don't see much disadvantage if these changes are propagated quickly.
>
> If there's not much changes going on then why can't we use the distro
> registry which has a process for rebuilding images periodically to account
> for CVEs? I know the Fedora registry is not perfect, but would like for us
> not to fragment and have so many different places to pull a system container
> from.
>
>> Even if we build them on the Fedora registry, they will still not work
>> "forever" as the Fedora release number is part of the image name.
>
> Yes, For whatever reason that was a decision made by Fedora to break up
> images and namespace them that way. I don't think it is a bad thing, though.

Agreed. Fedora specific images being split by version number makes
sense to me as well.

> Ultimately the projecatomic namespace [1] on docker hub is a tirefire of dead
> projects at this point other than maybe papr and asciibinder. There is no formal
> process for retiring things or releasing them or making sure they don't have CVEs.
> This model doesn't work and I'd prefer for it to go away complete IMHO.

The current "tirefire" model doesn't work, I agree. I believe we
already agreed on removing the old images from the projectatomic
namespace. However, I disagree that projectatomic on docker hub is a
bad location for images created by the Atomic team. While helping out
the openshift ansible team I found it very frustrating to try to
support 4 different registries and many more namespaces.

We can't be perfect, but we can make things better :-)

-- 
Thanks,
Steve Milner

Atomic | Red Hat | http://projectatomic.io/