[JIRA] (OVIRT-780) engine upgrade job is disabling puppet on slaves
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-780?page=com.atlassian.jira... ]
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)
8 years, 1 month
[JIRA] (OVIRT-780) engine upgrade job is disabling puppet on slaves
by Evgheni Dereveanchin (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-780?page=com.atlassian.jira... ]
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)
8 years, 1 month
[JIRA] (OVIRT-808) move upgrade jobs to lago
by Evgheni Dereveanchin (oVirt JIRA)
Evgheni Dereveanchin created OVIRT-808:
------------------------------------------
Summary: 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)
8 years, 1 month
[JIRA] (OVIRT-763) [Lago][rfe] ability to choose version to be installed
by Piotr Kliczewski (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-763?page=com.atlassian.jira... ]
Piotr Kliczewski commented on OVIRT-763:
----------------------------------------
Due to this issue I wasted time running lago on my host. We saw issues using system tests and this makes the tests unpredictable and without it in my opinion there is no value in running those tests since we do not know what is tested.
> [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)
8 years, 1 month
[JIRA] (OVIRT-761) Re: Do we or can we have Mac OS slaves in Jenkins?
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-761?page=com.atlassian.jira... ]
eyal edri [Administrator] updated OVIRT-761:
--------------------------------------------
Blocked By: pending user reply
Status: Blocked (was: In Progress)
> 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)
8 years, 1 month
[JIRA] (OVIRT-761) Re: Do we or can we have Mac OS slaves in Jenkins?
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-761?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-761:
-------------------------------------------------
anything else is needed?
> 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)
8 years, 1 month
[JIRA] (OVIRT-761) Re: Do we or can we have Mac OS slaves in Jenkins?
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-761?page=com.atlassian.jira... ]
eyal edri [Administrator] updated OVIRT-761:
--------------------------------------------
Epic Link: OVIRT-400
> 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)
8 years, 1 month
[JIRA] (OVIRT-761) Re: Do we or can we have Mac OS slaves in Jenkins?
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-761?page=com.atlassian.jira... ]
eyal edri [Administrator] updated OVIRT-761:
--------------------------------------------
Epic Link: OVIRT-400
> 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)
8 years, 1 month
[JIRA] (OVIRT-757) [VDSM] Add Travis CI to vdsm github project
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-757?page=com.atlassian.jira... ]
eyal edri [Administrator] closed OVIRT-757.
-------------------------------------------
Resolution: Fixed
working according to user, please reopen if needed.
> [VDSM] Add Travis CI to vdsm github project
> -------------------------------------------
>
> Key: OVIRT-757
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-757
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: Nir Soffer
> Assignee: Barak Korren
>
> Hi all,
> Vdsm includes now a travis configuration running vdsm tests
> on both Fedora 24 and Centos 7.
> You can see example build shere:
> https://travis-ci.org/nirs/vdsm/builds/166263228
> These builds are currently configured in my private vdsm
> fork on github.
> We want to enable Travis CI service on vdsm github project,
> so each time a patch is merged (sync from gerrit) or each time
> a pull request is submitted, a build is started.
> Developers can use these builds in 2 ways:
> - fork vdsm and enable travis on their fork
> - submit pull requests to get them tested
> When a build fails, travis sends email to the author about the
> failure, this works fine for developers forks without any
> additional configuration.
> You can configure github for us, or give Dan and/or me the
> permissions to configure the github project.
> Cheers,
> Nir
--
This message was sent by Atlassian JIRA
(v1000.482.6#100017)
8 years, 1 month