OTA-915: fix configs and add signature serving deployment #816
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
openshift-ci
bot
added
the
approved
PratikMahajan
force-pushed
the
serve-sigs
branch
4 times, most recently
from
4989d41 to
ac20664
Compare
PratikMahajan
changed the title
openshift-ci-robot
added
the
jira/valid-reference
|
@PratikMahajan: This pull request references OTA-915 which is a valid jira issue. DetailsIn 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. |
PratikMahajan
force-pushed
the
serve-sigs
branch
2 times, most recently
from
908f5ca to
d122954
Compare
this commit removes the unnecessary imports from the code. Also changes the ports used for metadata-helper as there was a port clash between pe and mh. in tests, changed the type from hyper::Uri to IpAddr::V4 as ipaddress correctly represents the data-type.
removes the unused upstream uri from metadata-helper and modifies the dockerfile to copy the new metadata-helper binary to cincinnati container. Also adds a sample deployment that can be used to deploy the cincinnati stack with metadata-helper container. metadata-helper is an optional container to serve the release signatures.
create a symlink to signatures directory for metadata-helper the secondary metadata scraper creates a temp directory to extract graph-data other containers wont have context of the directory that is being used. signatures symlink is at /signatures in the graph-data directory and will keep updating as newer graph-data is scraped.
PratikMahajan
force-pushed
the
serve-sigs
branch
from
d122954 to
769a051
Compare
petr-muller
approved these changes
Jul 20, 2023
Member
petr-muller
left a comment
petr-muller
left a comment
There was a problem hiding this comment.
/lgtm
/override ci/prow/e2e
We passed all tests but then failed in a post must-gather step
/hold
Holding to allow Lala / Trevor to take a look, but feel free to unhold if you think it is not necessary.
openshift-ci
bot
added
the
do-not-merge/hold
Contributor
|
@petr-muller: Overrode contexts on behalf of petr-muller: ci/prow/e2e DetailsIn 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. |
Member
|
/hold cancel |
openshift-ci
bot
removed
the
do-not-merge/hold
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: LalatenduMohanty, petr-muller, PratikMahajan The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Contributor
|
@PratikMahajan: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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. |
wking
added a commit
to wking/cincinnati-operator
that referenced
this pull request
Oct 3, 2023
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. [1]: openshift/enhancements#1485
wking
added a commit
to wking/cincinnati-operator
that referenced
this pull request
Oct 3, 2023
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. [1]: openshift/enhancements#1485
wking
added a commit
to wking/cincinnati-operator
that referenced
this pull request
Oct 3, 2023
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. [1]: openshift/enhancements#1485
wking
added a commit
to wking/cincinnati-operator
that referenced
this pull request
Oct 3, 2023
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. [1]: openshift/enhancements#1485
wking
added a commit
to wking/cincinnati-operator
that referenced
this pull request
Oct 3, 2023
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. [1]: openshift/enhancements#1485
wking
added a commit
to wking/cincinnati-operator
that referenced
this pull request
Oct 3, 2023
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
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
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
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
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
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
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
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
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
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
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
this PR fixes the existing configs/settings, removes unused imports
and adds a sample deployment yaml that deploys the metadata-helper
container along with graph-builder and policy-engine.
deploying metadata-helper is optional and is used to serve existing signatures