greenwave

#665 Passed test JSON representation does not include scenario
Closed: Fixed by lholecek. Opened by adamwill.

Closed: Fixed
Reopen Issue

Here's some typical output from a greenwave query with some passed, some failed and some missing results. The first result is from the satisfied_requirements list, the others are from the unsatisfied_requirements list.

    {
        "item": {
            "item": "FEDORA-2022-927d891099",
            "type": "bodhi_update"
        },
        "result_id": 40399162,
        "source": null,
        "subject_identifier": "FEDORA-2022-927d891099",
        "subject_type": "bodhi_update",
        "testcase": "update.desktop_update_graphical",
        "type": "test-result-passed"
    }
...
    {
        "item": {
            "item": "FEDORA-2022-927d891099",
            "type": "bodhi_update"
        },
        "scenario": "fedora.updates-workstation-live-iso.x86_64.uefi",
        "source": null,
        "subject_identifier": "FEDORA-2022-927d891099",
        "subject_type": "bodhi_update",
        "testcase": "update.install_default_update_live",
        "type": "test-result-missing"
    },
    {
        "item": {
            "item": "FEDORA-2022-927d891099",
            "type": "bodhi_update"
        },
        "result_id": 40400611,
        "scenario": "fedora.updates-workstation-live-iso.x86_64.64bit",
        "source": null,
        "testcase": "update.live_build",
        "type": "test-result-failed"
    }

For some reason, the 'scenario' is included in the test-result-failed and test-result-missing entries, but not the test-result-passed entry.

I looked at greenwave/policies.py to see if I could figure out why this is, but I can't. TestResultFailed and TestResultPassed are implemented very similarly, and called similarly. The only difference is that TestResultFailed defines a scenario property where TestResultPassed does not, but that doesn't seem like it should matter.

Both call data.update(self.data) in their to_json() implementations and I'd expect the scenario to be included there.

ah, it may be that this is fixed in master but not yet in production? When I run a query on a dev server from current git master it seems to include the scenario for test-result-passed items.

ah, yeah, it looks like 9a7cd287ab19ae0a75a7800ab5484053c8f7792e fixed it.

We haven't moved prod-fedora container image tag for a while (https://quay.io/repository/factory2/greenwave?tab=tags). Internally, for Red Hat build artifacts, tests and policies, we test new images extensively in stage. In near future we plan to deploy continuously also to prod without need for tagging the new versions first.

We have made some bigger changes in Greenwave recently, mainly use UBI base image and bumped a lot of dependencies to latest package versions in PyPI instead of using system packages. I have less confidence to do the deployment for Fedora.

Can we coordinate bumping the image tag somehow?

well, I ran a pet dev instance and did two queries against it, so I'm sure everything is fine. ;)

We do have a staging instance for Fedora; can we not just update that and monitor it manually for a bit?

Stage instance should use "latest" tagged container image:
https://pagure.io/fedora-infra/ansible/blob/ccafc8949833b3fa014a3b545e7df0f34dd0991f/f/roles/openshift-apps/greenwave/templates/imagestream.yml#_24

But for some reason it has same old version as prod (1.10.0): https://greenwave.stg.fedoraproject.org/api/v1.0/about

It may just be that the playbook hasn't been run lately, or something? I'm not entirely sure how the openshift stuff works. @kevin ?

Yes, there's currently nothing that would pull new images and roll out new deployments without someone doing so.

But... stg is also set to use the same image as prod:

{% if env == 'staging' %}
# The latest successful build of master that passes tests
# is auto-tagged here.
# name: quay.io/factory2/greenwave:latest
name: quay.io/factory2/greenwave:prod-fedora
{% else %}
# This is 'prod' tag is maintained by hand.
name: quay.io/factory2/greenwave:prod-fedora
{% endif %}

I set that when we moved from ocp3 to ocp4, because the image wouldn't deploy.

I switched it back just now and see it still fails with:

STEP 3/6: RUN dnf -y install fedora-messaging && dnf clean all
/bin/sh: dnf: command not found
error: build error: error building at STEP "RUN dnf -y install fedora-messaging && dnf clean all": error while running runtime: exit status 127

STEP 3/6: RUN dnf -y install fedora-messaging && dnf clean all
/bin/sh: dnf: command not found

We now use a minimal container image. Most dependencies including fedora-messaging are installed from a recent versions in PyPI. So I believe that step is not necessary.

ok. Would you like me to drop that and try it? Or would you like to rework it in a pr? Thats the only thing we do in the buildconfig, so probibly doesn't need to build anything, just pull the image in the long term.

ok. Would you like me to drop that and try it? Or would you like to rework it in a pr? Thats the only thing we do in the buildconfig, so probibly doesn't need to build anything, just pull the image in the long term.

Dropping buildconfig sounds good. Please let me know if any other problems pop up.

Metadata Update from @lholecek:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.