7:52 a.m.
Hi,
This message is aimed for project maintainers. Other developers may
also find it interesting to have a glimpse at the oVirt-wide test and
composition processes.
TL;DR: To get accurate CI for oVirt 4.2, most projects
need to add 4.2 jobs in YAML.
Before I can explain what the current issue is and which action is
required, I'm need to provide a brief overview into how oVirt CI
works.
oVirt CI has two major components to it:
1. The STDCI component which is used to build and test individual
projects. Most developers interact with this on a daily basis as it is
responding on GitHub and Gerrit events.
2. The "change-queue" (CQ) component which is used to automatically
compose the whole of oVirt from its sub projects and run system tests
(OST) on it. This component is used to gather the information that is
used by the infra team to compose the "OST failure report" you can
occasionally see being sent to this list. The change queue is also
used to automatically maintain the 'tested' and '*-snapshot' (AKA
nightly) repositories.
The way the CQ composes oVirt is by looking at the post-merge STDCI
'build-artifacts' jobs, and collecting together artifacts built by
jobs that target a specific oVirt version into that version's change
queue. Essentially the '*_master_build-artifacts-*' jobs go into the
'ovirt-master' change queue, the '*_4.1_build-artifacts-*' jobs go
into the 'ovirt-4.1' change queue etc.
Over the course of the oVirt 4.2 development, most project used their
'master' branch, which is typically mapped to '*_master_*' jobs, for
developing 4.2 code. So the 'ovirt-master' CQ provided good indication
of the state of 4.2 code.
As projects started addeing 4.2 branches, we have created an
'ovirt-4.2' CQ to gather them. We did so under the assumption that
most projects will branch soon after. The assumption turned up to be
wrong as most projects did not yet fork and may not do so in the near
future.
As some projects did fork, the end result is that currently:
___there is no accurate representation of oVirt 4.2 in CI___
'ovirt-master' CQ no longer represents oVirt 4.2 as some projects
already have some 4.3 code in their 'master' branches.
'ovirt-4.2' CQ does not represent oVirt 4.2 as most projects do not
push artifacts into it.
To get any benefit from CI, we need to have it represent what we are
going to release. This means that at this point we need all projects
to have '*_4.2_build-artifacts-*' jobs that map to the code that is
intended to be included in oVirt 4.2. Projects can either:
1. Create 4.2 branches and map the new jobs to them.
2. Keep 4.2 development in 'master' and create '4.2' jobs that map to it.
Taking route #2 means a commitment to not adding any 4.3 code to the
'master' branch. Please keep it, as rolling back "too new" builds from
the various repos and caches we have is very difficult.
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
11:44 a.m.
Hi Barak,
can you please please add links to the proper repositories and/or
directories when you send something like this? I really helps us when
we do not have to search through all the jenkins and other infra
repositories for which is the correct one. Because I really do not
remember all the places that need to change out of my head.
So what you are asking for here is basically that we edit the files
here [1] and create a 4.2_build-artifacts job using copy and paste,
right? Or is there some other place that needs to change as well?
[1]
https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/project...
Best regards
Martin Sivak
On Tue, Jan 23, 2018 at 1:52 PM, Barak Korren <bkorren(a)redhat.com> wrote:
Hi,
This message is aimed for project maintainers. Other developers may
also find it interesting to have a glimpse at the oVirt-wide test and
composition processes.
TL;DR: To get accurate CI for oVirt 4.2, most projects
need to add 4.2 jobs in YAML.
Before I can explain what the current issue is and which action is
required, I'm need to provide a brief overview into how oVirt CI
works.
oVirt CI has two major components to it:
1. The STDCI component which is used to build and test individual
projects. Most developers interact with this on a daily basis as it is
responding on GitHub and Gerrit events.
2. The "change-queue" (CQ) component which is used to automatically
compose the whole of oVirt from its sub projects and run system tests
(OST) on it. This component is used to gather the information that is
used by the infra team to compose the "OST failure report" you can
occasionally see being sent to this list. The change queue is also
used to automatically maintain the 'tested' and '*-snapshot' (AKA
nightly) repositories.
The way the CQ composes oVirt is by looking at the post-merge STDCI
'build-artifacts' jobs, and collecting together artifacts built by
jobs that target a specific oVirt version into that version's change
queue. Essentially the '*_master_build-artifacts-*' jobs go into the
'ovirt-master' change queue, the '*_4.1_build-artifacts-*' jobs go
into the 'ovirt-4.1' change queue etc.
Over the course of the oVirt 4.2 development, most project used their
'master' branch, which is typically mapped to '*_master_*' jobs, for
developing 4.2 code. So the 'ovirt-master' CQ provided good indication
of the state of 4.2 code.
As projects started addeing 4.2 branches, we have created an
'ovirt-4.2' CQ to gather them. We did so under the assumption that
most projects will branch soon after. The assumption turned up to be
wrong as most projects did not yet fork and may not do so in the near
future.
As some projects did fork, the end result is that currently:
___there is no accurate representation of oVirt 4.2 in CI___
'ovirt-master' CQ no longer represents oVirt 4.2 as some projects
already have some 4.3 code in their 'master' branches.
'ovirt-4.2' CQ does not represent oVirt 4.2 as most projects do not
push artifacts into it.
To get any benefit from CI, we need to have it represent what we are
going to release. This means that at this point we need all projects
to have '*_4.2_build-artifacts-*' jobs that map to the code that is
intended to be included in oVirt 4.2. Projects can either:
1. Create 4.2 branches and map the new jobs to them.
2. Keep 4.2 development in 'master' and create '4.2' jobs that map to
it.
Taking route #2 means a commitment to not adding any 4.3 code to the
'master' branch. Please keep it, as rolling back "too new" builds from
the various repos and caches we have is very difficult.
--
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
1:35 a.m.
On 23 January 2018 at 18:44, Martin Sivak <msivak(a)redhat.com> wrote:
Hi Barak,
can you please please add links to the proper repositories and/or
directories when you send something like this? I really helps us when
we do not have to search through all the jenkins and other infra
repositories for which is the correct one. Because I really do not
remember all the places that need to change out of my head.
See below.
So what you are asking for here is basically that we edit the files
here [1] and create a 4.2_build-artifacts job using copy and paste,
right? Or is there some other place that needs to change as well?
Yep. technically this should amount to a single change to a single
file (See below). The important part is making the right decision for
each project, understanding its consequences, and realizing the
actions that would be needed for changing that decision in the future.
There is only one file** you need to maintain that is (currently) not
in your own project's repo***.
Each project has such a file at [1].
Documentation for the contents of that file can be found here: [2].
There is no need to copy-paste much - the existing file should contain
a mapping of project branches to oVirt versions. Typically what would
be needed is just to add a single entry to the map. For example, for
engine it would be****:
version:
- master:
branch: master
- 4.2:
branch: master
...
** Bigger projects can spread configuration across multiple files, but
this is rarely needed.
*** This applies only to Gerrit projects. GitHub projects have
everything configured in their own repo. See [3].
**** Specifically for engine, the map appears twice in the file, this
should probably be re-factored.
[1]:
https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/project...
[2]:
http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_Gerr...
[3]:
http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_GitH...
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
2:52 a.m.
On Wed, Jan 24, 2018 at 8:35 AM, Barak Korren <bkorren(a)redhat.com> wrote:
On 23 January 2018 at 18:44, Martin Sivak <msivak(a)redhat.com>
wrote:
> Hi Barak,
>
> can you please please add links to the proper repositories and/or
> directories when you send something like this? I really helps us when
> we do not have to search through all the jenkins and other infra
> repositories for which is the correct one. Because I really do not
> remember all the places that need to change out of my head.
See below.
> So what you are asking for here is basically that we edit the files
> here [1] and create a 4.2_build-artifacts job using copy and paste,
> right? Or is there some other place that needs to change as well?
Yep. technically this should amount to a single change to a single
file (See below). The important part is making the right decision for
each project, understanding its consequences, and realizing the
actions that would be needed for changing that decision in the future.
> [1]
https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/project...
There is only one file** you need to maintain that is (currently) not
in your own project's repo***.
Each project has such a file at [1].
Documentation for the contents of that file can be found here: [2].
There is no need to copy-paste much - the existing file should contain
a mapping of project branches to oVirt versions. Typically what would
be needed is just to add a single entry to the map. For example, for
engine it would be****:
version:
- master:
branch: master
- 4.2:
branch: master
...
If project maintainers opt for this "Route 2", it is their personal
responsibility to change the above "master" to "ovirt-4.2" branch
*BEFORE* they create their stable branch ovirt-4.2. If they fail to do
so, CI would get "dirty" with 4.3 packages. Barak hinted to this a
bit too mildly.
** Bigger projects can spread configuration across multiple files, but
this is rarely needed.
*** This applies only to Gerrit projects. GitHub projects have
everything configured in their own repo. See [3].
**** Specifically for engine, the map appears twice in the file, this
should probably be re-factored.
[1]:
https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/project...
[2]:
http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_Gerr...
[3]:
http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_GitH...
--
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
3:23 a.m.
--Apple-Mail=_0BC00364-3869-4932-9C43-2C39D9DB1B26
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On 24 Jan 2018, at 08:52, Dan Kenigsberg <danken(a)redhat.com>
wrote:
=20
On Wed, Jan 24, 2018 at 8:35 AM, Barak Korren <bkorren(a)redhat.com =
<mailto:bkorren@redhat.com>> wrote:
> On 23 January 2018 at 18:44, Martin Sivak
<msivak(a)redhat.com> wrote:
>> Hi Barak,
>>=20
>> can you please please add links to the proper repositories and/or
>> directories when you send something like this? I really helps us =
when
>> we do not have to search through all the jenkins and other
infra
>> repositories for which is the correct one. Because I really do not
>> remember all the places that need to change out of my head.
>=20
> See below.
>=20
>> So what you are asking for here is basically that we edit the files
>> here [1] and create a 4.2_build-artifacts job using copy and paste,
>> right? Or is there some other place that needs to change as well?
>=20
> Yep. technically this should amount to a single change to a single
> file (See below). The important part is making the right decision for
> each project, understanding its consequences, and realizing the
> actions that would be needed for changing that decision in the =
future.
>=20
>> [1] =
https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/confs/pr=
ojects;h=3D5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=3Dcd75bb9eb33536523=
84ed89777fc15d71d1f9e36
>=20
> There is only one file** you need to maintain that is (currently) not
> in your own project's repo***.
> Each project has such a file at [1].
>=20
> Documentation for the contents of that file can be found here: [2].
>=20
> There is no need to copy-paste much - the existing file should =
contain
> a mapping of project branches to oVirt versions. Typically what
would
> be needed is just to add a single entry to the map. For example, for
> engine it would be****:
>=20
> version:
> - master:
> branch: master
> - 4.2:
> branch: master
> ...
=20
If project maintainers opt for this "Route 2", it is their personal
responsibility to change the above "master" to "ovirt-4.2" branch
*BEFORE* they create their stable branch ovirt-4.2. If they fail to do
so, CI would get "dirty" with 4.3 packages. Barak hinted to this a
bit too mildly.
well, I still do not get the hint at all
Why exactly?
=20
>=20
> ** Bigger projects can spread configuration across multiple files, =
but
> this is rarely needed.
> *** This applies only to Gerrit projects. GitHub projects have
> everything configured in their own repo. See [3].
> **** Specifically for engine, the map appears twice in the file, this
> should probably be re-factored.
>=20
> [1]: =
https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/confs/pr=
ojects;hb=3Drefs/heads/master
> [2]: =
http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_Gerri=
t/index.html
> [3]: =
http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_GitHu=
b/index.html
>=20
>=20
>=20
> --
> 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
>=20
>=20
_______________________________________________
Devel mailing list
Devel(a)ovirt.org <mailto:Devel@ovirt.org>
http://lists.ovirt.org/mailman/listinfo/devel =
<http://lists.ovirt.org/mailman/listinfo/devel>
--Apple-Mail=_0BC00364-3869-4932-9C43-2C39D9DB1B26
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"
class=3D""><br =
class=3D""><div><br class=3D""><blockquote
type=3D"cite" class=3D""><div =
class=3D"">On 24 Jan 2018, at 08:52, Dan Kenigsberg <<a =
href=3D"mailto:danken@redhat.com"
class=3D"">danken(a)redhat.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div
class=3D""><span =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">On Wed, Jan 24, 2018 at 8:35 AM,
=
Barak Korren <</span><a href=3D"mailto:bkorren@redhat.com" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" =
class=3D"">bkorren(a)redhat.com</a><span style=3D"font-family:
Helvetica; =
font-size: 12px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: =
inline !important;" class=3D"">> wrote:</span><br
style=3D"font-family:=
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;"
class=3D""><blockquote=
type=3D"cite" style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px;" class=3D"">On 23 January 2018 at 18:44,
=
Martin Sivak <<a href=3D"mailto:msivak@redhat.com" =
class=3D"">msivak(a)redhat.com</a>&gt; wrote:<br
class=3D""><blockquote =
type=3D"cite" class=3D"">Hi Barak,<br
class=3D""><br class=3D"">can you =
please please add links to the proper repositories and/or<br =
class=3D"">directories when you send something like this? I really helps =
us when<br class=3D"">we do not have to search through all the jenkins =
and other infra<br class=3D"">repositories for which is the correct one.
=
Because I really do not<br class=3D"">remember all the places that need =
to change out of my head.<br class=3D""></blockquote><br
class=3D"">See =
below.<br class=3D""><br class=3D""><blockquote
type=3D"cite" =
class=3D"">So what you are asking for here is basically that we edit the =
files<br class=3D"">here [1] and create a 4.2_build-artifacts job using =
copy and paste,<br class=3D"">right? Or is there some other place that =
needs to change as well?<br class=3D""></blockquote><br
class=3D"">Yep. =
technically this should amount to a single change to a single<br =
class=3D"">file (See below). The important part is making the right =
decision for<br class=3D"">each project, understanding its consequences,
=
and realizing the<br class=3D"">actions that would be needed for =
changing that decision in the future.<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">[1]
<a =
href=3D"https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3...
confs/projects;h=3D5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=3Dcd75bb9eb=
3353652384ed89777fc15d71d1f9e36" =
class=3D"">https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a...
bs/confs/projects;h=3D5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=3Dcd75bb=
9eb3353652384ed89777fc15d71d1f9e36</a><br
class=3D""></blockquote><br =
class=3D"">There is only one file** you need to maintain that is =
(currently) not<br class=3D"">in your own project's repo***.<br =
class=3D"">Each project has such a file at [1].<br
class=3D""><br =
class=3D"">Documentation for the contents of that file can be found =
here: [2].<br class=3D""><br class=3D"">There is no need
to copy-paste =
much - the existing file should contain<br class=3D"">a mapping of =
project branches to oVirt versions. Typically what would<br class=3D"">be
=
needed is just to add a single entry to the map. For example, for<br =
class=3D"">engine it would be****:<br class=3D""><br =
class=3D""> version:<br =
class=3D""> -
master:<br =
class=3D""> &nb=
sp;branch: master<br =
class=3D""> -
4.2:<br =
class=3D""> &nb=
sp;branch: master<br =
class=3D""> ...=
<br class=3D""></blockquote><br style=3D"font-family:
Helvetica; =
font-size: 12px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span
=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">If project maintainers opt for
=
this "Route 2", it is their personal</span><br
style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span
=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">responsibility to change the =
above "master" to "ovirt-4.2" branch</span><br
style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span
=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">*BEFORE* they create their =
stable branch ovirt-4.2. If they fail to do</span><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; float: none; display: inline =
!important;" class=3D"">so, CI would get "dirty" with 4.3
packages. =
Barak hinted to this a</span><br style=3D"font-family: Helvetica;
=
font-size: 12px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><span
=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;" class=3D"">bit too
mildly.</span><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D""></div></blockquote><div><br
class=3D""></div>well, I still do =
not get the hint at all</div><div>Why exactly?</div><div><br =
class=3D""><blockquote type=3D"cite"
class=3D""><div class=3D""><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D""><blockquote type=3D"cite" style=3D"font-family:
Helvetica; =
font-size: 12px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px;" class=3D""><br
class=3D"">** Bigger =
projects can spread configuration across multiple files, but<br =
class=3D"">this is rarely needed.<br class=3D"">*** This
applies only to =
Gerrit projects. GitHub projects have<br class=3D"">everything =
configured in their own repo. See [3].<br class=3D"">**** Specifically =
for engine, the map appears twice in the file, this<br class=3D"">should
=
probably be re-factored.<br class=3D""><br class=3D"">[1]:
<a =
href=3D"https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3...
confs/projects;hb=3Drefs/heads/master" =
class=3D"">https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a...
bs/confs/projects;hb=3Drefs/heads/master</a><br class=3D"">[2]:
<a =
href=3D"http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_wi=
th_Gerrit/index.html" =
class=3D"">http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI=
_with_Gerrit/index.html</a><br class=3D"">[3]: <a =
href=3D"http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_wi=
th_GitHub/index.html" =
class=3D"">http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI=
_with_GitHub/index.html</a><br class=3D""><br
class=3D""><br =
class=3D""><br class=3D"">--<br
class=3D"">Barak Korren<br class=3D"">RHV =
DevOps team , RHCE, RHCi<br class=3D"">Red Hat EMEA<br
class=3D""><a =
href=3D"http://redhat.com" class=3D"">redhat.com</a> | TRIED.
TESTED. =
TRUSTED. | <a href=3D"http://redhat.com/trusted" =
class=3D"">redhat.com/trusted</a><br =
class=3D"">_______________________________________________<br =
class=3D"">Devel mailing list<br class=3D""><a =
href=3D"mailto:Devel@ovirt.org"
class=3D"">Devel(a)ovirt.org</a><br =
class=3D"">http://lists.ovirt.org/mailman/listinfo/devel<br
class=3D""><br=
class=3D""><br class=3D""></blockquote><span
style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: =
inline !important;" =
class=3D"">_______________________________________________</span><br
=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" =
class=3D""><span style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; float: none; display: inline =
!important;" class=3D"">Devel mailing list</span><br
style=3D"font-family:=
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><a =
href=3D"mailto:Devel@ovirt.org" style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; orphans: auto; text-align: =
start; text-indent: 0px; text-transform: none; white-space: normal; =
widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px;"
class=3D"">Devel(a)ovirt.org</a><br =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"
class=3D""><a =
href=3D"http://lists.ovirt.org/mailman/listinfo/devel" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" =
class=3D"">http://lists.ovirt.org/mailman/listinfo/devel<...
uote></div><br class=3D""></body></html>=
--Apple-Mail=_0BC00364-3869-4932-9C43-2C39D9DB1B26--
3:46 a.m.
--Apple-Mail=_FE8AFCC6-240E-4305-A287-D83B0F5DAEBA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 24 Jan 2018, at 09:23, Michal Skrivanek =
<michal.skrivanek(a)redhat.com> wrote:
=20
=20
=20
> On 24 Jan 2018, at 08:52, Dan Kenigsberg <danken(a)redhat.com =
<mailto:danken@redhat.com>> wrote:
>=20
> On Wed, Jan 24, 2018 at 8:35 AM, Barak Korren <bkorren(a)redhat.com =
<mailto:bkorren@redhat.com>> wrote:
>> On 23 January 2018 at 18:44, Martin Sivak
<msivak(a)redhat.com =
<mailto:msivak@redhat.com>> wrote:
>>> Hi Barak,
>>>=20
>>> can you please please add links to the proper repositories and/or
>>> directories when you send something like this? I really helps us =
when
>>> we do not have to search through all the jenkins and
other infra
>>> repositories for which is the correct one. Because I really do not
>>> remember all the places that need to change out of my head.
>>=20
>> See below.
>>=20
>>> So what you are asking for here is basically that we edit the files
>>> here [1] and create a 4.2_build-artifacts job using copy and paste,
>>> right? Or is there some other place that needs to change as well?
>>=20
>> Yep. technically this should amount to a single change to a single
>> file (See below). The important part is making the right decision =
for
>> each project, understanding its consequences, and realizing
the
>> actions that would be needed for changing that decision in the =
future.
>>=20
>>> [1] =
https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/confs/pr=
ojects;h=3D5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=3Dcd75bb9eb33536523=
84ed89777fc15d71d1f9e36 =
<https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/confs/p=
rojects;h=3D5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=3Dcd75bb9eb3353652=
384ed89777fc15d71d1f9e36>
>>=20
>> There is only one file** you need to maintain that is (currently) =
not
>> in your own project's repo***.
>> Each project has such a file at [1].
>>=20
>> Documentation for the contents of that file can be found here: [2].
>>=20
>> There is no need to copy-paste much - the existing file should =
contain
>> a mapping of project branches to oVirt versions. Typically
what =
would
>> be needed is just to add a single entry to the map. For
example, for
>> engine it would be****:
>>=20
>> version:
>> - master:
>> branch: master
>> - 4.2:
>> branch: master
>> ...
>=20
> If project maintainers opt for this "Route 2", it is their personal
> responsibility to change the above "master" to "ovirt-4.2"
branch
> *BEFORE* they create their stable branch ovirt-4.2. If they fail to =
do
> so, CI would get "dirty" with 4.3 packages. Barak
hinted to this a
> bit too mildly.
=20
well, I still do not get the hint at all
Why exactly?
apologies for stupid questions, but TBH I do not get most of these =
things=E2=80=A6.I tried to take a look at projects I=E2=80=99m familiar =
with and I still don=E2=80=99t quite understand what is getting to what =
repo.
I guess the syntax is described, that=E2=80=99s fine, but I=E2=80=99m =
really not sure about semantics. Why do we need each of those things?=20
I see stuff like f24 everywhere=E2=80=A6is that just outdated?
And what=E2=80=99s the relation to https://github.com/oVirt/releng-tools =
?
Thanks,
michal
=20
>=20
>>=20
>> ** Bigger projects can spread configuration across multiple files, =
but
>> this is rarely needed.
>> *** This applies only to Gerrit projects. GitHub projects have
>> everything configured in their own repo. See [3].
>> **** Specifically for engine, the map appears twice in the file, =
this
>> should probably be re-factored.
>>=20
>> [1]: =
https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/confs/pr=
ojects;hb=3Drefs/heads/master =
<https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3Djobs/confs/p=
rojects;hb=3Drefs/heads/master>
>> [2]: =
http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_Gerri=
t/index.html =
<http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_Gerr=
it/index.html>
>> [3]: =
http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_GitHu=
b/index.html =
<http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_GitH=
ub/index.html>
>>=20
>>=20
>>=20
>> --
>> Barak Korren
>> RHV DevOps team , RHCE, RHCi
>> Red Hat EMEA
>> redhat.com <http://redhat.com/> | TRIED. TESTED. TRUSTED. | =
redhat.com/trusted <http://redhat.com/trusted>
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org <mailto:Devel@ovirt.org>
>> http://lists.ovirt.org/mailman/listinfo/devel
>>=20
>>=20
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org <mailto:Devel@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/devel =
<http://lists.ovirt.org/mailman/listinfo/devel>
--Apple-Mail=_FE8AFCC6-240E-4305-A287-D83B0F5DAEBA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"
class=3D""><br =
class=3D""><div><br class=3D""><blockquote
type=3D"cite" class=3D""><div =
class=3D"">On 24 Jan 2018, at 09:23, Michal Skrivanek <<a =
href=3D"mailto:michal.skrivanek@redhat.com" =
class=3D"">michal.skrivanek(a)redhat.com</a>&gt;
wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div
=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"
class=3D""><br=
class=3D"Apple-interchange-newline"><br
class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">On 24 Jan
2018, at 08:52, Dan =
Kenigsberg <<a href=3D"mailto:danken@redhat.com" =
class=3D"">danken(a)redhat.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><span
class=3D"" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;">On Wed, Jan 24, 2018 at 8:35 AM, Barak =
Korren <</span><a href=3D"mailto:bkorren@redhat.com"
class=3D"" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: =
0px;">bkorren(a)redhat.com</a><span class=3D""
style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: =
inline !important;">> wrote:</span><br class=3D""
style=3D"font-family:=
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote =
type=3D"cite" class=3D"" style=3D"font-family: Helvetica;
font-size: =
12px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px;">On 23 January 2018 at 18:44, Martin =
Sivak <<a href=3D"mailto:msivak@redhat.com" =
class=3D"">msivak(a)redhat.com</a>&gt; wrote:<br
class=3D""><blockquote =
type=3D"cite" class=3D"">Hi Barak,<br
class=3D""><br class=3D"">can you =
please please add links to the proper repositories and/or<br =
class=3D"">directories when you send something like this? I really helps =
us when<br class=3D"">we do not have to search through all the jenkins =
and other infra<br class=3D"">repositories for which is the correct one.
=
Because I really do not<br class=3D"">remember all the places that need =
to change out of my head.<br class=3D""></blockquote><br
class=3D"">See =
below.<br class=3D""><br class=3D""><blockquote
type=3D"cite" =
class=3D"">So what you are asking for here is basically that we edit the =
files<br class=3D"">here [1] and create a 4.2_build-artifacts job using =
copy and paste,<br class=3D"">right? Or is there some other place that =
needs to change as well?<br class=3D""></blockquote><br
class=3D"">Yep. =
technically this should amount to a single change to a single<br =
class=3D"">file (See below). The important part is making the right =
decision for<br class=3D"">each project, understanding its consequences,
=
and realizing the<br class=3D"">actions that would be needed for =
changing that decision in the future.<br class=3D""><br =
class=3D""><blockquote type=3D"cite"
class=3D"">[1]<span =
class=3D"Apple-converted-space"> </span><a =
href=3D"https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3...
confs/projects;h=3D5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=3Dcd75bb9eb=
3353652384ed89777fc15d71d1f9e36" =
class=3D"">https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a...
bs/confs/projects;h=3D5a59dfea545da98e252eb6c8d95a92d08708a22d;hb=3Dcd75bb=
9eb3353652384ed89777fc15d71d1f9e36</a><br
class=3D""></blockquote><br =
class=3D"">There is only one file** you need to maintain that is =
(currently) not<br class=3D"">in your own project's repo***.<br =
class=3D"">Each project has such a file at [1].<br
class=3D""><br =
class=3D"">Documentation for the contents of that file can be found =
here: [2].<br class=3D""><br class=3D"">There is no need
to copy-paste =
much - the existing file should contain<br class=3D"">a mapping of =
project branches to oVirt versions. Typically what would<br class=3D"">be
=
needed is just to add a single entry to the map. For example, for<br =
class=3D"">engine it would be****:<br class=3D""><br =
class=3D""> version:<br =
class=3D""> -
master:<br =
class=3D""> &nb=
sp;branch: master<br =
class=3D""> -
4.2:<br =
class=3D""> &nb=
sp;branch: master<br =
class=3D""> ...=
<br class=3D""></blockquote><br class=3D""
style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class=3D""
=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;">If project maintainers opt for this "Route =
2", it is their personal</span><br class=3D""
style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class=3D""
=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;">responsibility to change the above "master"
=
to "ovirt-4.2" branch</span><br class=3D""
style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class=3D""
=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;">*BEFORE* they create their stable branch =
ovirt-4.2. If they fail to do</span><br class=3D""
style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class=3D""
=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;">so, CI would get "dirty" with 4.3 packages.
=
Barak hinted to this a</span><br class=3D""
style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class=3D""
=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline !important;">bit too mildly.</span><br
class=3D"" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: =
0px;"></div></blockquote><div class=3D""><br
class=3D""></div>well, I =
still do not get the hint at all</div><div style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">Why =
exactly?</div></div></blockquote><div><br
class=3D""></div>apologies for =
stupid questions, but TBH I do not get most of these things=E2=80=A6.I =
tried to take a look at projects I=E2=80=99m familiar with and I still =
don=E2=80=99t quite understand what is getting to what repo.</div><div>I =
guess the syntax is described, that=E2=80=99s fine, but I=E2=80=99m =
really not sure about semantics. Why do we need each of those =
things? </div><div>I see stuff like f24 everywhere=E2=80=A6is that =
just outdated?</div><div>And what=E2=80=99s the relation to <a =
href=3D"https://github.com/oVirt/releng-tools" =
class=3D"">https://github.com/oVirt/releng-tools</a>
?</div><div><br =
class=3D""></div><div>Thanks,</div><div>michal</div><div><blockquote
=
type=3D"cite" class=3D""><div class=3D""><div
style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br =
class=3D""><blockquote type=3D"cite"
class=3D""><div class=3D""><br =
class=3D"" style=3D"font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: =
0px;"><blockquote type=3D"cite" class=3D""
style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br
class=3D"">** =
Bigger projects can spread configuration across multiple files, but<br =
class=3D"">this is rarely needed.<br class=3D"">*** This
applies only to =
Gerrit projects. GitHub projects have<br class=3D"">everything =
configured in their own repo. See [3].<br class=3D"">**** Specifically =
for engine, the map appears twice in the file, this<br class=3D"">should
=
probably be re-factored.<br class=3D""><br
class=3D"">[1]:<span =
class=3D"Apple-converted-space"> </span><a =
href=3D"https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a=3Dtree;f=3...
confs/projects;hb=3Drefs/heads/master" =
class=3D"">https://gerrit.ovirt.org/gitweb?p=3Djenkins.git;a...
bs/confs/projects;hb=3Drefs/heads/master</a><br
class=3D"">[2]:<span =
class=3D"Apple-converted-space"> </span><a =
href=3D"http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_wi=
th_Gerrit/index.html" =
class=3D"">http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI=
_with_Gerrit/index.html</a><br class=3D"">[3]:<span =
class=3D"Apple-converted-space"> </span><a =
href=3D"http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_wi=
th_GitHub/index.html" =
class=3D"">http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI=
_with_GitHub/index.html</a><br class=3D""><br
class=3D""><br =
class=3D""><br class=3D"">--<br
class=3D"">Barak Korren<br class=3D"">RHV =
DevOps team , RHCE, RHCi<br class=3D"">Red Hat EMEA<br
class=3D""><a =
href=3D"http://redhat.com/" class=3D"">redhat.com</a><span
=
class=3D"Apple-converted-space"> </span>| TRIED. TESTED.
TRUSTED. =
|<span class=3D"Apple-converted-space"> </span><a =
href=3D"http://redhat.com/trusted"
class=3D"">redhat.com/trusted</a><br =
class=3D"">_______________________________________________<br =
class=3D"">Devel mailing list<br class=3D""><a =
href=3D"mailto:Devel@ovirt.org"
class=3D"">Devel(a)ovirt.org</a><br =
class=3D""><a
href=3D"http://lists.ovirt.org/mailman/listinfo/devel" =
class=3D"">http://lists.ovirt.org/mailman/listinfo/devel<... =
class=3D""><br class=3D""><br
class=3D""></blockquote><span class=3D"" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; =
display: inline =
!important;">_______________________________________________</span><br =
class=3D"" style=3D"font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant-caps: normal; font-weight: normal; letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: =
0px;"><span class=3D"" style=3D"font-family: Helvetica;
font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; float: none; display: inline =
!important;">Devel mailing list</span><br class=3D""
style=3D"font-family:=
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a =
href=3D"mailto:Devel@ovirt.org" class=3D"" style=3D"font-family:
=
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: =
0px;">Devel(a)ovirt.org</a><br class=3D""
style=3D"font-family: Helvetica; =
font-size: 12px; font-style: normal; font-variant-caps: normal; =
font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px;"><a =
href=3D"http://lists.ovirt.org/mailman/listinfo/devel" class=3D"" =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: =
0px;">http://lists.ovirt.org/mailman/listinfo/devel</a><...
</div></div></blockquote></div><br
class=3D""></body></html>=
--Apple-Mail=_FE8AFCC6-240E-4305-A287-D83B0F5DAEBA--
4 a.m.
I do understand the semantics mostly, I am just not sure why we repeat
the distro excludes for almost every job and project.
Don't we have an oVirt global list for that somewhere (base-params)?
Because I am never sure which distros are supported for which
versions. Especially now after Sandro said Fedora bits are no longer
released.
Martin
On Wed, Jan 24, 2018 at 9:46 AM, Michal Skrivanek
<michal.skrivanek(a)redhat.com> wrote:
On 24 Jan 2018, at 09:23, Michal Skrivanek <michal.skrivanek(a)redhat.com>
wrote:
On 24 Jan 2018, at 08:52, Dan Kenigsberg <danken(a)redhat.com> wrote:
On Wed, Jan 24, 2018 at 8:35 AM, Barak Korren <bkorren(a)redhat.com> wrote:
On 23 January 2018 at 18:44, Martin Sivak <msivak(a)redhat.com> wrote:
Hi Barak,
can you please please add links to the proper repositories and/or
directories when you send something like this? I really helps us when
we do not have to search through all the jenkins and other infra
repositories for which is the correct one. Because I really do not
remember all the places that need to change out of my head.
See below.
So what you are asking for here is basically that we edit the files
here [1] and create a 4.2_build-artifacts job using copy and paste,
right? Or is there some other place that needs to change as well?
Yep. technically this should amount to a single change to a single
file (See below). The important part is making the right decision for
each project, understanding its consequences, and realizing the
actions that would be needed for changing that decision in the future.
[1]
https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/project...
There is only one file** you need to maintain that is (currently) not
in your own project's repo***.
Each project has such a file at [1].
Documentation for the contents of that file can be found here: [2].
There is no need to copy-paste much - the existing file should contain
a mapping of project branches to oVirt versions. Typically what would
be needed is just to add a single entry to the map. For example, for
engine it would be****:
version:
- master:
branch: master
- 4.2:
branch: master
...
If project maintainers opt for this "Route 2", it is their personal
responsibility to change the above "master" to "ovirt-4.2" branch
*BEFORE* they create their stable branch ovirt-4.2. If they fail to do
so, CI would get "dirty" with 4.3 packages. Barak hinted to this a
bit too mildly.
well, I still do not get the hint at all
Why exactly?
apologies for stupid questions, but TBH I do not get most of these things….I
tried to take a look at projects I’m familiar with and I still don’t quite
understand what is getting to what repo.
I guess the syntax is described, that’s fine, but I’m really not sure about
semantics. Why do we need each of those things?
I see stuff like f24 everywhere…is that just outdated?
And what’s the relation to https://github.com/oVirt/releng-tools ?
Thanks,
michal
** Bigger projects can spread configuration across multiple files, but
this is rarely needed.
*** This applies only to Gerrit projects. GitHub projects have
everything configured in their own repo. See [3].
**** Specifically for engine, the map appears twice in the file, this
should probably be re-factored.
[1]:
https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/project...
[2]:
http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_Gerr...
[3]:
http://ovirt-infra-docs.readthedocs.io/en/latest/CI/Using_STDCI_with_GitH...
--
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
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
4:50 a.m.
On 24 January 2018 at 11:00, Martin Sivak <msivak(a)redhat.com> wrote:
I do understand the semantics mostly, I am just not sure why we
repeat
the distro excludes for almost every job and project.
Don't we have an oVirt global list for that somewhere (base-params)?
Currently not, And current tooling unfortunately does not allow for
easily making such a file.
Because I am never sure which distros are supported for which
versions. Especially now after Sandro said Fedora bits are no longer
released.
You`re asking a bigger question here - Who decides which distros/archs
each project targets. The CI system currently places the burden of
this decision on the shoulders of individual maintainers. We could
have done things differently and placed the decision solely in the
hands of the integration team.
The reason to placing the power (and responsibility) in the hands of
maintainers we simple - we wanted to reduce the chances of having
maintainers be surprised. Suppose we made it so that target distros
change globally for everyone - you would have had patches failing CI
at arbitrary times as new target distros or architectures were
added...
Decisions like this can be changed, the CI system can be
re-architectured, but to do that we would like to see:
1. The integration team agreeing the shoulder the responsibility of
choosing target distros and platforms for everyone
2. Maintainers agreeing to fix issues in new distros/archs as soon as
the integration team adds them.
Personally I prefer that decisions remain distributed, this seems to
me to map better to the open source development model, but if the
community comes together and decides differently, I will make sure the
CI system does what the community wants it to do.
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
5:11 a.m.
Hi,
You`re asking a bigger question here - Who decides which
distros/archs
each project targets. The CI system currently places the burden of
this decision on the shoulders of individual maintainers. We could
have done things differently and placed the decision solely in the
hands of the integration team.
Actually, I believe it should be a global decision of the project
leadership. But I believe the word global to be important here. We
should decide together and then a common version to platform map
should be prepared by the integration team.
Single projects could still add additional overrides if needed though.
The reason to placing the power (and responsibility) in the hands of
maintainers we simple - we wanted to reduce the chances of having
maintainers be surprised.
This actually means we get surprised and confused indeed. Please note
that nobody really told us that Fedora bits are not going to be
released anymore (see 4.2 release notes [1]) and whether we should
update the job specifications or not.
Suppose we made it so that target distros
change globally for everyone - you would have had patches failing CI
at arbitrary times as new target distros or architectures were
added...
Right. But we have something very similar now: spreadsheets with lists
of packages that are missing from a new version compose. I do not see
too much difference actually..
Personally I prefer that decisions remain distributed
I agree with who decides things (all of us). But the decision needs to
be documented. Do we have any (easy to find) list of expected
platforms for given a release?
The decision then might be compiled into a file we could include and
stay current without manual edits.
[1] https://www.ovirt.org/release/4.2.0/#no-fedora-support
Martin
6:43 a.m.
Before commenting on specific things, let me say that I mostly agree
with everything you wrote.
On 24 January 2018 at 12:11, Martin Sivak <msivak(a)redhat.com> wrote:
Hi,
> You`re asking a bigger question here - Who decides which distros/archs
> each project targets. The CI system currently places the burden of
> this decision on the shoulders of individual maintainers. We could
> have done things differently and placed the decision solely in the
> hands of the integration team.
Actually, I believe it should be a global decision of the project
leadership. But I believe the word global to be important here. We
should decide together and then a common version to platform map
should be prepared by the integration team.
One thing here - I'm not sure who that leadership might actually be.
As Red Hat employees we have managers that can make decisions, but I
doubt we could refer to the as "The oVirt leadership". Red Hat
managers can make decisions that are relevant to RHV, but not
necessarily oVirt. Knowing some of those managers, most of them are
not likely to make any cutting decisions.
Furthermore, I do not think there is a community-based decision making
process in place at this time. It seems that mostly decisions are
taken based on what exists, and what could be done with reasonable
effort.
Single projects could still add additional overrides if needed
though.
> The reason to placing the power (and responsibility) in the hands of
> maintainers we simple - we wanted to reduce the chances of having
> maintainers be surprised.
This actually means we get surprised and confused indeed. Please note
that nobody really told us that Fedora bits are not going to be
released anymore (see 4.2 release notes [1]) and whether we should
update the job specifications or not.
WRT Fedora - I think the decisions to no longer release for Fedora was
made because it stopped working and nobody stepped up to fix it. It
was essentially made to ensure that the release documentation matched
what existed in the code.
WRT job specification - that one is on me, I guess that as the CI
system maintainers we should communicate our expectations of
maintainers better. The general rule is that we prefer to be concerned
with _how_ the CI system does what it does and let maintainers decide
the _what_. The is a grey area in the middle though, where we
cooperate (For e.g we do some maintenance of OST test suits).
> Suppose we made it so that target distros
> change globally for everyone - you would have had patches failing CI
> at arbitrary times as new target distros or architectures were
> added...
Right. But we have something very similar now: spreadsheets with lists
of packages that are missing from a new version compose. I do not see
too much difference actually..
> Personally I prefer that decisions remain distributed
I agree with who decides things (all of us). But the decision needs to
be documented. Do we have any (easy to find) list of expected
platforms for given a release?
Nope. No central or consensus-based decision making process is in
place ATM AFAIK, so no central file either.
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
8:45 a.m.
2018-01-24 11:11 GMT+01:00 Martin Sivak <msivak(a)redhat.com>:
Hi,
> You`re asking a bigger question here - Who decides which distros/archs
> each project targets. The CI system currently places the burden of
> this decision on the shoulders of individual maintainers. We could
> have done things differently and placed the decision solely in the
> hands of the integration team.
Actually, I believe it should be a global decision of the project
leadership. But I believe the word global to be important here. We
should decide together and then a common version to platform map
should be prepared by the integration team.
Single projects could still add additional overrides if needed though.
> The reason to placing the power (and responsibility) in the hands of
> maintainers we simple - we wanted to reduce the chances of having
> maintainers be surprised.
This actually means we get surprised and confused indeed. Please note
that nobody really told us that Fedora bits are not going to be
released anymore (see 4.2 release notes [1]) and whether we should
update the job specifications or not.
Integration team reported to the developers community that Fedora support
was broken starting with Fedora 26 back on August 2017[1].
We also reported during the beta process that oVirt 4.2 would have not
supported Fedora to user list in November 2017 [2] since nobody fixed
Fedora support in the meanwhile.
No request or direction about what to do with Jenkins fedora jobs has been
issued since we (integration team at least) want Fedora support back in 4.3
but since we don't have yet a schedule for 4.3 we don't know yet which
fedora version we'll target. In integration team we are now slowly enabling
jobs on master for fc27 and fcraw (rawhide).
[1] https://lists.ovirt.org/pipermail/devel/2017-August/030990.html
[2] https://lists.ovirt.org/pipermail/users/2017-November/085006.html
> Suppose we made it so that target distros
> change globally for everyone - you would have had patches failing CI
> at arbitrary times as new target distros or architectures were
> added...
Right. But we have something very similar now: spreadsheets with lists
of packages that are missing from a new version compose. I do not see
too much difference actually..
> Personally I prefer that decisions remain distributed
I agree with who decides things (all of us). But the decision needs to
be documented. Do we have any (easy to find) list of expected
platforms for given a release?
The decision then might be compiled into a file we could include and
stay current without manual edits.
[1] https://www.ovirt.org/release/4.2.0/#no-fedora-support
Martin
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
2:32 a.m.
On Fri, Jan 26, 2018 at 3:45 PM, Sandro Bonazzola <sbonazzo(a)redhat.com>
wrote:
2018-01-24 11:11 GMT+01:00 Martin Sivak <msivak(a)redhat.com>:
> Hi,
>
> > You`re asking a bigger question here - Who decides which distros/archs
> > each project targets. The CI system currently places the burden of
> > this decision on the shoulders of individual maintainers. We could
> > have done things differently and placed the decision solely in the
> > hands of the integration team.
>
> Actually, I believe it should be a global decision of the project
> leadership. But I believe the word global to be important here. We
> should decide together and then a common version to platform map
> should be prepared by the integration team.
>
> Single projects could still add additional overrides if needed though.
>
> > The reason to placing the power (and responsibility) in the hands of
> > maintainers we simple - we wanted to reduce the chances of having
> > maintainers be surprised.
>
> This actually means we get surprised and confused indeed. Please note
> that nobody really told us that Fedora bits are not going to be
> released anymore (see 4.2 release notes [1]) and whether we should
> update the job specifications or not.
>
Integration team reported to the developers community that Fedora support
was broken starting with Fedora 26 back on August 2017[1].
We also reported during the beta process that oVirt 4.2 would have not
supported Fedora to user list in November 2017 [2] since nobody fixed
Fedora support in the meanwhile.
No request or direction about what to do with Jenkins fedora jobs has been
issued since we (integration team at least) want Fedora support back in 4.3
but since we don't have yet a schedule for 4.3 we don't know yet which
fedora version we'll target. In integration team we are now slowly enabling
jobs on master for fc27 and fcraw (rawhide).
[1] https://lists.ovirt.org/pipermail/devel/2017-August/030990.html
[2] https://lists.ovirt.org/pipermail/users/2017-November/085006.html
I'd like to clarify my own understanding re what should be done with
jenkins jobs.
1. You can still, and are very welcome to, have and maintain fedora
builds/jobs for your projects.
2. Not officially publishing builds does not mean you can't build them, and
if you do, they are still published in the -snapshot repos, so users that do
want them, can have them.
3. If building for fedora will make the job(s) for your projects fail
constantly,
either because you have bugs there, or because you rely on some
infrastructure
packages (otopi, ovirt-setup-lib, etc) to work on fedora (and with python3),
then it probably does not make sense to build yet for fedora - this will
simply
add noise.
4. If OTOH your project is independent, and works just fine on fedora, you
are
more than welcome to build (and then publish in -snapshot). Doing this will
very likely make the eventual transition to "fedora is supported" much
smoother.
5. This is really a per-project decision, so unless we start having
cross-project
discussions about this, you should decide for yourself. Just keep in mind
that
eventually we'll have EL8, which is very likely to be more similar to
current
fedora than to current EL7, so better prepare... (saying this also mainly to
myself!).
Best regards,
>
> > Suppose we made it so that target distros
> > change globally for everyone - you would have had patches failing CI
> > at arbitrary times as new target distros or architectures were
> > added...
>
> Right. But we have something very similar now: spreadsheets with lists
> of packages that are missing from a new version compose. I do not see
> too much difference actually..
>
> > Personally I prefer that decisions remain distributed
>
> I agree with who decides things (all of us). But the decision needs to
> be documented. Do we have any (easy to find) list of expected
> platforms for given a release?
>
> The decision then might be compiled into a file we could include and
> stay current without manual edits.
>
> [1] https://www.ovirt.org/release/4.2.0/#no-fedora-support
>
> Martin
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
--
SANDRO BONAZZOLA
ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
Didi
2:39 a.m.
On 28 January 2018 at 09:32, Yedidyah Bar David <didi(a)redhat.com> wrote:
On Fri, Jan 26, 2018 at 3:45 PM, Sandro Bonazzola
<sbonazzo(a)redhat.com>
wrote:
>
>
> 2018-01-24 11:11 GMT+01:00 Martin Sivak <msivak(a)redhat.com>:
>
>> Hi,
>>
>> > You`re asking a bigger question here - Who decides which distros/archs
>> > each project targets. The CI system currently places the burden of
>> > this decision on the shoulders of individual maintainers. We could
>> > have done things differently and placed the decision solely in the
>> > hands of the integration team.
>>
>> Actually, I believe it should be a global decision of the project
>> leadership. But I believe the word global to be important here. We
>> should decide together and then a common version to platform map
>> should be prepared by the integration team.
>>
>> Single projects could still add additional overrides if needed though.
>>
>> > The reason to placing the power (and responsibility) in the hands of
>> > maintainers we simple - we wanted to reduce the chances of having
>> > maintainers be surprised.
>>
>> This actually means we get surprised and confused indeed. Please note
>> that nobody really told us that Fedora bits are not going to be
>> released anymore (see 4.2 release notes [1]) and whether we should
>> update the job specifications or not.
>>
>
> Integration team reported to the developers community that Fedora support
> was broken starting with Fedora 26 back on August 2017[1].
> We also reported during the beta process that oVirt 4.2 would have not
> supported Fedora to user list in November 2017 [2] since nobody fixed
> Fedora support in the meanwhile.
> No request or direction about what to do with Jenkins fedora jobs has
> been issued since we (integration team at least) want Fedora support back
> in 4.3 but since we don't have yet a schedule for 4.3 we don't know yet
> which fedora version we'll target. In integration team we are now slowly
> enabling jobs on master for fc27 and fcraw (rawhide).
>
> [1] https://lists.ovirt.org/pipermail/devel/2017-August/030990.html
> [2] https://lists.ovirt.org/pipermail/users/2017-November/085006.html
>
I'd like to clarify my own understanding re what should be done with
jenkins jobs.
1. You can still, and are very welcome to, have and maintain fedora
builds/jobs for your projects.
2. Not officially publishing builds does not mean you can't build them, and
if you do, they are still published in the -snapshot repos, so users that
do
want them, can have them.
3. If building for fedora will make the job(s) for your projects fail
constantly,
either because you have bugs there, or because you rely on some
infrastructure
packages (otopi, ovirt-setup-lib, etc) to work on fedora (and with
python3),
then it probably does not make sense to build yet for fedora - this will
simply
add noise.
This will cause more then just noise - if a project fails to build on any
platform it explicitly targets - builds from all plaforms are blocked and
do not get released to the '*-snapshot' repo. If you tell CI you want to
support platfrom X, it holds you to it...
I'm a little frustrated that this OT discussion derailed the original
discussion of getting proper testing for 4.2.
4. If OTOH your project is independent, and works just fine on fedora, you
are
more than welcome to build (and then publish in -snapshot). Doing this will
very likely make the eventual transition to "fedora is supported" much
smoother.
5. This is really a per-project decision, so unless we start having
cross-project
discussions about this, you should decide for yourself. Just keep in mind
that
eventually we'll have EL8, which is very likely to be more similar to
current
fedora than to current EL7, so better prepare... (saying this also mainly
to
myself!).
Best regards,
>
>
>
>
>>
>> > Suppose we made it so that target distros
>> > change globally for everyone - you would have had patches failing CI
>> > at arbitrary times as new target distros or architectures were
>> > added...
>>
>> Right. But we have something very similar now: spreadsheets with lists
>> of packages that are missing from a new version compose. I do not see
>> too much difference actually..
>>
>> > Personally I prefer that decisions remain distributed
>>
>> I agree with who decides things (all of us). But the decision needs to
>> be documented. Do we have any (easy to find) list of expected
>> platforms for given a release?
>>
>> The decision then might be compiled into a file we could include and
>> stay current without manual edits.
>>
>> [1] https://www.ovirt.org/release/4.2.0/#no-fedora-support
>>
>> Martin
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D
>
> Red Hat EMEA <https://www.redhat.com/>
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
--
Didi
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
4:13 a.m.
On 24 January 2018 at 10:46, Michal Skrivanek
<michal.skrivanek(a)redhat.com> wrote:
On 24 Jan 2018, at 09:23, Michal Skrivanek <michal.skrivanek(a)redhat.com>
wrote:
On 24 Jan 2018, at 08:52, Dan Kenigsberg <danken(a)redhat.com> wrote:
On Wed, Jan 24, 2018 at 8:35 AM, Barak Korren <bkorren(a)redhat.com> wrote:
On 23 January 2018 at 18:44, Martin Sivak <msivak(a)redhat.com> wrote:
Hi Barak,
can you please please add links to the proper repositories and/or
directories when you send something like this? I really helps us when
we do not have to search through all the jenkins and other infra
repositories for which is the correct one. Because I really do not
remember all the places that need to change out of my head.
See below.
So what you are asking for here is basically that we edit the files
here [1] and create a 4.2_build-artifacts job using copy and paste,
right? Or is there some other place that needs to change as well?
Yep. technically this should amount to a single change to a single
file (See below). The important part is making the right decision for
each project, understanding its consequences, and realizing the
actions that would be needed for changing that decision in the future.
[1]
https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/project...
There is only one file** you need to maintain that is (currently) not
in your own project's repo***.
Each project has such a file at [1].
Documentation for the contents of that file can be found here: [2].
There is no need to copy-paste much - the existing file should contain
a mapping of project branches to oVirt versions. Typically what would
be needed is just to add a single entry to the map. For example, for
engine it would be****:
version:
- master:
branch: master
- 4.2:
branch: master
...
If project maintainers opt for this "Route 2", it is their personal
responsibility to change the above "master" to "ovirt-4.2" branch
*BEFORE* they create their stable branch ovirt-4.2. If they fail to do
so, CI would get "dirty" with 4.3 packages. Barak hinted to this a
bit too mildly.
well, I still do not get the hint at all
Why exactly?
apologies for stupid questions, but TBH I do not get most of these things….
No need to apologise, there is no such thing as a "Stupid question"
only a stupid answer...
I'm sorry if my explanations or the documentation I provide is not
clear, I have the common problem where its hard for me to see that
things that I'm familiar with are not as clear to others.
I tried to take a look at projects I’m familiar with and I still
don’t quite
understand what is getting to what repo.
I guess the syntax is described, that’s fine, but I’m really not sure about
semantics. Why do we need each of those things?
Those files describes 3 pieces of information for each project:
1. What versions of oVirt a project targets (And which branch goes to
which version)
2. Which distros and architectures a project targets (Can differ by version)
3. Which jobs (stdci stages) the the project requires to be enabled for it.
The format is a bit convoluted for technical reasons that has to do
with the tooling that parses it. Additionally some files were written
at times where things needed to be specified in more complex ways then
they do now, so the files appear more complex then they need to be.
Please point me to a particular file of interest if you want me to use
it as an example and explain what it does.
I see stuff like f24 everywhere…is that just outdated?
Yep...
We needed to support fc24 up until 4.1 was released, so not as
outdated as you think. But I guess most people did not remove the
4.1/fc24 jobs yet.
And what’s the relation to https://github.com/oVirt/releng-tools ?
No relation. releng-tools is used by Sandro's team when they compose
official releases. That process is still manual. We hope to finally be
able to change that soon.
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
8:13 a.m.
On 01/24/2018 08:52 AM, Dan Kenigsberg wrote:
On Wed, Jan 24, 2018 at 8:35 AM, Barak Korren
<bkorren(a)redhat.com> wrote:
> On 23 January 2018 at 18:44, Martin Sivak <msivak(a)redhat.com> wrote:
>> Hi Barak,
>>
>> can you please please add links to the proper repositories and/or
>> directories when you send something like this? I really helps us when
>> we do not have to search through all the jenkins and other infra
>> repositories for which is the correct one. Because I really do not
>> remember all the places that need to change out of my head.
> See below.
>
>> So what you are asking for here is basically that we edit the files
>> here [1] and create a 4.2_build-artifacts job using copy and paste,
>> right? Or is there some other place that needs to change as well?
> Yep. technically this should amount to a single change to a single
> file (See below). The important part is making the right decision for
> each project, understanding its consequences, and realizing the
> actions that would be needed for changing that decision in the future.
>
>> [1]
https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/project...
> There is only one file** you need to maintain that is (currently) not
> in your own project's repo***.
> Each project has such a file at [1].
>
> Documentation for the contents of that file can be found here: [2].
>
> There is no need to copy-paste much - the existing file should contain
> a mapping of project branches to oVirt versions. Typically what would
> be needed is just to add a single entry to the map. For example, for
> engine it would be****:
>
> version:
> - master:
> branch: master
> - 4.2:
> branch: master
> ...
If project maintainers opt for this "Route 2", it is their personal
responsibility to change the above "master" to "ovirt-4.2" branch
*BEFORE* they create their stable branch ovirt-4.2. If they fail to do
so, CI would get "dirty" with 4.3 packages. Barak hinted to this a
bit too mildly.
OK, so let's get ready.
I want to take "route 1", so I want to create the branches and map the
new jobs to them, so I posted https://gerrit.ovirt.org/#/c/87159/
Rationale: I want the master branch and the ovirt-4.2 branch to be fully
independent, like ovirt-4.1 is.
Please let me know if I got it right.
Bests,
--
Francesco Romani
Senior SW Eng., Virtualization R&D
Red Hat
IRC: fromani github: @fromanirh
3:49 a.m.
On 5 February 2018 at 15:13, Francesco Romani <fromani(a)redhat.com> wrote:
On 01/24/2018 08:52 AM, Dan Kenigsberg wrote:
> On Wed, Jan 24, 2018 at 8:35 AM, Barak Korren <bkorren(a)redhat.com> wrote:
>> On 23 January 2018 at 18:44, Martin Sivak <msivak(a)redhat.com> wrote:
>>> Hi Barak,
>>>
>>> can you please please add links to the proper repositories and/or
>>> directories when you send something like this? I really helps us when
>>> we do not have to search through all the jenkins and other infra
>>> repositories for which is the correct one. Because I really do not
>>> remember all the places that need to change out of my head.
>> See below.
>>
>>> So what you are asking for here is basically that we edit the files
>>> here [1] and create a 4.2_build-artifacts job using copy and paste,
>>> right? Or is there some other place that needs to change as well?
>> Yep. technically this should amount to a single change to a single
>> file (See below). The important part is making the right decision for
>> each project, understanding its consequences, and realizing the
>> actions that would be needed for changing that decision in the future.
>>
>>> [1]
https://gerrit.ovirt.org/gitweb?p=jenkins.git;a=tree;f=jobs/confs/project...
>> There is only one file** you need to maintain that is (currently) not
>> in your own project's repo***.
>> Each project has such a file at [1].
>>
>> Documentation for the contents of that file can be found here: [2].
>>
>> There is no need to copy-paste much - the existing file should contain
>> a mapping of project branches to oVirt versions. Typically what would
>> be needed is just to add a single entry to the map. For example, for
>> engine it would be****:
>>
>> version:
>> - master:
>> branch: master
>> - 4.2:
>> branch: master
>> ...
> If project maintainers opt for this "Route 2", it is their personal
> responsibility to change the above "master" to "ovirt-4.2"
branch
> *BEFORE* they create their stable branch ovirt-4.2. If they fail to do
> so, CI would get "dirty" with 4.3 packages. Barak hinted to this a
> bit too mildly.
OK, so let's get ready.
I want to take "route 1", so I want to create the branches and map the
new jobs to them, so I posted https://gerrit.ovirt.org/#/c/87159/
Rationale: I want the master branch and the ovirt-4.2 branch to be fully
independent, like ovirt-4.1 is.
Please let me know if I got it right.
Generally looks ok, but see comments on patch.
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
2513
days inactive
2527
days old
15 comments
7 participants
participants (7)
-
Barak Korren -
Dan Kenigsberg -
Francesco Romani -
Martin Sivak -
Michal Skrivanek -
Sandro Bonazzola -
Yedidyah Bar David