RSA decryption API is very hard to use safely

It's well known that incorrect use of RSA decryption functions leads to Bleichenbacher oracles and thus vulnerability to Bleichenbacher attack, allowing for ciphertext decryption or signature forgery.
What's far less well known is how to use RSA decryption APIs correctly. Two most recent examples close to OpenSSL are CVE-2020-25659 (in pyca/cryptography) and CVE-2020-25657 (in M2Crypto).
As such, I think the issue is with the OpenSSL API: it's very hard to use correctly, so applications that do use it will get it wrong.
While the simple solution is to "just stop using PKCS#1 v1.5 decryption", I don't think it's a realistic approach for OpenSSL, it's too widely deployed for us to remove it completely (e.g. JSON Web Tokens use it).
So, I'd like to propose a change to the way the decryption API works, both the RSA_private_decrypt and EVP_PKEY_decrypt with RSA_PKCS1_PADDING.
My proposal is similar to the one recommended in RFC5246: make decryption always generate a decrypted message, even if padding checks failed.
The Bleichenbacher attack depends on the attacker being able to tell apart the whole systems behaviour in case the
decryption failed because of RSA padding check and between the case where the decryption was successful but later use of the decrypted message failed (for example, because the later HMAC check failed). Note: during the attack, certain fraction of attacker-generated ciphertexts will have valid PKCS#1 padding, may decrypt to the message of expected length or even have expected structure (like the case of TLS pre-master secret starting with the TLS version).
What's important, is that the attacker doesn't know what the ciphertexts he or she sends decrypt to.
Let's consider a case of an attacker that can both perform the API call and get the decrypted value itself.
In such case, if it feeds the messages generated from the Bleichenbacher algorithm to the API and gets some random message
back, the only way of knowing if that value is an actual decrypted value or if it was the randomly generated secret is to generate all possible ciphertexts with that message using all possible padding values: task with a work factor of at least 2^64 (as the minimal padding length is 8 bytes) and far more for if the returned message is smaller.
If the attacker can't see the actual decrypted value, just that the application received a secret message of specific length, then there is no offline operation that it can perform to guess if that message length really came from the ciphertext or if it was the result of the random number generator.
So, I think that both EVP_PKEY_decrypt and RSA_private_decrypt with PKCS#1 padding should use something like HMAC(hash(private_key), ciphertext) to seed an RNG that they then use to select the length of returned message and the contents of it.
Any arguments against it?
(yes, I've read #8446)

I think changing what the current RSA_PKCS1_PADDING does is
probably not a good idea. People will most likely rely on the
current behaviour where an error is returned, and I think your
proposal includes never returning an error. I have no idea how most
applications will then continue with that random data.
So if you want to change the behaviour, I think we need to add a
new option to the function that then documents that behaviour.

I agree changing the behavior to map the error away wouldn't work well. While any application that relies on it is already vulnerable to RSAES-PKCS1-v1_5's flaws, silently changing the success criteria won't make them any better. It's also not clear to me how it'd work anyway. EVP_PKEY_decrypt and RSA_private_decrypt do not know the expected length, so they can't generate the replacement string. (Lengths are closely related to memory access and allocation patterns, so constant-time code needs to understand all the public and private lengths involved.)
Rather, I'd suggest:

Document clearly that, absent some external source of authentication, the existing RSAES-PKCS1-v1_5 decryption API is broken and should not be used. I don't think there is any saving it. Maybe eventually remove it. Though this is made a little tricky by RSAES-PKCS1-v1_5 being the default for RSA keys when using EVP_PKEY_decrypt. (Perhaps OpenSSL 3.0 should start by removing the notion of a default RSAES padding and require callers specify it?)

Study existing protocols' use of RSAES-PKCS1-v1_5, their established workarounds, and build API(s) tailored to them. TLS needs a constant-time swap to random, with a known length. I expect this pattern is common. Go has this API, though note it doesn't cover the funny (and somewhat useless) version check. I believe Go's crypto/tls implementation just doesn't bother with it. Another possibility is an optional parameter. My understanding is SSH does something similar. Are there other patterns? Note this isn't compatible with EVP_PKEY_decrypt / RSA_private_decrypt at all due to the pre-supplied length.

Make sure existing protocols' use of RSAES-PKCS1-v1_5 are suitably deprecated so we can start the (very long) removal clock. We've done this for TLS. I didn't know JWT also used it. That's disappointing. Is there work anywhere to deprecate it in JWT?

@kroeckx wrote:
I think changing what the current RSA_PKCS1_PADDING does is probably not a good idea. People will most likely rely on the current behaviour where an error is returned,

but when would that matter in regular use case, when not under attack?

and I think your proposal includes never returning an error. I have no idea how most applications will then continue with that random data. So if you want to change the behaviour, I think we need to add a new option to the function that then documents that behaviour.

the basic assumption of the attack is that the attacker can force the application to process an RSA ciphertext; the attacker generally also has access to the public key; so the application already must handle messages that will decrypt to unexpected lengths—the attacker can create ciphertexts that decrypt to arbitrary messages already

@davidben wrote:
I agree changing the behavior to map the error away wouldn't work well. While any application that relies on it is likely already vulnerable to RSAES-PKCS1-v1_5's flaws, silently changing the success criteria won't make them any better. It's also not clear to me how it'd work anyway. EVP_PKEY_decrypt and RSA_private_decrypt do not know the expected length, so they can't generate the replacement string. (Lengths are closely related to memory access and allocation patterns, so constant-time code needs to understand all the public and private lengths involved, and tailor the API shape accordingly.)

that's exactly my point, we don't need to know what's the length application expects: if there are two cases that can generate message of given length, namely an actual valid PKCS#1 ciphertext that decrypts to such length, and a ciphertext for which we create a message of a given length, and the attacker can't differentiate between them, then they can't use it as an oracle in the Bleichenbacher attack, making the whole attack fail

Rather, I'd suggest:

Document clearly that, absent some external source of authentication, the existing RSAES-PKCS1-v1_5 decryption API is broken and should not be used. I don't think there is any saving it. Maybe eventually remove it. Though this is made a little tricky by RSAES-PKCS1-v1_5 being the default for RSA keys when using EVP_PKEY_decrypt. (Perhaps OpenSSL 3.0 should start by removing the notion of a default RSAES padding and require callers specify it?)

just because we document it, won't change code that already uses OpenSSL, it will remain insecure
the only option is to remove support for PKCS#1 v1.5, but that's not realistic

* Study existing protocols' use of RSAES-PKCS1-v1_5, their established workarounds, and build API(s) tailored to them. TLS needs a constant-time swap to random, with a known length. I expect this pattern is common. Go has [this API](https://golang.org/pkg/crypto/rsa/#DecryptPKCS1v15SessionKey), though note it doesn't cover the funny (and somewhat useless) version check. I believe Go's crypto/tls implementation just doesn't bother with it. Another possibility is an optional parameter. My understanding is SSH needs a similar constant-time replacement workaround. Are there other patterns? Note this isn't compatible with `EVP_PKEY_decrypt` / `RSA_private_decrypt` at all due to the pre-supplied length.

Is there an SSH Key exchange that uses RSA encryption? I'm not familiar with it, but then, I've only looked at what OpenSSH and libssh support...

Make sure existing protocols' use of RSAES-PKCS1-v1_5 are suitably deprecated so we can start the (very long) removal clock. We've done this for TLS. I didn't know JWT also used it. That's disappointing. Is there work anywhere to deprecate it in JWT?

I don't think so

We also need to be clear on what we can accomplish here. The swap to random isn't a general solution to make RSAES-PKCS1-v1_5 safe. It's something that specifically works for TLS (and SSH?) because of how the rest of the protocol is constructed. For instance, it doesn't work for SSL2.

that's because nobody tried to implement workarounds in SSLv2, we just killed it

that's exactly my point, we don't need to know what's the length application expects: if there are two cases that can generate message of given length, namely an actual valid PKCS#1 ciphertext that decrypts to such length, and a ciphertext for which we create a message of a given length, and the attacker can't differentiate between them, then they can't use it as an oracle in the Bleichenbacher attack, making the whole attack fail
please read the opening post again: I'm proposing a modification that works even if the attacker can get access to the supposedly decrypted value

Ah, I see. My initial thought is that the synthesized length will be unlikely to match the application's expected output size. (E.g. consider a naive TLS-like protocol using OpenSSL's API. It would check for RSA_private_decrypt's error, then check the output size is 48. The synthesized length is most likely not 48 (say 1/245 if picking valid RSA-2048 lengths entirely uniformly), so we still go down an error path, so it seems we still have an S-PKCS-conformity oracle (borrowing terminology from https://eprint.iacr.org/2003/052.pdf), albeit a noisy one.
But that's not really the probabilities we're comparing. The oracle will return 1 if:

the input is S-PKCS-conforming, OR
the input is not PKCS-conforming and the synthesized length happens to be 48

PKCS-conforming and S-PKCS-conforming plaintexts are common enough that we can find them, but they're still fairly rare, so I think the second bucket is... usually larger. (Bleichenbacher's paper bounds the probability of PKCS-conforming ciphertext between 0.18 * 2^-16 and 0.97 * 2^-8 for RSA-512 and higher. For RSA-2048, the first term seems to be around 0.6. The second term is closer to 2^16 if your modulus is a multiple of 8 bits.)
That might be enough to frustrate the attack? This probably needs some more analysis.
(This also assumes we're okay blanket-removing the error case from all uses of RSAES-PKCS1-v1_5. See note below. If we're making a new API, I don't think there's any need to play games with lengths and we can just ask the caller to tell us the length they expect. An API tailored to session keys also nudges developers away from using RSAES-PKCS1-v1_5 as a general-purpose encryption scheme.)

just because we document it, won't change code that already uses OpenSSL, it will remain insecure

Yeah, any fix to RSAES-PKCS1-v1_5's flaws requires changing the behavior of that existing code. Whether that behavior change comes from OpenSSL or the application, depends on the change. We can add a new API with the fixed behavior and get folks to migrate, or we can change the existing API's behavior. The latter gets us where we want faster, but carries a risk of breaking things if applications were relying on the old behavior.
If, say, fixing a bug in the TLS implementation, it makes sense to just change the existing API. But here we're talking about dramatically changing the meaning of an existing API.

the only option is to remove support for PKCS#1 v1.5, but that's not realistic

That's not the only option. We can remove support for that API, which would ask the remaining RSAES-PKCS1-v1_5 users move to the new one.

Is there an SSH Key exchange that uses RSA encryption? I'm not familiar with it, but then, I've only looked at what OpenSSH and libssh support...

I'm not very familiar with SSH either. It looks like I may be wrong here (yay!). For some reason I remembered seeing DecryptPKCS1v15SessionKey used by Go's SSH implementation as well, but now I can't find it. I'm probably misremembering. (Or perhaps it was some old mode and they since removed it?)

that's because nobody tried to implement workarounds in SSLv2, we just killed it

Hehe, you've gotten me to read the DROWN paper again to remind myself how this works. :-) The SSLv3/TLS swap-with-random countermeasure works because we're effectively using the client Finished message (which immediately follows ClientKeyExchange) as an authenticator. That is, whether the counter measure works depends on the rest of the protocol.
SSLv2 doesn't look like that. See section 4.1. It's got a ServerVerify message in between ClientMasterKey (SSLv2 ClientKeyExchange) and client Finished, where the server encrypts some data. When using an export cipher, the master key was too short so the attacker could observe the mitigation triggering some non-determinism. There's also a variation based on some OpenSSL bug (section 5.1). Of course, export ciphers and the OpenSSL bug are a problem in themselves, but the point remains that we depend on the rest of the protocol.
DROWN also relied on the countermeasure using a random substitute. Perhaps some deterministic replacement, like the HMAC you suggest, would have worked.

that's exactly my point, we don't need to know what's the length application expects: if there are two cases that can generate message of given length, namely an actual valid PKCS#1 ciphertext that decrypts to such length, and a ciphertext for which we create a message of a given length, and the attacker can't differentiate between them, then they can't use it as an oracle in the Bleichenbacher attack, making the whole attack fail
please read the opening post again: I'm proposing a modification that works even if the attacker can get access to the supposedly decrypted value

Ah, I see. My initial thought is that the synthesized length will be unlikely to match the application's expected output size. (E.g. consider a naive TLS-like protocol using OpenSSL's API. It would check for RSA_private_decrypt's error, then check the output size is 48. The synthesized length is most likely not 48 (say 1/245 if picking valid RSA-2048 lengths entirely uniformly), so we still go down an error path, so it seems we still have an S-PKCS-conformity oracle (borrowing terminology from https://eprint.iacr.org/2003/052.pdf), albeit a noisy one.

and that noisiness is precisely what helps us, there are two scenarios that can generate S-PKCS conformant plaintextext and the attacker can't differentiate between them, even if the hypothetical TLS implementation using the API leaks like a sieve

But that's not really the probabilities we're comparing. The oracle will return 1 if:

the input is S-PKCS-conforming, OR

the input is not PKCS-conforming and the synthesized length happens to be 48

PKCS-conforming and S-PKCS-conforming plaintexts are common enough that we can find them, but they're still fairly rare, so I think the second bucket is... usually larger. (Bleichenbacher's paper bounds the probability of PKCS-conforming ciphertext between 0.18 * 2^-16 and 0.97 * 2^-8 for RSA-512 and higher. For RSA-2048, the first term seems to be around 0.6. The second term is closer to 2^16 if your modulus is a multiple of 8 bits.)
That might be enough to frustrate the attack? This probably needs some more analysis.

yes, it's enough if we synthesize the message deterministically; as the attack will fail if even one positive guess is incorrect
and we will return "yes, the decryption went fine" for invalid ciphertexts far more often than for valid, so for the few tens of thousands of oracle calls necessary (in the optimistic scenario of system giving positive signal for positive decryptions of any length) with the improved algorithm we're basically certain that at least one guess by the attacker will be incorrect (I mean 0.5^20000 is as good as impossible, and attacker has lower chances than 0.5 of hitting real S-PKCS conforming ciphertexts)

(This also assumes we're okay blanket-removing the error case from all uses of RSAES-PKCS1-v1_5. See note below. If we're making a new API, I don't think there's any need to play games with lengths and we can just ask the caller to tell us the length they expect. An API tailored to session keys also nudges developers away from using RSAES-PKCS1-v1_5 as a general-purpose encryption scheme.)

yes, there might be uses that require to get a real error in case of decryption failure, but I hazard a guess that they are far and few in between, so it's better to document well and special case them than to special case regular use (and fix the 10000 code examples on the Internet that tell how to use the RSA decryption API)

just because we document it, won't change code that already uses OpenSSL, it will remain insecure

Yeah, any fix to RSAES-PKCS1-v1_5's flaws requires changing the behavior of that existing code. Whether that behavior change comes from OpenSSL or the application, depends on the change. We can add a new API with the fixed behavior and get folks to migrate, or we can change the existing API's behavior. The latter gets us where we want faster, but carries a risk of breaking things if applications were relying on the old behavior.
If, say, fixing a bug in the TLS implementation, it makes sense to just change the existing API. But here we're talking about dramatically changing the meaning of an existing API.

I'm afraid it's more like "hope that at least some people migrate, maybe, after much time" than "get folks to migrate"

the only option is to remove support for PKCS#1 v1.5, but that's not realistic

That's not the only option. We can remove support for that API, which would ask the remaining RSAES-PKCS1-v1_5 users move to the new one.

true, but I still worry that there may be users that don't know the size of the decrypted message a-priori... and an API that behaves like I've described will be still needed
also, we have 1.1.1, where we can't remove this API

I did some back-of-the-envelope calculations, and if we assume 20000 oracle calls necessary (very optimistic, for bad version oracle we are usually talking about few million calls) to decrypt an RSA ciphertext, then an oracle having a true positive rate of 0.99555 (a false positive rate of just 0.00445) would still give us a a security margin of 128bits (log_2(0.99555^20000) ~= -128.69)
the only realistic attack scenario is with an attacker having access to the decrypted message, and then looking for the ciphertexts that are max size (not uncommon) and then brute-forcing the padding bytes (embarrassingly parallelizable but not cheap at 2^64 RSA encryptions per oracle call²), since it's the attacker that decides if the decryption was successful or not, the few tens of thousands of oracle calls per decryption are realistic, let's assume the 20k calls, ie. 14 bits, and 2^16 cycles per RSA encryption (what I get from 2048 bit RSA on i7 4790K), we're talking about security margin of about 94 bits, which I think is good enough
² - I'm using 2^64 not the 2^32 birthday paradox because the vast majority of ciphertexts will be false positives (only few thousand true positive oracle calls are necessary to decrypt the ciphertext, most oracle calls are expected to fail) and we can prove that the oracle is a false positive only by exhaustion: by showing that there are no padding bytes that will encrypt to the matching ciphertext

@paulidale added this to the Post 3.0.0 milestone

should I read it as "none of the core OpenSSL developers will work on this before 3.0.0 is out" or as "we will not accept a PR for 3.0.0 alpha that implements this"

should I read it as "none of the core OpenSSL developers will work on this before 3.0.0 is out" or as "we will not accept a PR for 3.0.0 alpha that implements this"

Strictly speaking it means the latter - but I'd argue we should should remove the milestone altogether to mean the former. I personally, have no objection to this being addressed, but we don't have the bandwidth within the dev team to take this on at the moment. Note if there are API changes then it would have be completed and merged before beta 1 to be eligible for inclusion in 3.0.0.

should I read it as "none of the core OpenSSL developers will work on this before 3.0.0 is out" or as "we will not accept a PR for 3.0.0 alpha that implements this"

Strictly speaking it means the latter - but I'd argue we should should remove the milestone altogether to mean the former. I personally, have no objection to this being addressed, but we don't have the bandwidth within the dev team to take this on at the moment. Note if there are API changes then it would have be completed and merged before beta 1 to be eligible for inclusion in 3.0.0.

would you consider addition of a new flag to be an API change? not a new symbol, just a new #define?

would you consider addition of a new flag to be an API change?

Yes - that would be considered an API change IMO.

I've implemented the proposed fix in #13817, please review.

I've implemented the proposed fix in #13817, please review.

merged


check client state on existing manager

Signed-off-by: 662962756<EMAIL_ADDRESS>

 add checkRestClientState on every manager usage


Can't compile it..

I have no clue about Rust, so this may be my fault, but I get:

I actually just wanted to see what it will do with something like this: alias cowlol = cowsay hello | lolcat because pipes are not supported in aliases AFAIK.

Hi @oderwat! Did you try to install it using cargo install nu-alias-converter?
And please tell me the result of these two commands:

rustup show
rustc --version

The issue should be fixed after https://github.com/marcelarie/nu-alias-converter/commit/8ae55428c002a746b0cae0a88aa0a7777646dac3.
Please try to reinstall again with:
cargo install nu-alias-converter

I tried installing with cargo first. I do not use rustup but Nix. Versions are in the image:

Your fix worked. But it seems that the tool is not doing any conversions. I guess your scope was more on using the parsers than to actually make a converter like alias x=a && b alias x = a; b and more complicated stuff like rewriting an alias with pipes into the alias as a custom command / function.
TY for what it is :)

I guess your scope was more on using the parsers than to actually make a converter

Yes, the main goal was to create a tool that "sources" Bash aliases directly in Nushell with minimal overhead. It converts the syntax of the alias declaration and it checks each alias content. If the content of the alias is not valid Nushell code, it comments out the line, with the Nushell compile error, so you can review and manually convert it.
Here a couple of examples:
# alias ggpull = git pull origin $(git symbolic-ref --short HEAD) # Errors: Parse mismatch during operation.
# alias gpdw = git push && sc deploy workers # Errors: The '&&' operator is not supported in Nushell

I’ve considered enhancing the tool in the future to automatically convert the Bash code inside each alias to Nushell code. For now, though, it works well enough for my needs. :)
Thanks for trying it out! If you have any request or ideas that you will make the tool better, please share them, maybe I sparks my inspiration haha


xclip missing parameters

I'm using awesomewm for my window manager, and autopass does not copy contents to clipboard using xclip.
To use the clipboard functionality I have to explicitly usexclip -selection clipboard
e.g.
Line 444:
def copy(attribute, notification_seconds = 5)
  clear_clip_pidfile = '/tmp/autopass-clear-clip.pid'
  value = @entry.attributes[attribute]

  if File.exist?(clear_clip_pidfile)
    Process.kill(:INT, File.read(clear_clip_pidfile).to_i)
  end
  IO.popen('xclip -selection clipboard', 'w+') { |io| io.print(value) }
  notify("Copied #{attribute} to clipboard. Clearing in 45 seconds", :normal, notification_seconds*1000)
  fork do
    File.write(clear_clip_pidfile, Process.pid)
    sleep(45)
    IO.popen('xclip -selection clipboard', 'w+') { |io| io.print('') }
    File.delete(clear_clip_pidfile)
  end
end

Couldnt this behaviour be implemented using a configuration file? (perhaps even to change xclip with another clipboard tool?)

Sure. I'd be happy to add a config option for the clipboard selection. By default xclip uses the x primary clipboard (from which you paste using the middle mouse button or shift+insert). I almost never use -selection clipboard which is why i didn't think of this as an isssue. Would you want to make a pull request for this?

@jreinert done.
See: Pull request


Set OwnerReference on Plugin resources

What this PR does / why we need it:
When creating Pod or DaemonSet resources when running plugins, we didn't
mark them as owned by the Sonobuoy aggregator pod. This meant that if
the aggregator pod was deleted, the resources created by that pod would
be orphaned and would have to be deleted manually. This change sets the
OwnerReference for all resources to be the Sonobuoy aggregator pod so
that when the aggregator is deleted, all child resources are also
deleted.
Signed-off-by: Bridget McErlean<EMAIL_ADDRESS>Which issue(s) this PR fixes

Fixes #818

Special notes for your reviewer:
Release note:
release-note

Marking this as a draft until I add some tests for GetAggregatorPod.

Codecov Report

Merging #845 into master will increase coverage by 0.35%.
The diff coverage is 75%.

@@            Coverage Diff             @@
##           master     #845      +/-   ##
==========================================
+ Coverage   46.29%   46.64%   +0.35%
==========================================
  Files          75       75
  Lines        4800     4828      +28
==========================================
+ Hits         2222     2252      +30
  Misses       2448     2448
+ Partials      130      128       -2

Impacted Files
Coverage Δ

pkg/discovery/discovery.go
7.93% <0%> (ø)
:arrow_up:

pkg/plugin/aggregation/status.go
45.45% <0%> (ø)
:arrow_up:

pkg/client/retrieve.go
4.95% <0%> (ø)
:arrow_up:

pkg/plugin/aggregation/run.go
25.83% <33.33%> (-0.67%)
:arrow_down:

pkg/plugin/driver/daemonset/daemonset.go
66.25% <81.81%> (+1.77%)
:arrow_up:

pkg/plugin/driver/job/job.go
74.19% <81.81%> (+1.77%)
:arrow_up:

pkg/plugin/aggregation/update.go
51.04% <94.11%> (+5.06%)
:arrow_up:

pkg/plugin/aggregation/aggregator.go
83.2% <0%> (+4%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2fb844c...f9a01da. Read the comment docs.


Krishnayalavarthi getchilditem fakepath 4076

PR Summary
This PR addresses the issue #4076 "copy from \fake\share doesn't output error message"
PR Context
PS E:\Tools> Get-ChildItem \\fake\path\*
Get-ChildItem : An object at the specified path \\fake\path does not exist.
At line:1 char:1
+ Get-ChildItem \\fake\path\*
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (\\fake\path:String) [Get-ChildItem], ItemNotFoundException
    + FullyQualifiedErrorId : ItemDoesNotExist,Microsoft.PowerShell.Commands.GetChildItemCommand

PS E:\Tools>

PR Checklist

[ ] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[ ] Summarized changes
[ ] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[ ] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

Breaking changes

[ ] None
OR
[ ] Experimental feature(s) needed

[ ] Experimental feature name(s):

User-facing changes

[ ] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[ ] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

Tooling

[ ] I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
OR
[ ] I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:

Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

Need to make some changes


Button Group dropdown does not render correctly within NavBar #2.0-wip

Adding a button group on the Navbar causes odd issues:
-Caret Disappears
-DropDown placement is off

you need to add a caret element in 2.0 and the markup is different... also - the only browser really developed against at this point is chrome

I took the code directly from the docs and placed it in my markup.. it
worked fine.  If i copy it into the nav-bar, it breaks.
Im not sure what  markup i need to change.
On Mon, Jan 9, 2012 at 2:27 PM, Jacob Thornton <
<EMAIL_ADDRESS>
wrote:

you need to add a caret element in 2.0 and the markup is different... also

the only browser really developed against at this point is chrome

Reply to this email directly or view it on GitHub:
https://github.com/twitter/bootstrap/issues/947#issuecomment-3421556

Yeah, we haven't tested that part of the button groups. We'll look into it.

Resolved.

Awesome! Thank you for all the work you are doing.


All requests returns 503

Starting from version 1.0.21, any request with reactive feign client returns response status 503.
with message "Load balancer does not contain an instance for the service <IP_ADDRESS>"
(same requests worked fine with 1.0.20)

As workaround you need to exclude ReactiveLoadBalancerAutoConfiguration from auto-configuration.
Starting from 2.1.0 Spring added load balancer for WebClient and it breaks current implementation. Will think how to appropriately mange it.

Didn't find good solution. Will update documentation to exclude ReactiveLoadBalancerAutoConfiguration


MAID-2174: Renaming 'getHomeContainer' to 'getOwnContainer'

Renamed 'getHomeContainer' to 'getOwnContainer'

Coverage remained the same at 83.199% when pulling e5dbce42ee0a3fb37cbaa82edae1818642a30695 on safesurfer:correction into b2b19f08db619e01c0c34b446d4c8073b39213f3 on maidsafe:master.

Coverage remained the same at 81.341% when pulling 3f7c3e3f924272180eb6911d1b6af57576506fd1 on safesurfer:correction into e7ac54acc1d54d94135e0f3ba3288437e2bc0776 on maidsafe:master.


chore: updates engine version to 2.18.0-beta.2

What type of PR is this?
feature
What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Additional documentation e.g., usage docs, etc.:

:tada: This PR is included in version 2.13.0-rc.3 :tada:
The release is available on:

npm package (@pre/rc dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.17.0-rc.1 :tada:
The release is available on:

npm package (@pre/rc dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.20.0-development.1 :tada:
The release is available on:

npm package (@rc dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


GET file:///.../drawioEmbed.js net::ERR_FILE_NOT_FOUND

This line gives an error because the file drawioEmbed.js doesn't exist

Fix implemented in version 2.3.0
Thanks for the report


Fix Build Break for Anaheim as consumer of OneAuth

Proposed changes
Fix Build Break for Anaheim. As Anaheim's build system is using -std=c11 so that the usage of the typeof will break their build.
Type of change

[ ] Feature work
[X ] Bug fix
[ ] Documentation
[ ] Engineering change
[ ] Test
[ ] Logging/Telemetry

Risk

[ ] High – Errors could cause MAJOR regression of many scenarios. (Example: new large features or high level infrastructure changes)
[ ] Medium – Errors could cause regression of 1 or more scenarios. (Example: somewhat complex bug fixes, small new features)
[X ] Small – No issues are expected. (Example: Very small bug fixes, string changes, or configuration settings changes)

Additional information
An open question: Is that possible to switch language mode in order to avoid future breaks?

@ruixi1994, what is the default language mode for Xcode 11?

@ruixi1994, what is the default language mode for Xcode 11?

I saw a compiler default option in Xcode but I don't think there is an default language mode? Please correct me if I am wrong.


How to write hierarchical structure of data ?

Hello,
If there is a way in laravel 9 / "predis/predis": "^1.1" app with redis v 5.0.7 to write
hierarchical structure of data and later to read it? If yes please, link to example.
Thanks!

serialize()

Sorry, if I put my question in poor way. I mean how to write hierarchical structure on redis side ? Like ItemRoot and ItemSubRoot1, ItemSubRoot2...


Upgrade to Lucene 9.12.0

@romseygeek Could you please take another look? I've made some changes required due to the new READONCE restriction which has been introduced. (used https://github.com/opensearch-project/OpenSearch/pull/15333 as guide).


Name Doker Container

The comand line should include a name as
docker run -d pogo -p 3000:3000 -p 8081:8081 -it justinleewells/pogo-optimizer
usefull to stop or restart, so an update is as easy as:
docker stop pogo
docker pull justinleewells/pogo-optimizer
docker run -d pogo -p 3000:3000 -p 8081:8081 -it justinleewells/pogo-optimizer
Regards!

Also comand line for configuring portproxy and firewall, can be seted as a .bat:
netsh interface portproxy add v4tov4 listenaddress=<IP_ADDRESS> listenport=8081 connectaddress= connectport=8081
netsh interface portproxy add v4tov4 listenaddress=<IP_ADDRESS> listenport=3000 connectaddress=  connectport=3000
netsh advfirewall firewall add rule name="PoGo 8081" dir=in action=allow protocol=TCP localport=8081
netsh advfirewall firewall add rule name="PoGo 3000" dir=in action=allow protocol=TCP localport=3000

BTW, you rule!

I think the named container could help with those who are not used to docker.
To run the command again, we need to remove the old container with docker rm pogo
Updating can look like this.
docker stop pogo
docker rm pogo
docker pull justinleewells/pogo-optimizer
docker run -d --name pogo -p 3000:3000 -p 8081:8081 -it justinleewells/pogo-optimizer


Inconsistent render behavior between editor and WebGL implementation

Hi,
I've been using Effekseer in a web project for a while now and things have been working fine but I have run into an issue.
The issue being that for certain combinations of elements with different blend modes the end result is different between the editor and the runtime.
I have an example effect set up that highlights my problem: subtract_test.zip
The setup is:
-one pane with blend mode blend, blue in example
-one pane with blend mode subtract, pure white in the example(appears black)
-one particle effect with blend mode add, white in the example
In the editor the final result is like this:

The particles viewed through the panes appear blue.
In the runtime the final result is like this:

The particles viewed through the panes appear white.
Since I've been experimenting with using negative blend panes for tinting an effect, having this inconsistency is rather inconvenient.
And for the record the effect achieved in editor seems preferable from my end at least. But the most important issue is the lack of consistency.
I can only confirm this issue exists when using the WebGL runtime so I am unsure if this an issue specific to that runtime or a core issue.
Kind regards,
TSK

An example of the issue with a more complex effect for reference:

Subtract is complicated. It depends many things

Right, so I suppose it'll be better to try and work around it by using non-subtract blend.


.exe file not exporting!!! womp womp!! :(

Describe your problem here.
Attempting to compile using  lime test windows and getting this error (path is an actual path im not just typing path in lmfao)

And it exports along with the files, but no .exe file is created
Are you modding a build from source or with Lua?
Source
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
Yes. I edited MainMenuState.hx and changed "donate" to my Discord. I changed PlayState.hx to add my own accuracy notes (e.g. "You Suck!, Bad, Good, Sick!". I changed OutdatedState.hx to add my own note saying that people don't need to update to the newer version (if there will be) to play my mod. No code changes. I changed CreditsState.hx to add me there. And finally (oh thank god) I changed HScript.hx to change all "TeaCall"s to "Tea"

haxelib set flixel-addons 3.2.1


Fixes Dispose method on IntersectionObserver to reference this.element

Prevents runtime errors during a dispose call of Uncaught ReferenceError: element is not defined
Resolved #23

@iabshailley
@goosemanjack
@vladgurgov
@jdreetz
If any of you still have access to this repo.


Deprecate transformSamples, *Features, relabundance

Related to PR https://github.com/microbiome/mia/pull/321

Related to CLR + Z:

Easier to perform CLR + Z transformation

Creates maitenance issues and requires additional functionality
Is not hard to perform, we have already examples

In my opinion, we should have only examples on this thing and new method should not be implemented

Ok.


Travis complaining about "uninitialized constant Language::Python::Virtualenv" in php tap

Bug reports:
Since a few days back the Travis instance of homebrew-php is not able to do what its supposed to.  It currently throws out 2 errors
Error: Cannot tap homebrew/core: invalid syntax in tap!
and
uninitialized constant Language::Python::Virtualenv
An example can be seen here
https://travis-ci.org/Homebrew/homebrew-php/builds/149986898
Do you have any idea on what could be causing this ?

The Travis image is not up to date and the php tap is trying to brew tap homebrew/dupes   and brew tap homebrew/versions before running brew update.

@javian it should be fixed now.


Update Supplies Collection

Please do work for this task in a branch called issue-58.
Update supplies to have an inventory

Update supplies Collection similar to Medicine Collection, define the class/type of supply, and shows each inventory.


KeyError on calling du() when use_listings_cache is disabled

What happened:
Calling du() raises KeyError.
What you expected to happen:
It returns the size used.
Minimal Complete Verifiable Example:
import s3fs

s3 = s3fs.S3FileSystem(anon=True, use_listings_cache=False)
url = 's3://<your_s3_url_here>'
s3.du(url) # Raises KeyError

Anything else we need to know?:
du() works when use_listings_cache=True.
Environment:

Dask version: 2021.6.0
Python version: 3.7.9
Operating System: Windows
Install method (conda, pip, source): pip

Would you share the full traceback?

Sure, here you go:
---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
<ipython-input-86-976f31ab2ff1> in <module>
----> 1 s3.du(url)

/srv/jupyterhub/miniconda/lib/python3.7/site-packages/fsspec/asyn.py in wrapper(*args, **kwargs)
     70     def wrapper(*args, **kwargs):
     71         self = obj or args[0]
---> 72         return sync(self.loop, func, *args, **kwargs)
     73
     74     return wrapper

/srv/jupyterhub/miniconda/lib/python3.7/site-packages/fsspec/asyn.py in sync(loop, func, timeout, *args, **kwargs)
     51     event.wait(timeout)
     52     if isinstance(result[0], BaseException):
---> 53         raise result[0]
     54     return result[0]
     55

/srv/jupyterhub/miniconda/lib/python3.7/site-packages/fsspec/asyn.py in _runner(event, coro, result, timeout)
     18         coro = asyncio.wait_for(coro, timeout=timeout)
     19     try:
---> 20         result[0] = await coro
     21     except Exception as ex:
     22         result[0] = ex

/srv/jupyterhub/miniconda/lib/python3.7/site-packages/fsspec/asyn.py in _du(self, path, total, maxdepth, **kwargs)
    388         sizes = {}
    389         # async for?
--> 390         for f in await self._find(path, maxdepth=maxdepth, **kwargs):
    391             info = await self._info(f)
    392             sizes[info["name"]] = info["size"]

/srv/jupyterhub/miniconda/lib/python3.7/site-packages/s3fs/core.py in _find(self, path, maxdepth, withdirs, detail)
    595                     self.dircache[par] = []
    596             if par in sdirs:
--> 597                 self.dircache[par].append(o)
    598
    599         if withdirs:

/srv/jupyterhub/miniconda/lib/python3.7/site-packages/fsspec/dircache.py in __getitem__(self, item)
     60         if self.max_paths:
     61             self._q(item)
---> 62         return self._cache[item]  # maybe raises KeyError
     63
     64     def clear(self):

KeyError: '<your_s3_path_here>'

@isidentical , can you reproduce? I am not seeing this problem.

Just noticed that I had accidentally used the local env versions although I was running this on a server. So the running environment actually had:
dask: 2021.4.1
s3fs: 2021.4.0
Sorry about this! I'd try with the newest version myself, but I can't change the versions on the server and my local doesn't have access to that S3. Also if it makes a difference, the S3 server was anon=False with creds provided with key and secret.

I'll close this fo now, then. Please reopen if the issue reappears.


[Bug]: Language selector is showing on mobile version in single language

Expected Behavior
No response
Actual Behavior
Language selector is showing on mobile version in single language

Possible Solution
No response
Steps to reproduce
No response
What version of PrestaShop integration are you using?
any
What version of Node.js are you using?
any
What browser (and version) are you using?
any
What operating system (and version) are you using?
any
Relevant log output
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

PR: https://github.com/vuestorefront-community/prestashop/pull/77


Custom Access screen improvements

Is your feature request related to a problem? Please describe.
Custom Access screen improvements
https://www.figma.com/proto/4cYWHubrmdayui6VybR3BA/SubWallet-font-2?node-id=2046%3A10754&scaling=min-zoom&page-id=4%3A14

Pls fix 2 problems:

Don't public EVM acc for Substrate DApp
Add cursor = pointer in grant access screen

Scroll bar should be used in this area
Try to migrate the user's previous access data

@Quangdm-cdm Please sure that you haved migrate all allow list from old version

@Quangdm-cdm Other bugs:

Account List is empty even though Connect All in case the previous connect, user choose Cancel
Derivation Account not shown in the List Account in the Connect screen
Quantity of the account is incorrect when wallet have EVM account

fix some bug:

Quatity of the account incorrect when Forget Account

Can't connect All Account in case add account after connected the Dapp

@Quangdm-cdm

The language field in General Setting screen is not shows value in the first visit
To reproduce:

The popup confirm Forget Site should not show when no website request yet.


Gwas

[x] Recover lost multithreading
[ ] Change the default positivity constraint to 0.005?
[x] BATCH_SIZE default change?
[x] Eddie default change for Merge and filter beds?

Documentation Improvements:

[x] Update Contribution guide
[x] Rework Overview of Discovery workflow (simplify diagram)
[x] Describe the output format for both multi-dimensional and simple effects.
[x] Move runtime to TarGene's page
[x] Document Simulation's outputs
[x] clean index of parameters (add simulations)
[x] Examples

[x] PheWAS
[x] GWAS
[x] Interactions

Only hanging question on my side is that the 0.005 threshold seems to be safe from simulation studies and would lead to more estimands beging complete. Should we make this threshold the new default?

Only hanging question on my side is that the 0.005 threshold seems to be safe from simulation studies and would lead to more estimands beging complete. Should we make this threshold the new default?

Can you go into more detail on this? And in the simulation study do you perform the simulation with small cohorts/sample sizes as well? I'm just thinking about the ME-CFS application where we were concerned with small within case treatment frequency.

@joshua-slaughter I did update my message

@joshua-slaughter I did update my message

Yes, I agree that it should probably remain 0.01.

Only hanging question on my side is that the 0.005 POSITIVITY_CONSTRAINT threshold seems to be safe from simulation studies and would lead to more estimands beging complete.
The threshold has been validated for cohorts of size 100 000, 250 000, 500 000.
Preliminary results on 50 000 individuals seem to indicate it should be pushed higher (probably 0.01).
Should we make this threshold the new default or keep it safe to 0.01 thus also working on smaller datasets?

Keep it at 0.01 I think, but if it's an option in the configuration file, you could mention in the docs that this can be changed to 0.005 for larger cohorts.

Thank you @roskamsh for taking the time to look into this PR!


Adds support for focuster.com

This PR adds support for toggle button @ focuster.com
It will show the toggle button on the planning view and the now screen

Thank you for your PR and sorry for the delay; we'll review this week.

Thanks, let me know if you need me to make any changes


Could you please upload the requirements.txt file?

Thanks for your code! However, I found it hard to config the right conda environment. So could you please upload the requirements.txt file or write some guidance command to create the environment?

Hi, did you successfully build the environment for this project?

Hi, did you successfully build the environment for this project?

Yes, this project is based on diffuser. So you can just build the environments with the environment.yml in that project. However, I remember that this project was incomplete, so I didn't follow this project.

Sorry for this late reply. I've been really busy lately.
I have updated this repo and added the installation section in the README. You can install the packages in the environment.yml to launch the experiments.


[BUG] Install rancher on arm64 k3s cluster failed

Rancher Server Setup

Rancher version: 2.7.1
Installation option (Docker install/Helm Chart): Helm Chart

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): k3s(arm64)

Proxy/Cert Details: self-signed-ssl

Information about the Cluster

Kubernetes version:
k3s version v1.24.8+k3s1 (648004e4)
go version go1.18.8

Cluster Type (Local/Downstream): Local

User Information

What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom)
Admin

Describe the bug

The rancher pods are running, but there are more and more helm-operation-xxxx pod been created periodically after executing helm install cmd.
$ kc get pod
NAME                       READY   STATUS    RESTARTS   AGE
rancher-69b49b48c4-wqdw5   1/1     Running   0          5m41s
rancher-69b49b48c4-mh7rx   1/1     Running   0          5m41s
rancher-69b49b48c4-gpbt7   1/1     Running   0          5m41s
helm-operation-2tsng       2/2     Running   0          3m19s
helm-operation-6tpc2       2/2     Running   0          2m16s
helm-operation-jk9k2       2/2     Running   0          74s
helm-operation-g7t6h       2/2     Running   0          11s

To Reproduce

1.create self-signed cert.
2.install rancher by executing cmd:
helm install rancher rancher-stable/rancher \
    --namespace cattle-system \
    --set hostname=rancher.example.com \
    --set bootstrapPassword=admin \
    --set ingress.tls.source=secret \
    --set privateCA=true

Result
The rancher pods are running, but there are more and more helm-operation-xxxx pod been created periodically after executing helm install cmd.
Expected Result

Rancher is successfully installed.
Screenshots

Additional context

the log of rancher pod
$ kc logs rancher-69b49b48c4-gpbt7
Doing /etc/rancher/ssl
2023/02/04 07:17:07 [INFO] Rancher version v2.7.1 (bb1c35fc4) is starting
2023/02/04 07:17:07 [INFO] Rancher arguments {ACMEDomains:[] AddLocal:true Embedded:false BindHost: HTTPListenPort:80 HTTPSListenPort:443 K8sMode:auto Debug:false Trace:false NoCACerts:false AuditLogPath:/var/log/auditlog/rancher-api-audit.log AuditLogMaxage:10 AuditLogMaxsize:100 AuditLogMaxbackup:10 AuditLevel:0 Features: ClusterRegistry:}
2023/02/04 07:17:07 [INFO] Listening on /tmp/log.sock
2023/02/04 07:17:07 [INFO] EnsureSecretForServiceAccount: waiting for secret [rancher-token-sdxr7] to be populated with token
2023/02/04 07:17:07 [INFO] Running in clustered mode with ID <IP_ADDRESS>, monitoring endpoint cattle-system/rancher
2023/02/04 07:17:07 [INFO] Applying CRD features.management.cattle.io
2023/02/04 07:17:08 [INFO] Waiting for CRD features.management.cattle.io to become available
2023/02/04 07:17:08 [INFO] Done waiting for CRD features.management.cattle.io to become available
2023/02/04 07:17:11 [INFO] Applying CRD navlinks.ui.cattle.io
2023/02/04 07:17:11 [INFO] Applying CRD clusters.management.cattle.io
2023/02/04 07:17:12 [INFO] Applying CRD apiservices.management.cattle.io
2023/02/04 07:17:12 [INFO] Applying CRD clusterregistrationtokens.management.cattle.io
2023/02/04 07:17:12 [INFO] Applying CRD settings.management.cattle.io
2023/02/04 07:17:12 [INFO] Applying CRD preferences.management.cattle.io
2023/02/04 07:17:12 [INFO] Applying CRD features.management.cattle.io
2023/02/04 07:17:12 [INFO] Applying CRD clusterrepos.catalog.cattle.io
2023/02/04 07:17:12 [INFO] Applying CRD operations.catalog.cattle.io
2023/02/04 07:17:12 [INFO] Applying CRD apps.catalog.cattle.io
2023/02/04 07:17:13 [INFO] Applying CRD fleetworkspaces.management.cattle.io
2023/02/04 07:17:13 [INFO] Applying CRD bundles.fleet.cattle.io
2023/02/04 07:17:13 [INFO] Applying CRD clusters.fleet.cattle.io
2023/02/04 07:17:14 [INFO] Applying CRD managedcharts.management.cattle.io
2023/02/04 07:17:14 [INFO] Applying CRD clusters.provisioning.cattle.io
2023/02/04 07:17:14 [INFO] Applying CRD clusters.provisioning.cattle.io
2023/02/04 07:17:14 [INFO] Applying CRD rkeclusters.rke.cattle.io
2023/02/04 07:17:14 [INFO] Applying CRD rkecontrolplanes.rke.cattle.io
2023/02/04 07:17:14 [INFO] Applying CRD rkebootstraps.rke.cattle.io
2023/02/04 07:17:15 [INFO] Applying CRD rkebootstraptemplates.rke.cattle.io
2023/02/04 07:17:16 [INFO] Applying CRD rkecontrolplanes.rke.cattle.io
2023/02/04 07:17:16 [INFO] Applying CRD custommachines.rke.cattle.io
2023/02/04 07:17:16 [INFO] Applying CRD etcdsnapshots.rke.cattle.io
2023/02/04 07:17:16 [INFO] Applying CRD clusters.cluster.x-k8s.io
2023/02/04 07:17:16 [INFO] Applying CRD machinedeployments.cluster.x-k8s.io
2023/02/04 07:17:17 [INFO] Applying CRD machinehealthchecks.cluster.x-k8s.io
2023/02/04 07:17:17 [INFO] Applying CRD machines.cluster.x-k8s.io
2023/02/04 07:17:17 [INFO] Applying CRD machinesets.cluster.x-k8s.io
2023/02/04 07:17:18 [INFO] Waiting for CRD machinesets.cluster.x-k8s.io to become available
2023/02/04 07:17:18 [INFO] Done waiting for CRD machinesets.cluster.x-k8s.io to become available
2023/02/04 07:17:19 [INFO] Creating CRD authconfigs.management.cattle.io
2023/02/04 07:17:19 [INFO] Creating CRD groupmembers.management.cattle.io
2023/02/04 07:17:19 [INFO] Creating CRD groups.management.cattle.io
2023/02/04 07:17:19 [INFO] Creating CRD tokens.management.cattle.io
2023/02/04 07:17:19 [INFO] Creating CRD userattributes.management.cattle.io
2023/02/04 07:17:19 [INFO] Creating CRD users.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD apps.project.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD clusterroletemplatebindings.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD dynamicschemas.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD apprevisions.project.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD catalogs.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD catalogtemplates.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD catalogtemplateversions.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD etcdbackups.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD clusteralerts.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD clusteralertgroups.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD globalrolebindings.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD clustercatalogs.management.cattle.io
2023/02/04 07:17:23 [INFO] Waiting for CRD apps.project.cattle.io to become available
2023/02/04 07:17:23 [INFO] Creating CRD globalroles.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD clusteralertrules.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD kontainerdrivers.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD clustermonitorgraphs.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD clusterscans.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD nodedrivers.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD nodepools.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD composeconfigs.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD nodetemplates.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD multiclusterapps.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD nodes.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD multiclusterapprevisions.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD podsecuritypolicytemplateprojectbindings.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD monitormetrics.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD notifiers.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD podsecuritypolicytemplates.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD projectnetworkpolicies.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD projectalerts.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD projectroletemplatebindings.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD projectalertgroups.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD projects.management.cattle.io
2023/02/04 07:17:23 [INFO] Creating CRD projectcatalogs.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD rkek8ssystemimages.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD projectalertrules.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD projectmonitorgraphs.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD rkek8sserviceoptions.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD cisconfigs.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD rkeaddons.management.cattle.io
2023/02/04 07:17:24 [INFO] Done waiting for CRD apps.project.cattle.io to become available
2023/02/04 07:17:24 [INFO] Waiting for CRD apprevisions.project.cattle.io to become available
2023/02/04 07:17:24 [INFO] Creating CRD cisbenchmarkversions.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD roletemplates.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD templates.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD templateversions.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD samltokens.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD templatecontents.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD clustertemplates.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD globaldnses.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD clustertemplaterevisions.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD globaldnsproviders.management.cattle.io
2023/02/04 07:17:24 [INFO] Creating CRD rancherusernotifications.management.cattle.io
2023/02/04 07:17:24 [INFO] Done waiting for CRD apprevisions.project.cattle.io to become available
2023/02/04 07:17:24 [INFO] Waiting for CRD nodes.management.cattle.io to become available
2023/02/04 07:17:24 [INFO] Waiting for CRD globaldnsproviders.management.cattle.io to become available
2023/02/04 07:17:25 [INFO] Done waiting for CRD nodes.management.cattle.io to become available
2023/02/04 07:17:25 [INFO] Waiting for CRD podsecuritypolicytemplates.management.cattle.io to become available
2023/02/04 07:17:25 [INFO] Waiting for CRD globaldnsproviders.management.cattle.io to become available
2023/02/04 07:17:25 [INFO] Done waiting for CRD podsecuritypolicytemplates.management.cattle.io to become available
2023/02/04 07:17:25 [INFO] Waiting for CRD clustertemplaterevisions.management.cattle.io to become available
2023/02/04 07:17:26 [INFO] Waiting for CRD globaldnsproviders.management.cattle.io to become available
2023/02/04 07:17:26 [INFO] Done waiting for CRD globaldnsproviders.management.cattle.io to become available
2023/02/04 07:17:26 [INFO] Waiting for CRD projectmonitorgraphs.management.cattle.io to become available
2023/02/04 07:17:26 [INFO] Done waiting for CRD clustertemplaterevisions.management.cattle.io to become available
2023/02/04 07:17:26 [INFO] Waiting for CRD nodedrivers.management.cattle.io to become available
2023/02/04 07:17:26 [INFO] Done waiting for CRD projectmonitorgraphs.management.cattle.io to become available
2023/02/04 07:17:26 [INFO] Waiting for CRD projectalerts.management.cattle.io to become available
2023/02/04 07:17:27 [INFO] Done waiting for CRD nodedrivers.management.cattle.io to become available
2023/02/04 07:17:27 [INFO] Waiting for CRD nodepools.management.cattle.io to become available
2023/02/04 07:17:27 [INFO] Done waiting for CRD projectalerts.management.cattle.io to become available
2023/02/04 07:17:27 [INFO] Waiting for CRD rancherusernotifications.management.cattle.io to become available
2023/02/04 07:17:27 [INFO] Done waiting for CRD nodepools.management.cattle.io to become available
2023/02/04 07:17:27 [INFO] Waiting for CRD nodetemplates.management.cattle.io to become available
2023/02/04 07:17:28 [INFO] Done waiting for CRD rancherusernotifications.management.cattle.io to become available
2023/02/04 07:17:28 [INFO] Waiting for CRD cisconfigs.management.cattle.io to become available
2023/02/04 07:17:28 [INFO] Done waiting for CRD nodetemplates.management.cattle.io to become available
2023/02/04 07:17:28 [INFO] Waiting for CRD projectnetworkpolicies.management.cattle.io to become available
2023/02/04 07:17:28 [INFO] Done waiting for CRD projectnetworkpolicies.management.cattle.io to become available
2023/02/04 07:17:28 [INFO] Waiting for CRD samltokens.management.cattle.io to become available
2023/02/04 07:17:28 [INFO] Done waiting for CRD cisconfigs.management.cattle.io to become available
2023/02/04 07:17:28 [INFO] Waiting for CRD templates.management.cattle.io to become available
2023/02/04 07:17:29 [INFO] Done waiting for CRD samltokens.management.cattle.io to become available
2023/02/04 07:17:29 [INFO] Waiting for CRD rkeaddons.management.cattle.io to become available
2023/02/04 07:17:29 [INFO] Done waiting for CRD templates.management.cattle.io to become available
2023/02/04 07:17:29 [INFO] Waiting for CRD cisbenchmarkversions.management.cattle.io to become available
2023/02/04 07:17:29 [INFO] Done waiting for CRD rkeaddons.management.cattle.io to become available
2023/02/04 07:17:29 [INFO] Waiting for CRD projectroletemplatebindings.management.cattle.io to become available
2023/02/04 07:17:29 [INFO] Done waiting for CRD cisbenchmarkversions.management.cattle.io to become available
2023/02/04 07:17:29 [INFO] Waiting for CRD templatecontents.management.cattle.io to become available
2023/02/04 07:17:30 [INFO] Done waiting for CRD projectroletemplatebindings.management.cattle.io to become available
2023/02/04 07:17:30 [INFO] Waiting for CRD rkek8sserviceoptions.management.cattle.io to become available
2023/02/04 07:17:30 [INFO] Done waiting for CRD templatecontents.management.cattle.io to become available
2023/02/04 07:17:30 [INFO] Waiting for CRD globaldnses.management.cattle.io to become available
2023/02/04 07:17:30 [INFO] Done waiting for CRD rkek8sserviceoptions.management.cattle.io to become available
2023/02/04 07:17:30 [INFO] Waiting for CRD roletemplates.management.cattle.io to become available
2023/02/04 07:17:31 [INFO] Done waiting for CRD globaldnses.management.cattle.io to become available
2023/02/04 07:17:31 [INFO] Waiting for CRD notifiers.management.cattle.io to become available
2023/02/04 07:17:31 [INFO] Done waiting for CRD roletemplates.management.cattle.io to become available
2023/02/04 07:17:31 [INFO] Waiting for CRD projects.management.cattle.io to become available
2023/02/04 07:17:31 [INFO] Done waiting for CRD notifiers.management.cattle.io to become available
2023/02/04 07:17:31 [INFO] Waiting for CRD projectalertrules.management.cattle.io to become available
2023/02/04 07:17:31 [INFO] Done waiting for CRD projects.management.cattle.io to become available
2023/02/04 07:17:31 [INFO] Waiting for CRD clustertemplates.management.cattle.io to become available
2023/02/04 07:17:32 [INFO] Done waiting for CRD projectalertrules.management.cattle.io to become available
2023/02/04 07:17:32 [INFO] Waiting for CRD templateversions.management.cattle.io to become available
2023/02/04 07:17:32 [INFO] Done waiting for CRD clustertemplates.management.cattle.io to become available
2023/02/04 07:17:32 [INFO] Waiting for CRD podsecuritypolicytemplateprojectbindings.management.cattle.io to become available
2023/02/04 07:17:32 [INFO] Done waiting for CRD templateversions.management.cattle.io to become available
2023/02/04 07:17:32 [INFO] Waiting for CRD projectcatalogs.management.cattle.io to become available
2023/02/04 07:17:32 [INFO] Done waiting for CRD podsecuritypolicytemplateprojectbindings.management.cattle.io to become available
2023/02/04 07:17:32 [INFO] Waiting for CRD rkek8ssystemimages.management.cattle.io to become available
2023/02/04 07:17:33 [INFO] Done waiting for CRD projectcatalogs.management.cattle.io to become available
2023/02/04 07:17:33 [INFO] Waiting for CRD composeconfigs.management.cattle.io to become available
2023/02/04 07:17:33 [INFO] Done waiting for CRD rkek8ssystemimages.management.cattle.io to become available
2023/02/04 07:17:33 [INFO] Done waiting for CRD composeconfigs.management.cattle.io to become available
2023/02/04 07:17:33 [INFO] Waiting for CRD multiclusterapprevisions.management.cattle.io to become available
2023/02/04 07:17:34 [INFO] Done waiting for CRD multiclusterapprevisions.management.cattle.io to become available
2023/02/04 07:17:34 [INFO] Waiting for CRD monitormetrics.management.cattle.io to become available
2023/02/04 07:17:34 [INFO] Done waiting for CRD monitormetrics.management.cattle.io to become available
2023/02/04 07:17:34 [INFO] Waiting for CRD multiclusterapps.management.cattle.io to become available
2023/02/04 07:17:35 [INFO] Done waiting for CRD multiclusterapps.management.cattle.io to become available
2023/02/04 07:17:35 [INFO] Waiting for CRD projectalertgroups.management.cattle.io to become available
2023/02/04 07:17:35 [INFO] Done waiting for CRD projectalertgroups.management.cattle.io to become available
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=ProjectRoleTemplateBinding controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=APIService controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=CatalogTemplate controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=RkeAddon controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=DynamicSchema controller
2023/02/04 07:18:45 [INFO] Starting /v1, Kind=Secret controller
2023/02/04 07:18:45 [INFO] Starting cluster.x-k8s.io/v1beta1, Kind=Machine controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=GlobalDns controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=NodePool controller
2023/02/04 07:18:45 [INFO] Starting project.cattle.io/v3, Kind=App controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=AuthConfig controller
2023/02/04 07:18:45 [INFO] Starting API controllers
I0204 07:18:45.191547      34 leaderelection.go:248] attempting to acquire leader lease kube-system/cattle-controllers...
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=KontainerDriver controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=ClusterTemplateRevision controller
2023/02/04 07:18:45 [INFO] Starting rbac.authorization.k8s.io/v1, Kind=Role controller
2023/02/04 07:18:45 [INFO] Starting rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=Setting controller
2023/02/04 07:18:45 [INFO] Starting provisioning.cattle.io/v1, Kind=Cluster controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=User controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=GlobalRoleBinding controller
2023/02/04 07:18:45 [INFO] Starting /v1, Kind=ConfigMap controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=MultiClusterAppRevision controller
2023/02/04 07:18:45 [INFO] Starting /v1, Kind=ServiceAccount controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=RkeK8sSystemImage controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=Project controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=CisBenchmarkVersion controller
2023/02/04 07:18:45 [INFO] Starting rbac.authorization.k8s.io/v1, Kind=RoleBinding controller
2023/02/04 07:18:45 [INFO] Starting rbac.authorization.k8s.io/v1, Kind=ClusterRole controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=RoleTemplate controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=CatalogTemplateVersion controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=Feature controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=ClusterRoleTemplateBinding controller
2023/02/04 07:18:45 [INFO] Starting /v1, Kind=Endpoints controller
2023/02/04 07:18:45 [INFO] Adding peer wss://<IP_ADDRESS>/v3/connect, <IP_ADDRESS>
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=Node controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=Preference controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=UserAttribute controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=NodeTemplate controller
2023/02/04 07:18:45 [INFO] Starting rke.cattle.io/v1, Kind=RKEBootstrap controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=Token controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=Group controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=ClusterCatalog controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=ClusterTemplate controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=Catalog controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=RkeK8sServiceOption controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=Cluster controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=PodSecurityPolicyTemplate controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=CisConfig controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=ProjectCatalog controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=MultiClusterApp controller
2023/02/04 07:18:45 [INFO] Starting apiregistration.k8s.io/v1, Kind=APIService controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=ClusterRegistrationToken controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=GroupMember controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=NodeDriver controller
2023/02/04 07:18:45 [INFO] Starting catalog.cattle.io/v1, Kind=ClusterRepo controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=GlobalRole controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=PodSecurityPolicyTemplateProjectBinding controller
2023/02/04 07:18:45 [INFO] Starting apiextensions.k8s.io/v1, Kind=CustomResourceDefinition controller
2023/02/04 07:18:45 [INFO] Starting cluster controllers for local
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=Cluster controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=User controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=Token controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=UserAttribute controller
2023/02/04 07:18:45 [INFO] Starting /v1, Kind=Secret controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=GroupMember controller
2023/02/04 07:18:45 [INFO] Starting management.cattle.io/v3, Kind=Group controller
2023/02/04 07:18:45 [INFO] Active TLS secret cattle-system/serving-cert (ver=4947) (count 6): map[field.cattle.io/projectId:local:p-vbfxw listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-localhost:localhost listener.cattle.io/cn-rancher.cattle-system:rancher.cattle-system listener.cattle.io/fingerprint:SHA1=A4A860D0A3F81081120CCDC89303222ACF30B3F1]
2023/02/04 07:18:45 [INFO] Listening on :443
2023/02/04 07:18:45 [INFO] Listening on :80
2023/02/04 07:18:45 [INFO] certificate CN=dynamic,O=dynamic signed by CN=dynamiclistener-ca@1675495068,O=dynamiclistener-org: notBefore=2023-02-04 07:17:48 +0000 UTC notAfter=2024-02-04 07:18:45 +0000 UTC
2023/02/04 07:18:45 [INFO] Updating TLS secret for cattle-system/serving-cert (count: 7): map[field.cattle.io/projectId:local:p-vbfxw listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-localhost:localhost listener.cattle.io/cn-rancher.cattle-system:rancher.cattle-system listener.cattle.io/fingerprint:SHA1=AB9EE7096876D7EF7543A3123B6A55FFB9DF7ACC]
2023/02/04 07:18:45 [INFO] Active TLS secret cattle-system/serving-cert (ver=4969) (count 7): map[field.cattle.io/projectId:local:p-vbfxw listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-localhost:localhost listener.cattle.io/cn-rancher.cattle-system:rancher.cattle-system listener.cattle.io/fingerprint:SHA1=AB9EE7096876D7EF7543A3123B6A55FFB9DF7ACC]
2023/02/04 07:18:45 [INFO] Active TLS secret cattle-system/tls-rancher-internal (ver=4442) (count 2): map[field.cattle.io/projectId:local:p-vbfxw listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/fingerprint:SHA1=1FA2F177ABB949AC7DB824ADFA7F4C2CA099A867]
2023/02/04 07:18:45 [INFO] Listening on :444
2023/02/04 07:18:45 [INFO] Starting cluster agent for local [owner=false]
2023/02/04 07:18:45 [INFO] Starting /v1, Kind=ServiceAccount controller
2023/02/04 07:18:45 [INFO] Starting /v1, Kind=Namespace controller
2023/02/04 07:18:45 [INFO] Starting rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding controller
2023/02/04 07:18:45 [INFO] Starting /v1, Kind=Secret controller
2023/02/04 07:18:45 [INFO] Starting rbac.authorization.k8s.io/v1, Kind=ClusterRole controller
2023/02/04 07:18:45 [INFO] Starting rbac.authorization.k8s.io/v1, Kind=RoleBinding controller
2023/02/04 07:18:45 [INFO] Starting rbac.authorization.k8s.io/v1, Kind=Role controller
2023/02/04 07:18:45 [INFO] Starting /v1, Kind=Secret controller
2023/02/04 07:18:45 [INFO] Updating TLS secret for cattle-system/serving-cert (count: 7): map[field.cattle.io/projectId:local:p-vbfxw listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/cn-localhost:localhost listener.cattle.io/cn-rancher.cattle-system:rancher.cattle-system listener.cattle.io/fingerprint:SHA1=AB9EE7096876D7EF7543A3123B6A55FFB9DF7ACC]
2023/02/04 07:18:45 [INFO] Updating TLS secret for cattle-system/tls-rancher-internal (count: 2): map[field.cattle.io/projectId:local:p-vbfxw listener.cattle.io/cn-<IP_ADDRESS>:<IP_ADDRESS> listener.cattle.io/fingerprint:SHA1=1FA2F177ABB949AC7DB824ADFA7F4C2CA099A867]
W0204 07:18:47.077171      34 warnings.go:80] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
2023/02/04 07:18:47 [INFO] Adding peer wss://<IP_ADDRESS>/v3/connect, <IP_ADDRESS>
2023/02/04 07:18:47 [INFO] Watching metadata for monitoring.coreos.com/v1, Kind=Prometheus
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=Catalog
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=PodTemplate
2023/02/04 07:18:47 [INFO] Watching metadata for cluster.x-k8s.io/v1beta1, Kind=Cluster
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=APIService
2023/02/04 07:18:47 [INFO] Watching metadata for batch/v1, Kind=Job
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ClusterAlertRule
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ProjectMonitorGraph
2023/02/04 07:18:47 [INFO] Watching metadata for traefik.containo.us/v1alpha1, Kind=IngressRoute
2023/02/04 07:18:47 [INFO] Watching metadata for flowcontrol.apiserver.k8s.io/v1beta2, Kind=FlowSchema
2023/02/04 07:18:47 [INFO] Watching metadata for traefik.containo.us/v1alpha1, Kind=IngressRouteUDP
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=TemplateVersion
2023/02/04 07:18:47 [INFO] Watching metadata for batch/v1, Kind=CronJob
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=Service
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=User
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=Node
2023/02/04 07:18:47 [INFO] Watching metadata for rbac.authorization.k8s.io/v1, Kind=RoleBinding
2023/02/04 07:18:47 [INFO] Watching metadata for rke.cattle.io/v1, Kind=RKEControlPlane
2023/02/04 07:18:47 [INFO] Watching metadata for rbac.authorization.k8s.io/v1, Kind=ClusterRole
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=GlobalDnsProvider
2023/02/04 07:18:47 [INFO] Watching metadata for rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding
2023/02/04 07:18:47 [INFO] Watching metadata for storage.k8s.io/v1, Kind=CSINode
2023/02/04 07:18:47 [INFO] Watching metadata for monitoring.coreos.com/v1, Kind=Alertmanager
2023/02/04 07:18:47 [INFO] Watching metadata for autoscaling/v2, Kind=HorizontalPodAutoscaler
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=MultiClusterApp
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=PersistentVolume
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=Cluster
2023/02/04 07:18:47 [INFO] Watching metadata for flowcontrol.apiserver.k8s.io/v1beta2, Kind=PriorityLevelConfiguration
2023/02/04 07:18:47 [INFO] Watching metadata for traefik.containo.us/v1alpha1, Kind=MiddlewareTCP
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=RancherUserNotification
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=Pod
2023/02/04 07:18:47 [INFO] Watching metadata for cluster.x-k8s.io/v1beta1, Kind=Machine
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=CisConfig
2023/02/04 07:18:47 [INFO] Watching metadata for catalog.cattle.io/v1, Kind=App
2023/02/04 07:18:47 [INFO] Watching metadata for traefik.containo.us/v1alpha1, Kind=Middleware
2023/02/04 07:18:47 [INFO] Watching metadata for storage.k8s.io/v1, Kind=VolumeAttachment
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=GroupMember
2023/02/04 07:18:47 [INFO] Watching metadata for helm.cattle.io/v1, Kind=HelmChartConfig
2023/02/04 07:18:47 [INFO] Watching metadata for storage.k8s.io/v1, Kind=StorageClass
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=Template
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=DynamicSchema
2023/02/04 07:18:47 [INFO] Watching metadata for networking.k8s.io/v1, Kind=Ingress
2023/02/04 07:18:47 [INFO] Watching metadata for rke.cattle.io/v1, Kind=CustomMachine
2023/02/04 07:18:47 [INFO] Watching metadata for admissionregistration.k8s.io/v1, Kind=ValidatingWebhookConfiguration
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=ConfigMap
2023/02/04 07:18:47 [INFO] Watching metadata for fleet.cattle.io/v1alpha1, Kind=Cluster
2023/02/04 07:18:47 [INFO] Watching metadata for storage.k8s.io/v1, Kind=CSIDriver
2023/02/04 07:18:47 [INFO] Watching metadata for apiextensions.k8s.io/v1, Kind=CustomResourceDefinition
2023/02/04 07:18:47 [INFO] Watching metadata for traefik.containo.us/v1alpha1, Kind=TraefikService
2023/02/04 07:18:47 [INFO] Watching metadata for rke.cattle.io/v1, Kind=ETCDSnapshot
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=LimitRange
2023/02/04 07:18:47 [INFO] Watching metadata for policy/v1, Kind=PodDisruptionBudget
2023/02/04 07:18:47 [INFO] Watching metadata for apps/v1, Kind=ReplicaSet
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=NodeTemplate
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ClusterCatalog
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=ServiceAccount
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ClusterMonitorGraph
2023/02/04 07:18:47 [INFO] Watching metadata for monitoring.coreos.com/v1, Kind=ServiceMonitor
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ClusterTemplate
2023/02/04 07:18:47 [INFO] Watching metadata for events.k8s.io/v1, Kind=Event
2023/02/04 07:18:47 [INFO] Watching metadata for catalog.cattle.io/v1, Kind=Operation
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=GlobalRole
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=NodeDriver
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=PodSecurityPolicyTemplateProjectBinding
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ClusterRegistrationToken
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=CatalogTemplateVersion
2023/02/04 07:18:47 [INFO] Watching metadata for helm.cattle.io/v1, Kind=HelmChart
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=Preference
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=MonitorMetric
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=GlobalRoleBinding
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ComposeConfig
2023/02/04 07:18:47 [INFO] Watching metadata for rke.cattle.io/v1, Kind=RKECluster
2023/02/04 07:18:47 [INFO] Watching metadata for cluster.x-k8s.io/v1beta1, Kind=MachineHealthCheck
2023/02/04 07:18:47 [INFO] Watching metadata for scheduling.k8s.io/v1, Kind=PriorityClass
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=ResourceQuota
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=CisBenchmarkVersion
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ProjectNetworkPolicy
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=UserAttribute
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=PodSecurityPolicyTemplate
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=NodePool
2023/02/04 07:18:47 [INFO] Watching metadata for project.cattle.io/v3, Kind=AppRevision
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=PersistentVolumeClaim
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=MultiClusterAppRevision
2023/02/04 07:18:47 [INFO] Watching metadata for cluster.x-k8s.io/v1beta1, Kind=MachineDeployment
2023/02/04 07:18:47 [INFO] Watching metadata for traefik.containo.us/v1alpha1, Kind=IngressRouteTCP
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ManagedChart
2023/02/04 07:18:47 [INFO] Watching metadata for monitoring.coreos.com/v1, Kind=PrometheusRule
2023/02/04 07:18:47 [INFO] Watching metadata for coordination.k8s.io/v1, Kind=Lease
2023/02/04 07:18:47 [INFO] Watching metadata for traefik.containo.us/v1alpha1, Kind=ServersTransport
2023/02/04 07:18:47 [INFO] Watching metadata for apps/v1, Kind=StatefulSet
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ProjectAlert
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=Feature
2023/02/04 07:18:47 [INFO] Watching metadata for node.k8s.io/v1, Kind=RuntimeClass
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=RkeK8sSystemImage
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=Namespace
2023/02/04 07:18:47 [INFO] Watching metadata for certificates.k8s.io/v1, Kind=CertificateSigningRequest
2023/02/04 07:18:47 [INFO] Watching metadata for traefik.containo.us/v1alpha1, Kind=TLSOption
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ClusterRoleTemplateBinding
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=CatalogTemplate
2023/02/04 07:18:47 [INFO] Watching metadata for ui.cattle.io/v1, Kind=NavLink
2023/02/04 07:18:47 [INFO] Watching metadata for policy/v1beta1, Kind=PodSecurityPolicy
2023/02/04 07:18:47 [INFO] Watching metadata for apps/v1, Kind=Deployment
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=Notifier
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ProjectAlertGroup
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=KontainerDriver
2023/02/04 07:18:47 [INFO] Watching metadata for rke.cattle.io/v1, Kind=RKEBootstrapTemplate
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=FleetWorkspace
2023/02/04 07:18:47 [INFO] Watching metadata for fleet.cattle.io/v1alpha1, Kind=Bundle
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=RkeAddon
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ClusterAlertGroup
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=Group
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=SamlToken
2023/02/04 07:18:47 [INFO] Watching metadata for traefik.containo.us/v1alpha1, Kind=TLSStore
2023/02/04 07:18:47 [INFO] Watching metadata for cluster.x-k8s.io/v1beta1, Kind=MachineSet
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=AuthConfig
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=TemplateContent
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=RkeK8sServiceOption
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ProjectRoleTemplateBinding
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ClusterAlert
2023/02/04 07:18:47 [INFO] Watching metadata for storage.k8s.io/v1, Kind=CSIStorageCapacity
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=GlobalDns
2023/02/04 07:18:47 [INFO] Watching metadata for apps/v1, Kind=ControllerRevision
2023/02/04 07:18:47 [INFO] Watching metadata for apiregistration.k8s.io/v1, Kind=APIService
2023/02/04 07:18:47 [INFO] Watching metadata for admissionregistration.k8s.io/v1, Kind=MutatingWebhookConfiguration
2023/02/04 07:18:47 [INFO] Watching metadata for apps/v1, Kind=DaemonSet
2023/02/04 07:18:47 [INFO] Watching metadata for rke.cattle.io/v1, Kind=RKEBootstrap
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=ReplicationController
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=RoleTemplate
2023/02/04 07:18:47 [INFO] Watching metadata for networking.k8s.io/v1, Kind=NetworkPolicy
2023/02/04 07:18:47 [INFO] Watching metadata for provisioning.cattle.io/v1, Kind=Cluster
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=Token
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=Project
2023/02/04 07:18:47 [INFO] Watching metadata for project.cattle.io/v3, Kind=App
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=Endpoints
2023/02/04 07:18:47 [INFO] Watching metadata for networking.k8s.io/v1, Kind=IngressClass
2023/02/04 07:18:47 [INFO] Watching metadata for k3s.cattle.io/v1, Kind=Addon
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=Node
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=Setting
2023/02/04 07:18:47 [INFO] Watching metadata for discovery.k8s.io/v1, Kind=EndpointSlice
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ClusterScan
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=Event
2023/02/04 07:18:47 [INFO] Watching metadata for rbac.authorization.k8s.io/v1, Kind=Role
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ProjectCatalog
2023/02/04 07:18:47 [INFO] Watching metadata for catalog.cattle.io/v1, Kind=ClusterRepo
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ProjectAlertRule
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=ClusterTemplateRevision
2023/02/04 07:18:47 [INFO] Watching metadata for /v1, Kind=Secret
2023/02/04 07:18:47 [INFO] Watching metadata for management.cattle.io/v3, Kind=EtcdBackup
W0204 07:18:48.186872      34 warnings.go:80] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
W0204 07:18:48.232672      34 warnings.go:80] policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
2023/02/04 07:18:48 [INFO] Stopping cluster agent for local
2023/02/04 07:18:48 [INFO] Shutting down rbac.authorization.k8s.io/v1, Kind=Role workers
2023/02/04 07:18:48 [INFO] Shutting down rbac.authorization.k8s.io/v1, Kind=RoleBinding workers
2023/02/04 07:18:48 [INFO] Shutting down rbac.authorization.k8s.io/v1, Kind=ClusterRole workers
2023/02/04 07:18:48 [INFO] Shutting down /v1, Kind=Secret workers
2023/02/04 07:18:48 [INFO] Shutting down rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding workers
2023/02/04 07:18:48 [INFO] Shutting down /v1, Kind=Namespace workers
2023/02/04 07:18:48 [INFO] Shutting down /v1, Kind=ServiceAccount workers
2023/02/04 07:18:48 [INFO] Starting cluster controllers for local
2023/02/04 07:18:49 [INFO] Starting rke.cattle.io/v1, Kind=ETCDSnapshot controller
2023/02/04 07:18:49 [INFO] Starting management.cattle.io/v3, Kind=ClusterAlert controller
2023/02/04 07:18:49 [INFO] Starting management.cattle.io/v3, Kind=Notifier controller
2023/02/04 07:18:49 [INFO] Starting cluster agent for local [owner=true]
2023/02/04 07:18:49 [INFO] Starting rbac.authorization.k8s.io/v1, Kind=RoleBinding controller
2023/02/04 07:18:49 [INFO] Starting /v1, Kind=LimitRange controller
2023/02/04 07:18:49 [INFO] Starting /v1, Kind=ConfigMap controller
2023/02/04 07:18:49 [INFO] Starting /v1, Kind=Secret controller
2023/02/04 07:18:49 [INFO] Starting rbac.authorization.k8s.io/v1, Kind=ClusterRole controller
2023/02/04 07:18:49 [INFO] Starting apiregistration.k8s.io/v1, Kind=APIService controller
2023/02/04 07:18:49 [INFO] Starting /v1, Kind=ServiceAccount controller
2023/02/04 07:18:49 [INFO] Starting rbac.authorization.k8s.io/v1, Kind=Role controller
2023/02/04 07:18:49 [INFO] Starting /v1, Kind=ResourceQuota controller
2023/02/04 07:18:49 [INFO] Starting rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding controller
2023/02/04 07:18:49 [INFO] Starting /v1, Kind=Node controller
2023/02/04 07:18:49 [INFO] Starting /v1, Kind=Namespace controller
2023/02/04 07:18:55 [ERROR] Failed to connect to peer wss://<IP_ADDRESS>/v3/connect [local ID=<IP_ADDRESS>]: dial tcp <IP_ADDRESS>:443: i/o timeout
2023/02/04 07:18:57 [ERROR] Failed to connect to peer wss://<IP_ADDRESS>/v3/connect [local ID=<IP_ADDRESS>]: dial tcp <IP_ADDRESS>:443: i/o timeout
2023/02/04 07:19:10 [ERROR] Failed to connect to peer wss://<IP_ADDRESS>/v3/connect [local ID=<IP_ADDRESS>]: dial tcp <IP_ADDRESS>:443: i/o timeout
2023/02/04 07:19:12 [ERROR] Failed to connect to peer wss://<IP_ADDRESS>/v3/connect [local ID=<IP_ADDRESS>]: dial tcp <IP_ADDRESS>:443: i/o timeout
2023/02/04 07:19:25 [ERROR] Failed to connect to peer wss://<IP_ADDRESS>/v3/connect [local ID=<IP_ADDRESS>]: dial tcp <IP_ADDRESS>:443: i/o timeout
2023/02/04 07:19:27 [ERROR] Failed to connect to peer wss://<IP_ADDRESS>/v3/connect [local ID=<IP_ADDRESS>]: dial tcp <IP_ADDRESS>:443: i/o timeout
2023/02/04 07:19:40 [ERROR] Failed to connect to peer wss://<IP_ADDRESS>/v3/connect [local ID=<IP_ADDRESS>]: dial tcp <IP_ADDRESS>:443: i/o timeout
2023/02/04 07:19:42 [ERROR] Failed to connect to peer wss://<IP_ADDRESS>/v3/connect [local ID=<IP_ADDRESS>]: dial tcp <IP_ADDRESS>:443: i/o timeout

the logs of helm-operation-xxxx:
$ kc logs helm-operation-2tsng
Defaulted container "helm" out of: helm, proxy
Waiting for Kubernetes API to be available
Waiting for Kubernetes API to be available
Waiting for Kubernetes API to be available
Waiting for Kubernetes API to be available
Waiting for Kubernetes API to be available
Waiting for Kubernetes API to be available

There is no specific clue that this is related to ARM64.
How did you create self-signed cert？I've come across some users who created invalid certificates.
Did you add the tls-ca secret？
https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/resources/add-tls-secrets#using-a-private-ca-signed-certificate

Thanks, I find the problem. My k3s cluster's network was broken.

I got the same log,can you tell me how do you solve this problem


Equals method on Element

The equals method on Element ignores the Properties. There is a deepEquals method to perform an equals if it is desired that the Properties are included in the test.
What should the default be? The Properties are an integral part of the Element (cf Gaffer1 where the Properties were separate) so suggest the default is that the Properties should be included in the equals.
We want to support multigraphs, where there can be multiple edges between nodes (even of the same element type), so it feels more consistent with that aim to have Properties included in the equals.
If the consensus is to leave it as it is, can we record the justification here?

I agree, properties are an integral part of elements so let’s make the equals method compare everything in an element.

Merged into develop.


Bad sound!!!

Downloading the song and it gives me a very bad quality song.

It was a wrong setup of my player, sorry to bother


RHEL8 has a different package name

There is no package in EPEL for RHEL8 with the name python-gunicorn, but there is python3-gunicorn

Thanks for the contribution. Would be great to add a test to https://github.com/voxpupuli/puppet-python/blob/master/spec/classes/python_spec.rb for the RHEL section, similar to the gunicorn tests for the other distributions.

@kenyon Tests added

@bastelfreak Any idea when this might make a release?

@yakatz I need to get https://github.com/voxpupuli/puppet-python/pull/631 merged before a release


CCH22-19: Adjust the snippets/java/customDirs sample for cc #21816

Fixes #21816
This change moves the references to the Project object out of the execution phase, to make the task compatible with the configuration cache.
Contributor Checklist

[x] Review Contribution Guidelines
[x] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
[x] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
[x] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
[x] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[x] Provide unit tests (under <subproject>/src/test) to verify logic
[x] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[x] Ensure that tests pass sanity check: ./gradlew sanityCheck
[x] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation
[ ] Recognize contributor in release notes

This is looking good, @stopley. Please add your full name and github handle to the list of contributors in the release notes as described here.

Your PR is queued. See the queue page for details.

OK, I've already triggered a build for you.


Request to resolve url is cached even if request is different (has different headers)

Describe the bug
At this moment, in the function createCachedResolver inside Loader.ts, there is code to cache requests to resolve url. When we try to request resolving a url in two separate requests with different headers, the headers of the second one are ignored since the url is already cached. Shouldn't the cache check that both requests are the same and have the same headers?
To Reproduce

Make a request to resolve a url from ODSP
Make another request to resolve a url from ODSP which includes a header param such as isSharingLinkRedeem

Expected behavior
The sl param is included in the resolved url returned
Actual
SL param is not included in the resolved url since the request was already cached.

Opened here: https://dev.azure.com/fluidframework/internal/_workitems/edit/3495


Continuous evaluations for checkpoints for SLURM

🚀 Feature
Simple SLURM job that monitors checkpoints, launches evaluation jobs as checkpoints become available, monitor the evaluation jobs, and amalgamate the results into a single file.
Takes in a configuration file, spits out a metrics file.
Motivation & Examples
We want to automatically train a large swav model on 10+ different evaluations for many different checkpoints as they become available. This will make launching evaluations much easier -- currently, we have to launch evaluations one-by-one.
Note

We only consider adding new features if they are relevant to many users.

If your request is about a new ssl approach addition or new benchmarks, please choose New Benchmark issue template or New SSL Approach issue template.

"Make A faster" is not a valid feature request. "Implement a concrete feature that can make A faster" can be a valid feature request.

PR linked implements this issue.


Get block property the long way round

I have created v1.2.4 of ThePensionsRegulator.Umbraco with this same change in. Not sure how I get this into v5.

@HarryAmmon This is how you get it in, if you add a version bump as well. However I'm not sure whether it's needed as all the tests are passing on your project with the v5 changes merged in.

Tests seem to be passing without this change with the V5 changes merged in so will close this PR


Rail/chain signals are not marking trees/rocks for deconstruction

If you have a blueprint with rail and/or chain signals then the ghost on water version is not marking trees or rocks for deconstruction. They are just sitting there and waiting until the tree/rock is manually removed. Happens with vanilla and only ghost on water installed.
Maybe related to this issue: https://mods.factorio.com/mod/GhostOnWater/discussion/63598d137533c4faf851108c

Probably not related to the list, probably caused by the water ghosts not colliding with trees or rocks.

Seems like rail signals are not handled by the addAlternativeLayerForSpeicalRemovals funtion. Any idea why?
BTW, you can close this issue as duplicate in favor of #21 as they are both nearly the same issue, if you want to.


Changing select timeout of BaseEventLoop?

In some foreign event loops, especially Blender, Kivy and Jupyter,  I was able to run asyncio code quite successfully with a very dirty trick. I copied the _run_once method of the BaseEventLoop class into my own code, and changed only one line, setting the default timeout to a small value. Then I would use whatever means the foreign event loop has to call _run_once and ensure that the other event loop runs smoothly.
While that works, there are some obvious problems. Shouldn't the default timeout for the select call be configurable? Is there a cleaner way to use asyncio in essentially "polling" mode?
The polling method I use certainly isn't the most efficient, but it works well. I'm posting the Issue here because I think that either there is no documentation how to use a polling loop, the default timeout should be made configurable, or I'm completely misunderstanding how asyncio loops are supposed to work.

I guess to

Create custom selector derived from selectors.DefaultSelector.
Override `.select(timeout=None) method with reduce timeout to reasonable small value.
Instantiate event loop directly by asyncio.set_event_loop(asyncio.SelectorEventLoop(CustomSelector()))

The way doesn't require any asyncio code change.

Alternatively, you can make a function that causes itself to be queued to be called .1 sec later using loop.call_later().

@gvanrossum your way is better.

I tried the call_later method in a few tests, and it seems to work. I'll have to see if it still works when the coroutines get more complicated.
The main issue why I can't just implement a specific Event Loop for Kivy, Blender or the Jupyter Kernel is that their event loops don't do asynchronous IO as far as I can determine (I may be wrong). The selector loops from asyncio solve that problem nicely, though.
Thank you both for your input!

Close the issue