- Infra - oVirt List Archives

[JIRA] (OVIRT-886) Yum install does not throw error on missing package
by Barak Korren (oVirt JIRA) 03 Jul '17

03 Jul '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-886?page=com.atlassian.jira.p… ] Barak Korren commented on OVIRT-886: ------------------------------------ [~eedri] no this is actually a known issue, ticket should remain open. It can be easily fixed as long as we're using mock though. > Yum install does not throw error on missing package > --------------------------------------------------- > > Key: OVIRT-886 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-886 > Project: oVirt - virtualization made easy > Issue Type: Bug > Reporter: Gil Shinar > Assignee: infra > > When running el7 mock on fc24 (not necessary the issue) and one of the required packages is missing because a repository in .repos hadn't been added, yum will not fail and the package will not be installed -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0

[JIRA] (OVIRT-1014) avoid repetition in automation/*packages
by Barak Korren (oVirt JIRA) 03 Jul '17

03 Jul '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1014?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1014: ------------------------------------- [~eedri(a)redaht.com] actually it seems I linked to the wrong one. Which ticket are we using to track V2 again? > avoid repetition in automation/*packages > ---------------------------------------- > > Key: OVIRT-1014 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1014 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: danken > Assignee: infra > Labels: standard-ci > > Currently we have many automation/*packages* files, mostly repeating each other. > Most of the information there is then repeated in vdsm.spec as well. > It would be nice to have a hierarchical way to define packages. E.g. having most packages in automation/build-artifacts-manual.packages, and adding el7-specific dependencies in avoid repetition in automation/build-artifacts-manual.packages.el7. > It would be even better to have a single palce (yaml file?) to declare each required package and its version, for each platform/architecture. We can then use it to generate the spec file. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0

[JIRA] (OVIRT-1014) avoid repetition in automation/*packages
by Barak Korren (oVirt JIRA) 03 Jul '17

03 Jul '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1014?page=com.atlassian.jira.… ] Barak Korren commented on OVIRT-1014: ------------------------------------- [~eedri] linking. > avoid repetition in automation/*packages > ---------------------------------------- > > Key: OVIRT-1014 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1014 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: danken > Assignee: infra > Labels: standard-ci > > Currently we have many automation/*packages* files, mostly repeating each other. > Most of the information there is then repeated in vdsm.spec as well. > It would be nice to have a hierarchical way to define packages. E.g. having most packages in automation/build-artifacts-manual.packages, and adding el7-specific dependencies in avoid repetition in automation/build-artifacts-manual.packages.el7. > It would be even better to have a single palce (yaml file?) to declare each required package and its version, for each platform/architecture. We can then use it to generate the spec file. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0

[JIRA] (OVIRT-1014) avoid repetition in automation/*packages
by Barak Korren (oVirt JIRA) 03 Jul '17

03 Jul '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1014?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1014: -------------------------------- Labels: standard-ci (was: ) > avoid repetition in automation/*packages > ---------------------------------------- > > Key: OVIRT-1014 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1014 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: danken > Assignee: infra > Labels: standard-ci > > Currently we have many automation/*packages* files, mostly repeating each other. > Most of the information there is then repeated in vdsm.spec as well. > It would be nice to have a hierarchical way to define packages. E.g. having most packages in automation/build-artifacts-manual.packages, and adding el7-specific dependencies in avoid repetition in automation/build-artifacts-manual.packages.el7. > It would be even better to have a single palce (yaml file?) to declare each required package and its version, for each platform/architecture. We can then use it to generate the spec file. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0

[JIRA] (OVIRT-1014) avoid repetition in automation/*packages
by Barak Korren (oVirt JIRA) 03 Jul '17

03 Jul '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1014?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1014: -------------------------------- Component/s: oVirt CI > avoid repetition in automation/*packages > ---------------------------------------- > > Key: OVIRT-1014 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1014 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: danken > Assignee: infra > > Currently we have many automation/*packages* files, mostly repeating each other. > Most of the information there is then repeated in vdsm.spec as well. > It would be nice to have a hierarchical way to define packages. E.g. having most packages in automation/build-artifacts-manual.packages, and adding el7-specific dependencies in avoid repetition in automation/build-artifacts-manual.packages.el7. > It would be even better to have a single palce (yaml file?) to declare each required package and its version, for each platform/architecture. We can then use it to generate the spec file. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0

[JIRA] (OVIRT-1064) Re-factor experimental groovy script
by Barak Korren (oVirt JIRA) 03 Jul '17

03 Jul '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1064?page=com.atlassian.jira.… ] Barak Korren updated OVIRT-1064: -------------------------------- Resolution: Won't Fix Status: Done (was: To Do) Closing this ticket because the 'experimental' flow will be deprecated by the 'change-queue' flow. > Re-factor experimental groovy script > ------------------------------------ > > Key: OVIRT-1064 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1064 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > > The experimental Groovy scripts has several issues that should be resolved by re-factoring it: > # Turn the variables defined in the top of the file into constants with upper case manes to ensure they're not used in functions by mistake > # Remove unused arguments from functions > # Move the main() function definition to the top of the file so its easier to quickly see an overview of the whole flow > # Use the "global" constants inside main() instead of passing gazillion parameters to it. > # Pass parameters directly to function instead of turning them into strings and using interpolation > # Use 'for-each' loops instead of C-style indexed loops. > # Use consistent indention throughout the file -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0

Change 78189,11 (vdsm) failed system tests
by oVirt Jenkins 03 Jul '17

03 Jul '17

A system test invoked by the "ovirt-master" change queue including change 78189,11 (vdsm) failed. However, this change seems not to be to root cause for failure. Change 78630,13 (vdsm) that this change depends on or is based on, was detected to cause testing failures. This change had been removed from the testing queue. Artifacts built from this change will not be released until either change 78630,13 (vdsm) is fixed and this change is updated to refer to or rebased on the fixed version, or this change is modified to no longer depend on it. For further details about the change see: https://gerrit.ovirt.org/#/c/78189/11 For further details about the change that seems to be the root cause behind the testing failures see: https://gerrit.ovirt.org/#/c/78630/13 For failed test results see: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/1037/

1 0

[JIRA] (OVIRT-1396) Add a new 'test-system-artifacts' Standard-CI stage
by eedri (oVirt JIRA) 03 Jul '17

03 Jul '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1396?page=com.atlassian.jira.… ] eedri updated OVIRT-1396: ------------------------- Priority: High (was: Medium) > Add a new 'test-system-artifacts' Standard-CI stage > --------------------------------------------------- > > Key: OVIRT-1396 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1396 > Project: oVirt - virtualization made easy > Issue Type: New Feature > Components: oVirt CI > Reporter: Barak Korren > Assignee: infra > Priority: High > > This is a part of [containers CI/CD|https://docs.google.com/a/redhat.com/document/d/1mEo3E0kRvlUWT9VaSPKD…] flow implementation process. > An order to allow building and testing processes for containers to be triggered after package that are needed for them are built, we will introduce the "{{test-system-artifacts}}" standard-CI stage. > This stage will be invoked from the 'experimental' or 'change-queue-tester' pipelines jost like the existing OST-based flows. > In order to provide package and repo information to the std-CI script invoked by this stage we well need to implement OVIRT-1391 -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0

[JIRA] (OVIRT-1292) make ovirt-release RPMs RHEL compatible
by eedri (oVirt JIRA) 03 Jul '17

03 Jul '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1292?page=com.atlassian.jira.… ] eedri commented on OVIRT-1292: ------------------------------ [~sbonazzo(a)redhat.com] is there anything we can do in the release rpm to fix it? > make ovirt-release RPMs RHEL compatible > --------------------------------------- > > Key: OVIRT-1292 > URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1292 > Project: oVirt - virtualization made easy > Issue Type: Improvement > Reporter: eedri > Assignee: infra > > Some oVirt users are using the ovirt-release el7 RPMs to test oVirt on RHEL. > Unfortunately, RHEL uses the '7Server' link which doesn't exist in CentOS resulting in breakage like: > 'http://mirror.centos.org/centos/7Server/virt/x86_64/kvm-common/' > while 'http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/' exist > We should either ask CentOS to add that link on the repo or find a way to fix it ourselves in the release rpm. -- This message was sent by Atlassian JIRA (v1000.1092.1#100053)

1 0

[JIRA] (OVIRT-1276) generate a link to OST automation job
by eedri (oVirt JIRA) 03 Jul '17

03 Jul '17

[ https://ovirt-jira.atlassian.net/browse/OVIRT-1276?page=com.atlassian.jira.… ] eedri updated OVIRT-1276: ------------------------- Issue Type: Improvement (was: By-EMAIL) > 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: Improvement > Reporter: rgolan(a)redhat.com > 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.1092.1#100053)

1 0