-
Notifications
You must be signed in to change notification settings - Fork 60
OTA-915: Serve signatures through a new container #794
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.
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
OTA-915: Serve signatures through a new container #794
Conversation
metadata-helper/src/status.rs
Outdated
| /// | ||
| /// Status: | ||
| /// * Ready (200 code): the application has been initialized and is available to accept connections. | ||
| /// * Not Ready (503 code): no JSON graph available yet. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fuzzy on what app_data.is_ready is actually about, but the blocking issue for serving signatures out of this process is whether the local signature filesystem is present. With init-container data sourcing, that's true from before this container comes up. In a future where one of these containers is trying to poll graph-data image from the registry, it would be true after the first successful retrieval and unpacking. Neither of those are directly about the JSON graph (that graph-builder is serving?).
7ea86b7 to
daeaf26
Compare
daeaf26 to
72cf2c1
Compare
06e62cb to
4083aea
Compare
metadata-helper/src/signatures.rs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
|
Do we plan to address the issues with deps with rust 1.54? If not, should we remove the jobs? If yes, why do we need to support 1.54? :) |
petr-muller
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm very green in reviewing Rust code, so take the comments with a grain of salt and feel free to ignore them, I'm not yet familiar with Rust idioms and accepted practice :)
In general there seems to be quite a lot of duplicate code around the processing of parameters (merging params from cli and config file etc) that stems from how this was apparently created by making a gutted copy of policy-engine. It feels like we could DRY these pieces now when we have two or even three copies of them?
metadata-helper/src/status.rs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a duplicate of policy-engine/src/status.rs, would it make sense to extract these simple probe backends to a helper that would simply take app_data: actix_web::web::Data<AppState> as a parameter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the struct, though it has same name, the struct is a bit different in the packages, thats the reason for duplicate code
19863b4 to
8ac5b48
Compare
00a2769 to
454176f
Compare
|
/retest |
|
@PratikMahajan: The following tests failed, say
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. |
metadata-helper/src/config/cli.rs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fuzzy on details, but Status service options for service and Main service options for status seems like the comments may be flipped here?
|
@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. |
this commit adds a new container to help with serving the signatures. this commits adds all the code required to make the new container work, including liveness/readiness checks, taking user input from CLI and through TOML files. initializing the api and accepting connections.
1fcff3c to
fb20669
Compare
petr-muller
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/hold
I'm not the greatest Rust reviewer ever, hence holding for Trevor or Lala to have a chance if you want them to review. Feel free to unhold at will.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 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 |
| version = "0.1.0" | ||
| authors = ["Pratik Mahajan <pmahajan@redhat.com>"] | ||
| edition = "2021" | ||
| edition = "2018" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it an intentional change?
|
/hold cancel |
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
Exposing the config setting from fb20669 (add signatures serving module to metadata_helper, 2023-05-18, openshift#794) as a command-line option, so folks can pass it though without having to drop into TOML or hitting [1,2]: 2023-11-08T00:01:57.621922383Z [2023-11-08T00:01:57Z INFO metadata_helper] application settings: 2023-11-08T00:01:57.621922383Z AppSettings { 2023-11-08T00:01:57.621922383Z verbosity: Trace, 2023-11-08T00:01:57.621922383Z address: ::, 2023-11-08T00:01:57.621922383Z port: 8082, 2023-11-08T00:01:57.621922383Z path_prefix: "/api/upgrades_info", 2023-11-08T00:01:57.621922383Z status_address: ::, 2023-11-08T00:01:57.621922383Z status_port: 9082, 2023-11-08T00:01:57.621922383Z signatures_dir: "", 2023-11-08T00:01:57.621922383Z tracing_endpoint: None, 2023-11-08T00:01:57.621922383Z backlog: 10, 2023-11-08T00:01:57.621922383Z max_connections: 10, 2023-11-08T00:01:57.621922383Z max_connection_rate: 64, 2023-11-08T00:01:57.621922383Z keep_alive: None, 2023-11-08T00:01:57.621922383Z client_timeout: 5s, 2023-11-08T00:01:57.621922383Z } 2023-11-08T00:01:57.622031074Z [2023-11-08T00:01:57Z INFO metadata_helper] signatures data directory not provided, using /tmp/.tmp2r89fA [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/1722037234359603200 [2]: 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/1722037234359603200/artifacts/operator-e2e-hypershift-local-graph-data/e2e-test/artifacts/inspect/namespaces/openshift-updateservice/pods/example-695fd68b74-wjtv6/metadata/metadata/logs/current.log
This PR adds a new container to serve the signatures.
Signatures should be added to the directory in order to
serve the signatures.
The dir structure should look like
{ALGO}/{DIGEST}/{SIGNATURE}Add this directory to toml file in-order to read the signatures.
In the absence of dir in toml file, it'll create a temp directory and
read from it