May 2017 - Infra - oVirt List Archives

[JIRA] (OVIRT-1273) Greetings from Jessie
by eyal edri [Administrator] (oVirt JIRA) 25 May '17

25 May '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1273?page=com.atlassian.jira.… ] eyal edri [Administrator] deleted OVIRT-1273: --------------------------------------------- > Greetings from Jessie > --------------------- > > Key: OVIRT-1273 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1273 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: jp005(a)jp-balancer.com > Assignee: infra > -- This message was sent by Atlassian JIRA (v1000.1010.0#100044)

1 0

[JIRA] (OVIRT-1276) generate a link to OST automation job
by eyal edri [Administrator] (oVirt JIRA) 25 May '17

25 May '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1276?page=com.atlassian.jira.… ] eyal edri [Administrator] updated OVIRT-1276: --------------------------------------------- Epic Link: OVIRT-400 > generate a link to OST automation job > ------------------------------------- > > Key: OVIRT-1276 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1276 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: rgolan > Assignee: infra > > When activating the 'ci please help' robo verb, please generate a link with > job parameters for the ost job: > Say I told the robot to build my 4.1 patch, than asside from the aftifact > link, create a a link to trigger the ost job with refs/to/spec. pick 4.1 as > a release and so on. In that way a user is a click away from firing a job. > This could be then continued with 'ci please build and ost' kinda of thing > \R -- This message was sent by Atlassian JIRA (v1000.1010.0#100044)

1 0

[JIRA] (OVIRT-1276) generate a link to OST automation job
by eyal edri [Administrator] (oVirt JIRA) 25 May '17

25 May '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1276?page=com.atlassian.jira.… ] eyal edri [Administrator] updated OVIRT-1276: --------------------------------------------- Epic Link: OVIRT-400 > generate a link to OST automation job > ------------------------------------- > > Key: OVIRT-1276 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1276 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: rgolan > Assignee: infra > > When activating the 'ci please help' robo verb, please generate a link with > job parameters for the ost job: > Say I told the robot to build my 4.1 patch, than asside from the aftifact > link, create a a link to trigger the ost job with refs/to/spec. pick 4.1 as > a release and so on. In that way a user is a click away from firing a job. > This could be then continued with 'ci please build and ost' kinda of thing > \R -- This message was sent by Atlassian JIRA (v1000.1010.0#100044)

1 0

[JIRA] (OVIRT-1374) Provide a mechanism to obtain an ever increasing build number
by eyal edri [Administrator] (oVirt JIRA) 25 May '17

25 May '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1374?page=com.atlassian.jira.… ] eyal edri [Administrator] updated OVIRT-1374: --------------------------------------------- Epic Link: OVIRT-400 > Provide a mechanism to obtain an ever increasing build number > ------------------------------------------------------------- > > Key: OVIRT-1374 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1374 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: Juan Hernández > Assignee: infra > > Currently when a project needs to generate unique names for artifacts, they have to use mechanisms like embedding the date and/or the git hash into the artifact name. For example, when a new build of the Ruby SDK is generated, the name of the RPM is like this: > rubygem-ovirt-engine-sdk4-4.2.0-1.alpha0.20170505gita6de891.el7.centos.ppc64le.rpm > That information is useful, and usually unique. But can be repeated if the same jobs is manually triggered the same day, as the date and the git hash will be the same. > In addition the date may be misleading, because a build performed later but using an old commit, will look newer than an older build that uses a newer commit. > A possible solution is to count the number of commits since certain well known commit. But this isn't reliable if the repository isn't completely cloned, for example if it is cloned with '--depth 1', as that well known commit may not be in the cloned repository. That cloning out of the control of the automation scripts. > So my suggestion/request is to add to the CI/CD environment a mechanism to provide that sequence to the jobs explicitly. I'd suggest to use the count of commits since the initial commit of the repository. The CI/CD environment performs the clone, so it can make sure it has all the relevant commits. > This information could be passed to the build-artifacts.sh script in an environment variable, or in the command line, or in a file in a known location. > With that each project could (optionally) modify its automation scripts to include that number. for example, in the Ruby SDK I'd like to generate RPMs like this: > rubygem-ovirt-engine-sdk4-4.2.0-1.alpha0.<that-number>.rpm -- This message was sent by Atlassian JIRA (v1000.1010.0#100044)

1 0

[JIRA] (OVIRT-1374) Provide a mechanism to obtain an ever increasing build number
by eyal edri [Administrator] (oVirt JIRA) 25 May '17

25 May '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1374?page=com.atlassian.jira.… ] eyal edri [Administrator] updated OVIRT-1374: --------------------------------------------- Epic Link: OVIRT-400 > Provide a mechanism to obtain an ever increasing build number > ------------------------------------------------------------- > > Key: OVIRT-1374 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1374 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: Juan Hernández > Assignee: infra > > Currently when a project needs to generate unique names for artifacts, they have to use mechanisms like embedding the date and/or the git hash into the artifact name. For example, when a new build of the Ruby SDK is generated, the name of the RPM is like this: > rubygem-ovirt-engine-sdk4-4.2.0-1.alpha0.20170505gita6de891.el7.centos.ppc64le.rpm > That information is useful, and usually unique. But can be repeated if the same jobs is manually triggered the same day, as the date and the git hash will be the same. > In addition the date may be misleading, because a build performed later but using an old commit, will look newer than an older build that uses a newer commit. > A possible solution is to count the number of commits since certain well known commit. But this isn't reliable if the repository isn't completely cloned, for example if it is cloned with '--depth 1', as that well known commit may not be in the cloned repository. That cloning out of the control of the automation scripts. > So my suggestion/request is to add to the CI/CD environment a mechanism to provide that sequence to the jobs explicitly. I'd suggest to use the count of commits since the initial commit of the repository. The CI/CD environment performs the clone, so it can make sure it has all the relevant commits. > This information could be passed to the build-artifacts.sh script in an environment variable, or in the command line, or in a file in a known location. > With that each project could (optionally) modify its automation scripts to include that number. for example, in the Ruby SDK I'd like to generate RPMs like this: > rubygem-ovirt-engine-sdk4-4.2.0-1.alpha0.<that-number>.rpm -- This message was sent by Atlassian JIRA (v1000.1010.0#100044)

1 0

[JIRA] (OVIRT-1408) Please remove github/ovirt-web-ui from standard CI
by eyal edri [Administrator] (oVirt JIRA) 25 May '17

25 May '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1408?page=com.atlassian.jira.… ] eyal edri [Administrator] updated OVIRT-1408: --------------------------------------------- Epic Link: OVIRT-400 > Please remove github/ovirt-web-ui from standard CI > -------------------------------------------------- > > Key: OVIRT-1408 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1408 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Marek Libra > Assignee: infra > > Please remove github/ovirt-web-ui from standard CI since Travis is used instead. -- This message was sent by Atlassian JIRA (v1000.1010.0#100044)

1 0

[JIRA] (OVIRT-1408) Please remove github/ovirt-web-ui from standard CI
by eyal edri [Administrator] (oVirt JIRA) 25 May '17

25 May '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1408?page=com.atlassian.jira.… ] eyal edri [Administrator] updated OVIRT-1408: --------------------------------------------- Epic Link: OVIRT-400 > Please remove github/ovirt-web-ui from standard CI > -------------------------------------------------- > > Key: OVIRT-1408 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1408 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Marek Libra > Assignee: infra > > Please remove github/ovirt-web-ui from standard CI since Travis is used instead. -- This message was sent by Atlassian JIRA (v1000.1010.0#100044)

1 0

[JIRA] (OVIRT-1387) change gateway IP on PHX HE hypervisors
by eyal edri [Administrator] (oVirt JIRA) 25 May '17

25 May '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1387?page=com.atlassian.jira.… ] eyal edri [Administrator] updated OVIRT-1387: --------------------------------------------- Epic Link: OVIRT-403 > change gateway IP on PHX HE hypervisors > --------------------------------------- > > Key: OVIRT-1387 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1387 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Evgheni Dereveanchin > Assignee: infra > > We have an incorrect gateway set in HA configs of ovirt-srv01, ovirt-srv02 and ovirt-srv03v which can cause issues like the ones described in OVIRT-1369 > During the next host update window we need to edit /etc/ovirt-hosted-engine/hosted-engine.conf and change the gateway before rebooting. This has to be done in global maintenance to avoid unnecessary Engine restarts. -- This message was sent by Atlassian JIRA (v1000.1010.0#100044)

1 0

[JIRA] (OVIRT-1387) change gateway IP on PHX HE hypervisors
by eyal edri [Administrator] (oVirt JIRA) 25 May '17

25 May '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1387?page=com.atlassian.jira.… ] eyal edri [Administrator] updated OVIRT-1387: --------------------------------------------- Epic Link: OVIRT-403 > change gateway IP on PHX HE hypervisors > --------------------------------------- > > Key: OVIRT-1387 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1387 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Evgheni Dereveanchin > Assignee: infra > > We have an incorrect gateway set in HA configs of ovirt-srv01, ovirt-srv02 and ovirt-srv03v which can cause issues like the ones described in OVIRT-1369 > During the next host update window we need to edit /etc/ovirt-hosted-engine/hosted-engine.conf and change the gateway before rebooting. This has to be done in global maintenance to avoid unnecessary Engine restarts. -- This message was sent by Atlassian JIRA (v1000.1010.0#100044)

1 0

[JIRA] (OVIRT-1379) Re: Building ovirt-imageio for rawhide
by eyal edri [Administrator] (oVirt JIRA) 25 May '17

25 May '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1379?page=com.atlassian.jira.… ] eyal edri [Administrator] updated OVIRT-1379: --------------------------------------------- Epic Link: OVIRT-400 > Re: Building ovirt-imageio for rawhide > -------------------------------------- > > Key: OVIRT-1379 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1379 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Barak Korren > Assignee: infra > > Moving this to Jira. > On 15 May 2017 at 10:31, Barak Korren <bkorren(a)redhat.com> wrote: > > On 15 May 2017 at 10:13, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote: > >> > >> > >> > >> On Sat, May 13, 2017 at 11:12 PM, Nir Soffer <nsoffer(a)redhat.com> wrote: > >>> > >>> Hi Sandro, what is needed to build and public ovirt-imageio for Fedora rawhide? > >> > >> > >> We miss support for rawhide in mock runner, within jenkins git repo. > >> Adding Barak > > > > Get we get a mock configuration for it from somewhere? > > They are building it in Koji so I guess they have rawhide buildroots already no? > > > > Is there any other special behaviour needed besides the proper mock > > configuration? > > > > -- > > Barak Korren > > RHV DevOps team , RHCE, RHCi > > Red Hat EMEA > > redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted > -- > Barak Korren > RHV DevOps team , RHCE, RHCi > Red Hat EMEA > redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted -- This message was sent by Atlassian JIRA (v1000.1010.0#100044)

1 0