Update README with reliable instructions to start Trustify

I followed the README file and executed cargo run --bin trustd and all the api rest endpoints under /api/v1 has security in place (generate 401) error while the UI didn't receive the proper configuration for initializing the Login flow. Could we update the README with proper commands (specially the PM mode please)

I think it works as expected. The UI gets initialize with auth enabled. However, the embedded OIDC server does not ask for a password. Still, the UI sends a bearer token to the backend. When using the API directly, this must be sent as well.

Thanks for your reply @ctron

I was not aware of the fact that the embedded OIDC does not ask for a password, that explain things. I had a problem with cache but now I can get access to the UI through the server.

I still have one issue, how could I get access to the Swagger UI? I tried http://localhost:8080/openapi and I get the following error:

I also tried http://localhost:8080/swagger-ui/ as stated in the README but it didn't work either. Which is the proper URL for swagger? Or might it be that is is a bug?


headers: Ability to rewrite headers received from upstream cluster

…response
Signed-off-by: Shivanshu Goswami<EMAIL_ADDRESS>Fixes: #12591
Commit Message:
Additional Description:
Risk Level: low
Testing: Added unit tests, performed manual testing
Docs Changes: Added
Release Notes:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]

@ccravens
I am okay with a generic response_headers_to_rewrite API which we can use in out Location rewrite usecase.
@alyssawilk @htuch Your thoughts?
We can have an API which is like this:
oneof header_rewrite_specifier {
    typename1 header_rewrite_string = 1;
    typename2 header_rewrite_regex = 2;
}

Typenames take Header name and rewrite pattern which could be a string or regex

Just went through @ccravens open issue.
responseHeaderPolicy:
            set:
              - name: X-Service-Name
                value: s1
            remove:
              - X-Internal-Secret
            replace:
              - header: location
                regex: \http:\
                value: https:

This kind of API looks better. Will wait for suggestions. This takes care of add/remove as well as modify on response headers.
Wondering if we should introduce this at both Route as well as Virtualhost levels.

We already have API fields to add/remove response headers, so I would discourage introducing a redundant mechanism unless there is a plan to deprecate the existing mechanisms (and have your new scheme apply hierarchically similar to the existing one).

@htuch thanks for your response. I don't think we're requesting to deprecate functionality. I'm aware and using the add / remove functionality. I think we're requesting a feature that addresses a need/requirement that the add/remove functions don't provide. @shivanshu21 let me know if I'm mistaken in that assumption from your side, thanks

@htuch @ccravens If we try to introduce a comprehensive responseHeaderPolicy like the following:
responseHeaderPolicy:
            set:
              - name: X-Service-Name
                value: s1
            remove:
              - X-Internal-Secret
            replace:
              - header: location
                regex: \http:\
                value: https:

We would be adding new options to add/remove header too, and then it would make sense to change existing APIs for add/remove. But looks like that is not what we want to do right now.
Going by what @htuch said, I think it should suffice to have a response_headers_to_rewrite field which can take the name of the header, a value to match and the substitution value. Match can be based on regex as well as a blanket replacement string.
The core idea is that this should be generic for all headers, not just location.

/wait

/wait
Will have to redo the code changes. @htuch @ccravens please take a look at the Proto files for the API changes in the latest commit and let me know if the API is satisfactory.

/wait

ERROR: /build/tmp/_bazel_root/b570b5ccd0454dc9af9f65ab1833764d/external/envoy_api_canonical/envoy/config/route/v3/BUILD:7:18: in proto_library rule @envoy_api_canonical//envoy/config/route/v3:pkg: cycle in dependency graph:
    //tools/protoxform:protoprint
    //tools/type_whisperer:api_type_db.pb_text
    //tools/type_whisperer:api_type_db
    //tools/type_whisperer:api_type_db_target
    @envoy_api_canonical//versioning:active_protos
    @envoy_api_canonical//envoy/config/common/matcher/v3:pkg
.-> @envoy_api_canonical//envoy/config/route/v3:pkg.     <<<<<<<<<<<<<
|   @envoy_api_canonical//envoy/config/accesslog/v3:pkg <<<<<<<<<<<<<
`-- @envoy_api_canonical//envoy/config/route/v3:pkg
This cycle occurred because of a configuration option

@htuch
AccessLogFilter proto refers to route components proto. So there is a cyclic dependency if we refer to AccessLogFilter proto in route components.
I like the idea of and_filter and or_filter. I am gravitating towards duplication as AccessLogFilter anyway does not have a reason to be in Route components. Thinking of introducing a message just like access log filter in route components.

/wait

Concretely, duplicate AccessLogFilter into envoy.type.v3.matcher.RequestMatcher or the like.

Concretely, duplicate AccessLogFilter into envoy.type.v3.matcher.RequestMatcher or the like.

See https://github.com/envoyproxy/envoy/blob/master/api/envoy/config/common/matcher/v3/matcher.proto. This is where I think we really need it to go. The complexity here is every user will not support all matching options. This is what @snowp and @yangminzhu are currently working on.

@mattklein123 @htuch
If @snowp and @yangminzhu are almost done, I can wait. If not, do you think it would make sense to have a separate issue to refactor this code as well as AccessLogFilter once v3.matcher changes are done?

@mattklein123 @htuch
If @snowp and @yangminzhu are almost done, I can wait. If not, do you think it would make sense to have a separate issue to refactor this code as well as AccessLogFilter once v3.matcher changes are done?

For the Matcher API, I think you probably could already use it in this PR now. See the example in https://github.com/envoyproxy/envoy/pull/12964, you can add custom validation and document clearly that only part of the MatchPredicate (e.g. http_request_headers_match) is allowed to use.

For the Matcher API, I think you probably could already use it in this PR now. See the example in #12964, you can add custom validation and document clearly that only part of the MatchPredicate (e.g. http_request_headers_match) is allowed to use.

Yes, that's true. Let's do that please.

For the Matcher API, I think you probably could already use it in this PR now. See the example in #12964, you can add custom validation and document clearly that only part of the MatchPredicate (e.g. http_request_headers_match) is allowed to use.

Yes, that's true. Let's do that please.

Ack. I will make the changes today/tomorrow and send the PR for review.

@mattklein123 @htuch
If @snowp and @yangminzhu are almost done, I can wait. If not, do you think it would make sense to have a separate issue to refactor this code as well as AccessLogFilter once v3.matcher changes are done?

For the Matcher API, I think you probably could already use it in this PR now. See the example in #12964, you can add custom validation and document clearly that only part of the MatchPredicate (e.g. http_request_headers_match) is allowed to use.

Matchers API unfortunately depends on route components for HeaderMatcher.
Again I cannot import it in route components because of the circular dependency.
I am duplicating the Matchers API and focussing on the implementation and writing test cases for now. We can discuss refactoring solutions meanwhile.

I am duplicating the Matchers API and focussing on the implementation and writing test cases for now. We can discuss refactoring solutions meanwhile.

HeaderMatcher needs to be moved into a dedicated proto. I know we have dealt with this before. @htuch and @lizan can advise. Thank you for working through this!

Yeah, I think HeaderMatcher needs to go to envoy.type.v3.matcher as well. It also should switch to using StringMatcher internally at the same time, as per the [#next-major-version:  comment.

Yeah, I think HeaderMatcher needs to go to envoy.type.v3.matcher as well. It also should switch to using StringMatcher internally at the same time, as per the [#next-major-version:  comment.

I will move header matcher as a part of this and update its references in code.
The switch to string matcher can happen as a part of a separate PR.

The problem is that the switch to StringMatcher is a breaking change. So, we should do it at the same time as the deprecation.

Manual tests passing
Upstream headers
    w.Header().Set("location", "/itm/1234567890")
    w.Header().Set("x-envoy-abc", "/itm/00001111")
    w.Header().Set("x-envoy-def", "/itm/00001111")
    w.Header().Set("x-envoy-ghi", "/itm/")
    w.Header().Set("x-envoy-jkl", "")

Response from envoy
root@17aeaa91cb6c:/source# curl -v http://<IP_ADDRESS>:10000/
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 10000 (#0)
> GET / HTTP/1.1
> Host: <IP_ADDRESS>:10000
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< date: Wed, 23 Sep 2020 08:01:41 GMT
< content-length: 203
< content-type: text/plain; charset=utf-8
< x-envoy-upstream-service-time: 1001
< location: /n/error/1234567890
< x-envoy-abc: /n/00001111
< x-envoy-def: /sch/00001111
< x-envoy-ghi: abcd
< x-envoy-jkl: pqrs
< server: envoy

Envoy config
                                                "response_headers_to_rewrite": [
                                                 {
                                                    "header_name": "location",
                                                    "match_and_rewrite": {
                                                        "value_rewrite_literal": {
                                                            "string_match": {
                                                                "prefix": "/itm/"
                                                            },
                                                            "substitution": "/n/error/"
                                                        }
                                                    }
                                                },
                                                {
                                                    "header_name": "x-envoy-abc",
                                                    "match_and_rewrite": {
                                                        "value_rewrite_literal": {
                                                            "string_match": {
                                                                "prefix": "/itm/"
                                                            },
                                                            "substitution": "/n/"
                                                        }
                                                    }
                                                },
                                                {
                                                    "header_name": "x-envoy-def",
                                                    "match_and_rewrite": {
                                                        "value_rewrite_literal": {
                                                            "string_match": {
                                                                "prefix": "/itm/"
                                                            },
                                                            "substitution": "/sch/"
                                                        }
                                                    }
                                                },
                                                {
                                                    "header_name": "x-envoy-ghi",
                                                    "match_and_rewrite": {
                                                        "value_rewrite_literal": {
                                                            "string_match": {
                                                                "exact": "/itm/"
                                                            },
                                                            "substitution": "abcd"
                                                        }
                                                    }
                                                },
                                                {
                                                    "header_name": "x-envoy-jkl",
                                                    "match_and_rewrite": {
                                                        "value_rewrite_literal": {
                                                            "string_match": {
                                                                "exact": ""
                                                            },
                                                            "substitution": "pqrs"
                                                        }
                                                    }
                                                }

/wait

Basic case working with match predicate
root@d0d6f45e8147:~#
root@d0d6f45e8147:~# curl -sv <IP_ADDRESS>:10000
* Rebuilt URL to: <IP_ADDRESS>:10000/
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 10000 (#0)
> GET / HTTP/1.1
> Host: <IP_ADDRESS>:10000
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< x-envoy-abc: /itm/00001111
< x-envoy-def: /itm/00002222
< x-envoy-ghi: /itm/
< x-envoy-jkl:
< date: Mon, 12 Oct 2020 23:59:01 GMT
< content-length: 203
< content-type: text/plain; charset=utf-8
< x-envoy-upstream-service-time: 1001
< location: /n/error/1234567890 <<<<<<<<<<<<<<<<<<<<< Rewritten
< server: envoy
<
Accept : [*/*]
Content-Length : [0]
User-Agent : [curl/7.58.0]
X-Envoy-Expected-Rq-Timeout-Ms : [15000]
X-Forwarded-Proto : [http]
X-Request-Id : [6f711d1d-6fd2-43ca-965d-0d815ac2b098]
* Connection #0 to host <IP_ADDRESS> left intact
root@d0d6f45e8147:~#

                                                "response_headers_to_rewrite": [
                                                {
                                                    "header_name": "location",
                                                    "match_and_rewrite": {
                                                        "value_rewrite_literal": {
                                                            "string_match": {
                                                                "prefix": "/itm/"
                                                            },
                                                            "substitution": "/n/error/"
                                                        },
                                                        "response_match_criteria": { <<<<<<<<<<<<<<<<<
                                                            "or_match": {
                                                                "rules": [
                                                                    {
                                                                    "http_response_headers_match": {
                                                                        "headers": [{
                                                                            "name": "x-envoy-abc",
                                                                            "pattern": {
                                                                                "exact": "/itm/00001111"
                                                                            },
                                                                            "invert_match": false
                                                                        }]
                                                                    }
                                                                    },
                                                                    {
                                                                    "http_response_headers_match": {
                                                                        "headers": [{
                                                                            "name": "x-envoy-def",
                                                                            "pattern": {
                                                                                "exact": "/itm/00001111"
                                                                            },
                                                                            "invert_match": false
                                                                        }]
                                                                    }
                                                                    }
                                                                ]
                                                            }
                                                        }
                                                    }
                                                }
                                                ]

Todo
1. Integration and unit tests
2. Seeing a few crashes so trying to resolve them

Unit test passing
root@d0d6f45e8147:/source# bazel test //test/common/router:config_impl_test --test_env=ENVOY_IP_TEST_VERSIONS=v4only
INFO: Analyzed target //test/common/router:config_impl_test (2 packages loaded, 82 targets configured).
INFO: Found 1 test target...
Target //test/common/router:config_impl_test up-to-date:
  bazel-bin/test/common/router/config_impl_test
INFO: Elapsed time: 114.806s, Critical Path: 113.99s
INFO: 3 processes: 3 processwrapper-sandbox.
INFO: Build completed successfully, 4 total actions
//test/common/router:config_impl_test                                    PASSED in 11.3s

Executed 1 out of 1 test: 1 test passes.
INFO: Build completed successfully, 4 total actions
root@d0d6f45e8147:/source#

PR is complete and tested thoroughly. I will address the comments and respond.

@htuch PTAL.
root@d0d6f45e8147:/source# bazel test //test/common/router:config_impl_test --test_env=ENVOY_IP_TEST_VERSIONS=v4only
INFO: Analyzed target //test/common/router:config_impl_test (0 packages loaded, 0 targets configured).
INFO: Found 1 test target...
Target //test/common/router:config_impl_test up-to-date:
  bazel-bin/test/common/router/config_impl_test
INFO: Elapsed time: 113.505s, Critical Path: 113.13s
INFO: 3 processes: 3 processwrapper-sandbox.
INFO: Build completed successfully, 4 total actions
//test/common/router:config_impl_test                                    PASSED in 11.4s
Executed 1 out of 1 test: 1 test passes.
INFO: Build completed successfully, 4 total actions
root@d0d6f45e8147:/source#

@shivanshu21 I'll give this a review now, but please try avoid force pushes, as they make it hard to track deltas during review.

#13926  is merged. I will use that predicate API for this PR.

Just curios why was the closed? Is it still planned to support response header rewriting eventually?


[Impeller] Linux_pixel_7pro animated_advanced_blend_perf__timeline_summary is very flaky

The runs on 2/3d's of the past 100 commits have flaked: https://ci.chromium.org/ui/p/flutter/builders/luci.flutter.staging/Linux_pixel_7pro animated_advanced_blend_perf__timeline_summary
It appears to be crashing in the GL driver, but this benchmarks should not be using the GL backend, so I'm guessing something is going wrong with the logic or cleanup in https://github.com/flutter/flutter/blob/master/dev/devicelab/lib/tasks/perf_tests.dart#L1309.
cc @jonahwilliams

So the first commit where it started crashing was:
https://flutter.googlesource.com/mirrors/flutter/+/1333e16a4a1237fcc026dac844a29e4566368fa8
So that is probably "stencil buffer record/replay instead of MSAA storage". We should check if we can repro locally. The big change from that commit is the benchmark is running a lot faster, which in theory could trigger other bugs - but it could also have to do with the transient stencil changes too.

This test is no longer flaky. I suspect when @jason-simmons  rolled the vulkan deps and fixed the queue submit validation error this problem went away, the timing seems approximately correct


Monitoring Query fails periodically.

When the UI loads it makes 2 query requests when it loads the cluster page to the clustermonitorgraphs resources. It gets a 500 with the following payload:
{"filters":{"resourceType":"cluster","clusterId":"c-8h7s5"},"metricParams":{},"interval":"5s","isDetails":true,"from":"now-5s","to":"now"}
There have been some 500s where it gets an error that monitoring server might not be available. This isn't the case as the graphana graphs are still available, and a second call a moment later succeeds. There is no restarting pods.
This has been observed in clusters between 500-1000 nodes. The monitoring server is pinned to a dedicated n1-standard-8 node.

 Regarding UI issue is it sending too many requests to backend. I see no change in the interval of the query nor the data transmitted. I don't notice changes in how / where we query.
I compared against v2.2.3-rc6 (before the merge/fix) and see no changes. Further, I do not see us trying to query before monitoring is enabled/ready. I must be missing something - could you help me identify what I am missing?

@davidnuzik
There is a isMonitoringReady function in UI. The old logic will re-evaluate when conditions filed on cluster changed. However, we only cares about MonitoringEnabled condition in conditions filed.
When isMonitoringReady status changed, UI will send requests to backend.
In some setup, the conditions fields on cluster object keep updating sometimes.
But MonitoringEnabled condition didn't change at all.
We should not send the requests in this case

Thanks @loganhz I had misunderstood I for some reason was thinking we were doing something to decrease load such as upping the refresh interval. I understand now.

Version: Master (v2.3) (5/8/19)
I still observe that when we load the cluster dashboard page we make 2 query requests to clustermonitorgraphs but now, we no longer get 503 errors. The queries only start when monitoring is ready. I have tested this several times in order too try to reproduce the issue but no longer can. I can also disable monitoring, watch this page, and still avoid 503 or other errors upon the query. I can re-enable again, still watching the dashboard page and not observe and HTTP errors.
I do observe an unrelated error with HTTP 503 at https://RANCHERSERVER/k8s/clusters/c-zwvbx/api/v1/namespaces/cattle-prometheus/services/http:access-grafana:80/proxy/api/search
With the following console error:
Uncaught (in promise) {body: {…}, status: 503, statusText: "", headers: u}

Promise.then (async) |   |
-- | -- | --
  | r | @ | backburner.js:26
  | n._scheduleAutorun | @ | backburner.js:1227
  | n._end | @ | backburner.js:1021
  | _boundAutorunEnd | @ | backburner.js:653
  | Promise.then (async) |   |
  | r | @ | backburner.js:26
  | n._scheduleAutorun | @ | backburner.js:1227
  | n._end | @ | backburner.js:1021
  | _boundAutorunEnd | @ | backburner.js:653
  | Promise.then (async) |   |
  | r | @ | backburner.js:26
  | n._scheduleAutorun | @ | backburner.js:1227
  | n._end | @ | backburner.js:1021
  | _boundAutorunEnd | @ | backburner.js:653
  | Promise.then (async) |   |
  | r | @ | backburner.js:26
  | n._scheduleAutorun | @ | backburner.js:1227
  | n._end | @ | backburner.js:1021
  | _boundAutorunEnd | @ | backburner.js:653
  | Promise.then (async) |   |
  | r | @ | backburner.js:26
  | n._scheduleAutorun | @ | backburner.js:1227
  | n._end | @ | backburner.js:1021
  | _boundAutorunEnd | @ | backburner.js:653
  | Promise.then (async) |   |
  | r | @ | backburner.js:26
  | n._scheduleAutorun | @ | backburner.js:1227
  | n._end | @ | backburner.js:1021
  | _boundAutorunEnd | @ | backburner.js:653
  | Promise.then (async) |   |
  | r | @ | backburner.js:26
  | n._scheduleAutorun | @ | backburner.js:1227
  | n._end | @ | backburner.js:1021
  | _boundAutorunEnd | @ | backburner.js:653
  | Promise.then (async) |   |
  | r | @ | backburner.js:26
  | n._scheduleAutorun | @ | backburner.js:1227
  | n._end | @ | backburner.js:1021
  | _boundAutorunEnd | @ | backburner.js:653
  | Promise.then (async) |   |
  | r | @ | backburner.js:26
  | n._scheduleAutorun | @ | backburner.js:1227
  | n._end | @ | backburner.js:1021
  | _boundAutorunEnd | @ | backburner.js:653
  | Promise.then (async) |   |
  | r | @ | backburner.js:26
  | n._scheduleAutorun | @ | backburner.js:1227
  | n._end | @ | backburner.js:1021
  | _boundAutorunEnd | @ | backburner.js:653
  | Promise.then (async) |   |
  | r | @ | backburner.js:26
  | n._scheduleAutorun | @ | backburner.js:1227
  | n._ensureInstance | @ | backburner.js:1218
  | n.schedule | @ | backburner.js:789
  | (anonymous) | @ | rsvp.js:7
  | _ | @ | rsvp.js:445
  | E | @ | rsvp.js:420
  | (anonymous) | @ | rsvp.js:539
  | e.onload | @ | ember-fetch.js:363
  | load (async) |   |
  | (anonymous) | @ | ember-fetch.js:362
  | (anonymous) | @ | rsvp.js:533
  | e | @ | rsvp.js:1041
  | d | @ | ember-fetch.js:361
  | text | @ | ember-fetch.js:380
  | r | @ | fetch.js:31
  | b | @ | rsvp.js:334
  | k | @ | rsvp.js:507
  | C | @ | rsvp.js:493
  | t.invoke | @ | backburner.js:343
  | t.flush | @ | backburner.js:233
  | t.flush | @ | backburner.js:437
  | n._end | @ | backburner.js:1013
  | _boundAutorunEnd | @ | backburner.js:653
  | Promise.then (async) |   |
  | r | @ | backburner.js:26
  | n._scheduleAutorun | @ | backburner.js:1227
  | n._end | @ | backburner.js:1021
  | _boundAutorunEnd | @ | backburner.js:653
  | Promise.then (async) |   |
  | r | @ | backburner.js:26
  | n._scheduleAutorun | @ | backburner.js:1227
  | n._ensureInstance | @ | backburner.js:1218
  | n.schedule | @ | backburner.js:789
  | (anonymous) | @ | rsvp.js:7
  | _ | @ | rsvp.js:445
  | y | @ | rsvp.js:410
  | E | @ | rsvp.js:418
  | (anonymous) | @ | rsvp.js:539
  | o.onload | @ | ember-fetch.js:660
  | load (async) |   |
  | (anonymous) | @ | ember-fetch.js:652
  | (anonymous) | @ | rsvp.js:533
  | e | @ | rsvp.js:1041
  | E | @ | ember-fetch.js:639
  | n | @ | fetch.js:19
  | rawRequest | @ | store.js:288
  | (anonymous) | @ | service.js:75
  | x | @ | metal.js:288
  | t.flush | @ | metal.js:416
  | H | @ | metal.js:856
  | processQueue | @ | subscribe.js:133
  | setInterval (async) |   |
  | subscribeConnected | @ | subscribe.js:241
  | (anonymous) | @ | subscribe.js:79
  | x | @ | metal.js:288
  | trigger | @ | evented.js:114
  | _opened | @ | socket.js:151
  | n._run | @ | backburner.js:1064
  | n._join | @ | backburner.js:1040
  | n.join | @ | backburner.js:759
  | h | @ | index.js:165
  | (anonymous) | @ | index.js:269

I would assume this is something for a separate issue. Would you agree @loganhz ?
This is not related specifically to the clustermonitorgraphs 503 reported in this issue.

@davidnuzik yes, that should be a different issue. UI will start to check if grafana is ready when Prometheus is ready. UI need to call the grafana API to detect if grafana is ready.

Thanks Logan. I consider this issue resolved and validated then. I do not observe HTTP 503 errors when query clustermonitorgraphs any longer. https://github.com/rancher/rancher/issues/19564#issuecomment-490672830
It's possible the issue may stay open as we might test with a many-node cluster later.

I  have tried to reproduce this and have not been successful. I have tried in v2.2.2 (cannot get 503 errors) maybe this is because I need many more nodes or something.

@loganhz Could you comment on the 2 query requests that happen first time you load the page?
We still see this happen.

@davidnuzik thanks
It should be only one request. Submited a PR to fix it

Version: Master (v2.3) (5/20/19)
I can confirm the query happening twice upon initial load of the cluster dashboard is now fixed.
503 errors were not observed refer to my prior comment here https://github.com/rancher/rancher/issues/19564#issuecomment-490969416
The issue may stay open, but is considered resolved from a UI testing standpoint. We may keep it open because we may setup a large 500-1000 node cluster later and test with that.


The summary card component

Document the design of the summary card component, when and how to use it, and the different variants of it that are supported.

Why has Netlify not generated a preview for this?

@fofr Odd, it has but not updated GitHub. Bit flakey, it seems… Anyway: https://deploy-preview-92--bat-design-history.netlify.com


irq: Add extern define to _isr_wrapper

When CONFIG_GEN_IRQ_VECTOR_TABLE and CONFIG_GEN_SW_ISR_TABLE are enabled
the generate IRQ table is trying to reference the _isr_wrapper function.
Add an extern to that to avoid a failure when compiling:
arch/common/isr_tables.c:48:38: error: '_isr_wrapper' undeclared here (not in a function)
Signed-off-by: Carlo Caione<EMAIL_ADDRESS>

should these redundant declarations be removed?

totally.

Also just noting that this symbol, alongside other weird ones deeply buried in the arch code (e.g. _PrepC) should be renamed at some point.

Agree. The problem is that on some architecture (for example ARM64) even _isr_wrapper is misleading and yet this is enforced by zephyr.


Make refman docs pdf accessible?

With the move to artifact installation, each Gurobi_jll artifact actually carries a full set of docs within it.
This could either be

left alone
be deleted on installation, or
could there be a function that somehow opens it in the file browser or a web browser?

(I prefer the last.)

Transferred to Gurobi_jll


HM_Animations

MR Description
Add the new HM_Animations to the PSDKTechnicalDemo.
Before testing
This PR is supposed to be tested in parallel with the MR of the same name: https://gitlab.com/pokemonsdk/pokemonsdk/-/merge_requests/1391
It includes the addition of different graphic and audio files, as well as a new particle file, to allow the new functioning of HMs
List of changes

Add audio and graphics for some HM animation. (new W_Prio, new characters, new transitions, new particles...)
Change all the HM common events to add the script for HM bar animation.
Change the Waterfall common event, the Rock_Climb common event, the Rock_Smash common event and the Whirlpool common event to run the new graphics and particles effects.
Modify Cave map to add the new rock_climb events.

Tests to realize

The new rock_climb event in the cave map.
The new whirlpool particles in the beach map
The new waterfall particles in the river map.

Il y a un problème avec la carte de la cave, cf le screen :

Très étrange, elle apparaît normalement chez moi...
Les assets auraient changés ?
Je vais essayer de regarder à nouveau.


[BugFix] Fix bugs when materialized view with sort keys (#33125)

Fixes #issue
What type of PR is this:

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.2
[ ] 3.1
[ ] 3.0
[ ] 2.5

[FE Incremental Coverage Report]
:disappointed: fail : 36 / 52 (69.23%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMvRefreshProcessor.java
0
12
00.00%
[982, 991, 992, 994, 995, 999, 1000, 1001, 1002, 1003, 1004, 1005]

:large_blue_circle:
com/starrocks/sql/analyzer/MaterializedViewAnalyzer.java
24
28
85.71%
[109, 220, 411, 526]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
8
8
100.00%
[]

:large_blue_circle:
com/starrocks/sql/ast/CreateMaterializedViewStatement.java
3
3
100.00%
[]

:large_blue_circle:
com/starrocks/sql/ast/InsertStmt.java
1
1
100.00%
[]

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[BE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[FE Incremental Coverage Report]
:heart_eyes: pass : 40 / 48 (83.33%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/ast/InsertStmt.java
0
2
00.00%
[180, 181]

:large_blue_circle:
com/starrocks/scheduler/PartitionBasedMvRefreshProcessor.java
3
9
33.33%
[998, 999, 1000, 1001, 1002, 1003]

:large_blue_circle:
com/starrocks/catalog/MaterializedView.java
5
5
100.00%
[]

:large_blue_circle:
com/starrocks/sql/ast/CreateMaterializedViewStatement.java
4
4
100.00%
[]

:large_blue_circle:
com/starrocks/server/LocalMetastore.java
1
1
100.00%
[]

:large_blue_circle:
com/starrocks/sql/analyzer/MaterializedViewAnalyzer.java
27
27
100.00%
[]


Fluent: integrate webchat focus management

Fixes #

Changelog Entry

(Experimental) Added botframework-webchat-fluent-theme package for applying Fluent UI theme to Web Chat, by @compulim and @OEvgeny

Integrated focus management for send box, by @OEvgeny in PR #5150

Removed deprecated useFocusSendBox() hook, please use useFocus('sendBox') instead, by @OEvgeny, in PR #5150
Fixed suggested actions keyboard navigation skips actions after suggested actions got updated, by @OEvgeny, in PR #5150

Description
The PR refactors existing sendbox focus management code to use use-propagate provided hooks and exposes the newly added useRegisterFocusSendBox hook along with SendBoxFocusOptions so that Fluent SendBoxe's focus can be wired-in and managed by WebChat.
Design
The new component/src/hooks/sendBoxFocus file contains useRegisterFocusSendBox, useFocusSendBox hooks which are used in place of the old context.
Context bindings and other related code was removed.
Specific Changes

Added use-propagate dependency
Replaced context usage with usePropogate for sendbox focus
Removed now unused types and the previous implementation
Added a test case
Removed deprecated useFocusSendBox hoook
Updated hook usage in tests
Fixed suggested actions roving navigation

-

[x] I have added tests and executed them locally
[x] I have updated CHANGELOG.md
[x] I have updated documentation

Review Checklist

This section is for contributors to review your work.

[ ] Accessibility reviewed (tab order, content readability, alt text, color contrast)
[ ] Browser and platform compatibilities reviewed
[ ] CSS styles reviewed (minimal rules, no z-index)
[ ] Documents reviewed (docs, samples, live demo)
[ ] Internationalization reviewed (strings, unit formatting)
[ ] package.json and package-lock.json reviewed
[ ] Security reviewed (no data URIs, check for nonce leak)
[ ] Tests reviewed (coverage, legitimacy)

I'll update usage with use-propagate when the version with the React@>=16 support is out

Closes #4995
Closes #4996
Closes #4997
as well


Apache dumps core (signal 11) with mod_auth_openid

Sometimes apache seems to die on signal 11 when using mod_auth_openid. The crash occurs when login form is submitted.
I managed to get a core dump of it, gdb shows following stack trace:
#0  0x29127e3d in __cxa_allocate_exception () from /usr/lib/libstdc++.so.6
[New Thread 28501140 (LWP 100085)]
(gdb) bt
#0  0x29127e3d in _cxa_allocate_exception () from /usr/lib/libstdc++.so.6
#1  0x287a6338 in modauthopenid::MoidConsumer::find_assoc ()
from /usr/local/libexec/apache22/mod_auth_openid.so
#2  0x287f984e in opkele::basic_RP::checkid ()
from /usr/local/lib/libopkele.so.3
#3  0x287a0fa2 in start_authentication_session ()
from /usr/local/libexec/apache22/mod_auth_openid.so
#4  0x287a2c09 in mod_authopenid_method_handler ()
from /usr/local/libexec/apache22/mod_auth_openid.so
#5  0x080723b9 in ap_run_check_user_id (r=0x2a441058) at request.c:70
#6  0x08074479 in ap_process_request_internal (r=0x2a441058) at request.c:214
#7  0x080851e0 in ap_process_request (r=0x2a441058) at http_request.c:280
#8  0x0808230b in ap_process_http_connection (c=0x2a42f1f0) at http_core.c:190
#9  0x0807e0f9 in ap_run_process_connection (c=0x2a42f1f0) at connection.c:43
#10 0x0808a221 in child_main (child_num_arg=Variable "child_num_arg" is not available.
) at prefork.c:667
#11 0x0808a507 in make_child (s=0x28510f10, slot=2) at prefork.c:768
#12 0x0808a5c4 in startup_children (number_to_start=3) at prefork.c:786
#13 0x0808b1a5 in ap_mpm_run (_pconf=0x2850f018, plog=0x2853d018, s=0x28510f10)
at prefork.c:1007
#14 0x08064276 in main (argc=676384792, argv=0x2a42d018) at main.c:739
This is apache 2.2.21 and mod_auth_openid 0.6. libopkele is 2.0.2.
OS is FreeBSD 8.2.
--
Ari S.

I had a segfaulting apache today after installing mod-auth-openid-0.6.  I straced it and discovered that sqllite was attempting to create more files than just the one file referenced in OpenIDDBLocation.  Since I don't have that in a directory that the apache user can write to, it failed and segfaulted.  The solution for me was to create a directory that the www-data user can write to, put the Location file in that directory, and then allow it to create/delete files to its heart's content.  No more segfault, although now I'm chasing the "Error in authentication: openid.modauthopenid.nonce: no such field" issue.
Please give this a try and if it solves the problem, close the issue.


2 autogenerate a unique qr code

add_edit_event.xml is wrong. Need to fix it and implement the adding event.

Had to force push to revert back to the state before mergin with the main.


.addImportURL() for global libs

May be useful in some cases.
WorkerService.addImportURL(globalLibraryAbsoluteURL);

My request is duplication for #22
:-)


Loosen python constrains

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

#8 was changed in error and python version constrains weren't reverted in #9.  This PR reverts the unnecessary constraints.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

@conda-forge-admin, please rerender

@zshaheen, I saw that you got re-subscribed to this feedstock with this merge.    If you want to give me a list of feedstocks you want to be removed from, I'll be glad to take care of it.


Create Missing Demos for Libraries

Library Affected:

sw-cli (Probably doesn't need one, so remove the link.)
sw-lib
sw-precaching

Browser & Platform:
all browsers.
Issue or Feature Request Description:
We need a demo for certain packages to provide an example for it's use and to be consistent with other tools in the library.

Not sure a demo for sw-cli makes sense - it's just a set of commands that would be run (same for sw-build. But sw-lib and sw-precaching could do with one yes.

Then the cli demo link should be removed.


0.28.6 error: Could not dynamically require "url"

After updating 0.28.5 > 0.28.6, I get an error:
App threw an error during load
Error: Could not dynamically require "url". Please configure the dynamicRequireTargets or/and ignoreDynamicRequires option of @rollup/plugin-commonjs appropriately for this require call to work.

Can you provide a minimal reproduction repo?

I'm sorry, the problem is in my project: for some reason, asciidoctor.js is loaded as commonjs instead of esm.


Please invite me to your organization

sminio

Hey @sminio  !!
Welcome to openAOD! I have sent an invite to join our organization. We also recommend joining our Discord server : https://discord.gg/wZ83xSJSsN. If you have any questions regarding contributing or anything else feel free to write here or ping me on Discord. Cheers. Have a great day ahead of you!


Update of the pl.json - polish language (2021/07/25)

Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines
[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Update of the "pl.json", adding missing translations from the previous version and fixing some translations. This file was based on "en.json" from GBS3.0alpha (contain: 805 lines)

What is the current behavior? (You can also link to an open issue here)
Missing translations...

What is the new behavior (if this is a feature change)?
Missing translations...

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
Nothing... it is just a translation update of pl.json file, so GBS will have all terms.

Other information:
I had also send the pl.json via mail and discord. If I made something wrong, please let me know to fix it.

I think I would rather guess - I made something wrong (seems I can not make a proper "push" request in GitHub-desktop)
As HERE I see there is some [Files changes: 26] and I had made changes only to src/lang/pl.json

that it is not here...
Well, I will attach the file here also just in case (in ZIP)
pl_json.zip, so the file can get updated.

You did the PR against the develop branch, you should do it to v3alpha instead

My bad... I apologize m(_ _)m
Closing this PR.


Fails to index hundreds of repos

I am reticent to post this issue because it may somehow be related to the work I did in PR #138, but I can't quite see how and thought it may indeed need your eyes.
I am attempting to get hound to index 2,850 repos (~30GB) and after several hundred it bombs out like this:
2015/06/29 09:48:58 fork/exec /bin/cp: too many open files
2015/06/29 09:48:58 Searcher started for shoutware-master
2015/06/29 09:48:58 Failed to clone file:///Users/aidan/Desktop/allrepos/repos/shoutware-master, see output below
Continuing...
2015/06/29 09:48:58 fork/exec /bin/cp: too many open files
2015/06/29 09:48:58 Searcher started for triage-master
2015/06/29 09:48:58 open /Users/aidan/p/hound/data/idx-5055d50e566ad8eb/excluded_files.json: too many open files
2015/06/29 09:48:58 Searcher started for bootstrap-master
2015/06/29 09:48:58 Failed to clone file:///Users/aidan/Desktop/allrepos/repos/bootstrap-master, see output below
Continuing...
2015/06/29 09:48:58 pipe: too many open files
2015/06/29 09:48:58 Searcher started for czrecon-master
2015/06/29 09:48:58 Failed to clone file:///Users/aidan/Desktop/allrepos/repos/czrecon-master, see output below

From that point, the remaining ~2000 repos all fail in the same manner. My assumption is that perhaps files are not being closed after being indexed? This is where my knowledge falls short. Any ideas what the cause might be?

That's a lot of repos. Yeah it's probably related to how we deal with file handles. We never expected this to be used for so many repos. I'm sure this is fixable, it will just require some time debugging. It's a pretty narrow use case, so I'm going to mark it as an enhancement.

Thanks for the response! Yes, I agree that it's very much an edge case and understand why it would be looowww down the list of priorities. :)

I'm also running into this issue, increasing open file limits of course works around it but my hound process sits around holding thousands of files open.


Hard-coded parameters in evaluate.py leads to errors

In evaluate.py:
dloader_test = FewShotDataloader(
     dataset=MiniImageNet(phase=test_split),
     nKnovel=5, # number of novel categories on each training episode.
     nKbase=64, # number of base categories.
     nExemplars=nExemplars, # num training examples per novel category
     nTestNovel=15 * 5, # num test examples for all the novel categories
     nTestBase=15 * 5, # num test examples for all the base categories
     batch_size=1,
     num_workers=0,
     epoch_size=epoch_size, # num of batches per epoch
)

When evaluating the Proto Nets/Matching Nets, the hard-coded parameters above leads to some error related to missing Kbase_ids in FewShot.py because nKbase is set as non-zero (64). A possible fix is:
data_test_opt  = config['data_test_opt']
dloader_test = FewShotDataloader(
    dataset=MiniImageNet(phase=test_split),
    nKnovel=data_test_opt['nKnovel'], # number of novel categories on each training episode.
    nKbase=data_test_opt['nKbase'], # number of base categories.
    nExemplars=data_test_opt['nExemplars'], # num training examples per novel category
    nTestNovel=data_test_opt['nTestNovel'], # num test examples for all the novel categories
    nTestBase=data_test_opt['nTestBase'], # num test examples for all the base categories
    batch_size=data_test_opt['batch_size'],
    num_workers=args_opt.num_workers, #0
    epoch_size=epoch_size # num of batches per epoch # data_test_opt['epoch_size']
)

Hi, thanks for letting me know. I just fixed according to your recommendation.


readline.GetSize doesn't work on Windows

Hello,
I wrote a pretty simple Go script and tried to run it on different OS:
package main

import (
  "fmt"
  "github.com/chzyer/readline"
)

func main() {
  rl, err := readline.New("> ")
  if err != nil {
    panic(err)
  }
  defer rl.Close()

  _, maxRows, err := readline.GetSize(0)
  if err != nil {
    fmt.Println(err)
  }
  fmt.Println("Current dimentions is:", maxRows)

  for {
    line, err := rl.Readline()
    if err != nil {
      fmt.Println(err)
      break
    }
    fmt.Println(line)
  }
}

And it work fine on Linux system (Centos 6.5):
$: go run test.go
Current dimentions is: 65
> Hello
Hello

But fails on Windows (10):
C:\>go run test.go
The handle is invalid.

Actually, I'm getting the same error The handle is invalid. when calling another readline functions, like readline.MakeRaw(0). I feel that I missed something or use the lib in incorrect way for Windows.
Could you please assist me with it?

The issue I think is with your code:
readline.GetSize(0)

GetSize requires the fd of the TTY, which in some cases will be zero (eg if it's your first console on Linux) but in many cases wont be. Assuming readline is outputting to the default stdout, you can find the value with:
os.Stdout.Fd()

So your code would read something like:
fd := int(os.Stdout.Fd())
_, maxRows, err := readline.GetSize(fd)


API error in endpoint GET "query"

Test which is failing: https://github.com/jesusprubio/shodan-client.js/blob/master/test/index/query.js#L40
Response:
Error: request.get : 404 - "404 Not Found\n\nThe resource could not be found.\n\n\n/shodan/query}\n\n"

Solved


Requested: Ability to get path stats

The current stats are very limited, for example currently it's not possible to get the RTT due to it being placed in quiche_conn_path_stats

@dries-c I am currently very busy... if you have cycles you might want to do a PR ?

This was merged


Vim9: should we allow :const with a global variable?

Describe the bug
In Vim9 script, we cannot use :const with a global variable.
To Reproduce
Run this shell command:
vim -Nu NONE -S <(cat <<'EOF'
    vim9script
    const g:NAME = 123
EOF
)

E1016: Cannot declare a global variable: g:NAME

Expected behavior
I'm not sure.  On the one hand, I understand the error.  :const is equivalent to :var + :lockvar, but :var is disallowed with a global variable.
On the other hand, it's inconvenient to have to use :lockvar:
vim9script
g:NAME = 123
lockvar g:NAME

Also, it creates an inconsistency with Vim script legacy, where a global constant can be created in one single line, while in Vim9 we need two of them.
Should we allow :const (and :final) to be used with "public" variables (global, buffer-local, ...)?  So that we can keep creating constants in one single line, regardless of their scopes, just like in Vim script legacy.
Environment

Vim version: 8.2 Included patches: 1-2186
OS: Ubuntu 16.04.7 LTS
Terminal: xterm(362)

Yes, const and final should work.  I'll see if we make this consistent.


basic Linux compatibility

you can connect to a MQTT broker and expose a dummy sensor If you manually create config files

Custom commands now work cross platform on Linux/windows, assuming the command itself works on all platforms

The branch seems corrupted, I am going to create a new one.

The branch seems corrupted, I am going to create a new one.