baremetal bond-with-vlans in pike is failing

[wes hayutin]

https://thirdparty.logs.rdoproject.org/jenkins-tripleo-quickstart-pike-rdo_trunk-baremetal-dell_pe_r630-bond_with_vlans-27/

[Alex Schultz (alex-schultz)]

Looks infrastructure related

fatal: [host15.beaker.tripleo.lab.eng.rdu2.redhat.com]: FAILED! => {
    "changed": true,
    "cmd": [
        "curl",
        "-sfL",
        "http://rhos-release.virt.bos.redhat.com/ci-images/centos-org-image-cache/pike/rdo_trunk//undercloud.qcow2.md5"
    ],
    "delta": "0:00:00.053607",
    "end": "2017-10-10 11:55:59.143923",
    "failed": true,
    "invocation": {
        "module_args": {
            "_raw_params": "curl -sfL http://rhos-release.virt.bos.redhat.com/ci-images/centos-org-image-cache/pike/rdo_trunk//undercloud.qcow2.md5",
            "_uses_shell": false,
            "chdir": null,
            "creates": null,
            "executable": null,
            "removes": null,
            "warn": true
        },
        "module_name": "command"
    },
    "rc": 22,
    "start": "2017-10-10 11:55:59.090316",
    "stderr": "",
    "stdout": "",
    "stdout_lines": [],
    "warnings": [
        "Consider using get_url or uri module rather than running curl"
    ]
}

[Emilien Macchi (emilienm)]

Please improve the bug report, change the title and add some description.

Your servant triage bot

[wes hayutin (weshayutin)]

full baremetal deployments have been failing, we have no passes on bond-with-vlans since August 15 2017. This bug is to track getting this environment back into a stable state.

[wes hayutin (weshayutin)]

Current issue is that the "hash" variable is empty.

15:53:14 ++ get_delorean_hash_from_url
15:53:14 ++ uri=
15:53:14 ++ echo
15:53:14 ++ awk -F / '{ print $7 }'
15:53:14 + hash=
15:53:14 + cached_image=http://internal-server/ci-images/centos-org-image-cache/pike/rdo_trunk//undercloud.qcow2

[Matt Young (halcyondude)]

I suspect what's happening here is that the job is being launched such that current_build isn't being set.

There's a few ways it can be set, and a way to manually launch the job such that it's not set (bad). Just running the individual job will not set the parameter, which will cause the error being observed above.

There is an existing item [1] in the CI team's backlog that IMHO we should just address to make it clear when this is occurring.

<note>
The *only* reason that the jobs are set up using these property files (vs. other mechanism to pass parameters) is that at the time these pipelines were created, "being like RDO upstream" was a critical concern. RDO Phase 1 is still structured in a similar way, with property files being specified in the wrapping multijobs. This is less of an acute issue as most of those are set up to pull from a symlink, so whenever the jobs are simply run they always pull the current symlink - at the cost of not being reproducible once the symlinks have been updated.
</note>

Ways to launch the existing jobs such that current_build is defined:

1. launch wrapping multijob, which launch these jobs with a property file, containing "current_build=$urlHash", which is injected as a jenkins 'parameter' (an environment variable)

2. Using "Retry" on a failed build, which leverages the naginator plugin to re-use the same parameters which include "current_build" - and in the case of sbtest jobs contain additional parameters.

3. Using the "Rebuild" option (again on a specific numbered build job), which will present a UI page pre-populated with the previous parameters and their values, which could be changed or kept the same

4. using curl in the form "http://server/job/myjob/buildWithParameters?PARAMETER=Value"

[1] https://trello.com/c/rtFYw1dW/28-rdophase2ospphase0-make-jobs-fail-early-and-clearly-if-currentbuild-is-not-defined

[Matt Young (halcyondude)]

The docs for parameterized build is

- https://wiki.jenkins.io/display/JENKINS/Parameterized+Build

[wes hayutin (weshayutin)]

bah.. thanks Matt!