Helm: If there are extraLabels add them to all resources #3622
Conversation
This file contains 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
This extends the functionality of `extraLabels` so that, if they are defined, they will be templated for all resources created by the chart. Previously, they were only templated onto the Deployment resource.
They were completely missing previously, labels and extraLabels.
This comment has been minimized.
This comment has been minimized.
|
CI performance tests
|
5 tasks
BrynCooke
approved these changes
Sep 8, 2023
… is now fixed. In addition, logic that would have printed to stderr has been removed, and instead metrics values and attributes that are the wrong type are now silently ignored. Fixes #3687
Metrics attributes were being coerced to strings. This is now fixed. In addition, the logic around types accepted as metrics attributes has been simplified. It will log and ignore values of the wrong type. Fixes #3691
…ally a metric being handled. To make this work metric attributes MUST be declared after the metric value. This is checked via a cheap boolean indicating if we have already ignored attributes upton metric initialization. Fixes #3691
Previously uplink requests created a new reqwest client each time, this may cause CPU spikes especially on OSX. Fixes #3333 <!-- start metadata --> **Checklist** Complete the checklist (and note appropriate exceptions) before a final PR is raised. - [ ] Changes are compatible[^1] - [ ] Documentation[^2] completed - [ ] Performance impact assessed and acceptable - Tests added and passing[^3] - [ ] Unit Tests - [ ] Integration Tests - [ ] Manual Tests **Exceptions** *Note any exceptions here* **Notes** [^1]. It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. [^2]. Configuration is an important part of many changes. Where applicable please try to document configuration examples. [^3]. Tick whichever testing boxes are applicable. If you are adding Manual Tests: - please document the manual testing (extensively) in the Exceptions. - please raise a separate issue to automate the test and label it (or ask for it to be labeled) as `manual test` Co-authored-by: bryn <[email protected]>
[](https://renovatebot.com) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [router-bridge](https://www.apollographql.com/apollo-federation/) ([source](https://togithub.com/apollographql/federation)) | dependencies | patch | `=0.5.3+v2.5.3` -> `=0.5.4+v2.5.3` | --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/apollographql/router). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNi40My4yIiwidXBkYXRlZEluVmVyIjoiMzYuNjguMSIsInRhcmdldEJyYW5jaCI6ImRldiJ9--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com> Co-authored-by: Geoffroy Couprie <[email protected]>
Co-authored-by: Maria Elisabeth Schreiber <[email protected]> Co-authored-by: Edward Huang <[email protected]>
Metrics attributes were being coerced to strings. This is now fixed. In addition, the logic around types accepted as metrics attributes has been simplified. It will log and ignore values of the wrong type. Fixes: #3687 <!-- start metadata --> **Checklist** Complete the checklist (and note appropriate exceptions) before a final PR is raised. - [ ] Changes are compatible[^1] - [ ] Documentation[^2] completed - [ ] Performance impact assessed and acceptable - Tests added and passing[^3] - [ ] Unit Tests - [ ] Integration Tests - [ ] Manual Tests **Exceptions** *Note any exceptions here* **Notes** [^1]. It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. [^2]. Configuration is an important part of many changes. Where applicable please try to document configuration examples. [^3]. Tick whichever testing boxes are applicable. If you are adding Manual Tests: - please document the manual testing (extensively) in the Exceptions. - please raise a separate issue to automate the test and label it (or ask for it to be labeled) as `manual test` --------- Co-authored-by: bryn <[email protected]>
Update rust toolchain to 1.72.0
Fix #3554 This creates a new metric recorded only if we set the configuration option `telemetry.metrics.common.experimental_cache_metrics.enabled` to `true`. * `apollo.router.operations.entity` (histogram): cache hit ratio per subgraph and entity type This simulates an entity cache to find out if it would be useful. Each time we do a subgraph query, we use as cache key: - subgraph name - entity type - query - vary headers - entity key We record if we have seen this entity before (using a bloom filter) and calculate the cache hit ratio for that query, per subgraph and entity type. --------- Signed-off-by: Benjamin Coenen <[email protected]> Co-authored-by: Benjamin Coenen <[email protected]>
there was always one additional clone before, even when the entity was used in only one place. In local benchmarks, I could see this remove 200μs from a query
The crate is unmaintained, and the standard library has equivalent functionality since Rust 1.70.0 * https://github.com/apollographql/router/security/dependabot/68 * https://doc.rust-lang.org/stable/std/io/trait.IsTerminal.html Co-authored-by: Geoffroy Couprie <[email protected]>
Currently apollo metrics may have the same metadata between multiple
routers. This means that we can't disambiguate when multiple routers are
sending data.
Add a random UUID to the metadata.
This has no user facing impact.
Note: there is no unit test or integration test for this. We need to
take a broader look at how we do telemetry testing, and the solution
should probably involve otel collector. However that is beyond the scope
of this ticket.
<!-- start metadata -->
**Checklist**
Complete the checklist (and note appropriate exceptions) before a final
PR is raised.
- [ ] Changes are compatible[^1]
- [ ] Documentation[^2] completed
- [ ] Performance impact assessed and acceptable
- Tests added and passing[^3]
- [ ] Unit Tests
- [ ] Integration Tests
- [ ] Manual Tests
**Exceptions**
*Note any exceptions here*
**Notes**
[^1]. It may be appropriate to bring upcoming changes to the attention
of other (impacted) groups. Please endeavour to do this before seeking
PR approval. The mechanism for doing this will vary considerably, so use
your judgement as to how and when to do this.
[^2]. Configuration is an important part of many changes. Where
applicable please try to document configuration examples.
[^3]. Tick whichever testing boxes are applicable. If you are adding
Manual Tests:
- please document the manual testing (extensively) in the Exceptions.
- please raise a separate issue to automate the test and label it (or
ask for it to be labeled) as `manual test`
---------
Co-authored-by: bryn <[email protected]>
Co-authored-by: Brandt Kinzle <[email protected]>
…s it's documented (#3773) `subscription.enable_deduplication` was documented to be `true` by default but it wasn't really the case. --------- Signed-off-by: Benjamin Coenen <[email protected]> Co-authored-by: Jeremy Lempereur <[email protected]>
This adds logging for query validation errors with either Rust or JS
when there is a mismatch, i.e. one of them validates but the other does
not. In other cases we are not really interested in the specific error
(it will just go back to the user), so we don't need to log there.
To log the Rust validation error well, I now store the ApolloDiagnostics
that were produced on `Query{}`. `Query` is serializable for caching,
but ApolloDiagnostic is not. Here I just skipped serializing
`ApolloDiagnostic` so if `Query` is loaded from cache, it does not have
the validation error stored. I'm not sure this is the right thing to do.
The ApolloDiagnostics are later used after query planning (which may
produce a JS validation error). So it's correct if we can ~safely assume
that we only have valid Query instances cached. Otherwise we might get
spurious error logs from this.
- [ ] So is that a safe assumption? Reading the CachingQueryPlanner
implementation I think it does only store errors (then it's not a
`Query` instance) and fully successful planning (then it has run both
Rust and JS validation already). So it looks fine, but it could be a bit
brittle to rely on this.
I also simplified the validation error printing which
- [x] depends on apollographql/apollo-rs#630.
- [x] and on #3675
<!-- start metadata -->
**Checklist**
Complete the checklist (and note appropriate exceptions) before a final
PR is raised.
- [ ] Changes are compatible[^1]
- [ ] Documentation[^2] completed
- [ ] Performance impact assessed and acceptable
- Tests added and passing[^3]
- [ ] Unit Tests
- [ ] Integration Tests
- [ ] Manual Tests
**Exceptions**
*Note any exceptions here*
**Notes**
[^1]. It may be appropriate to bring upcoming changes to the attention
of other (impacted) groups. Please endeavour to do this before seeking
PR approval. The mechanism for doing this will vary considerably, so use
your judgement as to how and when to do this.
[^2]. Configuration is an important part of many changes. Where
applicable please try to document configuration examples.
[^3]. Tick whichever testing boxes are applicable. If you are adding
Manual Tests:
- please document the manual testing (extensively) in the Exceptions.
- please raise a separate issue to automate the test and label it (or
ask for it to be labeled) as `manual test`
Fix typos:
* timout->timeout
* filtered->authorization.filtered
* needs_authenticated->authorization.authenticated
* needs_requires_scopes->authorization.requires_scopes
<!-- start metadata -->
**Checklist**
Complete the checklist (and note appropriate exceptions) before a final
PR is raised.
- [ ] Changes are compatible[^1]
- [ ] Documentation[^2] completed
- [ ] Performance impact assessed and acceptable
- Tests added and passing[^3]
- [ ] Unit Tests
- [ ] Integration Tests
- [ ] Manual Tests
**Exceptions**
*Note any exceptions here*
**Notes**
[^1]. It may be appropriate to bring upcoming changes to the attention
of other (impacted) groups. Please endeavour to do this before seeking
PR approval. The mechanism for doing this will vary considerably, so use
your judgement as to how and when to do this.
[^2]. Configuration is an important part of many changes. Where
applicable please try to document configuration examples.
[^3]. Tick whichever testing boxes are applicable. If you are adding
Manual Tests:
- please document the manual testing (extensively) in the Exceptions.
- please raise a separate issue to automate the test and label it (or
ask for it to be labeled) as `manual test`
Co-authored-by: bryn <[email protected]>
) Followup to #3718, this changeset makes sure we're able to generate the most concrete selection set for a given operation. This means finding the most concrete type we can when we're dealing with interfaces: - If InterfaceA implements InterfaceB, use InterfaceA as current_type to generate an inline fragment's selection set Given the following invariants: ```graphql interface OperationItemStuff implements OperationItem ``` For ```graphql fragment OperationItemFragment on OperationItem { ... on OperationItemStuff { stuff } } ``` The most concrete interface to generate fields for `OperationItemStuff` is not `OperationItem`, so we narrow down the selection to `OperationItemStuff`. The fixes for #3718 still apply, IE: Given the following invariants: ```graphql type Dog implements Animal ``` For ```graphql ...on Animal { id ...on Dog { name } } ``` The most concrete type to generate a selection set for `Dog` is not `Animal`, so we narrow down the selection to `Dog`.
- In Rhai, it is `request[.subgraph].body.extensions`, the example was missing the `.body` - Fix link to rhai example for forwarding headers
Co-authored-by: Coenen Benjamin <[email protected]>
This corrects the CHANGELOG entry for #3586 which inadvertently suggested using `<your_graph_variant>` twice instead of `<your_graph_id>` and (separately) `<your_graph_variant>`: ``` https://studio.apollographql.com/graph/<your_graph_id>/variant/<your_graph_variant>/operations?query=<apollo_operation_id> ``` This doesn't replace the need to document this in #3803. 😄
The documentation for the helm chart will be generated at release time and will include the updated comment.
Good catch. I've updated the comment in the values.yaml file to address the change: a791fdd |
](https://renovatebot.com){kind=link}
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 extends the functionality of
extraLabelsso that, if they are defined, they will be templated for all resources created by the chart.Previously, they were only templated onto the Deployment resource.