[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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




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.

> 
> 
>> 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.

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. 

[1] https://hub.docker.com/u/projectatomic/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]