text:
Should this line not be explaining the opposite?

https://github.com/cdsmith/explainable-predicates/blob/3b4f5df776d5dd8238e6aecd0ade69a40fe5ffb2/src/Test/Predicates.hs#L483

Explanations are statements of a fact that justifies the decision about whether a predicate applies or not.  For example, if the predicate is containsAll [eq 1, eq 2, eq 3], then a good explanation would be "The value doesn't contain 3".  This statement is a good justification, regardless of whether you're trying to explain why containsAll [eq 1, eq 2, eq 3] accepts, or why notP (containsAll [eq 1, eq 2, eq 3]) rejects.

Ah, fair enough.

authors: cdsmith danwdart

repo: cdsmith/explainable-predicates


text:
🛑 tanecni-divadlo.cz is down

In b31e6ee, tanecni-divadlo.cz (https://www.tanecni-divadlo.cz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: tanecni-divadlo.cz is back up in 09b71a8.

source: gharchive/issue

repo: cebreus/upptime

license: MIT

license_type: permissive

license_source: github-api


text:
🛑 tanecni-divadlo.cz is down

In f99c8d5, tanecni-divadlo.cz (https://www.tanecni-divadlo.cz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: tanecni-divadlo.cz is back up in 6670dc2.


text:
🛑 tanecni-divadlo.cz is down

In 7c872fb, tanecni-divadlo.cz (https://www.tanecni-divadlo.cz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: tanecni-divadlo.cz is back up in 4bfeda9.


text:
🛑 tanecni-divadlo.cz is down

In 0703e52, tanecni-divadlo.cz (https://www.tanecni-divadlo.cz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: tanecni-divadlo.cz is back up in f263340 after 475 days, 9 hours, 42 minutes.


text:
🛑 tanecni-divadlo.cz is down

In c2d2278, tanecni-divadlo.cz (https://www.tanecni-divadlo.cz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: tanecni-divadlo.cz is back up in 0fc23bd.


text:
🛑 tanecni-divadlo.cz is down

In 4aa8f9b, tanecni-divadlo.cz (https://www.tanecni-divadlo.cz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: tanecni-divadlo.cz is back up in ad41e09.


text:
🛑 tanecni-divadlo.cz is down

In 77d63d8, tanecni-divadlo.cz (https://www.tanecni-divadlo.cz) was down:

HTTP code: 0
Response time: 0 ms

Resolved: tanecni-divadlo.cz is back up in d11f151.


text:
🛑 CDN is down

In 1908909, CDN (https://cdn.ceccun.com/cdynamic/captive) was down:

HTTP code: 522
Response time: 15589 ms

Resolved: CDN is back up in 811c839.

repo: ceccun/status


text:
🛑 CDN is down

In 9c0d24f, CDN (https://cdn.ceccun.com/cdynamic/captive) was down:

HTTP code: 522
Response time: 15279 ms

Resolved: CDN is back up in 3644db5.


text:
🛑 CDN is down

In b7f3203, CDN (https://cdn.ceccun.com/cdynamic/captive) was down:

HTTP code: 525
Response time: 218 ms

Resolved: CDN is back up in 1b5c3a5 after 786 days, 15 hours, 43 minutes.


text:
🛑 CDN is down

In a49676b, CDN (https://cdn.ceccun.com/cdynamic/captive) was down:

HTTP code: 525
Response time: 268 ms

Resolved: CDN is back up in 14f330a after 791 days, 46 minutes.


text:
Added MESSy/EMAC to source_id and land to realm

Hi Ag - minor updates to add a new modelling group. Thanks for your help.

Hello Ag. Did you see my last pull request - the one with the comment 'Added MESSy/EMAC...'? Just a double-check to make sure I am doing this correctly.  Thanks.

source: gharchive/pull-request


text:
Map types for records

Proposal for a way to treat records as maps in Cedar.
Rendered
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Thank you for writing this up!
If we assume that RFC 21 Add all and any operators can be extended to support .find() operator (similar to Array.find() in JS) that returns first matching item in the set, then we have two proposals that would help achieve the same outcomes in provided tags and timebox examples.
This RFC tackles these use cases through new data structure and enforces uniqueness of the key.
RFC 21 deals with it through new operators.
Motivating example using Map types
when { resource.tags["project"] == principal.tags["project"] }

can then be rewritten as
when { resource.tags.find(it.key == "project").value == principal.tags.find("it.key == "project").value }

I personally lean towards using predicates for their flexibility although I appreciate simplicity of having Map types for when element is a primitive. It does seem that RFCs are generally compatible so we could do both.

when { resource.tags.find(it.key == "project").value == principal.tags.find("it.key == "project").value }

Following up on @max2me's example from above, we can express this constraint without .find, using just .any, like this:
when { resource.tags.any(it.key == "project" && principal.tags.contains({key: "project", value: it.value})) }

.find() operator that returns first matching item in the set

Cedar sets are unordered, so "first" doesn't make sense.  You could potentially make a version of .find() that just returns any matching item in the set, though. That said, @emina's refactoring to use just .any() is probably the easier/preferable way to do this

This would address https://github.com/cedar-policy/cedar/issues/305

.find() operator that returns first matching item in the set
Cedar sets are unordered, so "first" doesn't make sense. You could potentially make a version of .find() that just returns any matching item in the set, though.
Fair point, any one matching item in the set works too.

That said, @emina's refactoring to use just .any() is probably the easier/preferable way to do this
I'd love to understand what makes it easier/preferrable. I find that approach very creative but harder to read. It also assumes that you know the entire value upfront.

The approach with .any doesn’t require that you know the value upfront.  It’s equivalent to the .find approach in that sense.  Note that we effectively find it.value for one set and then use that value to perform the membership test in the second set.

The .find operator is tricky to define. There is no notion of “first” and we can’t pick any value non-deterministically because the language must remain deterministic, for safety.

Here is an example where this approach might not be sufficient. Currently each tag is a {key, value} record. Imagine that instead each tag is a Record with 3 attributes {key, value, updatedAt}.
Although this is not an example based on real use case, if I understand approach correctly, contains won't work because it will require supplying valid updatedAt attribute that we do not know.

The approach still works, even with three attributes, assuming that we want to check equality of the entire record (as in the previous example).  It would look like this:
when {
  resource.tags.any(
    it.key == "project" &&
    principal.tags.contains({key: "project", value: it.value, updatedAt: it.updatedAt}))
}

It wouldn’t work if we wanted to ignore the .updatedAt attribute in the equality comparison, but in that case, we could represent the data differently.   We can use two sets of key/value pairs.  So, we’d have .tags, which maps keys to values, and also .updatedAt, which maps keys to timestamps.
Another disadvantage of .find, besides the tricky semantics, is that it negatively affects analyzability.  We could define .find to return a value only if it’s the sole such value in the set; otherwise, it errors.  This can be encoded for analysis, but it’s unclear how well the resulting encoding would be perform.

I updated RFC to include discussion above, in the "workarounds" part at the end. I'm becoming more convinced that we don't see this RFC, and that RFC 21 plus what we have is the way to go.

I updated RFC to include discussion above, in the "workarounds" part at the end. I'm becoming more convinced that we don't see this RFC, and that RFC 21 plus what we have is the way to go.

I agree. Should we move to FCP with intent to reject?

I've thought a little more about what we gain/lose by using an encoding of maps using sets.
From what I can see, the encoding is:

a value of type map<K,V> has type set<{ key: K, value: V }>
given map m, a predicate (boolean expression) E involving m[k] would be written m.any(it.key == k && E) where occurrences of m[k] in E are replaced with it.value. For example, checking whether m["foo"] == "bar" would be written m.any(it.key == "foo" && it.value == "bar").

The predicate E is limited by our inability to nest any and all, though.
In particular if E mentions any other map lookups, you can't use this encoding. There are some tricks you can play by using contains or containsAny, though. For example, to encode m[k] == n[k], you could write m.any(it.key == k && n.contains({key: k, value: it.value})). But you can't encode m[k] > n[k] because contains is limited to use of ==. One possible solution to any inadequacy we find is to add more set operators like contains to fill the gap, but I'm not sure what they would be.
So the question is: Is this limitation significant enough that the encoding is inadequate? What other expressions E per the above might we like to see in policies that could involve multiple maps? @max2me @emina

In my view, the cost of adding Maps (today) significantly outweighs the benefits of doing so (today).
For real use cases we've seen so far, there are viable alternative solutions.  And while there are hypothetical use cases that can't be handled, they don't sufficiently justify the added complexity brought by Maps.
Adding Maps is an invasive change to the language:  it's adding a new type, changing the syntax and semantics, changing validation, analysis etc.  This invasive change does add expressiveness but at the following cost:

It adds a non-trivial cognitive burden on users.  Cedar used to have Maps (prior to the open source release), and we removed them from the language based on the feedback from users.  Users found the distinction between Maps and records subtle and confusing.  It wasn't clear when to use one vs the other when both applied.  And the differences in how the two behave with respect to indexing (static vs dynamic) were also confusing. Some of this can be addressed with better documentation, but fundamentally, the differences between the two are subtle: records are heterogenous maps over a fixed domain of string keys, and Maps are homogenous maps over an unknown set of string keys.
Related to (1), Maps add sharp corners the language, outlined in this RFC.  For example, there is no way to write a Map literal without having to also add type casts to the language.
Maps are analyzable by reduction to the theory of arrays.  But it's not clear how well such an analysis would scale, especially in combination with all the other theories that Cedar analysis requires.

So, on the balance, I vote to reject this proposal for the time being.

Thinking about this more, here is a not-fully-fleshed-out alternative idea for adding map-like functionality to Cedar, without introducing a new type.  This idea should help with concerns (1) and (2) in the above comment, though (3) will remain a challenge.
Extend the record type so that a record can behave as closed or open.  Closed records behave exactly as they do today with respect to syntax, semantics, validation, and analysis.
But open records have an additional feature.  In addition to a pre-defined set of closed attributes, their schema also declares a default type $T$.  For all strings $f$ that are not declared as attributes, an instance of an open record implicitly has an optional attribute $f$ of type $T$.
With this alternative, we're just generalizing our current record type rather than introducing a new one.  The syntax of accessing and creating records etc. remains the same.  Validation does need to change to account for  these implicit attributes and so does the analysis.  But overall, the change is less invasive.
We can define what it means to have dynamic attribute access on such records, but this is not urgent.  All examples we've seen so far have used static (known) attribute names to access record values.   If needed, we can add dynamic access in the future.   Again, this is analyzable though there will be scaling limitations.

If keys are always static (i.e., they appear as literals in the policies), then I don't think we need to make any change and we can cancel this RFC. As I wrote in Workarounds, with static keys you can model a map as a record with each key as an optional attribute, and just enumerate those attributes/keys in the schema. The only reason you couldn't do this would be if policies are being generated on the fly but you could not update the schema to match them. Emina's open record proposal would help a little here, but this is a narrow use-case I think, and there are potential technical problems, see below.
To me, the only reason to add maps is if keys are dynamic. You can get dynamic keys with the set-of-records encoding, but you lack some flexibility, as I wrote above. I'd like to hear more from @max2me about whether there are applications that can't use the set-based encoding I gave above. If there are, then we might think more.
Back to open records: The problem here is that they do not play well with width subtyping (permissive mode). With width subtyping, you can do { foo: String, bar: String } <: { foo: String }, i.e., you can treat a record with two attributes as if it had just one. Now suppose that the record is open. That means you basically have a rule { foo: String } <: { foo: String, bar: T } for the default type T. This rule is unsound in combination with the first rule: stringing them together, we make it so that a field with a String is treated as it had a T instead. I wrote about this in the RFC and pointed out that subtyping a record to a map can only work if the record is closed, so we are sure it doesn't have any non-listed fields (i.e., it's type is complete). I'm sure we could figure something out, but it might be kludgey, and that speaks against doing this too.

Ah, I missed the part about permissive validation.  But this should be fine for strict validation because there is no subtyping, right?
In any case, I agree that this is not ideal either.  I'm still for maintaining the status quo.

I am going to close this RFC. I believe that optional keys in records, or sets of key/value records along with any / all, should get the job done sufficiently well. We can re-open this RFC if a use-case emerges that can't be handled in either of these ways (or some other one) and the downsides to analysis can be overcome.

Reopening because the reason that we closed this RFC no longer applies: We are no longer proposing a sufficiently general any?/all? feature.

authors: andrewmwells-amazon cdisselkoen cplee emina max2me mwhicks1

repo: cedar-policy/rfcs


text:
[#DEV-6320] Fixes MemeLeaks

Cullsettings being allocated each camera cullvisits
CullingSet stack reserve "cursor" wasn't rersetted to 0
Those were the last vec2/3/4 & Matrix Leaks during render loop.
/!\ changes in polytope/planes

very cool to eliminate leak

@jtorresfabra there is some changes in CullSettings/Polytope/Planes you might want to check

@Kuranes I will do it, thanks for the advice.

authors: Kuranes cedricpinson jtorresfabra

repo: cedricpinson/osgjs

license: mit

license_source: bigquery


text:
blob: store the first share of the Blob in the blob's proof

To protect against the length attack we should store the first share of the blob in the blob's proof.
A length attack is an attack when a malicious node can give us invalid proof and commitment and it could be proved against the header's DataRoot correctly. It can happen when the proof will contain only part of the subtreeRoots.

From the first share of the Blob you can get the Sequence Length. From the sequence Length, you can check the length of the blob. If i don't, i can create a correct inclusion proof for 3/4 of a blob that is actually 4 shares long. The malicious commitment would be PFB2

https://github.com/celestiaorg/celestia-node/pull/3610#issuecomment-2263610790

authors: nashqueue vgonkivs

repo: celestiaorg/celestia-node


text:
feat: adding example types and auth comments to OpenRPC doc generation

Overview
This PR adds auth comments and example types to our OpenRPC API docgen. It replaces #1408 and closes #1358.

Codecov Report

Merging #1685 (9abd46c) into main (897ce1f) will decrease coverage by 0.07%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1685      +/-   ##
==========================================
- Coverage   55.05%   54.99%   -0.07%
==========================================
  Files         231      231
  Lines       15032    15020      -12
==========================================
- Hits         8276     8260      -16
- Misses       5874     5877       +3
- Partials      882      883       +1

Impacted Files
Coverage Δ

api/rpc/client/client.go
72.72% <100.00%> (-9.63%)
:arrow_down:

das/coordinator.go
86.76% <0.00%> (-1.48%)
:arrow_down:

share/ipld/get.go
92.14% <0.00%> (-1.24%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


text:
Transition ODIS Combiner to Cloud Function Gen2

This transition would provide concurrency and give us access to more cloud resources.

See tracking doc
https://www.notion.so/celoplatform/ODIS-MiniPay-Scalability-Tracking-cff5b7d33f5a452889ea3dbfb96788b9

PR: https://github.com/celo-org/celo-monorepo/pull/10511

authors: alecps soloseng

repo: celo-org/celo-monorepo


text:
Fix for tapping on a push notification on android

Description
This is a fix for tapping on a push notification. Currently it is not handled properly if the app was backgrounded via the back button on android or swiped away (killed state).
We were setting up firebase too early in the app lifecycle. The firebase messaging setup needs to happen in sync with the App component because intents on android travel through Activities. This is mentioned briefly in the documentation here: https://rnfirebase.io/messaging/notifications
The call to getInitialNotification should happen within a React lifecycle method after mounting (e.g. componentDidMount or useEffect). If it's called too soon (e.g. within a class constructor or global scope), the notification data may not be available.
Tested
On an android emulator using the push script then tapping on the notification to see if the webview shows up.
Here are the different scenarios tested.

Start app, send push notice blue notification bar shows up at the top with the notification message.
Kill app (swipe away), send push, tap on it from the android status bar, make sure the app opens and navigates to the webview.
Open app, press android home button (app goes to background but main activity is paused not destroyed), send push, tap on it, make sure webview opens.
Open app, press android back button (app goes to background with main activity destroyed), send push, tap on it, make sure webview opens.

I also made sure there aren't any obvious leaks in either the channel use to listen for notifications or the callbacks by printing and pressing back and reopening the app to make sure there aren't multiple. But I am not entirely sure if the cleanup is properly done, so hopefully someone can confirm.
Added a new e2e test that simulates opening the app from a notification. It is currently disabled because circle ci does not support firebase yet. It runs successfully locally and hopefully soon @non-binary and @MuckT will help support firebase on CI.
Related issues

Fixes #161

Backwards compatibility
Yes.

Hey @etuleu I have verified this issue using Android internal build V1.13.0 (1004294348) & observed following:
Observations:

User able to receive Blue push notification & user able to redirect to celo.org web view page after tapping on it when app is foregrounded. Also it is observed that, continuous loading indicator not displayed after tapping on received blue notification. Attachment
User able to receive push notification & user redirect to celo.org web view page after tapping on it without loading indicator when app is running in background using home button on android emulator.
User able to receive push notification & user redirect to celo.org web view page after tapping on it without loading indicator when app is running in background using Back button on android emulator. Also we have observed that app takes some time (~5sec) on logo page & then redirect to web view. Attachment
User able to receive push notification & user redirect to celo.org web view page after tapping on it without loading indicator when app was swiped away(kill). Also it is observed that app takes same as 5 sec on logo page & now user gets first redirect to Home screen and after 20 second user redirect to web view. Attachment

Verified On Devices: Samsung Galaxy A5(7.0)
Thanks..!!

authors: Celoqa etuleu

repo: celo-org/wallet


text:
Account Number redesign

Description
Update Account Number design, add a visual "Tap to Copy" indicator
Tested

Related issues

Fixes #303

@jeanregisser thanks, I've fixed it 🙏

Hi @MuckT Again We have cross verified this issue on Latest android build V1.16.1 & Testflight build V1.16.1(67) and updated the status in testqulaity tool.
Testquality tool link:
Android:

https://valora.testquality.com/project/12128/plan/20854/run/148956/result/2432161
iOS:

https://valora.testquality.com/project/12128/plan/20854/run/148956/result/2432189

And also we have tested #482
Devices: Vivo v11 pro (10), iPhone 6+(12.4.5)
CC: @isabellewei

authors: Celoqa isabellewei


text:
Example unusable due to internal calls

when you copy the example main into a file (https://github.com/cenkalti/rain/blob/master/main.go) you get:
    main.go:23:2: use of internal package github.com/cenkalti/rain/internal/console not allowed
    main.go:24:2: use of internal package github.com/cenkalti/rain/internal/logger not allowed
    main.go:25:2: use of internal package github.com/cenkalti/rain/internal/magnet not allowed
    main.go:26:2: use of internal package github.com/cenkalti/rain/internal/metainfo not allowed

It is not an example. It is the entry point of the program. Please see the example in README file.

authors: cenkalti xackery

repo: cenkalti/rain


text:
The "Web browsable API" page displays  incorrect request id

The request id should be the same as the response id. But， the "Web browsable API" page displays  an incorrect request id which is not  Inconsistent with the response id 。

Hi,
This bug just affect a display page, on request and response from API it's OK.
Thank you.

authors: manortec nycholas

repo: cenobites/flask-jsonrpc


text:
Implement prometheus exporter with [Count, Distribution] Aggregation

Follow up of #181
Updates #168
Implements the Prometheus endpoint and now we can examine
data of the OpenCensus View Aggregation types of:

CountAggregation
DistributionAggregation

Also added a ViewRegistrar interface to stats so that
we can avoid the client having manually register views
to the exporter. With ViewRegistrar's RegisterView,
when a new View's Subscribe is invoked, the underlying
worker publishes the view to all Exporters that have
the RegisterView method. This way all the client has
to do is:

Create the Exporter.
Make measures and views
Invoke view.Subscribe() per view
thus simplifying our API.

And the sample output data after running the example
in examples/stats/prometheus/main.go

Exhibit:

shows video count + processed byte data continuously
being generated and due to the nice API @rakyll
thought of, we can view the video data by
visiting the set endpoint, in a sample case /metrics
curl http://localhost:9999/metrics

 # HELP opencensus_video_count number of videos processed processed over
 # time
 # TYPE opencensus_video_count counter
 opencensus_video_count 1879
 # HELP opencensus_video_cum processed video size over time
 # TYPE opencensus_video_cum histogram
 opencensus_video_cum_bucket{le="0.005"} 372
 opencensus_video_cum_bucket{le="0.01"} 372
 opencensus_video_cum_bucket{le="0.025"} 372
 opencensus_video_cum_bucket{le="0.05"} 372
 opencensus_video_cum_bucket{le="0.1"} 372
 opencensus_video_cum_bucket{le="0.25"} 372
 opencensus_video_cum_bucket{le="0.5"} 372
 opencensus_video_cum_bucket{le="1"} 372
 opencensus_video_cum_bucket{le="2.5"} 372
 opencensus_video_cum_bucket{le="5"} 372
 opencensus_video_cum_bucket{le="10"} 372
 opencensus_video_cum_bucket{le="+Inf"} 1116
 opencensus_video_cum_sum 1.597752213504e+12
 opencensus_video_cum_count 1116

Thanks for the first round of review @rakyll, I've addressed your feedback, PTAL.

Thanks @rakyll, I've addressed them too. Just CI waiting and then we are gucci to merge.

repo: census-instrumentation/opencensus-go


text:
🛑 NEGL, Rigolet, Nunatsiavut (NLQU0002) is down

In 3ec3980, NEGL, Rigolet, Nunatsiavut (NLQU0002) (https://www.smartatlantic.ca/erddap/tabledap/sma_negl_rigolet_nlqu0002.json?time&time>=now-2hours&distinct()) was down:

HTTP code: 404
Response time: 2148 ms

Resolved: NEGL, Rigolet, Nunatsiavut (NLQU0002) is back up in 4baa0a3.


text:
docker: use a better method to pull images

We now use the docker_image module to pull images. We also changed the
way we declare image. Prior to this patch we must have a "user/image:tag"
format, which is incompatible with non docker-hub registry where you
usually don't have a "user". On the docker hub a "user" is also
identified as a namespace, so for Ceph the user was "ceph". Now if you
want to specify a container image you need to set one of the variables:
'ceph_$DAEMON_docker_name' where DAEMON must be replaced by mon, osd,
mds, rgw, nfs, rbd_mirror or restapi. Here is an example of how you can
set this variable:

For docker hub images: ceph_mon_docker_name: "ceph/daemon" will give
you the 'daemon' image of the 'ceph' user.

For non docker hub images: ceph_mon_docker_name: "daemon" will simply
give you the "daemon" image.

Infrastructure playbooks have been modified as well.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1420207
Signed-off-by: Sébastien Han seb@redhat.com

Why not just use one variable ceph_docker_name and then have users set it in the appropriate group_vars file to define it for the individual daemons, if it differs. You could even define it per host in the inventory.
I've had some frustration in setting up the CI because I wanted to use a custom tag for the image I was building, but to do that I had to set the same value in like 4 different variables in ceph-ansible to deploy it.
IMHO, all these ceph_$daemon_docker_* variables should be made generic and moved into ceph-docker-common.

@andrewschoen we still need the image and tag separation because some module require it, see the  docker_image module.
BTW on Atomic host, docker-py version is python-docker-py-1.7.2-1.el7.noarch, this is why we are hitting https://github.com/ansible/ansible-modules-core/issues/1227 :(
@andrewschoen should we go back to the "docker pull command" in the meantime? That's so annoying.

@leseb I think image and tag separation is fine, lets just not create one of those variables for each daemon type.
Yeah, I suppose we should go back to docker pull in the meantime. Does docker_image have support for using a custom registry? I don't think I saw that in this PR and our ceph-docker tests depend on that functionality.

@andrewschoen alright, I'll do that for the variables. docker_image supports custom registries. So we can do name: localhost:5000/image:tag.

@andrewschoen any last comments for this one?

jenkins test ansible2.2-docker_cluster

authors: andrewschoen leseb

repo: ceph/ceph-ansible


text:
logrotate: add logrotate functionality for csi

Describe what this PR does

Make main container and csi addons container
log to a file(dependency on klog)

Add a log-rotate sidecar container,
so it can rotate the logs

Added other volume and volumemounts as needed

Added the privileged option for controllerplugin

Provide some context for the reviewer
Is there anything that requires special attention
Do you have any questions?
Is the change backward compatible?
Are there concerns around backward compatibility?
Provide any external context for the change, if any.
For example:

Kubernetes links that explain why the change is required
Ceph-CSI spec related changes/catch-up that necessitates this patch
golang related practices that necessitates this change

Related issues
Mention any github issues relevant to this PR. Adding below line
will help to auto close the issue once the PR is merged.
Fixes: #issue_number
Future concerns
List items that are not part of the PR and do not impact it's
functionality, but are work items that can be taken up subsequently.
Checklist:

[ ] Commit Message Formatting: Commit titles and messages follow
guidelines in the developer
guide.
[ ] Reviewed the developer guide on Submitting a Pull
Request
[ ] Pending release
notes
updated with breaking and/or notable changes for the next major release.
[ ] Documentation has been updated, if necessary.
[ ] Unit tests have been added, if necessary.
[ ] Integration tests have been added, if necessary.

@nb-ohad @Madhu-1 ^^

Testing:
[rider@localhost rbac]$ oc exec -it test.rbd.csi.ceph.com-nodeplugin-tg25d -n ceph-csi-operator-system  -c log-collector sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
sh-4.4#
sh-4.4# ls
bin  csi-logs  dev  etc  home  lib  lib64  logrotate-config  lost+found  media	mnt  opt  proc	root  run  sbin  srv  sys  tmp	usr  var
sh-4.4# cd csi-logs/
sh-4.4# ls
csi-rbdplugin.log
sh-4.4#
sh-4.4# cd ..
sh-4.4# cd logrotate-config/
sh-4.4# ls
csi
sh-4.4# cat csi

/csi-logs/*.log {
	daily
	missingok
	rotate 5
	compress
	copytruncate
	notifempty
    maxsize 500M
}sh-4.4# cd ..
sh-4.4# cd csi-logs/
sh-4.4# ls
csi-rbdplugin.log
sh-4.4# truncate -s 600M csi-rbdplugin.log
sh-4.4# ls -lh
total 4.0K
-rw-r--r-- 1 root root 600M Aug  7 18:47 csi-rbdplugin.log
sh-4.4#
sh-4.4#
sh-4.4# cd ..
sh-4.4# cd csi-logs/
sh-4.4# logrotate --verbose csi
error: cannot stat csi: No such file or directory
Reading state from file: /var/lib/logrotate/logrotate.status
Allocating hash table for state file, size 64 entries

Handling 0 logs
sh-4.4#
sh-4.4#
sh-4.4# ls
csi-rbdplugin.log
sh-4.4# cd ..
sh-4.4# cd logrotate-config/
sh-4.4# logrotate --verbose csi
reading config file csi
Reading state from file: /var/lib/logrotate/logrotate.status
Allocating hash table for state file, size 64 entries

Handling 1 logs

rotating pattern: /csi-logs/*.log  after 1 days (5 rotations)
empty log files are not rotated, log files >= 524288000 are rotated earlier, old logs are removed
considering log /csi-logs/csi-rbdplugin.log
Creating new state
  Now: 2024-08-07 18:48
  Last rotated at 2024-08-07 18:00
  log needs rotating
rotating log /csi-logs/csi-rbdplugin.log, log->rotateCount is 5
dateext suffix '-20240807'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
renaming /csi-logs/csi-rbdplugin.log.5.gz to /csi-logs/csi-rbdplugin.log.6.gz (rotatecount 5, logstart 1, i 5),
old log /csi-logs/csi-rbdplugin.log.5.gz does not exist
renaming /csi-logs/csi-rbdplugin.log.4.gz to /csi-logs/csi-rbdplugin.log.5.gz (rotatecount 5, logstart 1, i 4),
old log /csi-logs/csi-rbdplugin.log.4.gz does not exist
renaming /csi-logs/csi-rbdplugin.log.3.gz to /csi-logs/csi-rbdplugin.log.4.gz (rotatecount 5, logstart 1, i 3),
old log /csi-logs/csi-rbdplugin.log.3.gz does not exist
renaming /csi-logs/csi-rbdplugin.log.2.gz to /csi-logs/csi-rbdplugin.log.3.gz (rotatecount 5, logstart 1, i 2),
old log /csi-logs/csi-rbdplugin.log.2.gz does not exist
renaming /csi-logs/csi-rbdplugin.log.1.gz to /csi-logs/csi-rbdplugin.log.2.gz (rotatecount 5, logstart 1, i 1),
old log /csi-logs/csi-rbdplugin.log.1.gz does not exist
renaming /csi-logs/csi-rbdplugin.log.0.gz to /csi-logs/csi-rbdplugin.log.1.gz (rotatecount 5, logstart 1, i 0),
old log /csi-logs/csi-rbdplugin.log.0.gz does not exist
log /csi-logs/csi-rbdplugin.log.6.gz doesn't exist -- won't try to dispose of it
copying /csi-logs/csi-rbdplugin.log to /csi-logs/csi-rbdplugin.log.1
truncating /csi-logs/csi-rbdplugin.log
compressing log with: /bin/gzip

sh-4.4#
sh-4.4#
sh-4.4# cd ..
sh-4.4# cd csi-logs/
sh-4.4# ls
csi-rbdplugin.log  csi-rbdplugin.log.1.gz

@Madhu-1 This PR is ready to be merged, but merging is blocked on a change request that you have asked for that is already resolved. Can you please add your approved review so we can merge this?

/hold more manual testing nedded

Testing results:
[rider@localhost dist]$ kubectl get pod -nceph-csi-operator-system  -o wide
NAME                                                    READY   STATUS    RESTARTS   AGE     IP               NODE           NOMINATED NODE   READINESS GATES
ceph-csi-operator-controller-manager-5b85f8c9b8-jbcns   2/2     Running   0          28m     10.244.1.2       minikube-m02   <none>           <none>
test.rbd.csi.ceph.com-ctrlplugin-54b744ff6c-chht6       6/6     Running   0          27m     10.244.2.2       minikube-m03   <none>           <none>
test.rbd.csi.ceph.com-nodeplugin-dn4ww                  3/3     Running   0          27m     192.168.39.45    minikube-m03   <none>           <none>
test.rbd.csi.ceph.com-nodeplugin-s62ts                  3/3     Running   0          3m40s   192.168.39.232   minikube       <none>           <none>
test.rbd.csi.ceph.com-nodeplugin-vj2f2                  3/3     Running   0          27m     192.168.39.23    minikube-m02   <none>           <none>
[rider@localhost dist]$
[rider@localhost dist]$ kubectl exec -it test.rbd.csi.ceph.com-nodeplugin-dn4ww  -nceph-csi-operator-system -c log-rotator sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
sh-4.4# ls
bin  csi-logs  dev  etc  home  lib  lib64  logrotate-config  lost+found  media	mnt  opt  proc	root  run  sbin  srv  sys  tmp	usr  var
sh-4.4# cd logrotate-config/
sh-4.4# cat csi
/csi-logs/*.log {
	missingok
	compress
	copytruncate
	notifempty
	rotate 5
	daily
	maxsize 500M
}
sh-4.4# cd ..
sh-4.4# cd csi-logs/
sh-4.4# ls
csi-rbdplugin.log
sh-4.4# cat csi-rbdplugin.log
Log file created at: 2024/08/16 08:10:18
Running on machine: minikube-m03
Binary: Built with gc go1.21.5 for linux/amd64
Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
W0816 08:10:18.759665   17582 util.go:276] kernel 5.10.57 does not support required features
W0816 08:10:18.760132   17582 rbd_attach.go:252] kernel version "5.10.57" doesn't support cookie feature
sh-4.4#
sh-4.4#
sh-4.4# truncate -s 600M csi-rbdplugin.log
sh-4.4#
sh-4.4# ls -lh
total 4.0K
-rw-r--r-- 1 root root 600M Aug 16 08:15 csi-rbdplugin.log
sh-4.4#
sh-4.4# exit
exit
[rider@localhost dist]$ kubectl logs  test.rbd.csi.ceph.com-ctrlplugin-54b744ff6c-chht6  -nceph-csi-operator-system -c log-rotator
reading config file /logrotate-config/csi
Reading state from file: /var/lib/logrotate/logrotate.status
Allocating hash table for state file, size 64 entries

Handling 1 logs

rotating pattern: /csi-logs/*.log  after 1 days (5 rotations)
empty log files are not rotated, log files >= 524288000 are rotated earlier, old logs are removed
considering log /csi-logs/*.log
  log /csi-logs/*.log does not exist -- skipping
Creating new state
[rider@localhost dist]$
[rider@localhost dist]$
[rider@localhost dist]$ cd ..
[rider@localhost ceph-csi-operator]$ git add .
[rider@localhost ceph-csi-operator]$
[rider@localhost ceph-csi-operator]$
[rider@localhost ceph-csi-operator]$
[rider@localhost ceph-csi-operator]$
[rider@localhost ceph-csi-operator]$ kubectl exec -it test.rbd.csi.ceph.com-nodeplugin-dn4ww  -nceph-csi-operator-system -c log-rotator sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
sh-4.4# cd /csi-logs/
sh-4.4# ls
csi-rbdplugin.log  csi-rbdplugin.log.1.gz
sh-4.4#

@nb-ohad PTAL and merge it if everything is good.

@parth-gr may i know the recent change you pushed after i approved the PR?

LGTM
@Madhu-1 Are you ok with the state of the PR?

authors: Madhu-1 nb-ohad parth-gr

repo: ceph/ceph-csi-operator


text:
snapshot：why create a temp image and then create snapshot on the temp image？

Current design of snapshot：
parent image ->create temp snapshot on parent image -> clone a temp image from temp snapshot -> delete temp snapshot ->create snapshot on temp image
Since increasing the clone depth will reduce the read performance, why not create a snapshot directly on the parent image？

it was done to keep snapshots and clones independent of each other and also to flatten the temporary cloned image, not the actual image which will be mounted by application. flattening rbd images given to users will have an i/o impact. you can configure the depth of the images using https://github.com/ceph/ceph-csi/blob/cf6fdcb796471603cd87382842a652bcd81f98a9/cmd/cephcsi.go#L105-L114 if you want each image to be independent try configuring these values to lower one.

repo: ceph/ceph-csi


text:
rebase: update vault to latest release version

updating dependent vault package to latest available release version
Signed-off-by: Madhu Rajanna madhupr007@gmail.com

/retest ci/centos/mini-e2e-helm/k8s-1.22

/retest ci/centos/mini-e2e-helm/k8s-1.22

X Exiting due to GUEST_PROVISION: Failed to start host: creating host: create: Error creating machine: Error in driver during machine creation: IP not available after waiting: machine minikube didn't return IP after 1 minute

/test ci/centos/mini-e2e-helm/k8s-1.22

🎩]mrajanna@fedora ceph-csi $]go mod verify
all modules verified
[🎩]mrajanna@fedora ceph-csi $]echo $?
0

go mod verify is working fine locally

@mergifyio rebase

go: github.com/libopenstorage/secrets@v0.0.0-20210709082113-dde442ea20ec requires
github.com/hashicorp/vault@v1.4.2 requires
github.com/hashicorp/go-discover@v0.0.0-20201029210230-738cb3105cd0 requires
github.com/tencentcloud/tencentcloud-sdk-go@v3.0.83+incompatible: reading github.com/tencentcloud/tencentcloud-sdk-go/go.mod at revision v3.0.83: unknown revision v3.0.8

Due to inter dependencies this cannot be point to v1.8.2 closing it for now.


text:
STI subclass with model_name causes warning

This is admittedly a bit of an unusual situation, and (for reasons I don't yet understand) appears to still work as intended, so I'm mostly just documenting it here to provide a public reference point.
Consider the following models and resources:
class Machine < ActiveRecord::Base
  has_many :parts
end

class Part < ActiveRecord::Base
  belongs_to :machine
end

class Gadget < Part
  # ...
end

class PartResource < JSONAPI::Resource
  has_one :machine
end

class WidgetResource < PartResource
  model_name 'Gadget'
end

On definition of the WidgetResource class, JR issues the following warning:
[MODEL NOT FOUND] Model could not be found for WidgetResource. If this a base Resource declare it as abstract.

This is caused by the inherited hook in JSONAPI::Resource, which ends up calling _model_class, and since this happens before model_name is called, the model class cannot be found. Since the call is related to associations, a workaround is to define the has_one :machine on each subclass instead of the superclass. Although, as I mentioned, even with the warning the association still seems to work.

I'm noticing this same behavior.

I've seeing this as well.

Per d46a080, this was closed. Can anyone confirm/deny?

@stevenharman I don't remember seeing this issue anytime recently. I have no proof that it's fixed, but AFAIK it's no longer an issue, and okay to close.

I no longer work on (or have access to) the project where this issue originally came up, so I can't say whether the extraneous log line still occurs there. I will trust @maxkwallace on this one =)

Hello,
I just update 0.8.1 to 0.9.0 and i have the same issue.

authors: JulienItard charliemaffitt grantovich maxkwallace stevenharman

repo: cerebris/jsonapi-resources


text:
Seializer generates incorrect links when using inside an engine

When using JR in an engine, the resource serializer generates invalid URI's as it assumes a resourceful path and infers from the module nesting, however, an engine itself is namespaced and this namespace is included in the generated URI, i.e. for an API engine:
Rails.application.routes.draw do
  mount Api::Engine, at: 'api'
end

Api::Engine.routes.draw do
  namespace :v1 do
    resources :users
  end
end
module Api
  module V1
    class UsersController < ApplicationController
    end
  end
end
module Api
  module V1
    class UserResource < JSONAPI::Resource
      model_name 'Api::User'

      attribute :email
    end
  end
end

Generates:
{
  "data": [
    {
      "id": null,
      "email": "test@test.com",
      "type": "users",
      "links": {
        "self": "http://localhost:3000/api/v1/users/"
      }
    }
  ]
}

I know that I used resources here rather than jsonapi_resources, but after patching resource_for as described in #91 the error still applies

Sorry to take so long to look at this (vacation and then catching up to do). I'm a bit confused by the engine being named api and the resources also being under and api module. Are you saying the link should be http://localhost:3000/api/api/v1/users/?

Sorry I edited the namespace, the link you posted is actually what it generates, whereas the one I posted is the one I would expect

http://localhost:3000/api/api/v1/users/ is the result I would expect, though I haven't tried the code in an engine. So to me it seems to be working correctly. My understanding of engines is limited, but I thought they were supposed to host the app as normal under the specified path. Correct me if I'm wrong.
If that's the case you could simply remove the Api level module and start with the version, which would give you the path you want.

The rails engine generator generates a namespace with the same name as the engine, and you call isolate namespace to stop anything from leaking into your application code. There will be other cases where people don't want a direct mapping from namespaced class to URI so I think it would be better if it were configurable?

I've just hit this also but I'm not using a Rails Engine—I just namespace my resource classes inside modules, like this:
module MyProject
  class UserResource < JSONAPI::Resource
  end
end

But that produces self links that are "incorrect" for me:
user_resource = MyProject::UserResource.new(user)
JSONAPI::ResourceSerializer.new(MyProject::UserResource).serialize_to_hash(user_resource)
...
"links" => {"self"=>"/myproject/users/417"},

When what I want is /users/417. I've tried to build a custom route formatter which simply returns a blank string for the module route, but that results in links like "links" => {"self"=>"///416"}, I think because of how formatted_module_path works.
Would appreciate any guidance on the right way to do this, I'm newly adopting JSON:API and just hit this.

I decided to just use a V1:: module namespace so that the defaults work correctly for me, but I agree this is a bigger issue for people using Rails Engines to isolate their API code (or anyone whose module structure doesn't map directly to their URLs).
:+1: to making this a bit clearer/easier for that case—if a custom RouteFormatter is the right way to solve it, maybe just some documentation on how to do that would be enough?

I have the same issue, using header based versioning (with versionist gem) and api subdomain.
My routes:
  constraints subdomain: 'api' do
    namespace :api, path: '' do
      api_version( module: 'V1',
          header: {
            name:  'Accept',
            value: 'application/vnd.api+json; company.api.version=1'
          }
      ) do
        jsonapi_resources :users
      end
    end
  end

I need to have my links like api.company.com/users/1 and not api.company.com/api/v1/users/1.

I got around the challenge @thibaudgg describes above with this custom RouteFormatter:
class RemoveAPIFromResourceRoutesFormatter < JSONAPI::RouteFormatter
  class << self
    def format(route)
      route.slice!("API::")
      super
    end
  end
end

JSONAPI.configure do |config|
  config.route_format = :remove_api_from_resource_routes
end

Sadly, this does not work any more with version 0.5.2. :cry: Is there a way to exclude the word "api" from the generated link when I use the subdomain api?

@adomokos did you give a try to https://github.com/cerebris/jsonapi-resources/issues/257#issuecomment-122228952?

authors: AMHOL adomokos fotinakis lgebhardt thibaudgg


text:
Scrollbar on Chrome (Windows machine) is covering up modal content

Issue Description
The scrollbar on Chrome browsers on Windows 10 computers are covering up some of the Modal content.

This is not the case when using IE:

Issue Type

[ ] New Feature
[ ] Enhancement
[X] Bug
[ ] Other

Expected Behavior
The scrollbar shouldn't cover up anything that is listed in the content of the modal
Current Behavior
Currently, the scrollbar is covering up a few pixels of the actual modal content instead of adding space to the other side in Chrome only (Windows machines only).
Steps to Reproduce

Create a Modal that is scrollable with action buttons at the bottom.
Open the Modal in Chrome on a PC and shrink the browser window.

Environment

Component Version: terra-moda": 1.19.0
Browser Name and Version: Chrome 63.0.3239.132
Operating System and version (desktop or mobile): Windows 10 Desktop

I wonder if this may be an issue to how the box-sizing style is set on the element with the scrollbar, it may be set to border-box. We may want to test switching this to content-box.

@bjankord Maybe. I checked the scrollable modal in my VM and it appears to be working fine.
Note: Need to try in Win10. My VM is Win7 running up-to-date Chrome.

@Nino55N Does the scollbar render the same when you have a mouse hooked up to your computer versus when you don't have a mouse plugged into your computer. We've seen odd rendering of scrollbars with that before, not sure if it is what its triggering the issue here.

@bjankord We tired without a mouse as well but still no luck :/

Also @bjankord I should have put how we are using the modal.
We are using several different components inside which may cause the issue:
<Modal>
  <Card>
    <Card.Body>

    </Card.Body>
    <Arrange>
    -- buttons go here
    </Arrange>
  </Card>
</Modal>

Ah, we just released terra-dialog. I'd recommend using this component nested inside of modal rather then the card component. You can see an example of nesting the dialog in the modal here. This example is rendered in the doc site here. If you scroll down that page and then click on the button to open the modal under the Default Modal w/ Dialog section, you'll see the example.

@bjankord We can certainly try, is the terra-dialog component recommended over the card component? Or is the card component going to be deprecated?

The Card is fine. It is just that the Dialog is designed to specifically be consumed inside a modal to provide header, body, and footer. Card is generally consumed in popovers or as its own thing.

@bjankord I was able to replicate this on my mac when I have a mouse plugged in. So I think you are correct with that estimation, do you know of a remedy with this?

I could not recreate the issue with Terra-Abstract-Model since Terra-Modal is now deprecated.
Because of this I am closing the issue. I suggest uplifting to Terra-Abstract-Model. If the issue persists please open a new issue.

authors: AnthonyRoss BenBoersma Nino55N bjankord saedar

repo: cerner/terra-core


text:
[terra-form-select] [a11y] MultiSelect: Move Input into DropdownMenu as a Sibling to Options for Enhanced iOS VoiceOver Navigation

Feature Request
Description

Sub-issue of #2383
Move the MultiSelect input into the dropdown menu as a sibling of the options so that iOS VoiceOver swipe navigation behaves as expected: focus moves from input to the options list.
Constraints

Must be visually identical to current implementation.
Must be functionally identical to current implementation.
Should appropriately handle when the menu isAbove or not (input is at the top when menu is below, input is at the bottom when  menu is above)

Since VoiceOver operates on the DOM order (builds the a11y tree based on DOM order), the DOM order should not change when toggling where the input is rendered

If enough options are present to show a scroll bar, the input shouldn't scroll with the options

Extra Information
Exploration of how to solve this:

code
demo

@ Mentions

@nickpith @bjankord

Closed via #2658


text:
Use uniqueIds for ids on terra-arrange examples.

Issue Description
This implementation of an id for the terra-arrange components doesn't feel like we can be guaranteed a unique id (https://github.com/cerner/terra-core/blob/f9846b168e06d5e13a346b6176234d3ebf73b38a/packages/terra-site/src/examples/arrange/ArrangeAlignment.jsx#L35). We should look into using uniqueId to generate one, and then setting it in componentWillMount as opposed to the constructor.
Issue Type

[ ] New Feature
[x] Enhancement
[ ] Bug
[ ] Other

Expected Behavior
Look into using uniqueId to generate one, and then setting it in componentWillMount as opposed to the constructor.
Current Behavior
Id for example is set with the following:
class ArrangeAlignment extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      id: Math.floor(Math.random() * 0xFFFF),
    };
    this.getId = this.getId.bind(this);
    this.handleSelectChange = this.handleSelectChange.bind(this);
  }

  getId(name) {
    return name + this.state.id;
  }

Released in terra-site@1.11.0

authors: JakeLaCombe bjankord


text:
Implement configurable IssuerSetupTimeout (compliments #5084)

This PR compliments #5084, as this seems to be a stale PR.

Pull Request Motivation
Some ACME providers take a long time to respond, where a hardcoded 10 seconds timeout is insufficient to request certificates, which results in a context deadline exceeded.
This PR should fix:

#5080
cert-manager/website#583

Kind
feature
Release Note

Added IssuerSetupTimeout flag for controller to override context timeout for slow responding ACME API's

/assign @sgtcodfish

Thank you for the PR!
I think these timeouts is definitely an issue we should solve soon.
My concern is whether it is actually only issuer setup in all cases that times out or whether for the same or other slow CAs some steps in issuance process are also slow.
If it is the latter then we should probably have a single flag with which all these timouts can be configured as if we merge this PR, but then discover that we need to also allow for longer timouts for issuance, it will then be a lengthy process of deprecating this flag and adding another as well as for users having to reconfigure with another flag.

For me configuring this timeout alone resolved the issues I had with my slow CA (Sectigo). I understand your concerns on having to implement other timeouts in the future, but that doesn't seem to be an issue at this time.

Thanks @JoooostB ! It would be good to hear also from some Venafi users as that was another of slow CAs
Generally I'm wondering whether it's not worth to still add a flag that allows to configure the timeout for all issuance related steps- I am not sure we can really prove that for all cases where we time out when connecting to a slow external CA it's always only the account setup step that is slow (and I cannot see any downsides to using that timeout for all issuance steps except for that it would be a bit more work)

I also had timeout issues with Sectigo on the certificate side of things. But IMO. since they are two different operations, their timeout could be configured on different variables.
(If you want, I'm available to implement the timeout configuration on the certificate side of things)

I'm gonna add a talking point about this in our bi-weekly meeting this week. Hopefully we should be able to make a choice on how to proceed with this!

https://github.com/cert-manager/cert-manager/issues/5108 This is probably a related issue, in regards to issuance timeouts.
I have experience that as well when using Sectigo (OV Validated certs)

I'm experiencing issues with Sectigo not only with the initial setup of a Issuer or ClusterIssuer but also with certificates issuance.
I submitted a new request a half hour ago but I still get such errors:
E0601 11:16:15.407810       1 controller.go:163] cert-manager/orders "msg"="re-queuing item due to error processing" "error"="error creating new order: context deadline exceeded" "key"="cattle-system/rancher-ssl-cert-8ntp4-331559541"
I noticed that the time between retries increases after each failed attempt, a sort of exponential backoff algorithm that  causes very long times before a certificate is issued if it still fails after the first 4-5 attempts.
Bumping the default timeout from 10 to a least 20 seconds could probably mitigate most problems.

We discussed this in our biweekly meeting on Wednesday last week!
The general consensus was that we should start by making the smallest possible change here. That might be as small as only changing the hardcoded timeout for creating an issuer, and not touching anything else.
I've been asking for people to give feedback on how long their issuers take to set up so we can get a rough estimate on how long the default should be.
As @irbekrm mentioned above, this change will not just affect creating issuers, and I think people are nervous about using a really broad brush here and changing the other timeouts.
Is it possible for this PR to be changed to only change the timeout for creating issuers? The exact value we should default to might vary based on what people say but somewhere between 30s-120s is looking likely.

I'm afraid that raising the hard coded timeout only for issuer creation would not resolve all problems, as I and other users reported the problem occurs also during certificate issuance.

@SgtCoDFish the timeout for cluster issuer, in my opinion, is trivial compared to timeouts when issuing certs, as that's done more often than creating new issuers.
However, I see the benefit of not scope creeping this PR, and keeping it to issuers, but I would like to see a flag for certs too not too long down the line.
In our case, we have already created our issuers, so that's not an issue for us anymore. But now I have to tell the teams they need to wait ~8 hours till the certificate is in the cluster.

@SgtCoDFish In my opinion, extending the static timeout to 60 seconds would resolve 99% of the issues. I will modify this PR to reflect that change.

@SgtCoDFish the timeout for cluster issuer, in my opinion, is trivial compared to timeouts when issuing certs, as that's done more often than creating new issuers. However, I see the benefit of not scope creeping this PR, and keeping it to issuers, but I would like to see a flag for certs too not too long down the line.

I totally hear what you're saying. We'll try to address issuance as well!

/kind bug
/ok-to-test
/cherry-pick release-1.7
/cherry-pick release-1.8

/cherry-pick release-1.8
(I think the bot only handles one cherry pick at a time :cherries: )

I'm running into context-timeout with zerossl too, after trying this PR out, I found that the logging middleware also has a hard coded 10 second timeout that was killing the context.
https://github.com/cert-manager/cert-manager/blob/master/pkg/acme/client/middleware/logger.go#L30-L32
I suspect there are more places where issuerSetupTimeout will need to be propagated.

I'm running into context-timeout with zerossl too, after trying this PR out, I found that the logging middleware also has a hard coded 10 second timeout that was killing the context.

Thank you for pointing this out! I think it's super odd that we have that logging middleware adding a timeout; I think that needs to be removed entirely, which I'll try to look into now!

#5206 will need to merge before we can merge this!

I wanted to provide an update on this PR just to keep people in the loop!
I've been researching this a bunch and discussing it with other maintainers, trying to work out how we should proceed with this.
I'm still hopeful that we'll be able to get a fix made for cert-manager 1.9, but I might have to write up a quick design doc to explain the tradeoffs to the other maintainers and to work out what kinds of changes might be acceptable to everyone.
There's concern that if we make a change now we could tie our hands or do something in a way that would make things harder to improve in the future. I'm not really hugely concerned by that, but we definitely don't want to do the wrong thing now!
I'll keep you posted on what's going on!
TL;DR: I'm still looking into this!

Thank you again for raising this PR and for everyone who's been involved in this process!
I've created a separate PR - #5226 - which includes one of the commits from this PR as well as some extra stuff which looks to be required in order to increase these timeouts. That new PR implements the design document I wrote in #5214 to justify this change.
I'm increasingly hopeful that we should be able to get this merged before cert-manager 1.9 and then backported into the 1.8 and 1.7 release branches!
In the meantime, I'm going to close this PR since #5226 should allow me to make any requested changes by reviewers very quickly :+1:
Thank you again to everyone on this PR (and to everyone involved in #5084 ) for the efforts you've made so far!

authors: JoooostB MilheiroSantos SgtCoDFish fablarosa irbekrm jgreat omBratteng

repo: cert-manager/cert-manager


text:
fix: expose ALPN in TLS handshake

New versions of gRPC-go are enforcing the h2 ALPN to be presented during the TLS handshake. See
https://pkg.go.dev/google.golang.org/grpc/internal/envconfig#pkg-variables GRPC_ENFORCE_ALPN_ENABLED. The TLS server here isn't automatically getting this set due to usage of GetConfigForClient.
This properly sets it.
Without this, istio-csr will be incompatible with Istio 1.24, which upgrades the gRPC version. Note this can be worked around by setting GRPC_ENFORCE_ALPN_ENABLED=false on the proxy container, which Istio is able to do -- so there is an escape hatch for users.
The Istio logs look like
"transport: authentication handshake failed: credentials: cannot check peer: missing selected ALPN property"

cc @inteon

Also, do you know where in code this is normally auto-set when we are not using GetConfigForClient?

credentials.NewTLS() from gRPC auto adds it

Could you add a tests/ modify our tests to make sure GRPC_ENFORCE_ALPN_ENABLED now works & will keep working in the future?

Should we just add a test for Istio 1.24 directly? Can use a pre-release in the meantime

Adding an Istio 1.24 test sounds like a great solution.

@howardjohn In order to test istio 1.24, we will have to add a file here: https://github.com/cert-manager/istio-csr/tree/main/make/config/istio.
We can locally test the test using the following command:
ISTIO_VERSION="1.24.0-alpha.0" make test-e2e

@howardjohn In order to test istio 1.24, we will have to add a file here: https://github.com/cert-manager/istio-csr/tree/main/make/config/istio.
We can locally test the test using the following command: ISTIO_VERSION="1.24.0-alpha.0" make test-e2e

Thanks, added it and also https://github.com/cert-manager/testing/pull/1066/files

The errors were in the istio-proxy logs in my experience

/approve
/lgtm

Adding even though this has merged: I saw these errors in istio-proxy in the e2e tests without this change:
2024-10-25T10:13:04.992535Z     error   citadelclient   failed to sign CSR: create certificate: rpc error: code = Unavailable desc = connection error: desc = "transport: authentication handshake failed: credentials: cannot check peer: missing selected ALPN property"

I

authors: SgtCoDFish howardjohn inteon

repo: cert-manager/istio-csr


text:
[Release v1.12.4]: update installation instructions to 1.12.4

I forgot to do that in #1277.

/cc @inteon

repo: cert-manager/website


text:
Google indexuje URL i tam, kde by neměl

Google bohužel indexuje i URL uvnitř JSON dat na stránce, takže to pak z jeho pohledu vypadá, že například z každé stránky odkazujeme na všechny naše projekty. Zatím nevíme o žádných negativních dopadech toho chování, ale dovedu si představit, že by z toho mohl koukat nějaký SEO průšvih. Zkusme se třeba poptat u Next.js, jestli je nenapadá, co s tím.

V diskuzním fóru Next.js už tohle někdo řešil, ale zatím to na rychlé řešení nevypadá. Pošťouchl jsem, uvidíme.

Tohle se případně asi vyřeší přechodem na Next 13 a serverové komponenty, protože se nám posune síťová hranice mezi frontendem a backendem a nebude už potřeba tolik dat tahat přes JSON.

repo: cesko-digital/web


text:
type hierarchy should show Java supertypes

@bjansen just gave me a clue how.

Done!

repo: ceylon/ceylon-ide-intellij


text:
cleaned up init data

@kurtw @richaagarwal

It would be ideal to get this logic into setup_sites.py instead and use that, but looks good :+1:

authors: kave richaagarwal

repo: cfpb/cfgov-refresh


text:
Spellcheck: Installation.md

Documentation spellcheck: Installation.md.
Changes
Couple of small spelling amendments:
Github -> GitHub
Reinstall -> Re-install.
No functional changes to code.
Checklist

[x] Changes are limited to a single goal (no scope creep)
[x] Code can be automatically merged (no conflicts)
[x] Code follows the standards laid out in the front end playbook
[ ] Passes all existing automated tests
[ ] New functions include new tests
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged
[ ] Visually tested in supported browsers and devices
[ ] Project documentation has been updated (including the "Unreleased" section of the CHANGELOG)

Hi. Yes, there is actually. The reason is consistency. Re-install appears in usage.md too, so I thought it might be good to make those consistent.

OED uses no hyphen, but CFPB's style guide is based on AP, which calls for the hyphen. I vote for the change.

Re-install appears in usage.md too, so I thought it might be good to make those consistent.

Heh, so it does. Consistency is always good. I think "reinstall" would be preferable, in both places.

@higs4281 I think you're mistaken about AP, at least in the 2015 version on my desk. It says follow Webster's New World College Dictionary, but hyphenate if the last letter of the prefix is the same as the first letter after the prefix.

I'm looking at the AP guide available via our library.

On the second ballot, I change my vote to reinstall everywhere. Sorry, @Newman101

Sure, I'll just change the original one to reinstall then. No worries.

Consistency issue is now amended, as requested. Branch updated.

Thanks, @Newman101! Your contributions are very much appreciated.


text:
Updating Sauce labs instructions

Updating Sauce labs instructions
Checklist

[ ] PR has an informative and human-readable title
[ ] Changes are limited to a single goal (no scope creep)
[ ] Code can be automatically merged (no conflicts)
[ ] Code follows the standards laid out in the development playbook
[ ] Passes all existing automated tests
[ ] Any change in functionality is tested
[ ] New functions are documented (with a description, list of inputs, and expected output)
[ ] Placeholder code is flagged
[ ] Visually tested in supported browsers and devices
[ ] Project documentation has been updated
[ ] Reviewers requested with the Reviewer tool :arrow_right:

Unrelated to the docs, but opened https://github.com/cfpb/cfgov-refresh/issues/3506

Please test gulp test:acceptance --specs=header.feature, pagination.feature, otherwise looks GTG

authors: anselmbradford sebworks


text:
Add spacing when long lists of jump links wrap

Thanks to @Scotchester for the suggestion.
To test, visit a page like https://cfpb.github.io/design-system/components/buttons in a narrow browser, and observe how the buttons wrap.

Current
With this change

We have a spaced list modifier here, but it likely doesn't satisfy what you're after. There are two options to tighten up this change:
OPTION A: a new modifier
For this option we create a new modifier, maybe m-list__spaced-items or similar, and the CSS would be:
.m-list__spaced-items,
.m-list__spaced-items > .m-list_item {
    margin-bottom: unit( 15 / @base-font-size-px, em );
}

And the markup would be:

OPTION B: augment existing modifier
It appears the m-list__spaced modifier is intended for vertical lists, not horizontal, so you could make your adjustments when both the __horizontal and __spaced modifiers are present.
.m-list__horizontal.m-list__spaced {
    &,
    .m-list_item + .m-list_item {
        // Negate existing spaced styles
        margin-top: 0 !important;
    }

    &,
    & > .m-list_item {
         margin-bottom: unit( 15 / @base-font-size-px, em );
    }
}

And the markup would be:

Hopefully those both work. I worked this out in my head, not code

@anselmbradford I've implemented option A. See live at https://deploy-preview-677--cfpb-design-system.netlify.app/design-system/components/buttons.

if this is an official promoted pattern.

Right, I wasn't sure if we wanted this to become official or not.

authors: anselmbradford chosak

repo: cfpb/design-system


text:
Create 2019 Aggregate Report (Loans Purchased by Tract)

"Loans Purchased, BY LOCATION OF PROPERTY AND TYPE OF LOAN"
Loans Purchased by Tract refers to Table 2 from last year.
2017 Report Example: https://ffiec.cfpb.gov/data-publication/disclosure-reports/2017/451965/27180/2
Sample Mockup:

Changes from 2017:

Rows labeled A-G are now above loan types labels in table.

Amount is in whole dollar amount now, as opposed to being rounded to the nearest thousandth (e.g., $ 3 equated to $3000 in the 2017 report; this will now be reported as $3000)

Note: Mockups include "Table B", but this has been revised and table names will not be labeled as letters, but instead as the description of the table.

Implemented in 2019-disclosure branch

authors: chynnakeys wpears

repo: cfpb/hmda-pub-ui


text:
design updates

@wpears - a bunch of design changes and the last one ... for now :smiling_imp:

a-ok

repo: cfpb/rural-or-underserved-test


text:
feat: add date placeholder logic

This update will add #10.
It also makes sure that the default file name used includes date placeholders. The default file name is now {vaultName}-Backup-%Y_%m_%d-%H-%M-%S.zip

What are you using to style your code? It doesn't seem like there was any consistency between single quotes and double quotes.
I downloaded the EditorConfig For VSCode plugin from the VSCode plugin and used the .editorconfig file that came default from Obsidian. I opened the command palette and did "Format document"

I am still fixing an error with the merge conflict

The code works on my end. I'm open to receive any feedback :)

Thank you for your job!

authors: cgcel trey-wallis

repo: cgcel/obsidian-local-backup


text:
chore(main): release 0.6.0

:robot: I have created a release beep boop
0.6.0 (2023-04-04)
Features

cli: build a nice cli interface for composerize-ts (907e681)

Bug Fixes

options: correct long-opt value detach/d (0c8140f)
parser: don't use errors but more messages to make parsing of partly incorrect cmds possible (c126ec5)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/cgoIT/composerize-ts/releases/tag/v0.6.0 :sunflower:

repo: cgoIT/composerize-ts


text:
Allow for easier evaluation when word is in sim dataset but not in DataFrame

This allows individual readers to fail (yield NaN) during full_word_similarity_evaluation. This was inspired after attempting to evaluate the retrofitting CSV saved in "vsm_03_retrofitting.ipynb", and getting frustrated by not being able to evaluate w/ the single function.
Alternatively, could set the score to 0 instead of np.nan, so that words not found would reduce the Macro-average instead of being ignored, but either way, I think this makes it easier for code from one notebook to interact smoothly with code from another.

Thank you @UpwardTrajectory! This seems very useful, and I think catching and printing any error could be helpful in this context, so I like the generality of the logic.

authors: UpwardTrajectory cgpotts


text:
cg-busy is not working with ionic.

I want to develop spinner that is define on my index.html like

now when i try to load my page it does not show antthing on page, after that i have removed cg-busy attribute then my page is loaded.
after that i have cross check is there any refrence error in js, but no error.
after i have try to put div inside ionic-view like
        <ion-nav-view>

then try to run page- so my 1st login page is run successfully and now i try to move home page after login then i found that my homepage is not loaded.
so i again remove cg-busy tag and try to re run and page is loaded successfully.
so can anyone help me to resolve this issue

That is true. Me too right now.

repo: cgross/angular-busy


text:
🛑 Enchanted Vacations is down

In dd59a00, Enchanted Vacations (https://yourenchantingvacation.com) was down:

HTTP code: 521
Response time: 202 ms

Resolved: Enchanted Vacations is back up in 122ec4b after 41 minutes.

repo: chadburrus/upptime


text:
🛑 Enchanted Vacations is down

In 364462d, Enchanted Vacations (https://yourenchantingvacation.com) was down:

HTTP code: 521
Response time: 237 ms

Resolved: Enchanted Vacations is back up in 6a9a7d1 after 11 minutes.


text:
🛑 Personal is down

In 62da1cb, Personal (https://chadburrus.com) was down:

HTTP code: 521
Response time: 97 ms

Resolved: Personal is back up in b0c063a after 22 hours, 58 minutes.


text:
Chainer: Simplify n_step_gru test

jenkins, test this please

Jenkins CI test (for commit d3a1ee18ae95fe71fdea209e5f582d177c4c6686, target branch master) failed with status FAILURE.

Is this failure related to this PR?

Jenkins, test this please

Jenkins CI test (for commit d3a1ee18ae95fe71fdea209e5f582d177c4c6686, target branch master) failed with status FAILURE.

CI unrelated, merging

authors: chainer-ci dido1998 emcastillo

repo: chainer/chainer


text:
Chainer: Simplify n_step_lstm test

Jenkins, test this please!

Jenkins CI test (for commit e0136fd79c1af45ebfd8cc373506b32a1439c4c7, target branch master) failed with status FAILURE.

The jenkins failure seems to be unrelated

ChainerCI, test this please!

Jenkins CI test (for commit 576e1d69d6fbba0a830da7ff3121fbfdb1964663, target branch master) failed with status FAILURE.

Jenkins, test this please!

Jenkins CI test (for commit 576e1d69d6fbba0a830da7ff3121fbfdb1964663, target branch master) failed with status FAILURE.

Is this failure related to this PR?

Seems jenkins error doesn't relate to this PR so don't mind since pfn ci is working fine

Jenkins, test this please!

Jenkins CI test (for commit 576e1d69d6fbba0a830da7ff3121fbfdb1964663, target branch master) failed with status FAILURE.

Jenkins, test this please!

Jenkins CI test (for commit 576e1d69d6fbba0a830da7ff3121fbfdb1964663, target branch master) failed with status FAILURE.

Jenkins, test this please!

Jenkins CI test (for commit 576e1d69d6fbba0a830da7ff3121fbfdb1964663, target branch master) failed with status FAILURE.

@take-cheeze This pull-request is marked as st:test-and-merge, but there were no activities for the last 3 days. Could you check?

ChainerCI, test this please!

Jenkins CI test (for commit 576e1d69d6fbba0a830da7ff3121fbfdb1964663, target branch master) succeeded!

@take-cheeze can this be merged?

Seems to be OK. Thanks for reminding me.

ChainerCI, test this please!

Jenkins CI test (for commit 576e1d69d6fbba0a830da7ff3121fbfdb1964663, target branch master) failed with status FAILURE.

authors: chainer-ci dido1998 take-cheeze


text:
Support sign function on exporting ONNX

Sign is not implemented as FunctionNode and ONNX-Chainer cannot convert such functions. This PR support them, at first support sign.

Jenkins, test this please!

Jenkins CI test (for commit 6baeeda5b04a6d4eb2a83222acdbe1b9ed0f3821, target branch master) failed with status FAILURE.

Awesome!
I experimented the new mechanism with my n_step_gru converter and it worked.
I'd like to make a pull request for my converter once this pull request is merged.

Jenkins test this please!

Jenkins CI test (for commit 6baeeda5b04a6d4eb2a83222acdbe1b9ed0f3821, target branch master) succeeded!

authors: chainer-ci disktnk msakai take-cheeze


text:
Make MergeInto threadsafe

Just appending to maps or slices is not great in a concurrent universe, so my previous fix was in fact not fixing much of anything, whoops.

Our tests against alpine are all failing because currently they only have riscv64 packages in edge/main.

repo: chainguard-dev/apko


text:
don't use FREE_PORT to get unique container name

When we use ${FREE_PORT} to get a ~random container name, without also running something on that port to "claim" it, we end up getting name conflicts and flaky tests.
Instead of relying on ${FREE_PORT} when we're not going to ~immediately run on that port, just use ${RANDOM}.

Can you send the same to the downstream repo? 🙏

https://github.com/chainguard-images/images-private/pull/465

repo: chainguard-images/images


text:
Update license headers

Summary
The license headers in source files currently state
https://github.com/chains-project/ghasum/blob/82d6993e3d1e0787fa1c947b3c77e076cb33de52/internal/cache/cache.go#L1
this should probably be changed now that the project has been moved to the chains-project organization to reflect the fact that others will likely contribute too.
I'm actually not sure what to put there in this case. I've seen something like "Copyright 2024 ghasum contributors" in the past but also recall reading that's probably not legally meaningful.

Based on some informal research I believe the best way to handle this is to list individual contributors according to the years they contributed (as they make contributions). This can take multiple forms but generally looks something like the below (with variations in separating entries by year or by contributor).
// Copyright 2024-2025 Eric Cornelissen
// Copyright 2025 Alice Bobby

Using something like "ghasum contributors" should only be done if that list is explicitly defined somewhere. As of writing, I'm not a fan of this particular approach.

repo: chains-project/ghasum


text:
Newline character (\n) in tagged template literals becomes "n"

From the comment here: https://github.com/chalk/chalk/issues/12#issuecomment-315685346

When using tagged template literals, \n does not work => n is output and there is no line break.

I just ran into this myself, so I figured I'd do as @Qix- asked.

It looks like part of your processing is eating the \. Multi-line template literals (or anything similar in other languages) always seem like a cool idea until you have code like this...
function run() {
	if (something) {
		if (somethingElse) {
			console.log(`this is the first line
			this is the second`);
		}
	}
}

...producing the output...
this is the first line
			this is the second

...which isn't optimal. You could pull the second line all the way to the margin, but that'd never fly with formatters or linters.
Maybe there's a better way for chalk to detect character escapes (certain character escapes) and not eat them?
As a workaround, it is possible to do something like this, though it's not very attractive:
console.log(chalk`{red NO} but...${'\n'}really, {green YES}`);

I know exactly why this happens and I agree it's not optimal.
@sindresorhus thoughts about this? I can fix it but I'm worried about how we'd release.

Interestingly, while using your library even more (the first good use of tagged template literals I've ever seen -- so slick and clean :+1:), I found out some more constraints for that workaround:
If a color block precedes it, it works:
> console.log(chalk`testing {blue hi}${'\n'}there`)
testing hi
there

If a color block follows it, it eats the \n:
> console.log(chalk`testing hi${'\n'}{blue there}`)
testing hithere

Probably doesn't matter if you know how you think you'd like to change it; but, I thought I'd mention it anyway.

thoughts about this? I can fix it but I'm worried about how we'd release.

It would be a patch release, it's a bug fix.

Hey guys. Just contributing what I can:

This converts to:

As you can see it strips out the newline character. I verified it goes into the function and is stripped out when it returns. Is there any way I can help?

const a = '\\'
chalk`{blue ${a}}`

Chalk will crash in this case.

authors: LitoMore Qix- jtenner nazrhyn sindresorhus

repo: chalk/chalk


text:
Add lost density as OtherQuantity

When running with lossy boundary conditions for the radial transport we should calculate and store the number of particles which are lost in each time step as an OtherQuantity. It should be possible, and rather straightforward, to obtain this by calling AddVectorElements() on the BoundaryCondition for the transport. The lost density is then obtained as this value multiplied by VpVol*dr.

This would go hand in hand with an equation term we need for the new particle source. Let’s discuss this at the next opportunity.

repo: chalmersplasmatheory/DREAM


text:
Added Java port of minecli for Windows compatability

@chamburr @xcb-xwii Can merge?
I tested this. It works, but address has to be inserted in "hostname:port" format. Might fix that someday

This is great work! However, I don't think having the program in two environments would benefit much. It would make maintenance work harder in future.
For Windows, you could look into Windows Subsystems for Linux (WSL). The program is really just intended to run under a Linux environment, since it requires a UNIX shell and journalctl for logs. Without logs, nothing much sets us apart from the alternatives.

I understand. I could try adding logging, but I agree with you. Doing this was fun, though!

repo: chamburr/minecli


text:
Enforce consistency between acknowledgement comment and actual action

Problem
Currently, when a user leaves a comment on a pull request that is detected as an approval, Hoff immediately leaves a comment to acknowledge the approval. In the comment, it says what action it is going to take: https://github.com/channable/hoff/blob/3b525b2f285d37766612ac6a559f603efa5c2898/src/Logic.hs#L288-L322
This means we have duplicate logic: once to leave the comment, and once when actually executing it. This has bitten us multiple times:

https://github.com/channable/hoff/pull/36 (acknowledging unknown pull requests)
When you leave an approval comment on a PR that failed to build, nothing happens (it will remain approved, and it will remain failed), but we still acknowledge it (still an unresolved bug).

Also, when an event happens that clears the approval status (such as pushing a new commit), we have no feedback for this.
Proposed solution
Rather than commenting immediately what action we will take, we can have a per-PR flag “needs feedback”. When we modify a pull request (for example, because it was approved), we set this flag. Then at the end of handling events, we can go over all PRs that need feedback, post a comment about its current status, and clear the flag. The update would then be based on the true state, and not on a prediction of what we expect to do.

It would be good to first add tests that reproduce the cases where we ran into this:

https://github.com/channable/requestmachine/pull/9726#issuecomment-656122873
The fix for #35 already included a test.
#48 This may have been fixed in the meantime, but I’m not sure if there is a test for it — approving a PR while a failed PR with a lower number exists.

@splintah please be aware that this repository is public.

repo: channable/hoff


text:
Server busy with "SSL: inappropriate fallback (_ssl.c:720)" & "SSL: peer did not return a certificate (_ssl.c:720)" Errors

I have set up a Sanic Server supporting SSL_SERVER_AUTH. (with ca_cert).
From clients who has authorized certificates, they are successfully connecting to Server  but who has not, Server also handling these exceptions and becoming busy. Instead of being busy, i want my server directly reject (or even not accept) these connections. You can see following errors which i want to ignore or at least i want to handle them on main function.
Server-Side;
context = ssl.create_default_context(purpose=ssl.Purpose.SERVER_AUTH)
context.load_verify_locations("client.crt")
context.load_cert_chain("server.crt", keyfile="server.key")
ERRORS;
    <uvloop.loop.SSLProtocol object at 0x7f3819055f28>: SSL handshake failed
    protocol: <uvloop.loop.SSLProtocol object at 0x7f3819055f28>
    transport: <TCPTransport closed=False reading=False 0x564cdf49c368>
    Traceback (most recent call last):
      File "uvloop/sslproto.pyx", line 592, in uvloop.loop.SSLProtocol._on_handshake_complete
      File "uvloop/sslproto.pyx", line 171, in uvloop.loop._SSLPipe.feed_ssldata
      File "/usr/lib/python3.5/ssl.py", line 641, in do_handshake
        self._sslobj.do_handshake()
    ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:720)
    <uvloop.loop.SSLProtocol object at 0x7f3819055f28>: SSL error errno:1 reason: PEER_DID_NOT_RETURN_A_CERTIFICATE
    protocol: <uvloop.loop.SSLProtocol object at 0x7f3819055f28>
    transport: <TCPTransport closed=False reading=False 0x564cdf49c368>
    Traceback (most recent call last):
      File "uvloop/sslproto.pyx", line 496, in uvloop.loop.SSLProtocol.data_received
      File "uvloop/sslproto.pyx", line 204, in uvloop.loop._SSLPipe.feed_ssldata
      File "uvloop/sslproto.pyx", line 171, in uvloop.loop._SSLPipe.feed_ssldata
      File "/usr/lib/python3.5/ssl.py", line 641, in do_handshake
        self._sslobj.do_handshake()
    ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:720)
    <uvloop.loop.SSLProtocol object at 0x7f3815f70860>: SSL handshake failed
    protocol: <uvloop.loop.SSLProtocol object at 0x7f3815f70860>
    transport: <TCPTransport closed=False reading=False 0x564cdf4af0c8>
    Traceback (most recent call last):
      File "uvloop/sslproto.pyx", line 592, in uvloop.loop.SSLProtocol._on_handshake_complete
      File "uvloop/sslproto.pyx", line 171, in uvloop.loop._SSLPipe.feed_ssldata
      File "/usr/lib/python3.5/ssl.py", line 641, in do_handshake
        self._sslobj.do_handshake()
    ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:720)
    <uvloop.loop.SSLProtocol object at 0x7f3815f70860>: SSL error errno:1 reason: PEER_DID_NOT_RETURN_A_CERTIFICATE
    protocol: <uvloop.loop.SSLProtocol object at 0x7f3815f70860>
    transport: <TCPTransport closed=False reading=False 0x564cdf4af0c8>
    Traceback (most recent call last):
      File "uvloop/sslproto.pyx", line 496, in uvloop.loop.SSLProtocol.data_received
      File "uvloop/sslproto.pyx", line 204, in uvloop.loop._SSLPipe.feed_ssldata
      File "uvloop/sslproto.pyx", line 171, in uvloop.loop._SSLPipe.feed_ssldata
      File "/usr/lib/python3.5/ssl.py", line 641, in do_handshake
        self._sslobj.do_handshake()
    ssl.SSLError: [SSL: PEER_DID_NOT_RETURN_A_CERTIFICATE] peer did not return a certificate (_ssl.c:720)
    <uvloop.loop.SSLProtocol object at 0x7f3815f70908>: SSL handshake failed
    protocol: <uvloop.loop.SSLProtocol object at 0x7f3815f70908>
    transport: <TCPTransport closed=False reading=False 0x564cdf4c19d8>
    Traceback (most recent call last):
      File "uvloop/sslproto.pyx", line 592, in uvloop.loop.SSLProtocol._on_handshake_complete
      File "uvloop/sslproto.pyx", line 171, in uvloop.loop._SSLPipe.feed_ssldata
      File "/usr/lib/python3.5/ssl.py", line 641, in do_handshake
        self._sslobj.do_handshake()
    ssl.SSLError: [SSL: INAPPROPRIATE_FALLBACK] inappropriate fallback (_ssl.c:720)
    <uvloop.loop.SSLProtocol object at 0x7f3815f70908>: SSL error errno:1 reason: INAPPROPRIATE_FALLBACK
    protocol: <uvloop.loop.SSLProtocol object at 0x7f3815f70908>
    transport: <TCPTransport closed=False reading=False 0x564cdf4c19d8>
    Traceback (most recent call last):
      File "uvloop/sslproto.pyx", line 496, in uvloop.loop.SSLProtocol.data_received
      File "uvloop/sslproto.pyx", line 204, in uvloop.loop._SSLPipe.feed_ssldata
      File "uvloop/sslproto.pyx", line 171, in uvloop.loop._SSLPipe.feed_ssldata
      File "/usr/lib/python3.5/ssl.py", line 641, in do_handshake
        self._sslobj.do_handshake()
    ssl.SSLError: [SSL: INAPPROPRIATE_FALLBACK] inappropriate fallback (_ssl.c:720)

I have a similar issue, although even with a valid stored SSL certificate on the client side, it will deny access to the client.
Ideally, I'd like to reroute HTTP traffic to HTTPS, and refresh client certs. I'm not sure why the client-side cert is not refreshed, as the cert, keyfile, host, nor domain have changed.
After digging around a bit, I attempted to create a custom SSLObject that handled do_handshake() exceptions and pass it to a custom SSLContext which should be passed from app.Run() all the way to the ssl lib. Unfortunately, this problem is in a different space.
UVLoop uses their own handshake in SSLProtocol, and seems to trigger a callback on error.
I think handling the error in that callback is the way to go. Currently freeing up some cycles from other work to delve into callback shenanigans.

Hi @Sunrise17 I think that is because sanic doesn't pass the ssl error from the loop to the app to handle it.
But if you don't mind, you could use my trick below, where I put the sanic app behind nginx and pass the cert from nginx.
THESE ARE COPIED FROM MY PROJECT. I AM NOT SURE THEY CAN BE RUN DIRECTLY
server {
    listen 443 ssl;
    ssl_certificate     /certs/nginx.crt;
    ssl_certificate_key /certs/nginx.key;
    # client certificate
    ssl_client_certificate /certs/ca.crt;
    ssl_verify_client on;
    location / {
        root /frontend;
    }
    location /api {
        # NOTICE: this requires higher version of nginx, or you have to use $ssl_client_cert
        proxy_set_header X-SSL-CERT $ssl_client_escaped_cert;
        proxy_pass http://upstream;
    }
}

@app.middleware('request')
async def set_ssl_context(request):
    cert = request.headers.get('x-ssl-cert')
    if cert is None:
        raise SanicException('Invalid Cert')
    cert = unquote(cert)
    cert = crypto.load_certificate(crypto.FILETYPE_PEM, cert)
    ca_cert = request.app.ca_cert
    store = crypto.X509Store()
    store.add_cert(ca_cert)  # add trusted ca
    store_ctx = crypto.X509StoreContext(store, cert)
    # this line will raise an error if the cert is invalid
    store_ctx.verify_certificate()
    subject = cert.get_subject()
    for name, value in subject.get_components():
        # get info from the cert
        name_map = {
            b'C': 'countryName',
            b'UID': 'userId',
            b'CN': 'commonName',
            b'O': 'organizationName',
        }
        if name in name_map:
            name = name_map[name]
        request.client_cert[name] = value.decode()
    # further operations...

I didn't notice this problem before since I only tested with valid certification and take it for granted that one should reject the invalid request by default...
My previous implementation is like that (where the keys for cert subject are different):
@app.middleware('request')
async def set_ssl_context(request):
    transport = request.transport
    peer_cert = transport.get_extra_info('peercert')
    for term in peer_cert['subject']:
        # notice the difference here
        (key, value), = term
        request.client_cert[key] = value

ca_file = config['ssl']['ca']['cert']
cert = config['ssl']['server']['cert']
key = config['ssl']['server']['key']
context = ssl.create_default_context(purpose=ssl.Purpose.CLIENT_AUTH, cafile=ca_file)
context.set_ciphers('TLSv1.2')
context.verify_mode = CERT_REQUIRED
context.load_cert_chain(cert, keyfile=key)
app.run(ssl=context)

authors: MyNameIsCosmo Sunrise17 fduxiao

repo: channelcat/sanic


text:
test/healthcheck_test.go: verify existing RPCs can proceed

Motivation
The motivation of the PR is to investigate whether existing RPCs (streaming, unary RPCs) can still proceed when its associated subcon is already marked as TRANSIENT_FAILURE after client received the not serving status.
Mainly to address the feedback

My only concern is that based on that https://github.com/grpc/grpc-go/blob/d7f45cdf9ae720256d328fcdb6356ae58122a7f6/health/client.go#L104, it might impact the on-going requests(still in trasfering data) and force to recreate connection. (I haven't verified it yet, update it later)

https://github.com/etcd-io/etcd/issues/16276#issuecomment-1646729943
Background

More in Deep Dive: gRPC - Yuxuan Li, Google and slide
Code analysis
When health server pushes the unhealthy status to client, setConnectivityState(connectivity.TransientFailure in the health client will be called as part of func (ac *addrConn) startHealthCheck in the background as long as the clientConn is not closed.
This connectivity state change will be then eventually propagated to func (b *baseBalancer) UpdateSubConnState and generate a new picker that excludes this SubConn.
So any new RPCs will not be sent to the SubConn while existing RPCs are not impacted.
Verification
To run the new test
cd test

GRPC_GO_LOG_VERBOSITY_LEVEL=2 go test -v -run "Test/HealthCheckWithAddrConnDrain"

=== RUN   Test
=== RUN   Test/HealthCheckWithAddrConnDrain
    tlogger.go:116: INFO server.go:629 [core] [Server #1] Server created  (t=+1.992198ms)
    tlogger.go:116: INFO clientconn.go:316 [core] [Channel #2] Channel created  (t=+2.084992ms)
    tlogger.go:116: INFO clientconn.go:1768 [core] [Channel #2] original dial target is: "whatever:///test.server"  (t=+2.115039ms)
    tlogger.go:116: INFO server.go:817 [core] [Server #1 ListenSocket #3] ListenSocket created  (t=+2.181237ms)
    tlogger.go:116: INFO clientconn.go:1775 [core] [Channel #2] parsed dial target is: {Scheme:whatever Authority: URL:{Scheme:whatever Opaque: User: Host: Path:/test.server RawPath: OmitHost:false ForceQuery:false RawQuery: Fragment: RawFragment:}}  (t=+2.213167ms)
    tlogger.go:116: INFO clientconn.go:1875 [core] [Channel #2] Channel authority set to "test.server"  (t=+2.236468ms)
    tlogger.go:116: INFO resolver_conn_wrapper.go:238 [core] [Channel #2] Resolver state updated: {
          "Addresses": [
            {
              "Addr": "127.0.0.1:52256",
              "ServerName": "",
              "Attributes": null,
              "BalancerAttributes": null,
              "Type": 0,
              "Metadata": null
            }
          ],
          "ServiceConfig": {
            "Config": {
              "Config": null,
              "LB": null,
              "Methods": {}
            },
            "Err": null
          },
          "Attributes": null
        } (service config updated; resolver returned new addresses)  (t=+2.484247ms)
    tlogger.go:116: INFO balancer_conn_wrappers.go:192 [core] [Channel #2] Channel switches to new LB policy "round_robin"  (t=+8.2543ms)
    tlogger.go:116: INFO balancer.go:98 [balancer] base.baseBalancer: got new ClientConn state:  {{[{Addr: "127.0.0.1:52256", ServerName: "", }] 0xc000094240 <nil>} <nil>}  (t=+8.324678ms)
    tlogger.go:116: INFO clientconn.go:897 [core] [Channel #2 SubChannel #4] Subchannel created  (t=+8.429799ms)
    tlogger.go:116: INFO roundrobin.go:50 [roundrobin] roundrobinPicker: Build called with info: {map[]}  (t=+8.48485ms)
    tlogger.go:116: INFO clientconn.go:564 [core] [Channel #2] Channel Connectivity change to CONNECTING  (t=+8.517962ms)
    tlogger.go:116: INFO clientconn.go:1283 [core] [Channel #2 SubChannel #4] Subchannel Connectivity change to CONNECTING  (t=+8.540769ms)
    tlogger.go:116: INFO clientconn.go:1396 [core] [Channel #2 SubChannel #4] Subchannel picks a new address "127.0.0.1:52256" to connect  (t=+8.600348ms)
    tlogger.go:116: INFO balancer.go:183 [balancer] base.baseBalancer: handle SubConn state change: 0xc000010408, CONNECTING  (t=+8.614538ms)
    tlogger.go:116: INFO syscall_nonlinux.go:39 [core] CPU time info is unavailable on non-linux environments.  (t=+8.931579ms)
    tlogger.go:116: INFO clientconn.go:1283 [core] [Channel #2 SubChannel #4] Subchannel Connectivity change to READY  (t=+9.584311ms)
    tlogger.go:116: INFO balancer.go:183 [balancer] base.baseBalancer: handle SubConn state change: 0xc000010408, READY  (t=+9.616043ms)
    tlogger.go:116: INFO roundrobin.go:50 [roundrobin] roundrobinPicker: Build called with info: {map[SubConn(id:4):{{Addr: "127.0.0.1:52256", ServerName: "", }}]}  (t=+9.639118ms)
    tlogger.go:116: INFO clientconn.go:564 [core] [Channel #2] Channel Connectivity change to READY  (t=+9.661999ms)
    tlogger.go:116: INFO clientconn.go:1285 [core] [Channel #2 SubChannel #4] Subchannel Connectivity change to TRANSIENT_FAILURE, last error: connection active but health check failed. status=NOT_SERVING  (t=+10.211725ms)
    tlogger.go:116: INFO balancer.go:183 [balancer] base.baseBalancer: handle SubConn state change: 0xc000010408, TRANSIENT_FAILURE  (t=+10.235345ms)
    tlogger.go:116: INFO clientconn.go:564 [core] [Channel #2] Channel Connectivity change to TRANSIENT_FAILURE  (t=+10.247573ms)
    tlogger.go:116: INFO resolver_conn_wrapper.go:238 [core] [Channel #2] Resolver state updated: {
          "Addresses": [
            {
              "Addr": "fake address",
              "ServerName": "",
              "Attributes": null,
              "BalancerAttributes": null,
              "Type": 0,
              "Metadata": null
            }
          ],
          "ServiceConfig": {
            "Config": {
              "Config": null,
              "LB": null,
              "Methods": {}
            },
            "Err": null
          },
          "Attributes": null
        } ()  (t=+2.086912116s)
    tlogger.go:116: INFO balancer.go:98 [balancer] base.baseBalancer: got new ClientConn state:  {{[{Addr: "fake address", ServerName: "", }] 0xc000094240 <nil>} <nil>}  (t=+2.086983587s)
    tlogger.go:116: INFO clientconn.go:897 [core] [Channel #2 SubChannel #7] Subchannel created  (t=+2.087061181s)
    tlogger.go:116: INFO clientconn.go:1283 [core] [Channel #2 SubChannel #4] Subchannel Connectivity change to SHUTDOWN  (t=+2.08709784s)
    tlogger.go:116: INFO http2_client.go:1016 [transport] [client-transport 0xc00016a000] GracefulClose called  (t=+2.087120556s)
    tlogger.go:116: INFO clientconn.go:1283 [core] [Channel #2 SubChannel #7] Subchannel Connectivity change to CONNECTING  (t=+2.087134428s)
    tlogger.go:116: INFO clientconn.go:1396 [core] [Channel #2 SubChannel #7] Subchannel picks a new address "fake address" to connect  (t=+2.087192422s)
    tlogger.go:116: INFO clientconn.go:1636 [core] [Channel #2 SubChannel #4] Subchannel deleted  (t=+2.087210272s)
    tlogger.go:116: INFO clientconn.go:1454 [core] Creating new client transport to "{Addr: \"fake address\", ServerName: \"test.server\", }": connection error: desc = "transport: Error while dialing: dial tcp: address fake address: missing port in address"  (t=+2.087236461s)
    tlogger.go:116: WARNING clientconn.go:1458 [core] [Channel #2 SubChannel #7] grpc: addrConn.createTransport failed to connect to {Addr: "fake address", ServerName: "test.server", }. Err: connection error: desc = "transport: Error while dialing: dial tcp: address fake address: missing port in address"  (t=+2.087260894s)
    tlogger.go:116: INFO clientconn.go:1285 [core] [Channel #2 SubChannel #7] Subchannel Connectivity change to TRANSIENT_FAILURE, last error: connection error: desc = "transport: Error while dialing: dial tcp: address fake address: missing port in address"  (t=+2.087287678s)
    tlogger.go:116: INFO clientconn.go:564 [core] [Channel #2] Channel Connectivity change to SHUTDOWN  (t=+2.097923858s)
    tlogger.go:116: INFO balancer.go:183 [balancer] base.baseBalancer: handle SubConn state change: 0xc000010408, SHUTDOWN  (t=+2.097963049s)
    tlogger.go:116: INFO controlbuf.go:543 [transport] [client-transport 0xc00016a000] loopyWriter exiting with error: finished processing active streams while in draining mode  (t=+2.09798884s)
    tlogger.go:116: INFO balancer.go:183 [balancer] base.baseBalancer: handle SubConn state change: 0xc00061b110, CONNECTING  (t=+2.098022146s)
    tlogger.go:116: INFO balancer.go:183 [balancer] base.baseBalancer: handle SubConn state change: 0xc00061b110, TRANSIENT_FAILURE  (t=+2.098060178s)
    tlogger.go:116: INFO balancer_conn_wrappers.go:203 [core] [Channel #2] ccBalancerWrapper: closing  (t=+2.098080934s)
    tlogger.go:116: INFO http2_client.go:959 [transport] [client-transport 0xc00016a000] Closing: connection error: desc = "error reading from server: read tcp 127.0.0.1:52257->127.0.0.1:52256: use of closed network connection"  (t=+2.098143071s)
    tlogger.go:116: INFO resolver_conn_wrapper.go:126 [core] [Channel #2] Closing the name resolver  (t=+2.098204814s)
    tlogger.go:116: INFO clientconn.go:1283 [core] [Channel #2 SubChannel #7] Subchannel Connectivity change to SHUTDOWN  (t=+2.098222445s)
    tlogger.go:116: INFO clientconn.go:1636 [core] [Channel #2 SubChannel #7] Subchannel deleted  (t=+2.09826865s)
    tlogger.go:116: INFO clientconn.go:316 [core] [Channel #2] Channel deleted  (t=+2.098288661s)
    tlogger.go:116: INFO types.go:68 [channelz] attempt to delete child with id 4 from a parent (id=2) that doesn't currently exist  (t=+2.098304318s)
    tlogger.go:116: INFO types.go:68 [channelz] attempt to delete child with id 7 from a parent (id=2) that doesn't currently exist  (t=+2.09832953s)
    tlogger.go:116: INFO types.go:68 [channelz] attempt to delete child with id 4 from a parent (id=2) that doesn't currently exist  (t=+2.09834108s)
    tlogger.go:116: INFO http2_server.go:1232 [transport] [server-transport 0xc0003b4000] Closing: EOF  (t=+2.098357493s)
    tlogger.go:116: INFO types.go:68 [channelz] attempt to delete child with id 7 from a parent (id=2) that doesn't currently exist  (t=+2.098384334s)
    tlogger.go:116: INFO controlbuf.go:543 [transport] [server-transport 0xc0003b4000] loopyWriter exiting with error: transport closed by client  (t=+2.098400391s)
    tlogger.go:116: INFO server.go:768 [core] [Server #1 ListenSocket #3] ListenSocket deleted  (t=+2.098428225s)
--- PASS: Test (2.10s)
    --- PASS: Test/HealthCheckWithAddrConnDrain (2.10s)
PASS
ok  	google.golang.org/grpc/test	2.940s

@chaochn47 Thanks! let me try to verify it. I was testing it with containerd. The ongoing streaming request was impacted. Maybe there is only one available service. Will update.

@fuweid Thanks for the verification!