Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bootstrap VM using old version of ironic #775

Closed
hardys opened this issue Aug 28, 2019 · 2 comments · Fixed by #776
Closed

bootstrap VM using old version of ironic #775

hardys opened this issue Aug 28, 2019 · 2 comments · Fixed by #776

Comments

@hardys
Copy link

hardys commented Aug 28, 2019

Describe the bug

Originally reported via openshift/installer#2282 and related to openshift/installer#2234 which recently landed

We're seeing issues starting ironic-inspector on the bootstrap VM, we can see the image referenced is:

Aug 28 08:51:17 localhost startironic.sh[1972]: + IRONIC_INSPECTOR_IMAGE=registry.svc.ci.openshift.org/origin/4.2-2019-08-28-054558@sha256:2cf170cc3e
6dad9c9bae32dea3a82267530a8d02742d16e865bb9d8b2fc7653f

However attempts to start the ironic-inspector container fail like this, indicating that it's an old version of ironic:

[core@localhost ~]$ sudo podman logs ironic-inspector | grep ConfigFileValueError
2019-08-28 09:34:13.447 1 CRITICAL ironic_inspector [-] Unhandled error: ConfigFileValueError: Value for option store_data is not valid: Valid values are [none, swift], but found 'database'
2019-08-28 09:34:13.447 1 ERROR ironic_inspector ConfigFileValueError: Value for option store_data is not valid: Valid values are [none, swift], but found 'database'

This has already been discussed in openshift/ironic-inspector-image#17, and with the nightly release payload we've previously been getting an ART build (which contains the right version of ironic), vs a CI build (which currently does not ref openshift/release#4835 openshift/release#4836 openshift/release#4837)

Previously we were getting an image from quay.io/openshift-release-dev/ocp-v4.0-art-dev - this was tested and proven to work OK, hence the revert in openshift/ironic-inspector-image#17

The problem seems to be that 65a987c#diff-2407feeeedf4de6f5b077ee1746f344b stopped setting the installer release image override, but we still need to set OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE or the installer uses the default (origin) pullspec

@stbenjam
Copy link
Member

stbenjam commented Aug 28, 2019

I don't think we should not be using OPENSHIFT_INSTALL_RELEASE_IMAGE_OVERRIDE at all, the installer will point to whatever release it's extracted from, just like regular openshift. If you want a different release, OPENSHIFT_INSTALL_IMAGE will work, but I'm not sure I understand the distinction, the default we use registry.svc.ci.openshift.org/ocp/release:4.2 is incorrect, or the payload isn't being set correctly in the installer?

hardys pushed a commit to hardys/dev-scripts that referenced this issue Aug 28, 2019
This was removed in openshift-metal3#758 but it turns out the default origin builds
still contain old ironic images, ref discussion on
openshift/ironic-inspector-image#17

It also seems sane to ensure the release image set in dev-scripts is
the same as the installer, which currently is not the case, we're
defaulting to ocp builds and the installer to origin.

Closes: openshift-metal3#775
@stbenjam
Copy link
Member

Oh, I see - are you doing a git install? I think from source we use the default which would be origin, so we need to set the override in that case. Must be why #766 is failing as well.

hardys pushed a commit to hardys/dev-scripts that referenced this issue Aug 28, 2019
This was removed in openshift-metal3#758 but it turns out the default origin builds
still contain old ironic images, ref discussion on
openshift/ironic-inspector-image#17

This means we need to set the installer release image override in the
case where export KNI_INSTALL_FROM_GIT=true, or we'll get the default
from the openshift/installer source, and that currently won't work.

Closes: openshift-metal3#775
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants