2:22 p.m.
On 18 April 2017 at 16:22, Juan Hernández <jhernand(a)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
5:47 p.m.
New subject: Which is the official oVirt docker repository, 'ovirt' or 'ovirtorg'?
On Tue, Apr 25, 2017 at 2:23 PM Barak Korren <bkorren(a)redhat.com> wrote:
On 18 April 2017 at 16:22, Juan Hernández <jhernand(a)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
You can talk with Fabian if you need to add stuff to ovirt docker.
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.
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.
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.
You can also build the images manually if needed via docker hub web ui
or using web triggers.
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
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
6:01 p.m.
New subject: 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
2768
days inactive
2768
days old
2 comments
2 participants
participants (2)
-
Barak Korren -
Nir Soffer