Skip to content

OTA-949: README: Define a 1.2.0 filesystem schema for release signatures #3509

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.

Sign up for GitHub

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

Jump to bottom
Merged
openshift-merge-robot merged 2 commits into from
Apr 19, 2023
Merged

OTA-949: README: Define a 1.2.0 filesystem schema for release signatures #3509

openshift-merge-robot merged 2 commits into from
Apr 19, 2023

Conversation

@wking
Copy link
Member

@wking wking commented Apr 19, 2023

I'm not actually consuming this new structure in Git, so the version file remains at 1.1.0. But we're defining it here because:

  • We want a versioned schema for passing signature data from oc-mirror and other graph-data image producers through to Cincinnati (for locally run update services),
  • We might decide to version-control signatures in the future, and
  • We wanted to avoid the overhead of having one versioned filesystem API for Git-to-Cincinnati and another for oc-mirror-graph-data-images-to-Cincinnati.

wking added 2 commits April 19, 2023 10:30
@wking
README: Explicit versions for each directory/file/property
9366385 
We grew conditional update risks in faf68e2 (blocked-edges/4.7.4*:
Targeted edge blocking and version 1.1.0, 2021-09-01, openshift#1089).  This
commit marks the other directories, files, and properties as supported
since 1.0.0, so 1.0.0 parsers can look at the current spec, and still
understand what they're on the hook to support.
@wking
README: Define a 1.2.0 filesystem schema for release signatures
9e9e97c 
I'm not actually consuming this new structure in Git, so the 'version'
file remains at 1.1.0.  But we're defining it here because:

* We want a versioned schema for passing signature data from oc-mirror
  and other graph-data image producers through to Cincinnati (for
  locally run update services [1]),
* We might decide to version-control signatures in the future, and
* We wanted to avoid the overhead of having one versioned filesystem
  API for Git-to-Cincinnati and another for
  oc-mirror-graph-data-images-to-Cincinnati.

[1]: https://issues.redhat.com/browse/OTA-949
@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Apr 19, 2023
@openshift-ci-robot
Copy link

openshift-ci-robot commented Apr 19, 2023 •
edited by openshift-ci bot
Loading

@wking: This pull request references OTA-949 which is a valid jira issue.

Details

In response to this:

I'm not actually consuming this new structure in Git, so the version file remains at 1.1.0. But we're defining it here because:

  • We want a versioned schema for passing signature data from oc-mirror and other graph-data image producers through to Cincinnati (for locally run update services),
  • We might decide to version-control signatures in the future, and
  • We wanted to avoid the overhead of having one versioned filesystem API for Git-to-Cincinnati and another for oc-mirror-graph-data-images-to-Cincinnati.

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.

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 19, 2023
LalatenduMohanty
LalatenduMohanty approved these changes Apr 19, 2023
View reviewed changes
Copy link
Member

@LalatenduMohanty LalatenduMohanty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Apr 19, 2023
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Apr 19, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: LalatenduMohanty, wking

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:
  • OWNERS [LalatenduMohanty,wking]

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

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Apr 19, 2023

@wking: all tests passed!

Full PR test history. Your PR dashboard.

Details

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. I understand the commands that are listed here.

@openshift-merge-robot openshift-merge-robot merged commit 4e2481b into openshift:master Apr 19, 2023
@wking wking deleted the signatures branch April 19, 2023 21:18
wking added a commit to wking/cincinnati-operator that referenced this pull request Oct 3, 2023
@wking
controllers: Add metadata container and Route
6a5633a 
Catching up with openshift/cincinnati@efe98dcbbbc6 (add
metadata-helper deployments, 2023-07-18, openshift/cincinnati#816),
allowing users to retrieve signatures from the metadata Route.  For
signatures provided via the graph-data image, this will provide a more
convenient access than pushing signature ConfigMaps to individual
clusters.  [1] is in flight with a proposed mechanism to configure
clusters to consume this signature-metadata endpoint.

I'm using the multi-arch 4.13.0 as the example release for signatures:

  $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=stable-4.13&arch=multi' | jq -r '.nodes[] | select(.version == "4.13.0").payload'
  quay.io/openshift-release-dev/ocp-release@sha256:beda83fb057e328d6f94f8415382350ca3ddf99bb9094e262184e0f127810ce0

The signature location in the graph-data image is defined in
openshift/cincinnati-graph-data@9e9e97cf2a (README: Define a 1.2.0
filesystem schema for release signatures, 2023-04-19,
openshift/cincinnati-graph-data#3509).

[1]: openshift/enhancements#1485
wking added a commit to wking/cincinnati-operator that referenced this pull request Oct 3, 2023
@wking
controllers: Add metadata container and Route
6e91a2b 
Catching up with openshift/cincinnati@efe98dcbbbc6 (add
metadata-helper deployments, 2023-07-18, openshift/cincinnati#816),
allowing users to retrieve signatures from the metadata Route.  For
signatures provided via the graph-data image, this will provide a more
convenient access than pushing signature ConfigMaps to individual
clusters.  [1] is in flight with a proposed mechanism to configure
clusters to consume this signature-metadata endpoint.

I'm using the multi-arch 4.13.0 as the example release for signatures:

  $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=stable-4.13&arch=multi' | jq -r '.nodes[] | select(.version == "4.13.0").payload'
  quay.io/openshift-release-dev/ocp-release@sha256:beda83fb057e328d6f94f8415382350ca3ddf99bb9094e262184e0f127810ce0

The signature location in the graph-data image is defined in
openshift/cincinnati-graph-data@9e9e97cf2a (README: Define a 1.2.0
filesystem schema for release signatures, 2023-04-19,
openshift/cincinnati-graph-data#3509).

[1]: openshift/enhancements#1485
wking added a commit to wking/cincinnati-operator that referenced this pull request Oct 10, 2023
@wking
controllers: Add metadata container and Route
35a15d5 
Catching up with openshift/cincinnati@efe98dcbbbc6 (add
metadata-helper deployments, 2023-07-18, openshift/cincinnati#816),
allowing users to retrieve signatures from the metadata Route.  For
signatures provided via the graph-data image, this will provide a more
convenient access than pushing signature ConfigMaps to individual
clusters.  [1] is in flight with a proposed mechanism to configure
clusters to consume this signature-metadata endpoint.

I'm using the multi-arch 4.13.0 as the example release for signatures:

  $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=stable-4.13&arch=multi' | jq -r '.nodes[] | select(.version == "4.13.0").payload'
  quay.io/openshift-release-dev/ocp-release@sha256:beda83fb057e328d6f94f8415382350ca3ddf99bb9094e262184e0f127810ce0

The signature location in the graph-data image is defined in
openshift/cincinnati-graph-data@9e9e97cf2a (README: Define a 1.2.0
filesystem schema for release signatures, 2023-04-19,
openshift/cincinnati-graph-data#3509).

[1]: openshift/enhancements#1485
wking added a commit to wking/cincinnati-operator that referenced this pull request Nov 7, 2023
@wking
controllers: Add metadata container and Route
a43a5a4 
Catching up with openshift/cincinnati@efe98dcbbbc6 (add
metadata-helper deployments, 2023-07-18, openshift/cincinnati#816),
allowing users to retrieve signatures from the metadata Route.  For
signatures provided via the graph-data image, this will provide a more
convenient access than pushing signature ConfigMaps to individual
clusters.  [1] is in flight with a proposed mechanism to configure
clusters to consume this signature-metadata endpoint.

I'm using the multi-arch 4.13.0 as the example release for signatures:

  $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=stable-4.13&arch=multi' | jq -r '.nodes[] | select(.version == "4.13.0").payload'
  quay.io/openshift-release-dev/ocp-release@sha256:beda83fb057e328d6f94f8415382350ca3ddf99bb9094e262184e0f127810ce0

The signature location in the graph-data image is defined in
openshift/cincinnati-graph-data@9e9e97cf2a (README: Define a 1.2.0
filesystem schema for release signatures, 2023-04-19,
openshift/cincinnati-graph-data#3509).

The GRAPH_DATA local check consumes openshift/release@23d93465e8
(ci-operator/config/openshift/cincinnati-operator:
operator-e2e-old-ocp-published-graph-data, etc., 2023-11-02,
openshift/release#45245), which sets that variable for the
operator-e2e-hypershift-local-graph-data presubmit which consumes the
graph-data image built from dev/Dockerfile (where we inject the
signature we're testing for).  The other end-to-end tests will consume
external graph-data images (built by cincinnati-graph-data
postsubmits), have GRAPH_DATA unset, and expect '404 Not Found' for
requests for that signature.

[1]: openshift/enhancements#1485
wking added a commit to wking/cincinnati-operator that referenced this pull request Nov 7, 2023
@wking
controllers: Add metadata container and Route
72dbdd2 
Catching up with openshift/cincinnati@efe98dcbbbc6 (add
metadata-helper deployments, 2023-07-18, openshift/cincinnati#816),
allowing users to retrieve signatures from the metadata Route.  For
signatures provided via the graph-data image, this will provide a more
convenient access than pushing signature ConfigMaps to individual
clusters.  [1] is in flight with a proposed mechanism to configure
clusters to consume this signature-metadata endpoint.

I'm using the multi-arch 4.13.0 as the example release for signatures:

  $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=stable-4.13&arch=multi' | jq -r '.nodes[] | select(.version == "4.13.0").payload'
  quay.io/openshift-release-dev/ocp-release@sha256:beda83fb057e328d6f94f8415382350ca3ddf99bb9094e262184e0f127810ce0

The signature location in the graph-data image is defined in
openshift/cincinnati-graph-data@9e9e97cf2a (README: Define a 1.2.0
filesystem schema for release signatures, 2023-04-19,
openshift/cincinnati-graph-data#3509).

The GRAPH_DATA local check consumes openshift/release@23d93465e8
(ci-operator/config/openshift/cincinnati-operator:
operator-e2e-old-ocp-published-graph-data, etc., 2023-11-02,
openshift/release#45245), which sets that variable for the
operator-e2e-hypershift-local-graph-data presubmit which consumes the
graph-data image built from dev/Dockerfile (where we inject the
signature we're testing for).  The other end-to-end tests will consume
external graph-data images (built by cincinnati-graph-data
postsubmits), have GRAPH_DATA unset, and expect '404 Not Found' for
requests for that signature.

[1]: openshift/enhancements#1485
wking added a commit to wking/cincinnati that referenced this pull request Nov 7, 2023
@wking
openshift_secondary_metadata_parser: Support graph-data 1.2.0
0a5a84a 
openshift/cincinnati-graph-data@9e9e97cf2a (OTA-949: README: Define a
1.2.0 filesystem schema for release signatures, 2023-04-19,
openshift/cincinnati-graph-data#3509) defined that graph-data version,
adding only:

  signatures/{algorithm}/{digest}/signature-{number}

Cincinnati learned how to process those paths already in fb20669
(add signatures serving module to metadata_helper, 2023-06-26, openshift#794).
This commit just catches up the supported-version set, to avoid
failing like [1]:

  $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_cincinnati-operator/176/pull-ci-openshift-cincinnati-operator-master-operator-e2e-hypershift-local-graph-data/1722001220597452800/artifacts/operator-e2e-hypershift-local-graph-data/e2e-test/artifacts/inspect/namespaces/openshift-updateservice/pods/example-5cd78cdf8b-vqcgv/graph-builder/graph-builder/logs/current.log | tail -n3
  2023-11-07T21:50:33.646877602Z [2023-11-07T21:50:33Z TRACE cincinnati::plugins] Running next plugin 'openshift-secondary-metadata-parse'
  2023-11-07T21:50:33.657154577Z [2023-11-07T21:50:33Z ERROR graph_builder::graph] unrecognized graph-data version 1.2.0
  2023-11-07T21:50:33.657154577Z     ; supported versions: ["1.0.0", "1.1.0"]

when run against graph-data that declares itself to use the new
version.

[1]: https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_cincinnati-operator/176/pull-ci-openshift-cincinnati-operator-master-operator-e2e-hypershift-local-graph-data/1722001220597452800
@wking wking mentioned this pull request Nov 7, 2023
Merged
wking added a commit to wking/cincinnati-operator that referenced this pull request Nov 7, 2023
@wking
controllers: Add metadata container and Route
2d39a6f 
Catching up with openshift/cincinnati@efe98dcbbbc6 (add
metadata-helper deployments, 2023-07-18, openshift/cincinnati#816),
allowing users to retrieve signatures from the metadata Route.  For
signatures provided via the graph-data image, this will provide a more
convenient access than pushing signature ConfigMaps to individual
clusters.  [1] is in flight with a proposed mechanism to configure
clusters to consume this signature-metadata endpoint.

I'm using the multi-arch 4.13.0 as the example release for signatures:

  $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=stable-4.13&arch=multi' | jq -r '.nodes[] | select(.version == "4.13.0").payload'
  quay.io/openshift-release-dev/ocp-release@sha256:beda83fb057e328d6f94f8415382350ca3ddf99bb9094e262184e0f127810ce0

The signature location in the graph-data image is defined in
openshift/cincinnati-graph-data@9e9e97cf2a (README: Define a 1.2.0
filesystem schema for release signatures, 2023-04-19,
openshift/cincinnati-graph-data#3509).

The GRAPH_DATA local check consumes openshift/release@23d93465e8
(ci-operator/config/openshift/cincinnati-operator:
operator-e2e-old-ocp-published-graph-data, etc., 2023-11-02,
openshift/release#45245), which sets that variable for the
operator-e2e-hypershift-local-graph-data presubmit which consumes the
graph-data image built from dev/Dockerfile (where we inject the
signature we're testing for).  The other end-to-end tests will consume
external graph-data images (built by cincinnati-graph-data
postsubmits), have GRAPH_DATA unset, and expect '404 Not Found' for
requests for that signature.

[1]: openshift/enhancements#1485
wking added a commit to wking/cincinnati-operator that referenced this pull request Nov 7, 2023
@wking
controllers: Add metadata container and Route
405b732 
Catching up with openshift/cincinnati@efe98dcbbbc6 (add
metadata-helper deployments, 2023-07-18, openshift/cincinnati#816),
allowing users to retrieve signatures from the metadata Route.  For
signatures provided via the graph-data image, this will provide a more
convenient access than pushing signature ConfigMaps to individual
clusters.  [1] is in flight with a proposed mechanism to configure
clusters to consume this signature-metadata endpoint.

I'm using the multi-arch 4.13.0 as the example release for signatures:

  $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=stable-4.13&arch=multi' | jq -r '.nodes[] | select(.version == "4.13.0").payload'
  quay.io/openshift-release-dev/ocp-release@sha256:beda83fb057e328d6f94f8415382350ca3ddf99bb9094e262184e0f127810ce0

The signature location in the graph-data image is defined in
openshift/cincinnati-graph-data@9e9e97cf2a (README: Define a 1.2.0
filesystem schema for release signatures, 2023-04-19,
openshift/cincinnati-graph-data#3509).

The GRAPH_DATA local check consumes openshift/release@23d93465e8
(ci-operator/config/openshift/cincinnati-operator:
operator-e2e-old-ocp-published-graph-data, etc., 2023-11-02,
openshift/release#45245), which sets that variable for the
operator-e2e-hypershift-local-graph-data presubmit which consumes the
graph-data image built from dev/Dockerfile (where we inject the
signature we're testing for).  The other end-to-end tests will consume
external graph-data images (built by cincinnati-graph-data
postsubmits), have GRAPH_DATA unset, and expect '404 Not Found' for
requests for that signature.

[1]: openshift/enhancements#1485
wking added a commit to wking/cincinnati-operator that referenced this pull request Nov 8, 2023
@wking
controllers: Add metadata container and Route
1102d7a 
Catching up with openshift/cincinnati@efe98dcbbbc6 (add
metadata-helper deployments, 2023-07-18, openshift/cincinnati#816),
allowing users to retrieve signatures from the metadata Route.  For
signatures provided via the graph-data image, this will provide a more
convenient access than pushing signature ConfigMaps to individual
clusters.  [1] is in flight with a proposed mechanism to configure
clusters to consume this signature-metadata endpoint.

I'm using the multi-arch 4.13.0 as the example release for signatures:

  $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=stable-4.13&arch=multi' | jq -r '.nodes[] | select(.version == "4.13.0").payload'
  quay.io/openshift-release-dev/ocp-release@sha256:beda83fb057e328d6f94f8415382350ca3ddf99bb9094e262184e0f127810ce0

The signature location in the graph-data image is defined in
openshift/cincinnati-graph-data@9e9e97cf2a (README: Define a 1.2.0
filesystem schema for release signatures, 2023-04-19,
openshift/cincinnati-graph-data#3509).

The GRAPH_DATA local check consumes openshift/release@23d93465e8
(ci-operator/config/openshift/cincinnati-operator:
operator-e2e-old-ocp-published-graph-data, etc., 2023-11-02,
openshift/release#45245), which sets that variable for the
operator-e2e-hypershift-local-graph-data presubmit which consumes the
graph-data image built from dev/Dockerfile (where we inject the
signature we're testing for).  The other end-to-end tests will consume
external graph-data images (built by cincinnati-graph-data
postsubmits), have GRAPH_DATA unset, and expect '404 Not Found' for
requests for that signature.

[1]: openshift/enhancements#1485
wking added a commit to wking/cincinnati-operator that referenced this pull request Nov 8, 2023
@wking
controllers: Add metadata container and Route
3c5fcfc 
Catching up with openshift/cincinnati@efe98dcbbbc6 (add
metadata-helper deployments, 2023-07-18, openshift/cincinnati#816),
allowing users to retrieve signatures from the metadata Route.  For
signatures provided via the graph-data image, this will provide a more
convenient access than pushing signature ConfigMaps to individual
clusters.  [1] is in flight with a proposed mechanism to configure
clusters to consume this signature-metadata endpoint.

I'm using the multi-arch 4.13.0 as the example release for signatures:

  $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=stable-4.13&arch=multi' | jq -r '.nodes[] | select(.version == "4.13.0").payload'
  quay.io/openshift-release-dev/ocp-release@sha256:beda83fb057e328d6f94f8415382350ca3ddf99bb9094e262184e0f127810ce0

The signature location in the graph-data image is defined in
openshift/cincinnati-graph-data@9e9e97cf2a (README: Define a 1.2.0
filesystem schema for release signatures, 2023-04-19,
openshift/cincinnati-graph-data#3509).

The GRAPH_DATA local check consumes openshift/release@23d93465e8
(ci-operator/config/openshift/cincinnati-operator:
operator-e2e-old-ocp-published-graph-data, etc., 2023-11-02,
openshift/release#45245), which sets that variable for the
operator-e2e-hypershift-local-graph-data presubmit which consumes the
graph-data image built from dev/Dockerfile (where we inject the
signature we're testing for).  The other end-to-end tests will consume
external graph-data images (built by cincinnati-graph-data
postsubmits), have GRAPH_DATA unset, and expect '404 Not Found' for
requests for that signature.

[1]: openshift/enhancements#1485
wking added a commit to wking/cincinnati-operator that referenced this pull request Nov 9, 2023
@wking
controllers: Add metadata container and Route
425be2f 
Catching up with openshift/cincinnati@efe98dcbbbc6 (add
metadata-helper deployments, 2023-07-18, openshift/cincinnati#816),
allowing users to retrieve signatures from the metadata Route.  For
signatures provided via the graph-data image, this will provide a more
convenient access than pushing signature ConfigMaps to individual
clusters.  [1] is in flight with a proposed mechanism to configure
clusters to consume this signature-metadata endpoint.

I'm using the multi-arch 4.13.0 as the example release for signatures:

  $ curl -s 'https://api.openshift.com/api/upgrades_info/graph?channel=stable-4.13&arch=multi' | jq -r '.nodes[] | select(.version == "4.13.0").payload'
  quay.io/openshift-release-dev/ocp-release@sha256:beda83fb057e328d6f94f8415382350ca3ddf99bb9094e262184e0f127810ce0

The signature location in the graph-data image is defined in
openshift/cincinnati-graph-data@9e9e97cf2a (README: Define a 1.2.0
filesystem schema for release signatures, 2023-04-19,
openshift/cincinnati-graph-data#3509).

The GRAPH_DATA local check consumes openshift/release@23d93465e8
(ci-operator/config/openshift/cincinnati-operator:
operator-e2e-old-ocp-published-graph-data, etc., 2023-11-02,
openshift/release#45245), which sets that variable for the
operator-e2e-hypershift-local-graph-data presubmit which consumes the
graph-data image built from dev/Dockerfile (where we inject the
signature we're testing for).  The other end-to-end tests will consume
external graph-data images (built by cincinnati-graph-data
postsubmits), have GRAPH_DATA unset, and expect '404 Not Found' for
requests for that signature.

[1]: openshift/enhancements#1485
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@PratikMahajan PratikMahajan Awaiting requested review from PratikMahajan

1 more reviewer

@LalatenduMohanty LalatenduMohanty LalatenduMohanty approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

@LalatenduMohanty LalatenduMohanty

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@wking @openshift-ci-robot @LalatenduMohanty @openshift-merge-robot