On 18 April 2017 at 16:22, Juan Hernández <jhernand@redhat.com> wrote:
Hello,
Both exist:
https://hub.docker.com/u/ovirt https://hub.docker.com/u/ovirtorg
The first, 'ovirt', has some branding, but it is empty, no images.
The second, 'ovirtorg', has no branding, but hosts some images.
Which one should we use to publish our official images? I'd like to start publishing the images that we are building for the engine? Who has the credentials for that?
Hi Juan, I see you've been referred to all the relevant tickets in Jira. Let me try and summarise where we stand currently. The TL;DR is that everything that has to do with container publishing it still TBD and we (The CI team) are waiting for input from developers before implementing any capabilities into the system. When it comes to Dockerhub repos, as described in OVIRT-758 [1], we have the credentials for two of them: 1. ovirt - Which I guess would be used for "official" releases 2. ovirtinfra - Which I guess would be used for storing intermediate builds during the testing processes I'm not sure who holds 'ovirtorg' and for what. 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.
From our standpoint, we'd like to be able to create a similar process to what we have for RPMs currently, where artifacts get moved between different repositories as they progress in the testing process. The main issue with that is that Docker does not seem support a well structured notion of versions and repositories like RPMs do. I think this could be implemented by using tags, but this would necessitate taking approach #2 above, and developers might prefer using tags for other things.
A similar question is what official releases look like, I guess the 'latest' tag indicates some kind of a "release" for a container, but how does one maintain multiple official releases at the same time? Another related question is when do we release containers and who will do it, will it work in a similar process to how we release RPMs? Sine we do want to move things along and provide support, we've started work on OVIRT-894 [3] which would enable approach #1 above. Credentials are useful for many things, so I guess there will be no harm in implementing it even if we don't end up using it for containers. I hope this clarifies where we stand right now. [1]: https://ovirt-jira.atlassian.net/browse/OVIRT-758 [2]: https://ovirt-jira.atlassian.net/browse/OVIRT-890 [3]: https://ovirt-jira.atlassian.net/browse/OVIRT-894 -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted