<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Apr 25, 2017 at 2:23 PM Barak Korren <<a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 18 April 2017 at 16:22, Juan Hernández <<a href="mailto:jhernand@redhat.com" target="_blank">jhernand@redhat.com</a>> wrote:<br>
> Hello,<br>
><br>
> Both exist:<br>
><br>
> <a href="https://hub.docker.com/u/ovirt" rel="noreferrer" target="_blank">https://hub.docker.com/u/ovirt</a><br>
> <a href="https://hub.docker.com/u/ovirtorg" rel="noreferrer" target="_blank">https://hub.docker.com/u/ovirtorg</a><br>
><br>
> The first, 'ovirt', has some branding, but it is empty, no images.<br>
><br>
> The second, 'ovirtorg', has no branding, but hosts some images.<br>
><br>
> Which one should we use to publish our official images? I'd like to<br>
> start publishing the images that we are building for the engine? Who has<br>
> the credentials for that?<br>
<br>
Hi Juan,<br>
<br>
I see you've been referred to all the relevant tickets in Jira. Let me try<br>
and summarise where we stand currently. The TL;DR is that everything that<br>
has to do with container publishing it still TBD and we (The CI team) are<br>
waiting for input from developers before implementing any capabilities into<br>
the system.<br>
<br>
When it comes to Dockerhub repos, as described in OVIRT-758 [1], we have the<br>
credentials for two of them:<br>
1. ovirt - Which I guess would be used for "official" releases<br></blockquote><div><br></div><div>You can talk with Fabian if you need to add stuff to ovirt docker.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. ovirtinfra - Which I guess would be used for storing intermediate builds<br>
during the testing processes<br>
<br>
I'm not sure who holds 'ovirtorg' and for what.<br></blockquote><div><br></div><div>ovirtorg was opened by Dan because we could not find who owns ovirt, and</div><div>it is used for vdsm testing images and other stuff.</div><div><br></div><div>We plan to move the images to ovirt docker when we find the time to do this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When it comes to publishing As described in the comments on OVIRT-890 [2],<br>
there are basically two approaches we could take.<br>
1. Let developers access the credentials for the repos from STD-CI scripts<br>
and do with then as they please. This will provide the greatest degree<br>
of freedom to developers but will make it hard to standardise on naming<br>
and versioning conventions.<br>
2. Establish a method for STD-CI scripts to indicate the there are<br>
containers to be published and let the CI system take care of the rest<br>
like it does for RPMs.<br></blockquote><div><br></div><div>We update vdsm image using github and docker. When you upload a new</div><div>commit to a special "dockerfile" branch, dockerhub builds new images</div><div>from the github branch.</div><div><br></div><div>You can also build the images manually if needed via docker hub web ui</div><div>or using web triggers.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>From our standpoint, we'd like to be able to create a similar process to<br>
what we have for RPMs currently, where artifacts get moved between<br>
different repositories as they progress in the testing process.<br>
The main issue with that is that Docker does not seem support a well<br>
structured notion of versions and repositories like RPMs do. I think this<br>
could be implemented by using tags, but this would necessitate taking<br>
approach #2 above, and developers might prefer using tags for other things.<br>
<br>
A similar question is what official releases look like, I guess the 'latest'<br>
tag indicates some kind of a "release" for a container, but how does one<br>
maintain multiple official releases at the same time? Another related<br>
question is when do we release containers and who will do it, will it work<br>
in a similar process to how we release RPMs?<br>
<br>
Sine we do want to move things along and provide support, we've started<br>
work on OVIRT-894 [3] which would enable approach #1 above. Credentials are<br>
useful for many things, so I guess there will be no harm in implementing it<br>
even if we don't end up using it for containers.<br>
<br>
I hope this clarifies where we stand right now.<br>
<br>
[1]: <a href="https://ovirt-jira.atlassian.net/browse/OVIRT-758" rel="noreferrer" target="_blank">https://ovirt-jira.atlassian.net/browse/OVIRT-758</a><br>
[2]: <a href="https://ovirt-jira.atlassian.net/browse/OVIRT-890" rel="noreferrer" target="_blank">https://ovirt-jira.atlassian.net/browse/OVIRT-890</a><br>
[3]: <a href="https://ovirt-jira.atlassian.net/browse/OVIRT-894" rel="noreferrer" target="_blank">https://ovirt-jira.atlassian.net/browse/OVIRT-894</a><br>
<br>
--<br>
Barak Korren<br>
RHV DevOps team , RHCE, RHCi<br>
Red Hat EMEA<br>
<a href="http://redhat.com" rel="noreferrer" target="_blank">redhat.com</a> | TRIED. TESTED. TRUSTED. | <a href="http://redhat.com/trusted" rel="noreferrer" target="_blank">redhat.com/trusted</a><br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a></blockquote></div></div>