Fixing openshift-ocp-release-operator-sdk-master.yaml to use dockerfile from ocp-build-data

[alvaroaleman]

No description provided.

[jupierce]

/test all

[jupierce]

/test all

[jupierce]

/retest

[jupierce]

/retest

[jupierce]

/retest

[jupierce]

/retest

[jupierce]

/retest

[joelanford]

It isn't clear to me why the errors in the master/images job are happening. Are those flakes or does it have something to do with the base images that are changed in this PR?

[joelanford]

I'm probably out of the loop, but can you explain this change?

Am I understanding correctly that with this change, there would be no distinction between os and os-minimal? Is there a minimal version of this image?

[jupierce]

@joelanford - context can be found in aos-devel thread [aos-devel] [Action Required] Promotion Dockerfiles will be synced from ocp-build-data .

[jupierce]

Downstream product builds do not build on ubi8 minimal. This change ensure that your image builds on the same base as ART.

[joelanford]

Is there any reason we don't consolidate and remove the os-minimal base image and update any references to it to use os since os and os-minimal are now identical.

That might help reduce confusion for our future selves. If so, that definitely seems like something that can be done in a follow-up.

[jupierce]

/retest

[jupierce]

/retest

[jupierce]

/test all

[jupierce]

/retest

[jmrodri]

We need this PR to merge. The Dockerfile.rhel8 had the old commands in it. openshift/ocp-release-operator-sdk#67

[timflannagan]

/retest

[crawford]

I can't tell why the memcached operator didn't start memcached in the latest failure. I also see Ansible complaining about oauthlib when it tries to collect the logs (I assume that's what it's trying to do).

In the previous failure, I see the test failing in a different spot, so there seems to be a race. Let's retest anyway.

/retest

[jmrodri]

It failed this time with a weird error

 TASK [start memcached] ******************************** 
�[0;31mAn exception occurred during task execution. To see the full traceback, use -vvv. The error was: ModuleNotFoundError: No module named 'oauthlib'�[0m
�[0;31mfatal: [localhost]: FAILED! => {"changed": false, "error": "No module named 'oauthlib'", "msg": "Failed to import the required Python library (openshift) on memcached-operator-66d945589b-xrvs5's Python /usr/libexec/platform-python. Please read module documentation and install in the appropriate location. If the required library is installed, but Ansible is using the wrong Python interpreter, please consult the documentation on ansible_python_interpreter"}�[0m```

First the python executable is strange: `/usr/libexec/platform-python` After some investigation looks like there are 2 pythons and they look in the same place for modules. 

/usr/libexec/platform-python

Python 3.6.8 (default, Dec 5 2019, 15:45:45)
[GCC 8.3.1 20191121 (Red Hat 8.3.1-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.

import sys
type(sys.path)
<class 'list'>
for path in sys.path:
... print(path)
...

/usr/lib64/python36.zip
/usr/lib64/python3.6
/usr/lib64/python3.6/lib-dynload
/usr/lib64/python3.6/site-packages
/usr/lib/python3.6/site-packages

/usr/bin/python3

Python 3.6.8 (default, Dec 5 2019, 15:45:45)
[GCC 8.3.1 20191121 (Red Hat 8.3.1-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.

import sys
type(sys.path)
<class 'list'>
for path in sys.path:
... print(path)
...

/usr/lib64/python36.zip
/usr/lib64/python3.6
/usr/lib64/python3.6/lib-dynload
/usr/lib64/python3.6/site-packages
/usr/lib/python3.6/site-packages

In RHEL7, oauthlib comes from python-requests-oauthlib this is required by ultimately by python3-openshift through other deps.

[jmrodri]

I can't tell why the memcached operator didn't start memcached in the latest failure. I also see Ansible complaining about oauthlib when it tries to collect the logs (I assume that's what it's trying to do).

In the previous failure, I see the test failing in a different spot, so there seems to be a race. Let's retest anyway.

This previous failure was because the dockerfile was building operator-sdk instead of ansible-operator binary. They have different flagsets.

The new failure with oauthlib makes me think there might be a dependency that isn't setup in the RPMs correctly to pull in the needed library. I'm havnig a hard time trying to build these images by hand so I can debug it trying to decipher how the metadata file in this PR translates to updates to the dockerfile in our repo. I think I got close but it's less than obvious.

[alvaroaleman]

/retest

[alvaroaleman]

/retest

[jmrodri]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alvaroaleman, jmrodri

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• ci-operator/config/openshift/ocp-release-operator-sdk/OWNERS [alvaroaleman,jmrodri]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

@alvaroaleman: Updated the ci-operator-master-configs configmap in namespace ci at cluster app.ci using the following files:

• key openshift-ocp-release-operator-sdk-master.yaml using file ci-operator/config/openshift/ocp-release-operator-sdk/openshift-ocp-release-operator-sdk-master.yaml

Details

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.