Re: [ovirt-devel] Which is the official oVirt docker repository, 'ovirt' or 'ovirtorg'?
On 25 April 2017 at 17:47, Nir Soffer <nsoffer(a)redhat.com> wrote:
On Tue, Apr 25, 2017 at 2:23 PM Barak Korren
<bkorren(a)redhat.com> wrote:
ovirtorg was opened by Dan because we could not find who owns ovirt, and
it is used for vdsm testing images and other stuff.
We plan to move the images to ovirt docker when we find the time to do this.
As long as thos are testing images and not releases of official
containerized oVirt components they should probably stay there and not
move to the 'official' repo.
Possibly they could move to ovirtinfra.
> When it comes to publishing As described in the comments on
OVIRT-890 [2],
> there are basically two approaches we could take.
> 1. Let developers access the credentials for the repos from STD-CI scripts
> and do with then as they please. This will provide the greatest degree
> of freedom to developers but will make it hard to standardise on naming
> and versioning conventions.
> 2. Establish a method for STD-CI scripts to indicate the there are
> containers to be published and let the CI system take care of the rest
> like it does for RPMs.
We update vdsm image using github and docker. When you upload a new
commit to a special "dockerfile" branch, dockerhub builds new images
from the github branch.
This is hardly publishing. There is no way to get a proper testing/QA
process here. I mean, how do you prevent a bad build from being
published? How do you differentiate between an intermediate build for
CI and an official release? How do you keep multiple release branches?
How do you ensure that containers that are supposed to run together
but come from different sources get "published" at the same time?
This also limits you selection of container build tools to one.
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted