Move the cli image stream into samples operator

[smarterclayton]

Add installer, which was the next dependency we need to include with
the cluster.

@bparees I realized that having where it is now (in the cli image) is a big
problem because everyone who descends from the cli image was getting added
multiple times during release creation, including jenkins agents. Once this moves
I can delete it out of origin.

[bparees]

typo?

[bparees]

To be clear, by doing this you're not really adding it to the samples operator in any meaningful way... yes the imagestream will get created by the CVO when it installs the samples operator, but the samples operator is not going to manage the imagestream:

1. it won't care if the import fails (will have no bearing on the samples operator reporting available)
2. it won't restore it if you modify/delete it (of course the CVO will)
3. it won't apply any of its platform or registry hostname configuration logic to the pullspec of the imagestream

I assume you understand and are ok with that.

[bparees]

@smarterclayton you need to explicitly add this new file to our dockerfiles:
https://github.com/openshift/cluster-samples-operator/blob/master/Dockerfile#L8
https://github.com/openshift/cluster-samples-operator/blob/master/Dockerfile.rhel7#L8

Feel free to fix it to just do 0* instead like we do elsewhere:
https://github.com/openshift/cluster-image-registry-operator/blob/master/Dockerfile#L10

[smarterclayton]

it won't care if the import fails (will have no bearing on the samples operator reporting available)

CVO will still report in that case that something is failing via its status

it won't restore it if you modify/delete it (of course the CVO will)

Yeah, I think this is ok

it won't apply any of its platform or registry hostname configuration logic to the pullspec of the imagestream

Since release payloads are single architecture, we're going to need to sort out platform stuff eventually, but the CLI image should be the one in the payload. I think we can get away without these for now and revisit (we can move management from CVO to your operator).

[bparees]

CVO will still report in that case that something is failing via its status

the CVO will recognize that the imagestream import failed? Not just that the creation failed, but that the actual import failed?

[smarterclayton]

the CVO will recognize that the imagestream import failed? Not just that the creation failed, but that the actual import failed?

e2e runs will start failing

[bparees]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bparees, smarterclayton

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [bparees]

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

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.