- Infra - oVirt List Archives

[JIRA] (OVIRT-809) [gerrit hooks] recreate set_modified hook
by Shlomo Ben David (oVirt JIRA) 03 Nov '16

03 Nov '16

Shlomo Ben David created OVIRT-809: -------------------------------------- Summary: [gerrit hooks] recreate set_modified hook Key: OVIRT-809 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-809 Project: oVirt - virtualization made easy Issue Type: Task Reporter: Shlomo Ben David Assignee: infra -- This message was sent by Atlassian JIRA (v1000.482.6#100017)

1 0

[JIRA] (OVIRT-809) [gerrit hooks] recreate set_modified hook
by Shlomo Ben David (oVirt JIRA) 03 Nov '16

03 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-809?page=com.atlassian.jira.p… ] Shlomo Ben David updated OVIRT-809: ----------------------------------- Epic Link: OVIRT-403 > [gerrit hooks] recreate set_modified hook > ----------------------------------------- > > Key: OVIRT-809 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-809 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Shlomo Ben David > Assignee: infra > -- This message was sent by Atlassian JIRA (v1000.482.6#100017)

1 0

[JIRA] (OVIRT-809) [gerrit hooks] recreate set_modified hook
by Shlomo Ben David (oVirt JIRA) 03 Nov '16

03 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-809?page=com.atlassian.jira.p… ] Shlomo Ben David reassigned OVIRT-809: -------------------------------------- Assignee: Shlomo Ben David (was: infra) > [gerrit hooks] recreate set_modified hook > ----------------------------------------- > > Key: OVIRT-809 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-809 > Project: oVirt - virtualization made easy > Issue Type: Task > Reporter: Shlomo Ben David > Assignee: Shlomo Ben David > -- This message was sent by Atlassian JIRA (v1000.482.6#100017)

1 0

[JIRA] (OVIRT-763) [Lago][rfe] ability to choose version to be installed
by Piotr Kliczewski (oVirt JIRA) 03 Nov '16

03 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-763?page=com.atlassian.jira.p… ] Piotr Kliczewski commented on OVIRT-763: ---------------------------------------- I saw when running system testes that somehow it is not using the latest merged version. On my machine I created custom repo with my changes and I pulled dependencies from ovirt repo for this specific version. I run the tests several times to make sure that my changes are not breaking anything. In between ovirt repo was updated with newest build which caused lago to pull it instead of my changes. Both scenarios make lago/system tests unpredictable. I am do not know what I am testing and this leads to wrong assumptions. > [Lago][rfe] ability to choose version to be installed > ----------------------------------------------------- > > Key: OVIRT-763 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-763 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Piotr Kliczewski > Assignee: infra > > I started to test using lago with master repos and my custom engine built. > It was built on 7.10 one test failed and I noticed that newer engine was > installed instead of my specific version. It seems that we need an ability > to define which version of the rpms should be used during the tests. > Thanks, > Piotr -- This message was sent by Atlassian JIRA (v1000.482.6#100017)

1 0

[JIRA] (OVIRT-763) [Lago][rfe] ability to choose version to be installed
by eyal edri [Administrator] (oVirt JIRA) 03 Nov '16

03 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-763?page=com.atlassian.jira.p… ] eyal edri [Administrator] commented on OVIRT-763: ------------------------------------------------- [~pkliczew(a)redhat.com] I'm not sure what you mean, how the tests are unpredictable? You can choose which suite you want to run (3.6/4.0/master) basic / hosted-engine - what exactly is unpredictable? can you elaborate? > [Lago][rfe] ability to choose version to be installed > ----------------------------------------------------- > > Key: OVIRT-763 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-763 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: Piotr Kliczewski > Assignee: infra > > I started to test using lago with master repos and my custom engine built. > It was built on 7.10 one test failed and I noticed that newer engine was > installed instead of my specific version. It seems that we need an ability > to define which version of the rpms should be used during the tests. > Thanks, > Piotr -- This message was sent by Atlassian JIRA (v1000.482.6#100017)

1 0

[JIRA] (OVIRT-761) Re: Do we or can we have Mac OS slaves in Jenkins?
by eyal edri [Administrator] (oVirt JIRA) 03 Nov '16

03 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-761?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-761: -------------------------------------------- Resolution: Fixed Status: Done (was: Blocked) > Re: Do we or can we have Mac OS slaves in Jenkins? > -------------------------------------------------- > > Key: OVIRT-761 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-761 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: Barak Korren > > Opening a ticket. > On Mon, Oct 10, 2016 at 11:44 AM, Juan Hernández <jhernand(a)redhat.com> > wrote: > > Hello, > > > > Part of the Ruby SDK uses native code that needs to be compiled during > > installation of the gem. The Ruby SDK is a requirement of ManageIQ, and > > many ManageIQ developers/users use Mac OS. In the past I had some issues > > with this environment, as the C compiler there behaves in an slightly > > different way than GCC. Those issues were discovered only when the SDK > > was already released. To avoid that I would like to have Jenkins jobs > > building/testing the SDK for Mac OS. Is that possible? Do we have Mac OS > > slaves? If not, can we have them? > > > > Regards, > > Juan Hernandez > > > > -- > > Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta > > 3ºD, 28016 Madrid, Spain > > Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016> -- This message was sent by Atlassian JIRA (v1000.482.6#100017)

1 0

[JIRA] (OVIRT-761) Re: Do we or can we have Mac OS slaves in Jenkins?
by Juan Hernández (oVirt JIRA) 03 Nov '16

03 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-761?page=com.atlassian.jira.p… ] Juan Hernández commented on OVIRT-761: -------------------------------------- We agreed that using Travis CI is good enough for now, so this issue can be closed. > Re: Do we or can we have Mac OS slaves in Jenkins? > -------------------------------------------------- > > Key: OVIRT-761 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-761 > Project: oVirt - virtualization made easy > Issue Type: By-EMAIL > Reporter: sbonazzo > Assignee: Barak Korren > > Opening a ticket. > On Mon, Oct 10, 2016 at 11:44 AM, Juan Hernández <jhernand(a)redhat.com> > wrote: > > Hello, > > > > Part of the Ruby SDK uses native code that needs to be compiled during > > installation of the gem. The Ruby SDK is a requirement of ManageIQ, and > > many ManageIQ developers/users use Mac OS. In the past I had some issues > > with this environment, as the C compiler there behaves in an slightly > > different way than GCC. Those issues were discovered only when the SDK > > was already released. To avoid that I would like to have Jenkins jobs > > building/testing the SDK for Mac OS. Is that possible? Do we have Mac OS > > slaves? If not, can we have them? > > > > Regards, > > Juan Hernandez > > > > -- > > Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta > > 3ºD, 28016 Madrid, Spain > > Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L. > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016> -- This message was sent by Atlassian JIRA (v1000.482.6#100017)

1 0

[JIRA] (OVIRT-808) move upgrade jobs to lago
by eyal edri [Administrator] (oVirt JIRA) 03 Nov '16

03 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-808?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-808: -------------------------------------------- Resolution: Duplicate Status: Done (was: To Do) https://ovirt-jira.atlassian.net/browse/OVIRT-567 > move upgrade jobs to lago > ------------------------- > > Key: OVIRT-808 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-808 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Evgheni Dereveanchin > Assignee: infra > > Our upgrade jobs still run on slaves directly, causing various issues (OVIRT-780 OVIRT-802 OVIRT-475 ). We should move these jobs to run in Lago instead. -- This message was sent by Atlassian JIRA (v1000.482.6#100017)

1 0

[JIRA] (OVIRT-780) engine upgrade job is disabling puppet on slaves
by eyal edri [Administrator] (oVirt JIRA) 03 Nov '16

03 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-780?page=com.atlassian.jira.p… ] eyal edri [Administrator] updated OVIRT-780: -------------------------------------------- Resolution: Fixed Status: Done (was: To Do) > engine upgrade job is disabling puppet on slaves > ------------------------------------------------ > > Key: OVIRT-780 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-780 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Evgheni Dereveanchin > Assignee: infra > Priority: Low > > I found a lot of out-of-sync slaves in Foreman and further investigation revealed that puppet agent is disabled on them. > The journal indicates that it's the upgrade job doing this: > Oct 19 14:24:51 vm0079.workers-phx.ovirt.org sudo[18213]: jenkins : TTY=unknown ; PWD=/home/jenkins/workspace/ovirt-engine_master_upgrade-from-4.0_el7_created ; USER=root ; COMMAND=/bin/puppet agent --disable > Oct 19 14:24:54 vm0079.workers-phx.ovirt.org puppet-agent[18215]: Disabling Puppet. > The job seems to re-enable puppet after it runs, but once there's several consecutive jobs in the queue this causes puppet to be effectively turned off for hours. > Do we really need this? Can we run engine upgrade jobs inside mock to not affect the node itself? -- This message was sent by Atlassian JIRA (v1000.482.6#100017)

1 0

[JIRA] (OVIRT-780) engine upgrade job is disabling puppet on slaves
by Evgheni Dereveanchin (oVirt JIRA) 03 Nov '16

03 Nov '16

[ https://ovirt-jira.atlassian.net/browse/OVIRT-780?page=com.atlassian.jira.p… ] Evgheni Dereveanchin commented on OVIRT-780: -------------------------------------------- Logged ovirt-808 to track moving upgrade jobs to lago - that should fix the issue. In general, disabling puppet during a job run is not critical and is only visible when there's a lot of builds so dozens of nodes get stale on Foreman. I think we can close this case. > engine upgrade job is disabling puppet on slaves > ------------------------------------------------ > > Key: OVIRT-780 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-780 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: Evgheni Dereveanchin > Assignee: infra > Priority: Low > > I found a lot of out-of-sync slaves in Foreman and further investigation revealed that puppet agent is disabled on them. > The journal indicates that it's the upgrade job doing this: > Oct 19 14:24:51 vm0079.workers-phx.ovirt.org sudo[18213]: jenkins : TTY=unknown ; PWD=/home/jenkins/workspace/ovirt-engine_master_upgrade-from-4.0_el7_created ; USER=root ; COMMAND=/bin/puppet agent --disable > Oct 19 14:24:54 vm0079.workers-phx.ovirt.org puppet-agent[18215]: Disabling Puppet. > The job seems to re-enable puppet after it runs, but once there's several consecutive jobs in the queue this causes puppet to be effectively turned off for hours. > Do we really need this? Can we run engine upgrade jobs inside mock to not affect the node itself? -- This message was sent by Atlassian JIRA (v1000.482.6#100017)

1 0