master-to-master CI upgrade tests

Description

Hi all,

Recently a patch to the engine [1] added a new package,
with a certain set of dependencies, which broke upgrade.
This is similar to [2] but for a new package.

CI wasn't affected, I think because of [3].

To make CI test such flows, we should have a job that:
1. Builds, installs and sets up the version we want to test
2. Pushes a dummy change to the local git repo (to force
a new version), build the patched tree, create a yum repo
with the build and add it to yum.repos.d.
3. yum update
4. engine-setup

Another option is to revert [3], or to duplicate - have
both "upgrade current to self" and "upgrade latest snapshot
to current". The downside is that it will be checked later
than above plan - instead of in the same build, will only
be tested in the first build that uses the snapshot after
it was updated, and also will be misleading, as the reason
why that job failed will not be apparent (which was why
[3] was added).

Please handle. I can of course try to help. Best,

[1] https://gerrit.ovirt.org/66999
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1321249
[3] https://gerrit.ovirt.org/67263

Didi

Activity

Show:

Eyal Edri February 27, 2017 at 7:56 AM

We have other priorities and limited people to do it, so its people time.
Of course if you have the time you can contribute a new suite if you'd like and if needed can help with the details.

Yedidyah Bar David February 27, 2017 at 7:28 AM

On Sun, Feb 26, 2017 at 7:33 PM, eyal edri [Administrator] (oVirt JIRA) <

That's good.

Indeed, but it has the potential to uncover bugs quickly after they are
introduced, when hopefully things are still fresh enough in the minds of
the relevant developers, instead of many months later (e.g. when we add
4.2->master upgrade jobs)

You mean machine time? Or people time?
Do we have an analysis of how much actual time each of our jobs
uses, and similar things, to help make such decisions?

Also, you might want to run it once a day or so, instead of per-patch
or per-merge. It will still be helpful.

Not sure why. Will this require more work? Or just more hardware?
If more hardware, how would this change in the future?


Didi

Eyal Edri February 26, 2017 at 5:33 PM

We added upgrade flows for all major versions and z-streams as part of the OST suites.
so 4.0->master and 4.1->master will run.

I'm not sure we need to support master->master since its not a valid case a user or customer would face and its better to invest CI time in more relevant flows.

I'm not closing this, but moving to low priority to see if we'll need it in the future.

Eyal Edri December 29, 2016 at 1:38 PM

reminder to add to upgrade suites

Eyal Edri December 4, 2016 at 11:17 AM

Also, you might want to change the ticket name for " fixing/updating
upgrade job" the current title is misleading

On Sun, Dec 4, 2016 at 1:11 PM, eyal edri [Administrator] (oVirt JIRA) <


Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)

Eyal Edri December 4, 2016 at 11:10 AM

well, depending on the amount of effort needed to update the job, we
might want to wait with it until the jobs are moved to an ost suit, which
is in progress.

On Dec 4, 2016 13:07, "Yedidyah Bar David" <didi@redhat.com> wrote:

On Sun, Dec 4, 2016 at 11:06 AM, eyal edri [Administrator] (oVirt
atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel&focusedCommentId=23805#comment-23805 ]
from-master_el7_merged/

Indeed, and I explained in the ticket why it's not enough as-is.

Best,

Didi
_______________________________________________
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Yedidyah Bar David December 4, 2016 at 11:08 AM

On Sun, Dec 4, 2016 at 11:06 AM, eyal edri [Administrator] (oVirt

Indeed, and I explained in the ticket why it's not enough as-is.

Best,

Didi

Eyal Edri December 4, 2016 at 9:05 AM

Won't Do

Details

Assignee

Reporter

Priority

Created December 4, 2016 at 8:59 AM
Updated June 1, 2017 at 11:32 AM
Resolved May 18, 2017 at 12:04 PM

Flag notifications