search

operator-framework / enhancements

Apache License 2.0
9 stars 40 forks source link

doc(bundles): use imagestreams to proxy bundle images #34

Closed njhale closed 4 years ago

njhale commented 4 years ago

Use ImageStreams to pull bundle images via CRI-O when OLM is deployed to an OpenShift cluster. This allows ImageContentSourcePolicy constraints to be satisfied while using opm -- instead of a PodSpec -- to pull bundles directly, enabling an unambiguous bundle unpacking process (see Motivation for more details).

shawn-hurley commented 4 years ago

We (@bparees, @jwforres) think that we can achieve the same result that the proposal is trying to solve with less complexity by:

  1. Define that metadata/annotations.yaml is the sole source of truth. You can add labels to the bundle but that is not authoritative. This IIRC is what we said in the initial enhancement proposal.

  2. We do not allow the metadata/annotations to be in any other location in the container then /metadata/annotations. IIRC this was a by-product of OPM for some time, where we only looked at this location. We should codify that in the spec of the bundle image. This will make it easy to find the annotations.yaml when running the container because if it is a valid bundle it will only be in one place.

@njhale WDYT?

@bparees and @jwforres can you double-check that this covers all the actions that we discussed?

bparees commented 4 years ago

i thought we also considered declaring the the manifests had to be in a specific path, but perhaps that ship has already sailed?

njhale commented 4 years ago

We (@bparees, @jwforres) think that we can achieve the same result that the proposal is trying to solve with less complexity by:

  1. Define that metadata/annotations.yaml is the sole source of truth. You can add labels to the bundle but that is not authoritative. This IIRC is what we said in the initial enhancement proposal.
  2. We do not allow the metadata/annotations to be in any other location in the container then /metadata/annotations. IIRC this was a by-product of OPM for some time, where we only looked at this location. We should codify that in the spec of the bundle image. This will make it easy to find the annotations.yaml when running the container because if it is a valid bundle it will only be in one place.

@njhale WDYT?

@bparees and @jwforres can you double-check that this covers all the actions that we discussed?

Sorry for the delay, finally got around to reading this. Please see https://github.com/operator-framework/enhancements/pull/34#discussion_r456628549 for my response.

njhale commented 4 years ago

The concern that @bparees raised over the availability of an internal registry is convincing enough for me to close this out.

Placing that aside, based of the other feedback in this PR, I would like to ask @shawn-hurley and @jwforres whether there's appetite to continue moving towards taking advantage of OCI artifacts for future bundle specifications. I, and I think a few others working on OLM, have been operating under the assumption that bundle specs which utilize layers for storing k8s manifests were just a stop-gap for specs which instead use custom mediatypes in OCI-based images. Is this still a sound assumption?