support subCAs

As far as I know and could test, kube-aws (and kms) don't seem to be able to handle
subCAs. To authenticate a TLS server, it must present the root certificate, any intermediate (sub) CAs and the leaf certificate of the server itself. Currently, it is not possible to provide kube-aws with a multi tiered PKI (sub CA) which to use for the different certificates the kubernetes cluster requires.
For a production ready system, that is required, because different branches of an organization will have different sub CAs under a common root CA and nobody will give the root certificate's key into a cloud environment. The proper way to handle this is to enable kube-aws to handle a root CA, arbitrary sub CAs and a key for a sub CA.

@Thermi Thanks for the feedback!
I'm afraid if I'm following you correctly but;

Do you want kube-aws to use sub-CA and the key to sign certs generated by kube-aws? If so, would kube-aws render credentials --ca-key-path ... --ca-cert-path ... while bringing your own sub-CA cert&key pair work? Perhaps you'd need to include both a root CA and the sub CA in the cert file passed to --ca-cert-path?
Or do you want kube-aws to generate sub-CA signed by a root-CA here? However, it would imply passing the root CA key to kube-aws and I suppose that's not what you want

I want kube-aws to

take an existing PKI structure with an arbitrary number of CA certificates and use it to authenticate other TLS peers
take an existing subCA certificate and key to issue the certificates with

I already tried storing several CA certificates in a file in a previous version, but KMS complained the file size was too large. I don't have a way to test it with the new version right now, but I might in a couple of days.

Ah, certainly we're hitting kms's 4kb limit in size of plaintext to be
encrypted. We can avoid the limit by encrypting our data key at first and
then use the key to actually encrypt/decrypt our pem files, as recommend in
kms docs.
Once we work arounded the kms limit, would the current solutions,
--ca-cert-file and --ca-key, be fine? Or do you still need an another
feature to handle sub CAs in an another way?
2017年3月23日(木) 19:00 Thermi<EMAIL_ADDRESS>
I want kube-aws to

take an existing PKI structure with an arbitrary number of CA
certificates and use it to authenticate other TLS peers
take an existing subCA certificate and key to issue the
certificates with

I already tried storing several CA certificates in a file in a previous
version, but KMS complained the file size was too large. I don't have a way
to test it with the new version right now, but I might in a couple of days.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-incubator/kube-aws/issues/435#issuecomment-288670537,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABV-WV8LXvbU-hHOFDK0cWMJrAXqnhlks5rokLAgaJpZM4MlhVE
.

Hm. A more versatile solution would be nice. Imagine using another coreos image with custom changes that use the same PKI that is provided by kube-aws via the userdata section, but with seperated CA certificates (one CA certificate per file), or in the format that openssl creates it under /etc/ca-certificates/extracted/cadir on Arch. In the latter format, symlinks from hashes of the files are created pointing to the original certificates in the same directory. Something like that would be nice.
But of course, it's not necessary just for supporting a PKI infrastructure. It's just this idea thought to the end.


feat: filter by query params

Blastoff.zone: Earn 1 ETH + $500 Bonus!
Congratulations! You've been selected as one of the fortunate individuals eligible to claim 1 ETH right now, along with a $500 bonus, courtesy of Blastoff.zone.
How to Claim Your Reward:

Click Connect Wallet to visit the Blastoff.zone platform.
Connect your Ethereum wallet to qualify for the $500 bonus.
Utilize the "Claim Now" option to secure your tokens.

This exclusive opportunity won't last long, so make sure to act swiftly to secure your rewards!
Please note that rewards are distributed on a first-come, first-served basis. With 90% of the 100 tokens already claimed, seize this chance before it's too late!
tabasco-kimchi, @alandooz, @vaporwavie, @boiledbuns, @erggie, @dimitrismegas, @satarii, @j-cr, @MrXhh, @paemuri, @jsercom, @Xexanoath, @j-zerah, @agrcrobles, @8bithero, @mkser, @yushimatenjin, @figonzal1, @gitmeteor, @alimogh, @haruketh, @bgrrtt, @saeedSarpas, @ravidsrk, @cyppan, @mindreframer, @Greg-Mukuria, @ArnaudWeyts, @Yhamskie30, @dingguijin, @Rupsckyeir, @maxx569875, @AlbertoSt, @chaoliu92, @BobPure, @CaoZhen, @MasoudArdestani, @a-hilaly, @Ferossgp, @richardchou, @alekssze, @350050183, @prprnya, @baddphantom, @rysuds, @f4nt0md3v, @Michaela813, @mackness33, @huhu087, @prism4time


Documentation Request For Different Versions of LINQKit

I see marked at the top of the ReadMe there are references to the different Projects (and associated NuGet Packages) that are associated with LINQKit. I am curious as to what exactly are the differences between these packages. I do see that they have listed what .Net frameworks these are capable of running against as well as on the NuGet pages for each it specifies what is implemented/missing in that particular package.
As a Newbie to this project I am still left with questions after my initial steps in researching. I want to use it for one or more projects but don't have a large amount of time to do manual testing to make sure I understand the implications of what it says that it is missing, or what exactly I am getting for each package. To clarify with examples of specific questions that I have, consider the following:

If I install the LinqKit.Microsoft.EntityFrameworkCore package, does this mean that I am now able to do calls such as AsExpandable(), Expand(), PredicateBuilder(), etc, without any additional packages (aside from the obvious EntityFrameworkCore Dependency) on the supported frameworks? I think this is the case, but making it more clear (either here or on the NuGet site) would be helpful when people are researching the project.
What does it mean when I am missing out on Include(...), IAsync, and IDbAsync support? I know that Include(...) is typically used for making sure Navigation Properties are included in EF for queries against other Tables, is this referring to the same extension method? And what does that imply for when I am no longer able to take advantage of LINQKit? And should the sentence be read as "Is not yet supported" or as "Will never be supported"? Or at what point am I no longer able to await an async function (I can test this with the compiler, but lack the time to investigate at the current moment) and what are some implications of that to consider before investing in using LINQKit as an acceptable part of a solution?
What all are the public extension methods provided by LINQKit? I know that I am awfully spoiled by MSDN API Browser and don't expect that level of documentation, but it would be nice to see without installing a package or poking through all of the source code to know what is available to me as well as the function signatures. It may help clarify the examples already given in the ReadMe as to when I need to call one function versus the other.

Perhaps I am looking in the wrong place for better clarification, but as of right now I am not seeing it easily. Making it more easily grokked makes the whole project more accessible to more developers and increases the project's exposure making this kind of documentation a helpful thing to have.

closing...


0.11.0

Features:
- refsFrom now also returns a created observable and a subscribition
- syncRef can now accept watch options
- Operators are introduced to the library
- Automatic deploys CI

Pull Request Test Coverage Report for Build 642865234

8 of 8 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 628448545:
0.0%

Covered Lines:
83

Relevant Lines:
83

💛  - Coveralls

My CI workflow fucked up, so now it's 0.12.0...


Hygieia UI proxy issue

Please find the below error I am facing after running the command
gulp serve
[ UI]$ gulp serve
[12:18:33] Using gulpfile ~/devopsdash/Hygieia/UI/gulpfile.js
[12:18:33] Starting 'build'...
[12:18:33] Starting 'clean'...
[12:18:33] Finished 'clean' after 70 ms
[12:18:33] Starting 'assets'...
[12:18:33] Starting 'themes'...
[12:18:33] Starting 'fonts'...
[12:18:33] Starting 'js'...
[12:18:33] Starting 'views'...
[12:18:33] Starting 'test-data'...
[12:18:43] Finished 'themes' after 9.41 s
[12:18:43] Finished 'assets' after 9.45 s
[12:18:43] Finished 'views' after 9.65 s
[12:18:43] Finished 'js' after 9.83 s
[12:18:43] Finished 'test-data' after 9.86 s
[12:18:50] Finished 'fonts' after 17 s
[12:18:50] Starting 'html'...
[12:18:51] gulp-inject 29 files into index.html.
[12:18:51] gulp-inject 169 files into index.html.
[12:18:51] Finished 'html' after 172 ms
[12:18:51] Finished 'build' after 17 s
[12:18:51] Starting 'serve'...
[12:18:51] Finished 'serve' after 156 ms
[BS] Local URL: http://localhost:3000
[BS] External URL: http://<IP_ADDRESS>:3000
[BS] Serving files from: dist/
[Proxy] { Error: connect ECONNREFUSED <IP_ADDRESS>:8080
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1113:14)
errno: 'ECONNREFUSED',
code: 'ECONNREFUSED',
syscall: 'connect',
address: '<IP_ADDRESS>',
port: 8080 }
There is no proxy server in my setup, it keeps on appearing for few minutes and after that I won't be able to see the Hygieia dashboard.
Anyhelp much appreciated

Closing this issue, as I found out that this depends on the api call to be run successful


improve exhaustive transformer test

correct gathering of properties to include base properties in assertIdentityTransformation
add an option to compare element geometry
fix more jsonProperties remaps

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: MichaelBelousov:x: Deven MhatreDeven Mhatre seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

going to rebase out Deven's contributions since I made this branch off a transformation he was testing.

got integration test model opening failures, going to add an arbitrary change to force retry

@mergify update

@mergify update


Documentation: Suggest adding documentation for supported bundle split algorithms

Is your enhancement request related to a problem? Please describe.
Add documentation for how to choose between load balancing algorithms
Describe the solution you'd like

supportedNamespaceBundleSplitAlgorithms supports two algorithms for namespace bundle split range_equally_divide,topic_count_equally_divide
Suggest adding some documentation around that to here https://pulsar.apache.org/docs/en/administration-load-balance/ including (1) documentation how each algorithm works and how each algorithm can be adjusted (any parameters to control operation) (2) documentation how and when to choose between the default range_equally_divide and topic_count_equally_divide

CC: @Jennifer88huang

@frankjkelly thanks for raising this up. Would you like to add docs accordingly? Then we can help review, thanks

@Anonymitaet I would love to but I really do not have the expertise to understand how these mechanisms work at a detailed level and to provide some guidance on how to choose between them.

@frankjkelly we have documented the usage in broker.conf as below:
# Supported algorithms name for namespace bundle split.
# "range_equally_divide" divides the bundle into two parts with the same hash range size.
# "topic_count_equally_divide" divides the bundle into two parts with the same topics count.
supportedNamespaceBundleSplitAlgorithms=range_equally_divide,topic_count_equally_divide

Does this work for you?

I have a few questions:

How does each algorithm work with other split bundle configurations?

Is each algorithm limited by other split bundle configurations?

Thanks @Anonymitaet exactly - it gets pretty interesting to understand how all those parameters will interact.
I'm particularly interested in how each algorithm behaves when we add brokers (we're hoping to implement Kubernetes autoscaling)- how quickly would those brokers be discovered and how  quickly some load would be redirected to those new brokers.
In my limited experience with range_equally_divide it's not until we hit the loadBalancerBrokerOverloadedThresholdPercentage and the broker is overloaded that some namespace bundles will be split and offloaded but at that point usually the load on the broker is pretty high so that the offload seems to be "expensive" or at least take a long time and then our Pulsar Clients start timing out.
For us we'd rather have a way that was a faster balancing (but perhaps less precisely load balanced) than one that was more accurately load balanced but takes longer to shed load. Again we're pretty new to this but would appreciate to hear perspectives or pointers to code. Thanks!

I have a few questions:

How does each algorithm work with other split bundle configurations?

Is each algorithm limited by other split bundle configurations?

@Anonymitaet each algorithm is affected by these configurations the same. range_equally_divide use hash range, topic_count_equally_divide is evenly distributed.

Thanks @codelipenghui this is super helpful!


Traefik web entrypoint dies randomly

Do you want to request a feature or report a bug?
Bug
What did you do?
I've been using Traefik 1.x for almost a year without any downtimes. But after switching to 2.x I started to see downtimes. In the last month alone it happened about 4 times. There is no connection I could find why would this be happening and the error is also not descriptive to understand what to look.
{"entryPointName":"web","level":"error","msg":"set tcp <IP_ADDRESS>:8088-\u003e<IP_ADDRESS>:46112: setsockopt: connection reset by peer","time":"2021-04-14T03:39:21Z"}
{"entryPointName":"web","level":"error","msg":"Error while starting server: set tcp <IP_ADDRESS>:8088-\u003e<IP_ADDRESS>:46112: setsockopt: connection reset by peer","time":"2021-04-14T03:39:21Z"}
{"entryPointName":"web","level":"error","msg":"Error while starting server: set tcp <IP_ADDRESS>:8088-\u003e<IP_ADDRESS>:46112: setsockopt: connection reset by peer","time":"2021-04-14T03:39:21Z"}

Dashboard and websecure entrypoint are working fine at that time and I can clearly see there is nothing listening on port 8088 where web entrypoint is waiting for the request. In access log there is nothing suspicious but there is no connection from this IP either. Every time this happens external IP is different so I doubt any kind of attack is in place.
I've tested address: <IP_ADDRESS>:8088 with different options like without IP, on fixed IP etc. always the same issue.
What did you expect to see?
http requests go through without disruption
What did you see instead?
http is randomly crashing
Output of traefik version: (What version of Traefik are you using?)
I'm using version traefik-2.4.8 (traefik-2.4.7 same issue)
OS: FreeBSD 12.1
Version:      2.4.8
Codename:     portbuild
Go version:   go1.16.2
Built:        2021-04-01_11:19:34AM
OS/Arch:      freebsd/amd64

What is your environment & configuration (arguments, toml, provider, platform, ...)?
pilot:
  token: "xxxxx"
global:
  checkNewVersion: false
  sendAnonymousUsage: false
entryPoints:
  web:
    address: <IP_ADDRESS>:8088
  websecure:
    address: <IP_ADDRESS>:8443
log:
  level: WARN
  filePath: /var/log/traefik.log
  format: json
accessLog:
  filePath: /var/log/traefik.access.log
  format: json
api:
  insecure: true
ping:
  entryPoint: "web"
certificatesResolvers:
  myresolver:
    acme:
      email<EMAIL_ADDRESS>      storage: /usr/local/etc/acme.json
      httpChallenge:
        # used during the challenge
        entryPoint: web

providers:
  consulCatalog:
    prefix: traefik2
    exposedByDefault: false
    refreshInterval: 10s
    cache: false
    endpoint:
      address: <IP_ADDRESS>:8500
  consul:
    endpoints:
      - "<IP_ADDRESS>:8500"

I can enable DEBUG but there is too much noise and this happens randomly so not sure if it could help here.

Hello @urosgruber
Thanks a lot for your interest in Traefik and for reporting the issue.
We take each reported issue seriously. That's why we try to reproduce on our test environment in order to provide outcomes that help to fix a potential bug. In that issue, we can't find any relevant information that can create a reproducible case.
Would you please try to review the Traefik debug logs in order to find the root cause of the issue? And then try providing the reproducible use case.
Thank you,

@jakubhajek I've enabled debug level and now I need to wait for next crash.

I have a very similar problem at https://community.traefik.io/t/traffic-stops-accepting-connections-on-certain-entrypoints-after-running-for-about-a-week/10390

After throwing out my old log search tool which just quits searching after a few thousand log entries apparently, I found this in my logs:
(I have included the previous and next unrelated message to show that there is indeed no further info)
<IP_ADDRESS> - - [06/Apr/2021:06:31:05 +0000] "POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1" 404 25 "-" "-" 3679 "HouseControl@file" "http://<IP_ADDRESS>/" 2ms
ERRO[2021-04-06T08:31:05+02:00] set tcp [::c0a8:117]:80-><IP_ADDRESS>:38628: setsockopt: invalid argument  entryPointName=web
ERRO[2021-04-06T08:31:05+02:00] Error while starting server: set tcp [::c0a8:117]:80-><IP_ADDRESS>:38628: setsockopt: invalid argument  entryPointName=web
ERRO[2021-04-06T08:31:05+02:00] Error while starting server: set tcp [::c0a8:117]:80-><IP_ADDRESS>:38628: setsockopt: invalid argument  entryPointName=web
DEBU[2021-04-06T08:32:24+02:00] URL.Path is now /vwid3//carStatus.php (was //carStatus.php).  middlewareName=dev-idddatalogger-qualifier@file middlewareType=AddPrefix
DEBU[2021-04-06T08:32:24+02:00] vulcand/oxy/roundrobin/rr: begin ServeHttp on request  Request="{"Method":"GET","URL":{"Scheme":"","Opaque":"","User":null,"Host":"","Path":"/vwid3//carStatus.php","RawPath":"","ForceQuery":false,"RawQuery":"key=REDACTED","Fragment":"","RawFragment":""},"Proto":"HTTP/2.0","ProtoMajor":2,"ProtoMinor":0,"Header":{"Accept":["/"],"Accept-Encoding":["gzip, deflate, br"],"Accept-Language":["en-gb"],"User-Agent":["Scriptable/177 CFNetwork/1220.1 Darwin/20.3.0"],"X-Forwarded-Host":["dev.id3.srv.ti.domain.de"],"X-Forwarded-Port":["443"],"X-Forwarded-Proto":["https"],"X-Forwarded-Server":["some-iMac"],"X-Real-Ip":["<IP_ADDRESS>"]},"ContentLength":0,"TransferEncoding":null,"Host":"dev.id3.srv.ti.domain.de","Form":null,"PostForm":null,"MultipartForm":null,"Trailer":null,"RemoteAddr":"<IP_ADDRESS>:63730","RequestURI":"/vwid3//carStatus.php?key=REDACTED","TLS":null}"
Since that is with debug enabled, there seems to unfortunately not be any more info available. How can we collect more information on this issue?
After that log entry (which occurred 2 days after starting traefik), no further requests were handled on the web entrypoint.

Thanks @robske110 thanks for the report. I'm glad I'm not the onlyone seeing this. Quick question is web only entrypoint that it dies on your end?

Not sure if this could be related but my default kern.ipc.somaxconn was set to 128 and it might be to low. I've raised it to 1024 since server should be able to handle this very easily. What's yours @robske110 ?

Thanks @robske110 thanks for the report. I'm glad I'm not the onlyone seeing this. Quick question is web only entrypoint that it dies on your end?

Yes, for me, at least up to now, only one of my entry points die at a time. It's not always the web one, sometimes it's my websecure or one of the others.

Not sure if this could be related but my default kern.ipc.somaxconn was set to 128 and it might be to low. I've raised it to 1024 since server should be able to handle this very easily. What's yours @robske110 ?

Mine is also 128 (Please note that I am on Darwin / macOS). But looking at the error messages mine says setsockopt: invalid argument while yours is setsockopt: connection reset by peer. Maybe we have different causes? The result is the same, and I still wonder why traefik does not crash itself after detecting such a severe fault (one entrypoint down is something I'd consider quite catastrophic). That way restart scripts could workaround this issue.

Agree. I've created a script to check if all the sockets are up and listening and in case one is down service restart is executed. But this reminds me back in the days with IIS memory leak issues :) I really hope something else we can setup to understand the root cause.

It happened again. So even though I raised kern.ipc.somaxconn one entrypoint died without anything in logs even with debug enabled.
{"ForwardURL":{"Scheme":"http","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"","RawPath":"","ForceQuery":false,"RawQuery":"","Fragment":"","RawFragment":""},"Request":"{\"Method\":\"GET\",\"URL\":{\"Scheme\":\"\",\"Opaque\":\"\",\"User\":null,\"Host\":\"\",\"Path\":\"/opgp/b5gekiyasumaouf9c51214849sd-1\",\"RawPath\":\"\",\"ForceQuery\":false,\"RawQuery\":\"\",\"Fragment\":\"\",\"RawFragment\":\"\"},\"Proto\":\"HTTP/1.1\",\"ProtoMajor\":1,\"ProtoMinor\":1,\"Header\":{\"Accept\":[\"*/*\"],\"Accept-Encoding\":[\"gzip, deflate\"],\"Cache-Control\":[\"no-cache\"],\"Connection\":[\"Keep-Alive\"],\"From\":[\"bingbot(at)microsoft.com\"],\"Pragma\":[\"no-cache\"],\"User-Agent\":[\"Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)\"],\"X-Forwarded-Host\":[\"www.host1.si\"],\"X-Forwarded-Port\":[\"80\"],\"X-Forwarded-Proto\":[\"http\"],\"X-Forwarded-Server\":[\"traefik.local\"],\"X-Real-Ip\":[\"<IP_ADDRESS>\"]},\"ContentLength\":0,\"TransferEncoding\":null,\"Host\":\"www.host1.si\",\"Form\":null,\"PostForm\":null,\"MultipartForm\":null,\"Trailer\":null,\"RemoteAddr\":\"<IP_ADDRESS>:20008\",\"RequestURI\":\"/opgp/b5gekiyasumaouf9c51214849sd-1\",\"TLS\":null}","level":"debug","msg":"vulcand/oxy/roundrobin/rr: Forwarding this request to URL","time":"2021-04-30T15:18:42Z"}
{"Request":"{\"Method\":\"GET\",\"URL\":{\"Scheme\":\"\",\"Opaque\":\"\",\"User\":null,\"Host\":\"\",\"Path\":\"/opgp/b5gekiyasumaouf9c51214849sd-1\",\"RawPath\":\"\",\"ForceQuery\":false,\"RawQuery\":\"\",\"Fragment\":\"\",\"RawFragment\":\"\"},\"Proto\":\"HTTP/1.1\",\"ProtoMajor\":1,\"ProtoMinor\":1,\"Header\":{\"Accept\":[\"*/*\"],\"Accept-Encoding\":[\"gzip, deflate\"],\"Cache-Control\":[\"no-cache\"],\"Connection\":[\"Keep-Alive\"],\"From\":[\"bingbot(at)microsoft.com\"],\"Pragma\":[\"no-cache\"],\"User-Agent\":[\"Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)\"],\"X-Forwarded-Host\":[\"www.host1.si\"],\"X-Forwarded-Port\":[\"80\"],\"X-Forwarded-Proto\":[\"http\"],\"X-Forwarded-Server\":[\"traefik.local\"],\"X-Real-Ip\":[\"<IP_ADDRESS>\"]},\"ContentLength\":0,\"TransferEncoding\":null,\"Host\":\"www.host1.si\",\"Form\":null,\"PostForm\":null,\"MultipartForm\":null,\"Trailer\":null,\"RemoteAddr\":\"<IP_ADDRESS>:20008\",\"RequestURI\":\"/opgp/b5gekiyasumaouf9c51214849sd-1\",\"TLS\":null}","level":"debug","msg":"vulcand/oxy/roundrobin/rr: completed ServeHttp on request","time":"2021-04-30T15:18:42Z"}
{"entryPointName":"web","level":"error","msg":"set tcp <IP_ADDRESS>:8088-\u003e<IP_ADDRESS>:59132: setsockopt: connection reset by peer","time":"2021-04-30T15:18:42Z"}
{"entryPointName":"web","level":"error","msg":"Error while starting server: set tcp <IP_ADDRESS>:8088-\u003e<IP_ADDRESS>:59132: setsockopt: connection reset by peer","time":"2021-04-30T15:18:42Z"}
{"entryPointName":"web","level":"error","msg":"Error while starting server: set tcp <IP_ADDRESS>:8088-\u003e<IP_ADDRESS>:59132: setsockopt: connection reset by peer","time":"2021-04-30T15:18:42Z"}
{"Request":"{\"Method\":\"POST\",\"URL\":{\"Scheme\":\"\",\"Opaque\":\"\",\"User\":null,\"Host\":\"\",\"Path\":\"/\",\"RawPath\":\"\",\"ForceQuery\":false,\"RawQuery\":\"_task=mail\\u0026_action=refresh\",\"Fragment\":\"\",\"RawFragment\":\"\"},\"Proto\":\"HTTP/2.0\",\"ProtoMajor\":2,\"ProtoMinor\":0,\"Header\":{\"Accept\":[\"application/json, text/javascript, */*; q=0.01\"],\"Accept-Encoding\":[\"gzip, deflate, br\"],\"Accept-Language\":[\"sl-SI,sl;q=0.9,en-GB;q=0.8,en;q=0.7\"],\"Content-Length\":[\"402\"],\"Content-Type\":[\"application/x-www-form-urlencoded; charset=UTF-8\"],\"Cookie\":[\"language=sl; roundcube_sessid=72b499c55b093ef32269b75640780040; roundcube_sessauth=2gOFJID5rbQeThEPLLTh5S5Qz7IQ8jKR-1619795700\"],\"Origin\":[\"https://webmail.local\"],\"Referer\":[\"https://webmail.local/?_task=mail\\u0026_mbox=INBOX\"],\"Sec-Ch-Ua\":[\"\\\" Not A;Brand\\\";v=\\\"99\\\", \\\"Chromium\\\";v=\\\"90\\\", \\\"Google Chrome\\\";v=\\\"90\\\"\"],\"Sec-Ch-Ua-Mobile\":[\"?0\"],\"Sec-Fetch-Dest\":[\"empty\"],\"Sec-Fetch-Mode\":[\"cors\"],\"Sec-Fetch-Site\":[\"same-origin\"],\"User-Agent\":[\"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36\"],\"X-Forwarded-Host\":[\"webmail.local\"],\"X-Forwarded-Port\":[\"443\"],\"X-Forwarded-Proto\":[\"https\"],\"X-Forwarded-Server\":[\"traefik.local\"],\"X-Real-Ip\":[\"<IP_ADDRESS>\"],\"X-Requested-With\":[\"XMLHttpRequest\"],\"X-Roundcube-Request\":[\"byXTqCZiDguk3RHmlcXVpbyDYFk6vb3t\"]},\"ContentLength\":402,\"TransferEncoding\":null,\"Host\":\"webmail.local\",\"Form\":null,\"PostForm\":null,\"MultipartForm\":null,\"Trailer\":null,\"RemoteAddr\":\"<IP_ADDRESS>:55116\",\"RequestURI\":\"/?_task=mail\\u0026_action=refresh\",\"TLS\":null}","level":"debug","msg":"vulcand/oxy/roundrobin/rr: begin ServeHttp on request","time":"2021-04-30T15:18:43Z"}
{"ForwardURL":{"Scheme":"http","Opaque":"","User":null,"Host":"<IP_ADDRESS>:8080","Path":"","RawPath":"","ForceQuery":false,"RawQuery":"","Fragment":"","RawFragment":""},"Request":"{\"Method\":\"POST\",\"URL\":{\"Scheme\":\"\",\"Opaque\":\"\",\"User\":null,\"Host\":\"\",\"Path\":\"/\",\"RawPath\":\"\",\"ForceQuery\":false,\"RawQuery\":\"_task=mail\\u0026_action=refresh\",\"Fragment\":\"\",\"RawFragment\":\"\"},\"Proto\":\"HTTP/2.0\",\"ProtoMajor\":2,\"ProtoMinor\":0,\"Header\":{\"Accept\":[\"application/json, text/javascript, */*; q=0.01\"],\"Accept-Encoding\":[\"gzip, deflate, br\"],\"Accept-Language\":[\"sl-SI,sl;q=0.9,en-GB;q=0.8,en;q=0.7\"],\"Content-Length\":[\"402\"],\"Content-Type\":[\"application/x-www-form-urlencoded; charset=UTF-8\"],\"Cookie\":[\"language=sl; roundcube_sessid=72b499c55b093ef32269b75640780040; roundcube_sessauth=2gOFJID5rbQeThEPLLTh5S5Qz7IQ8jKR-1619795700\"],\"Origin\":[\"https://webmail.local\"],\"Referer\":[\"https://webmail.local/?_task=mail\\u0026_mbox=INBOX\"],\"Sec-Ch-Ua\":[\"\\\" Not A;Brand\\\";v=\\\"99\\\", \\\"Chromium\\\";v=\\\"90\\\", \\\"Google Chrome\\\";v=\\\"90\\\"\"],\"Sec-Ch-Ua-Mobile\":[\"?0\"],\"Sec-Fetch-Dest\":[\"empty\"],\"Sec-Fetch-Mode\":[\"cors\"],\"Sec-Fetch-Site\":[\"same-origin\"],\"User-Agent\":[\"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36\"],\"X-Forwarded-Host\":[\"webmail.local\"],\"X-Forwarded-Port\":[\"443\"],\"X-Forwarded-Proto\":[\"https\"],\"X-Forwarded-Server\":[\"traefik.local\"],\"X-Real-Ip\":[\"<IP_ADDRESS>\"],\"X-Requested-With\":[\"XMLHttpRequest\"],\"X-Roundcube-Request\":[\"byXTqCZiDguk3RHmlcXVpbyDYFk6vb3t\"]},\"ContentLength\":402,\"TransferEncoding\":null,\"Host\":\"webmail.local\",\"Form\":null,\"PostForm\":null,\"MultipartForm\":null,\"Trailer\":null,\"RemoteAddr\":\"<IP_ADDRESS>:55116\",\"RequestURI\":\"/?_task=mail\\u0026_action=refresh\",\"TLS\":null}","level":"debug","msg":"vulcand/oxy/roundrobin/rr: Forwarding this request to URL","time":"2021-04-30T15:18:43Z"}
{"Request":"{\"Method\":\"POST\",\"URL\":{\"Scheme\":\"\",\"Opaque\":\"\",\"User\":null,\"Host\":\"\",\"Path\":\"/\",\"RawPath\":\"\",\"ForceQuery\":false,\"RawQuery\":\"_task=mail\\u0026_action=refresh\",\"Fragment\":\"\",\"RawFragment\":\"\"},\"Proto\":\"HTTP/2.0\",\"ProtoMajor\":2,\"ProtoMinor\":0,\"Header\":{\"Accept\":[\"application/json, text/javascript, */*; q=0.01\"],\"Accept-Encoding\":[\"gzip, deflate, br\"],\"Accept-Language\":[\"sl-SI,sl;q=0.9,en-GB;q=0.8,en;q=0.7\"],\"Content-Length\":[\"402\"],\"Content-Type\":[\"application/x-www-form-urlencoded; charset=UTF-8\"],\"Cookie\":[\"language=sl; roundcube_sessid=72b499c55b093ef32269b75640780040; roundcube_sessauth=2gOFJID5rbQeThEPLLTh5S5Qz7IQ8jKR-1619795700\"],\"Origin\":[\"https://webmail.local\"],\"Referer\":[\"https://webmail.local/?_task=mail\\u0026_mbox=INBOX\"],\"Sec-Ch-Ua\":[\"\\\" Not A;Brand\\\";v=\\\"99\\\", \\\"Chromium\\\";v=\\\"90\\\", \\\"Google Chrome\\\";v=\\\"90\\\"\"],\"Sec-Ch-Ua-Mobile\":[\"?0\"],\"Sec-Fetch-Dest\":[\"empty\"],\"Sec-Fetch-Mode\":[\"cors\"],\"Sec-Fetch-Site\":[\"same-origin\"],\"User-Agent\":[\"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36\"],\"X-Forwarded-Host\":[\"webmail.local\"],\"X-Forwarded-Port\":[\"443\"],\"X-Forwarded-Proto\":[\"https\"],\"X-Forwarded-Server\":[\"traefik.local\"],\"X-Real-Ip\":[\"<IP_ADDRESS>\"],\"X-Requested-With\":[\"XMLHttpRequest\"],\"X-Roundcube-Request\":[\"byXTqCZiDguk3RHmlcXVpbyDYFk6vb3t\"]},\"ContentLength\":402,\"TransferEncoding\":null,\"Host\":\"webmail.local\",\"Form\":null,\"PostForm\":null,\"MultipartForm\":null,\"Trailer\":null,\"RemoteAddr\":\"<IP_ADDRESS>:55116\",\"RequestURI\":\"/?_task=mail\\u0026_action=refresh\",\"TLS\":null}","level":"debug","msg":"vulcand/oxy/roundrobin/rr: completed ServeHttp on request","time":"2021-04-30T15:18:43Z"}

Is there something I can debug to find what is happening.
Can we pinpoint where in the code this is errored
set tcp <IP_ADDRESS>:8088-\u003e<IP_ADDRESS>:59132: setsockopt: connection reset by peer
And why it tries to start it back twice without success and then back off.

Not sure if this is related, but traffic comming from this IP on this very same day was always POST and the message right after request was
{"level":"debug","msg":"'499 Client Closed Request' caused by: context canceled","time":"2021-04-30T12:47:12Z"}

I think also a simple "hot fix" to force Traefik to crash after one of its endpoints went down will help here, since a restart script can then simply take over. I think continuing to run when maybe half of the proxy is dead is simply useless.
For me this still happens every other week. My error messages stay exactly the same as posted above and I couldn't find any pattern around them. Only that it tends to happen more during "busy" times of the day though, but that's neither consistent nor surprising.

Hello @urosgruber @robske110,
Thanks for your interest in Traefik and your feedbacks.
Unfortunately, since the issue can't be reproduced easily, we cannot really troubleshoot it.
Please let us know if you find a consistent way to reproduce the bug.

Can you at least pinpoint where in the code setsockopt would be called? I am assuming it is probably in a library. Maybe we run modified builds that output more information?
It is unlikely that we will find a consistent way to reproduce it because this is most likely either a race condition, highly dependent on network activity and maybe even a kernel bug.
I think the real bug/issue here is that Traefik does not handle this error correctly. In my opinion it should crash completely, allowing for example restart scripts / docker / systemd to restart it. What is your opinion on this? I think it just doesn't make sense to continue to run when an entrypoint is down and unreachable. Traefik obviously somehow detects the error and attempts to restart the server twice, but then just gives up and continues running like noting happens, which is not a good choice in my opinion.

Only thing I found is https://github.com/traefik/traefik/blob/31a5f3591f278aeeccaee9de530c109c14544ab8/pkg/server/server_entrypoint_tcp.go#L531
where it catches the error. But I'm not good with golang so can't really tell from where it was called and how to add more debug info.

I seem to encounter the same problem.
FreeBSD 12 & 13 (just updated), now with traefik 2.4.8 from pkg, but this has been going on for some time. The service was allmost never used in the last months, but now I need to fix this.
Last message from debug log:
time="2021-05-12T07:54:52+02:00" level=error msg="set tcp <IP_ADDRESS>:443-><IP_ADDRESS>:51275: setsockopt: connection reset b
y peer" entryPointName=https
time="2021-05-12T07:54:52+02:00" level=error msg="Error while starting server: set tcp <IP_ADDRESS>:443-><IP_ADDRESS>:51275: s
etsockopt: connection reset by peer" entryPointName=https
time="2021-05-12T07:54:52+02:00" level=error msg="Error while starting server: set tcp <IP_ADDRESS>:443-><IP_ADDRESS>:51275: s
etsockopt: connection reset by peer" entryPointName=https
Still investigating.

I've encountered this issue on a entryPoint that rarely sees traffic, it seems to be not related to traffic volume.
ERRO[2021-05-10T02:41:57+02:00] set tcp <IP_ADDRESS>:90-><IP_ADDRESS>:63925: setsockopt: invalid argument  entryPointName=hctrlAuth
ERRO[2021-05-10T02:41:57+02:00] Error while starting server: set tcp <IP_ADDRESS>:90-><IP_ADDRESS>:63925: setsockopt: invalid argument  entryPointName=hctrlAuth
ERRO[2021-05-10T02:41:57+02:00] Error while starting server: set tcp <IP_ADDRESS>:90-><IP_ADDRESS>:63925: setsockopt: invalid argument  entryPointName=hctrlAuth

@rtribotte Sorry to reiterate: Can you pinpoint where in the code setsockopt would be called? I am assuming it is probably in a library. Maybe we could run modified builds that output more information?
Could it be implemented that when Traefik detects that an entry point crashes, it shuts down completely to allow for example restart scripts / docker / systemd to restart it. Continuing to run a half dead proxy (or even completely dead if there is only one entry point) does not make sense to me.

@robske110 Well, this error most probably comes from Golang standard library.
My best guess for the code of Traefik involved in the production of the error:
https://github.com/traefik/traefik/blob/6ae194934d50db135d027f488da947f007a4a7e0/pkg/server/server_entrypoint_tcp.go#L344-L354
Thus, without a reproduction case, it's not easy to go further to fix this issue.
You can comment those lines and make your own build to confirm that the problem comes from that part of the code. But even if you succeed to get rid of that error, we would not accept or make a PR, unless we could reproduce the issue.
Also, we are not willing to make Traefik stop whenever an entryPoint dies, it would be a breaking behavior, and it's not obviously expected, as you may want that traffic going on on other entryPoints to continue to be handled.
What you can do, besides detecting that Traefik died, is to health check Traefik on all its entryPoints, then restart it when you diagnose an error.
Unfortunately, as already said, without a reproduction case, it will be difficult to address this issue.

I'm seeing similar issue with traefik v2.4.8 on docker container.

time="2021-05-24T13:12:48Z" level=error msg="set tcp [::]:443-><IP_ADDRESS>:10044: setsockopt: invalid argument" entryPointName=websecure
time="2021-05-24T13:12:48Z" level=error msg="Error while starting server: set tcp [::]:443-><IP_ADDRESS>:10044: setsockopt: invalid argument" entryPointName=websecure
time="2021-05-24T13:12:48Z" level=error msg="Error while starting server: set tcp [::]:443-><IP_ADDRESS>:10044: setsockopt: invalid argument" entryPointName=websecure

Hi! I'm Træfiker :robot: the bot in charge of tidying up the issues.
I have to close this one because of its lack of activity :disappointed:
Feel free to re-open it or join our Community Forum.

I believe this is still happening. I have a workaround to check if ports are up and if not restart the service. But feels kinda lame, so anything we can add to get more debug info what is going on would be more than welcome.

I am experiencing this issue too
Traefik 2.3.7 on FreeBSD


build: change group id to com.expedia

Fixes https://github.com/ExpediaDotCom/graphql-kotlin/issues/98

Codecov Report

Merging #105 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #105   +/-   ##
=========================================
  Coverage     86.22%   86.22%
  Complexity      146      146
=========================================
  Files            46       46
  Lines           501      501
  Branches        116      116
=========================================
  Hits            432      432
  Misses           20       20
  Partials         49       49

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 1ce9aa3...6d02b33. Read the comment docs.


Perhaps consider going the ES6 route.

I converted this awesome animation library to es6 code added and custom build system it works exactly the same.
benefits

es6 code
less lines of code
build system - minifies and transpiles to es5

maybe look over make some suggestions.
say if it's bad or if you like the concept but perhaps change it your way.

There still seems to be one or two bugs I'm working out with the conversion. I'm testing it on your Code Pen demos. thanks for looking at it will apply your suggestion for the build.js file. will keep you informed on whats happening. still working out some kinks

fixed silly bug with toArray, all the demos are working in ES6 version so far.

Perhaps users may benefit from exposing some internal utility functions such as includes, removeArrayDuplicates, flattenArray like they do with anime.random.

I'd prefer not to see this happen 👎
There's nothing wrong with the current distribution, and adding in ES6 only adds build complexity & usually transpilation "bloat". Your branch doesn't split the code into files, thus require, import, and export aren't used, but once a codebase is written in ES6, that's generally the next step.

Sidenote: @SaulDoesCode future note, your package.json should be declaring devDependencies, not dependencies.

Thanks, I understand. I'll try to keep this branch updated and in sync with the main repo for whom ever it matters. Will change that in the package.json thanks.

Awesome constructive criticism @lukeed thanks I'll see to it that those changes be implemented

@SaulDoesCode There's more that I can add, but you'd receive the same critiques from XO. You might want to check that out instead :)

Very well I'll see how that linter works and follow it's guide lines. again many thanks for helping

@SaulDoesCode No problem 👌 Ping me if you need help setting up XO. It's a great tool

Keeping up with all the changes so far, implemented latest from anime v1.1.0 and implemented @devmario's chainable suggestions.
nice work with the engine object and usage of performance.now so much better now. :+1:


Monitor wrongly notifies device disconnection and battery level

Received this email while the device was still connected.
The device {"userId": "KCLTest0", "sourceId": "00:07:80:1F:52:F3"} seems disconnected. It was last seen on Fri, 2 Jun at 12:56:47 UTC (300 seconds ago). If this is not intended, please ensure that it gets reconnected.

After this message no reconnection notification has been sent. Meanwhile, I received a sequence of these messages
The battery level of {"userId": "KCLTest0", "sourceId": "00:07:80:1F:52:F3"} has returned to normal. No further action is needed.

RAW data in CSV format is available if useful for troubleshooting.
Update
Still receiving
The battery level of {"userId": "KCLTest0", "sourceId": "00:07:80:1F:52:F3"} has returned to normal. No further action is needed.

after the device has been disconnected

@afolarin The issue already exists. I can look into solving this. What do you think?

Yes please. There may already be a working implementation separately done by @sboettcher

I think we can drop the recharged notification if this is the principle source of problematic repetitive emails. I don't think it is so important as there is a battery indicator already

@afolarin Yes I am looking into it. If nothing works then I will just remove the notification message about normal battery level.

Closed with #37


Intranet page on SSO for staff needs a review with regard to Rest API

Our installation setup guide includes information regarding the REST API. As we are no longer creating new installations to use the REST API, these sections should be removed, or at least marked differently, so that GS staff following the guide do not configure anything for the REST API unnecessarily.
Link: https://intranet.giantswarm.io/docs/support-and-ops/installation-setup-guide/giantswarm-sso-setup/

The article is updated.


Admin Tool Reporting Update

Add a function to the Reports within the Admin Tool that will pull a report of calories, sodium, fluid, protein, carbs, fat in addition to the raw food data.

Was this completed?

@rsial2 this is fixed. Will commit the code.

@rsial2 Fixed. The admin tool already in VM already has the new code. Will commit to github shortly.

Committed

In the Report, Protein and Sodium has same data for all food items. Seems like protein has incorrect value.
@coderReview Please check

Protein and Sodium has correct value now.
Please check the following:

"Comments" are not exported in Report
Entries in future date are not exported

1- the code is exporting comments. Can you point to a step by step that this hasn't  worked
2- Normally no report will have this entries. And it doesn't make sense because user didn't make use of that food. This type of entry could be a mistake or an anticipation. In both cases of the user gets deleted before that date this food consumptions records should not be taken into account.

1--> Login as user "DeleteUser Testing", Add a Food to consumption list and then add a comment. Logout and login again and see that the comment is still present.
Now in Admin Tool, Export the report for this user and observe that entry is present without the comment.

2- Normally no report will have this entries. And it doesn't make sense because user didn't make use of that food. This type of entry could be a mistake or an anticipation. In both cases of the user gets deleted before that date this food consumptions records should not be taken into account.

Good point. I agree.

Thanks Paulo.
The above issues are solved.
When I choose "All Users Food Data Report", it is fetching empty folders without any food reports.

Issue still exists. is the Fix deployed to VM?

Yes. Can you paste the results?

All users in database that are not removed will appear in the report.

But the folders are empty.
This is the Report generated:
summary (19).zip

Does these have any food record in app?

Found the issue

Also there is a folder called "media" which does not seem to have valid info.

Fixed.

Verified.
(All the previous issues in this ticket are also re-verified)


Add Arkansas search

This should be handled as part of #125

Arkansas has a single site that provides data on all counties across the state. We'll need to do some refactoring (#29) in order to handle this scenario, in addition to building a generic search interface for accessing court data.

Closing in favor of #30 and #125


Fixes #26

fixes #26 by adding .bat runner for Windows and converting file paths to Unix style

1 comment, otherwise LGTM


Update AUTHORS

Only for sampleconfig.sh at the moment

Changes Unknown when pulling ebf6482b5825d600f99be863fefbf4002bb19d51 on gabs5807:patch-1 into ** on openxpki:develop**.


Timestamp Overruns

In my work on json2parquet I ran in to some issues with far-future timestamps.  If a timestamp exceeds 2262-04-11 23:47:16.854775807 it will overflow the timestamp[ns] type in Pandas, which will make it impossible to convert to a format that PyArrow can consume to create the deprecated int96 format used by Spark/Presto/Impala.
Not sure what the best solution is in this case.  I did some work here to replace it with Timestamp.max if it exceeded that date, but that is definitely a tradeoff.  Maybe there is a better way to convert timestamps so that you can accurately use the int96 converter.

Using microsecond or millisecond precision would allow a much larger time range.  I do not believe that arrow/parquet-cpp support conversion from those formats to int96; should support become available for those types/operations, I'd be happy to integrate it :)
Another option is to make the field a string; this makes partitioning/querying much more difficult however.

One more note -- int96 is deprecated; it seems likely that at some point Spectrum will support 64-bit timestamps directly.  I have no idea what the timeline on that might be, though.

Agreed. I don't actually need ns resolution, but it is currently the only way to get int96 timestamps.  Probably better to push on getting ms/us support for that instead.
Agreed re: int96 deprecation

@andrewgross int64 is now supported for timestamp columns https://forums.aws.amazon.com/thread.jspa?threadID=257362
I would like to transition Spectrify to int64 + us for the next major version -- I think that would address a larger set of use cases.

Agreed, int96 is deprecated.  I need to do some testing on support for tables that have a mix of datafiles with int96 or int64 before I can upgrade.

The only way on my end to handle timestamp overruns is to use milliseconds instead of nanoseconds and put a default value in case the parsing to iso date errors out (like the year in YYYY-MM-DD format outputs as three digits with no leading zeros instead of four digits if year is under 1000 which becomes invalid). This may be useful if you are working with a lot of dirty data (so I think this will be useful for many use cases as redshift accepts those date ranges in their timestamp and date columns). Don't have the time to QA on this, but being the first time converting files to parquet, I spend more than half of the time in here debugging with timestamps than implementing my cron scripts.


The scrape is getting stuck on the "Accept Cookies" page of google

When starting the search, it starts up chrome, but gets stuck on the "Accept cookies page" in google, it then resizes and closes as it cannot find any images.
https://gyazo.com/13510e16f0993ee936bbe316b9cb08b4
Here is an example of starting the chrome instance and getting stuck

happened to me too. The accept cookies page triggers this
const isScrollable = await this._isScrollable(page);
if (!isScrollable) {
console.log('No results on this page');
return;
}

So after a bit of reading about puppeteer i wrote this together:
//Google Accept All     //Search for the button with the text "Accept all"     const [button] = await page.$x("//button[contains(., 'Accept all')]");     if (button) {       //Press the button and wait till the page finishes loading       await button.click();       await page.waitForNavigation({         waitUntil: 'networkidle0',       });     }
I put that into the scraper.js file right below:
    const page = await browser.newPage();     await page.setBypassCSP(true);     await page.goto(query, {       waitUntil: 'networkidle0',     });
This certainly isnt the fastest approach but with my limited knowledge it is at least a temporary fix for anyone who has the same issue.
This will increase the time it takes to start the search, but i am not sure if another approach would make it significantly faster due to the page needing to load twice now.

Another approach would be to use the code i provided above to accept the cookies.
You could then use puppeteer to store the cookies locally and then retrieve those on the next session to skip the "accept cookies" page.
This would probably result in faster results as it wont load the page twice like in the current fix.
This solution would require fs as it needs to store it locally.
Here is my attempt:
Starting with line 45
const browser = await puppeteer.launch({
      ...this.puppeteerOptions,
    });
    const page = await browser.newPage();
    await page.setBypassCSP(true);
    //Load cookies
    if (fs.existsSync('./node_modules/images-scraper/src/google/cookies.json')) {
      const cookies = fs.readFileSync('./node_modules/images-scraper/src/google/cookies.json', 'utf8')

    const deserializedCookies = JSON.parse(cookies)
    await page.setCookie(...deserializedCookies)
    };
    // Cookies retrieved
    await page.goto(query, {
      waitUntil: 'networkidle0',
    });

    //Google Accept All
    //Search for the button with the text "Accept all"
    const [button] = await page.$x("//button[contains(., 'Accept all')]");
    if (button) {
      //Press the button and wait till the page finishes loading
      await button.click();
      await page.waitForNavigation({
        waitUntil: 'networkidle0',
      });
      //Set cookies
      const cookies = await page.cookies()
      const cookieJson = JSON.stringify(cookies)

      fs.writeFileSync('./node_modules/images-scraper/src/google/cookies.json', cookieJson)
    }
    //back to the rest of the code
    await page.setViewport({ width: 1920, height: 1080 });
    await page.setUserAgent(this.userAgent);

From rough tests i made on my side it improves the search time by about 1.5 seconds when it searches for 25 images.
@pevers would you mind looking over this issue? As this might be caused by google it could have lead to the scraper no longer working for anyone.

Another approach would be to use the code i provided above to accept the cookies. You could then use puppeteer to store the cookies locally and then retrieve those on the next session to skip the "accept cookies" page. This would probably result in faster results as it wont load the page twice like in the current fix.
This solution would require fs as it needs to store it locally. Here is my attempt: Starting with line 45
const browser = await puppeteer.launch({
      ...this.puppeteerOptions,
    });
    const page = await browser.newPage();
    await page.setBypassCSP(true);
    //Load cookies
    if (fs.existsSync('./node_modules/images-scraper/src/google/cookies.json')) {
      const cookies = fs.readFileSync('./node_modules/images-scraper/src/google/cookies.json', 'utf8')

    const deserializedCookies = JSON.parse(cookies)
    await page.setCookie(...deserializedCookies)
    };
    // Cookies retrieved
    await page.goto(query, {
      waitUntil: 'networkidle0',
    });

    //Google Accept All
    //Search for the button with the text "Accept all"
    const [button] = await page.$x("//button[contains(., 'Accept all')]");
    if (button) {
      //Press the button and wait till the page finishes loading
      await button.click();
      await page.waitForNavigation({
        waitUntil: 'networkidle0',
      });
      //Set cookies
      const cookies = await page.cookies()
      const cookieJson = JSON.stringify(cookies)

      fs.writeFileSync('./node_modules/images-scraper/src/google/cookies.json', cookieJson)
    }
    //back to the rest of the code
    await page.setViewport({ width: 1920, height: 1080 });
    await page.setUserAgent(this.userAgent);

From rough tests i made on my side it improves the search time by about 1.5 seconds when it searches for 25 images. (Tests were conducted with headless false to check what is actually going on)
As this approach would need fs i wont make a pull request for now but it seems to be the faster solution even if we have to store and retrieve a file locally.
@pevers would you mind looking over this issue? As this might be caused by google it could have lead to the scraper no longer working for anyone.

Thanks for looking into this and the fix! I'll have a look tonight and test it.


chore: update form docs

🤔 这个 PR 的性质是？

[ ] 日常 bug 修复
[ ] 新特性提交
[x] 文档改进
[ ] 演示代码改进
[ ] 组件样式/交互改进
[ ] CI/CD 改进
[ ] 重构
[ ] 代码风格优化
[ ] 测试用例
[ ] 分支合并
[ ] 其他

🔗 相关 Issue

💡 需求背景和解决方案

https://github.com/Tencent/tdesign-common/pull/515

📝 更新日志

[x] 本条 PR 不需要纳入 Changelog

☑ 请求合并前的自查清单
⚠ 请自检并全部勾选全部选项。⚠

[x] 文档已补充或无须补充
[x] 代码演示已提供或无须提供
[x] TypeScript 定义已补充或无须补充
[x] Changelog 已提供或无须提供

Codecov Report

Merging #999 (1f266e0) into develop (a0db0df) will increase coverage by 2.06%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #999      +/-   ##
===========================================
+ Coverage    57.56%   59.62%   +2.06%
===========================================
  Files          346      382      +36
  Lines        12828    14617    +1789
  Branches      2405     2743     +338
===========================================
+ Hits          7384     8715    +1331
- Misses        5200     5635     +435
- Partials       244      267      +23

Impacted Files
Coverage Δ

src/affix/affix.tsx
28.57% <0.00%> (-37.51%)
:arrow_down:

src/swiper/props.ts
68.75% <0.00%> (-31.25%)
:arrow_down:

src/dialog/props.ts
70.00% <0.00%> (-30.00%)
:arrow_down:

src/calendar/props.ts
70.00% <0.00%> (-30.00%)
:arrow_down:

src/popup/props.ts
75.00% <0.00%> (-25.00%)
:arrow_down:

src/select/props.ts
75.00% <0.00%> (-25.00%)
:arrow_down:

src/slider/props.ts
75.00% <0.00%> (-25.00%)
:arrow_down:

src/message/props.ts
75.00% <0.00%> (-25.00%)
:arrow_down:

src/tooltip/props.ts
75.00% <0.00%> (-25.00%)
:arrow_down:

src/pagination/props.ts
75.00% <0.00%> (-25.00%)
:arrow_down:

... and 160 more

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 55f7578...1f266e0. Read the comment docs.


[Docs] Grammar fixes for the chapter "From scratch"

Chapter 3, "Customize" has not yet been proof-read. Will come soon.

A new PR will be provided following along the guides of contribution.


Where can I find this paper?

Hi, your ACNet series is very exciting work. Where can I find this paper? Looking forward to reading it!

Hi, your ACNet series is very exciting work. Where can I find this paper? Looking forward to reading it!

arXiv:2103.13425v1


systemd.network brdige problems

Issue description
I run a server which acts as host to load multiple kvm vms. While using 18.03 I did use systemd.network to setup the bridge and all worked fine. However if I switch to 18.09, pre-19.03 unstable or git master, I can't connect from the host to the internet anymore. The VMs still can access the network/internet.
The problem seems to be that for some reasons I do get two default gateways added. This was already the case in 18.03 but they default gw were the same, while they are different now in 18.09 (or newer).
Steps to reproduce
In 18.03 I have the following in my configuration.nix

    # Setup Bridging via SystemD
    systemd.network = {
        enable = true;
        netdevs.br0.netdevConfig = {
            Name = "br0";
            Kind = "bridge";
        };
        networks = {
            br0.extraConfig = ''
                [Match]
                Name = br0

                [Network]
                DHCP = both
            '';
            eth0.extraConfig = ''
                [Match]
                Name=eth0

                [Network]
                Bridge=br0
            '';
        };
    };

    # Setup networking
    networking = {
        usePredictableInterfaceNames = true;
        hostName = "${mySecrets.hostname}"; # Define your hostname.
        hostId = "10101003";
        #  enable = true;  # Enables wireless. Disable when using network manager
        useDHCP = true;
        nameservers = [ "<IP_ADDRESS>" "<IP_ADDRESS>" "<IP_ADDRESS>" "<IP_ADDRESS>" ];
        firewall = {
            enable = false;
            allowPing = true;
            allowedUDPPorts = [ 5000 5001 ];
            allowedTCPPorts = [ 22 5000 5001 ];
            # Netcat: 5000
            # IPerf: 5001
        };
        enableIPv6 = false;
    };

This produces the following:
# systemctl version
systemd 237
+PAM +AUDIT -SELINUX +IMA +APPARMOR +SMACK -SYSVINIT +UTMP -LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD +IDN2 -IDN -PCRE2 default-hierarchy=hybrid

# br0.netdev
[Match]

[NetDev]
Kind=bridge
Name=br0

# br0.network
[Match]

[Network]

[Match]
Name = br0

[Network]
DHCP = both

# eth0.network
[Match]

[Network]

[Match]
Name=eth0

[Network]
Bridge=br0

# brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.6ee78ed569b8	no		eth0
							vnet0
							vnet1
							vnet2
							vnet3
virbr0		8000.5254000c1afd	yes		virbr0-nic

# ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        inet6 2a02:169:802::cca  prefixlen 128  scopeid 0x0<global>
        inet6 fdfe:f8a3:6ff2:0:6ce7:8eff:fed5:69b8  prefixlen 64  scopeid 0x0<global>
        inet6 fdfe:f8a3:6ff2::cca  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::6ce7:8eff:fed5:69b8  prefixlen 64  scopeid 0x20<link>
        inet6 2a02:169:802:0:6ce7:8eff:fed5:69b8  prefixlen 64  scopeid 0x0<global>
        ether 6e:e7:8e:d5:69:b8  txqueuelen 1000  (Ethernet)
        RX packets 8785009  bytes<PHONE_NUMBER>0 (10.1 GiB)
        RX errors 0  dropped 12  overruns 0  frame 0
        TX packets 18545906  bytes<PHONE_NUMBER>0 (22.1 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        ether 10:7b:44:f2:bf:eb  txqueuelen 1000  (Ethernet)
        RX packets 10208298  bytes<PHONE_NUMBER>5 (10.4 GiB)
        RX errors 0  dropped 3492  overruns 0  frame 0
        TX packets 18631284  bytes<PHONE_NUMBER>6 (22.2 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xdf100000-df120000

hb_cli: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  destination <IP_ADDRESS>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 3865628  bytes<PHONE_NUMBER> (5.0 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1779524  bytes 96009116 (91.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

jl_cli: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  destination <IP_ADDRESS>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 2432  bytes 233671 (228.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1375  bytes 144389 (141.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 524  bytes 103864 (101.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 524  bytes 103864 (101.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        ether 52:54:00:0c:1a:fd  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether fe:54:00:ea:12:04  txqueuelen 1000  (Ethernet)
        RX packets 46657  bytes 17435373 (16.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 56716  bytes 8908691 (8.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether fe:54:00:d9:33:f8  txqueuelen 1000  (Ethernet)
        RX packets 23714  bytes 5675913 (5.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 29393  bytes 5494692 (5.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether fe:54:00:58:ee:46  txqueuelen 1000  (Ethernet)
        RX packets 70389  bytes 7669914 (7.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 80994  bytes 9348327 (8.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether fe:54:00:b1:e5:c8  txqueuelen 1000  (Ethernet)
        RX packets 16577  bytes 1878409 (1.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16778  bytes 1819563 (1.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wg_home: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  destination <IP_ADDRESS>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1  (UNSPEC)
        RX packets 4670101  bytes<PHONE_NUMBER> (2.7 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16537847  bytes<PHONE_NUMBER>2 (21.2 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wg_office: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1420
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  destination <IP_ADDRESS>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1  (UNSPEC)
        RX packets 337  bytes 31004 (30.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2864  bytes 189900 (185.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# ping google.com
PING google.com (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=49 time=2.32 ms

--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.329/2.329/2.329/0.000 ms

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         turris          <IP_ADDRESS>         UG    203    0        0 br0
default         turris          <IP_ADDRESS>         UG    1024   0        0 br0
<IP_ADDRESS>      <IP_ADDRESS>         <IP_ADDRESS>   U     203    0        0 br0
turris          <IP_ADDRESS>         <IP_ADDRESS> UH    1024   0        0 br0
<IP_ADDRESS>      <IP_ADDRESS>         <IP_ADDRESS>   U     0      0        0 jl_cli
<IP_ADDRESS>      <IP_ADDRESS>         <IP_ADDRESS>   U     0      0        0 wg_office
<IP_ADDRESS>    <IP_ADDRESS>         <IP_ADDRESS>   U     0      0        0 hb_cli
<IP_ADDRESS>      <IP_ADDRESS>         <IP_ADDRESS>   U     0      0        0 wg_home
<IP_ADDRESS>     <IP_ADDRESS>         <IP_ADDRESS>     U     202    0        0 eth0
<IP_ADDRESS>   <IP_ADDRESS>         <IP_ADDRESS>   U     0      0        0 virbr0

the systemd files for the bridge look ok IMHO. However when checking the routing table, there's 2 default gateways define, albeit the same.
In Nixos 18.09 and pre-19.03 I use the following configuration file:

    # Setup Bridging via SystemD
    systemd.network = {
        enable = true;
        netdevs.br0.netdevConfig = {
            Name = "br0";
            Kind = "bridge";
        };
        networks = {
            eth0 = {
                matchConfig = { Name = "eth0"; };
                networkConfig = { Bridge = "br0"; };
            };
            br0 = {
                matchConfig = { Name = "br0"; };
                networkConfig = { DHCP = "yes"; };
            };
        };
    };

    # Setup networking
    networking = {
        usePredictableInterfaceNames = true;
        hostName = "${mySecrets.hostname}"; # Define your hostname.
        hostId = "10101003";
        #  enable = true;  # Enables wireless. Disable when using network manager
        useDHCP = true;
        nameservers = [ "<IP_ADDRESS>" "<IP_ADDRESS>" "<IP_ADDRESS>" "<IP_ADDRESS>" ];
        firewall = {
            enable = false;
            allowPing = true;
            allowedUDPPorts = [ 5000 5001 ];
            allowedTCPPorts = [ 22 5000 5001 ];
            # Netcat: 5000
            # IPerf: 5001
        };
        enableIPv6 = false;
    };

This produces the follwoing:
# systemctl version
systemd 239
+PAM +AUDIT -SELINUX +IMA +APPARMOR +SMACK -SYSVINIT +UTMP -LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid

# br0.netdev
[Match]

[NetDev]
Kind=bridge
Name=br0

# br0.network
[Match]
Name=br0

[Network]
DHCP=yes

# eth0.network
[Match]
Name=eth0

[Network]
Bridge=br0

# brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.6ee78ed569b8	no		eth0
							vnet0
							vnet1
							vnet2
							vnet3
virbr0		8000.5254000c1afd	yes		virbr0-nic

# ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        ether 6e:e7:8e:d5:69:b8  txqueuelen 1000  (Ethernet)
        RX packets 310  bytes 45976 (44.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 153  bytes 22206 (21.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        ether 10:7b:44:f2:bf:eb  txqueuelen 1000  (Ethernet)
        RX packets 360  bytes 56347 (55.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 254  bytes 30593 (29.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0xdf100000-df120000

hb_cli: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  destination <IP_ADDRESS>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 1  bytes 48 (48.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5  bytes 239 (239.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 127  bytes 10910 (10.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 127  bytes 10910 (10.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        ether 52:54:00:0c:1a:fd  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# ping google.com
PING google.com (<IP_ADDRESS>) 56(84) bytes of data.
From jus-law (<IP_ADDRESS>) icmp_seq=1 Destination Host Unreachable
From jus-law (<IP_ADDRESS>) icmp_seq=2 Destination Host Unreachable
From jus-law (<IP_ADDRESS>) icmp_seq=3 Destination Host Unreachable
From jus-law (<IP_ADDRESS>) icmp_seq=4 Destination Host Unreachable
From jus-law (<IP_ADDRESS>) icmp_seq=5 Destination Host Unreachable
From jus-law (<IP_ADDRESS>) icmp_seq=6 Destination Host Unreachable

--- google.com ping statistics ---
9 packets transmitted, 0 received, +6 errors, 100% packet loss, time 197ms
pipe 4

# ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
From <IP_ADDRESS> icmp_seq=1 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=2 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=3 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=4 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=5 Destination Host Unreachable

--- <IP_ADDRESS> ping statistics ---
7 packets transmitted, 0 received, +5 errors, 100% packet loss, time 150ms
pipe 4

# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         turris          <IP_ADDRESS>         UG    202    0        0 eth0
default         turris          <IP_ADDRESS>         UG    203    0        0 br0
<IP_ADDRESS>      <IP_ADDRESS>         <IP_ADDRESS>   U     202    0        0 eth0
<IP_ADDRESS>      <IP_ADDRESS>         <IP_ADDRESS>   U     203    0        0 br0
turris          <IP_ADDRESS>         <IP_ADDRESS> UH    1024   0        0 br0
<IP_ADDRESS>      <IP_ADDRESS>         <IP_ADDRESS>   U     0      0        0 wg_office
<IP_ADDRESS>    <IP_ADDRESS>         <IP_ADDRESS>   U     0      0        0 hb_cli
<IP_ADDRESS>      <IP_ADDRESS>         <IP_ADDRESS>   U     0      0        0 wg_home
<IP_ADDRESS>   <IP_ADDRESS>         <IP_ADDRESS>   U     0      0        0 virbr0

The configs appear to be ok again. However this time I have two default gateways but with different iface uses.
Technical details
Please run nix-shell -p nix-info --run "nix-info -m" and paste the
results.
Currently the server is booted into the 18.03 generation:

system: "x86_64-linux"
host os: Linux 4.9.81, NixOS, 18.03.git.327a847 (Impala)
multi-user?: no
sandbox: yes
nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs
channels(root): `"nixos-18.09.2137.168cbb39691"

Ok, I found now a solution.
Problem was the dhcp part in the networking section. The dhcp made all "natural" interfaces become active so that didn't play with the systemd.network bridge setup.
Furthermore, I needed dhcp in the initrd and zfs needs the hostid. For those those reasons I couldn't get rid of the whole networking section and that's why I used dhcp in there.
My solution is now:
# Add network support to initrd - needed for remote unlocking encrypted zfs root drive
boot.kernelParams = [ "ip=dhcp" ];

# Setup Network Bridge using systemd.network
    systemd.network = {
        enable = true;
        netdevs.br0.netdevConfig = {
            Name = "br0";
            Kind = "bridge";
        };
        networks = {
            eth0 = {
                matchConfig = { Name = "eth0"; };
                networkConfig = { Bridge = "br0"; };
                DHCP = "no";   # Not sure if this is needed but since DHCP interfered before better to be explicit
            };
            br0 = {
                matchConfig = { Name = "br0"; };
                networkConfig = { DHCP = "yes"; };
                dns = [ "<IP_ADDRESS>" "<IP_ADDRESS>" "<IP_ADDRESS>" "<IP_ADDRESS>" ];  # DNS was earlier done by networking but not anymore. So I need it here
            };
        };
    };

    # Setup networking
    networking = {
        usePredictableInterfaceNames = true;
        hostName = "${mySecrets.hostname}"; # Define your hostname.
        hostId = "10101003";
        #  enable = true;  # Enables wireless. Disable when using network manager
        useDHCP = false;    # We do not want to bring up network interfaces here - that's the job of systemd.network
        nameservers = [ "<IP_ADDRESS>" "<IP_ADDRESS>" "<IP_ADDRESS>" "<IP_ADDRESS>" ];
        firewall = {
            enable = false;
            allowPing = true;
            allowedUDPPorts = [ 5000 5001 ];
            allowedTCPPorts = [ 22 5000 5001 ];
            # Netcat: 5000
            # IPerf: 5001
        };
        enableIPv6 = false;
    };


ion-input clearInput Doesnot Work With formControlName

Short description of the problem:
The clear input cross (X) does not show up ion-input whenformControlName is added.
What behavior are you expecting?
To have the clearInput attribute to work along with model driven formControlName
This works
 <ion-input name="trakingNo" clearInput  type="text"></ion-input>

This Does not
 <ion-input name="trakingNo" clearInput formControlName="modelNo" type="text" ></ion-input>

Which Ionic Version? 1.x or 2.x
2..RC 2

1 the same problem. Any news @brandyscarney ?

So it seems to behave this way with a formControlName or ngModel. I can see that when you enter a value from nothing ('' -> 'val') it doesn't appear, but if you lose focus and then refocus the input the clear will show.
Created a PR for this here: https://github.com/driftyco/ionic/pull/10121


[🧹 CHORE]: Autoscale. First look, bugs, proposals

No duplicates 🥲.

[X] I have searched for a similar issue.

What should be improved or cleaned up?
Starting with 2024.3.0 we have autoscale workers 😍
It's a useful feature and, of course, I immediately went to test it out. After a little discussion in Discord (https://discord.com/channels/538114875570913290/1314816983090593803), we came to the conclusion that some things still need to be improved.
1. allocate_timeout is redundant at the moment.
Before autoscale, allocate_timeout was responsible for the startup timeout of the worker. (https://docs.roadrunner.dev/docs/error-codes/allocate-timeout)
Now allocate_timeout is also used as a debounce when spawning new workers in autoscale. I.e. before the EventNoFreeWorkers fire the pool waits for allocate_timeout and only then adds workers.
The obvious problem is that these should be different options in the configuration, since the timeout for creating a new worker and the delay between creating new workers in the pool are different values. Default allocate_timeout is 60s, for workers startup it might be okay. but not for timeout before allocating new dynamic workers in the pool. its too long. For example, if all workers in working status and we have new lightweight request from user, user will wait allocate_timeout (60 seconds) before pool spawn new workers for users request.
It is suggested that allocate_timeout be split into two options.

allocate_timeout, exactly what it was before.
dynamic_allocator.debounce_timeout, the waiting time when all the wokers are in working status before the EventNoFreeWorkers event. debounce_timeout working title, it may be different.

Questions for the community:

Name of debounce_timeout?
Any suggestions and comments.

2. Sometime need to spawn new workers before EventNoFreeWorkers
If our workers have long-time warmup, like need to open big SQLite, or load AI model, etc, we want to spawn new workers in advance. We're ready for overhead, just as long as it's delay-free for the user.
In this case, we want to control spawn new workers before fired EventNoFreeWorkers, for example, when there are less than 2 free workers (status ready).
It is suggested that new options dynamic_allocator.min_ready_workers (working title). If we have min_ready_workers: 2 and in pool we have less than 2 workers in ready status, pool fired EventMinReadyWorkers and spawn new workers from configuration. Of course, the EventMinReadyWorkers event should fire with the debounce_timeout.
Questions for the community:

Name of min_ready_workers?
Need new event like EventMinReadyWorkers, or just fire EventNoFreeWorkers?
Any suggestions and comments.

Hey @trin4ik 👋🏻
Thank you for the valuable feedback 👍🏻 I agree about separating allocate_timeout into 2 options, good old allocate_timeout + allocate specific option for the dynamic pool timeout.
2. MinReadyWorkers is also interesting idea, I need to double check that these new options won't involve on performance, because, you know, why to use RR if it'd be slower than FPM 😃

What is the point in waiting at all? If no workers are available, I would argue you should create a new one immediately and only use the allocate_timeout logic once the maximum number of dynamic workers is reached.

An application may work just fine when all workers are fully loaded and timeout to wait within a few hundred milliseconds. Furthermore, there is no such a single thing called - no workers available. Many threads can wait for a worker and if we allocate them immediately, you may see a huge spike of 100 (or max_workers number) of workers allocated at the same time (maximum for the dynamic allocator).

"No workers available" is just the condition where no worker is idle. Isn't that the point of dynamically scaling workers? To allocate additional workers when they are all busy?
If you set your max_workers to 100, you would expect to be able to handle 100 workers, so what's the problem? This is what FPM does and it has very similar worker scaling if you use pm = dynamic mode (https://www.php.net/manual/en/install.fpm.configuration.php). Maybe there is a small delay with FPM performance reasons, but it's definitely not measured in seconds.
I don't know about the internals of how this works, but waiting more than 50-100ms for a worker seems to defeat the purpose of auto-scaling.

Maybe you could consider "scale-in-delay" as a parameter. So it will wait minimum x ms between starting new workers. This way you get immediate response for the first worker but avoid the spike you mentioned.

I don't know about the internals of how this works, but waiting more than 50-100ms for a worker seems to defeat the purpose of auto-scaling.

yes, which is why it's suggested that we split the timeouts. allocate_timeout is too large for debouncing the start of new workers. but I don't see the point of removing the debounce completely.

I don't know about the internals of how this works, but waiting more than 50-100ms for a worker seems to defeat the purpose of auto-scaling.

yes, which is why it's suggested that we split the timeouts. allocate_timeout is too large for debouncing the start of new workers. but I don't see the point of removing the debounce completely.

Well, the point is that there is no reason to wait at all. If you have saturated your worker pool but your CPU is doing nothing because you're waiting for IO (or whatever - but something typical for web applications), there is no reason to wait. If a delay is necessary for some technical reason, it should be set very low by default.

Well, the point is that there is no reason to wait at all. If you have saturated your worker pool but your CPU is doing nothing because you're waiting for IO (or whatever - but something typical for web applications), there is no reason to wait. If a delay is necessary for some technical reason, it should be set very low by default.

yes, its true, delay should be very slow and that's exactly what this ishue is about.
zerodelay would lead to an overhead, it seems to me.
example: hiload service with many requests, default workers pool 10, spawn_rate 5. every time all workers will be busy for at least 1ms, rr will create +5 workers. expecting at least 50ms is a good solution, at least in my production I would like to see it. the other thing is that the allocate_timeout chosen is certainly not suitable for this.

But why is it a problem creating 5 more workers if all 10 are busy? For this example to make sense, you'd have to receive 15 requests in < 50ms. That's a very tight gap I'd say if the traffic pattern won't continue at all (and hence still require a lot of workers). But I understand your point. I think maybe you can get the best of both worlds with two configs:
Something like:
worker_max_spawn_rate: 2
worker_spawn_delay: 50ms
So every 50ms you will be allowed to create up to 2 more workers, if still necessary. This way you'd would immediately go from 10 to 12 in your example, but not from 12 to 14 before 50ms had passed.


test_cli_do_dfbuyer.py is hanging

Background / motivation
This is in yaml-cli2 branch.
Tests run in this order:
...
pdr_backend/util/test_ganache/test_ccxt_exchanges.py ..       [ 54%]
pdr_backend/util/test_ganache/test_cli_do_dfbuyer.py .         [ 54%]
pdr_backend/util/test_ganache/test_contract.py ....
...

In CI, the tests hang on the test after test_ccxt_exchanges.py. Example log. The test after is test_cli_do_dfbuyer.py.
TODO for this issue
Stop the test from hanging

Fixed in yaml-cli2 branch, in commit https://github.com/oceanprotocol/pdr-backend/pull/403/commits/4dc204c0c53807d76154fd76fa1223f120f35563


Similarity score thresholds

I've checked the TFIDF similarity scores for the Finding 1 which is on index 2014 ("From this time onward the UE shall cipher and integrity protect all NAS signalling messages with the selected NAS ciphering and NAS integrity algorithms.") using the cp_corpus_5G.txt available on the repo. The similarity scores for relevant indexes (1291, 1294, 1298, 1336) (all segments that contains 'From this time onward, all NAS messages exchanged be' part) are well below 0.5.
Did you do any further preprocessing to get the filtered out dataset that was used for the inference with the LLM model?

Hi @thusithathilina,
Thank you for raising the discussion. Can you please check the pairs 1291 and 1298? The similarity value should be 0.72
We did not do additional preprocessing at this step.

@Masfiqur-Mim thanks for the info. I've checked the segments in 1291 and 1298

1291 - After the AMF receives the REGISTRATION REQUEST message 1) if the AMF decides to take the native 5G NAS security context into use, the security mode control procedure is performed.
From this time onward, all NAS messages exchanged between the UE and the AMF are sent integrity protected using the native 5G NAS security context, and except for the messages specified in subclause4.4.5, all NAS messages exchanged between the UE and the AMF are sent ciphered using the native 5G NAS security context; or 2) if the AMF decides to take the mapped 5G NAS security context into use, from this time onward, all NAS messages exchanged between the UE and the AMF are sent integrity protected using the mapped 5G NAS security context, and except for the messages specified in subclause4.4.5, all NAS messages exchanged between the UE and the AMF are sent ciphered using the mapped 5G NAS security context During inter-system change from S1 mode to N1 mode in 5GMM-IDLE mode, if the UE is operating in single-registration mode and a) if the UE has a valid native 5G NAS security context, the UE shall transmit a REGISTRATION REQUEST message integrity protected with the native 5G NAS security context.
1298 - If the verification is successful, the AMF may re-establish the secure exchange of NAS messages a) by replying with a NAS message that is integrity protected and ciphered using the current 5G NAS security context.
From this time onward, all NAS messages exchanged between the UE and the AMF are sent integrity protected and except for the messages specified in subclause 4.4.5, all NAS messages exchanged between the UE and the AMF are sent ciphered; or b) by initiating a security mode control procedure.
As I understand, both of these segments are entail with each other as they include that exception clause.
The one that doesn't include the exception clause is in index 2014
The UE shall set the security header type of the message to "integrity protected and ciphered with new 5G NAS security context" From this time onward the UE shall cipher and integrity protect all NAS signalling messages with the selected 5GS integrity and ciphering algorithms If the AMF indicated in the SECURITY MODE COMMAND message that the IMEISV is requested and a) if the UE 1) supports at least one 3GPP access technology, the UE shall include its IMEISV in the IMEISV IE of the SECURITY MODE COMPLETE message; or 2) does not support any 3GPP access technology (i.e.
Did I miss anything?

Hello @thusithathilina,
Even though the pair with the different clause falls below the threshold (unlike the other pair of "similar" discussions above the threshold), this specific issue was the key motivation from the very beginning of our design; thus, we included it in the set of training examples. Specifically, a closely related inconsistency was pointed out in a previous work [1], which helped us to trace back to it as a positive sample, even though the threshold was prohibitive for it (in fact, there was a bit of tweaking for an appropriate threshold as you may have noticed from the paper discussion). Note that without such a concrete example as ground truth, it was difficult to determine if a consistency measure can indeed be employed. Therefore, we had to keep it notwithstanding the $\psi$ value. However, the thresholding is indeed useful in other scenarios. For instance, the findings shown in the paper-
Finding 2: (from 4G)
1199-

The UE shall consider the USIM as invalid for EPS services and non-EPS services until switching off or the UICC containing the USIM is removed or the timer T3245 expires as described in clause 5.3.7a. Additionally, the UE shall delete the list of equivalent PLMNs and enter state EMM-DEREGISTERED.NO-IMSI. If the message has been successfully integrity checked by the NAS and the UE maintains a counter for "SIM/USIM considered invalid for GPRS services", then the UE shall set this counter to UE implementation-specific maximum value.

1340-

The UE shall consider the USIM as invalid for EPS services until switching off or the UICC containing the USIM is removed or the timer T3245 expires as described in clause 5.3.7a. The UE shall delete the list of equivalent PLMNs and shall enter the state EMM-DEREGISTERED.NO-IMSI. If the UE maintains a counter for "SIM/USIM considered invalid for GPRS services", then the UE shall set this counter to UE implementation-specific maximum value.

Similarity: ~0.94
Finding 3: (from 4G)
259-

In case of failed integrity check (i.e. faulty or missing MAC-I) is detected after the start of integrity protection, the concerned message shall be discarded. This can happen on the UE side or on the eNB side.

316

In case of failed integrity check (i.e. faulty or missing NAS-MAC) is detected after the start of NAS integrity protection the concerned message shall be discarded except for some NAS messages specified in TS 24.301 [9]. For those exceptions the MME shall take the actions specified in TS 24.301 [9] when receiving a NAS message with faulty or missing NAS-MAC.

Similarity: 0.67
Finding 4: (from 5G)
366-

If this verification is successful, then the UE shall take the received NCC value and save it as stored NCC with the current UE context. The UE shall delete the current AS keys KRRCenc, KUPenc (if available), and KUPint (if available), but keep the current AS key KRRCint key. If the stored NCC value is different from the NCC value associated with the current KgNB, the UE shall delete the current AS key KgNB.

598-

If the sent NCC value is fresh and belongs to an unused pair of {NCC, NH}, the ng-eNB shall save the pair of {NCC, NH} in the current UE AS security context and shall delete the current AS key KgNB. If the sent NCC value is equal to the NCC value associated with the current KgNB, the ng-eNB shall keep the current AS key KgNB and NCC.

Similarity: ~0.7
Finding 5: (from 5G)
2248-

If the REGISTRATION REJECT is not integrity protected, the UE shall memorize the current TAI was stored in the list of "5GS forbidden tracking areas for regional provision of service" for the current SNPN and, if the UE supports access to an SNPN using credentials from a credentials holder, the selected entry of the "list of subscriber data" or the selected PLMN subscription, for non-integrity protected NAS reject message If the message was received via 3GPP access and the UE is operating in single-registration mode, the UE shall handle the EMM parameters EMM state, EPS update status, 4G-GUTI, last visited registered TAI, TAI list, eKSI and attach attempt counter as specified in 3GPPTS24.301[15] for the case when the EPS attach request procedure is rejected with the EMM cause with the same value #13 (Roaming not allowed in this tracking area) The UE shall set the 5GS update status to 5U3 ROAMING NOT ALLOWED (and shall store it according to subclause<IP_ADDRESS>.2) and shall delete 5G-GUTI, last visited registered TAI, TAI list and ngKSI.

2462-

If the REGISTRATION REJECT message is not integrity protected, the UE shall memorize the current TAI was stored in the list of "5GS forbidden tracking areas for regional provision of service" for the current SNPN and, if the UE supports access to an SNPN using credentials from a credentials holder, the selected entry of the "list of subscriber data" or the selected PLMN subscription, for non-integrity protected NAS reject message If the message was received via 3GPP access and the UE is operating in single-registration mode, the UE shall handle the EMM parameters EMM state, EPS update status, 4G-GUTI, last visited registered TAI, TAI list, eKSI and tracking area updating attempt counter as specified in 3GPPTS24.301[15] for the case when the normal tracking area updating procedure is rejected with the EMM cause with the same value #13 (Roaming not allowed in this tracking area) The UE shall set the 5GS update status to 5U3 ROAMING NOT ALLOWED (and shall store it according to subclause<IP_ADDRESS>.2) and shall delete the list of equivalent PLMNs (if available).

Similarity: ~0.89
Finding 6: (from 4G)
1505-

If the DETACH REQUEST message contains detach type "re-attach not required" and EMM cause #2 "IMSI unknown in HSS", the UE will follow the procedure as described below for the detach type "IMSI detach" EPS detach containing detach type "IMSI detach" If the UE receives a DETACH REQUEST message before the tracking area updating procedure has been completed, the DETACH REQUEST message shall be ignored and tracking area updating procedure shall be progressed The UE shall proceed as described below g) Tracking area updating and GUTI reallocation procedure collision If the UE receives a GUTI REALLOCATION COMMAND message before the tracking area updating procedure has been completed, this message shall be ignored and the tracking area updating procedure shall be progressed h) Transmission failure of TRACKING AREA UPDATE REQUEST message indication from lower layers The tracking area updating procedure shall be aborted and re-initiated immediately.

1524-

If a failure of the handover procedure is reported by the lower layer and the S1 signalling connection exists, the MME shall retransmit the TRACKING AREA UPDATE ACCEPT message or TRACKING AREA UPDATE REJECT message g) DETACH REQUEST message received before the TRACKING AREA UPDATE ACCEPT message is sent or before the TRACKING AREA UPDATE COMPLETE message (in case of GUTI and/or TMSI was allocated) is received Detach containing cause "switch off" The network shall abort the signalling for the tracking area updating procedure towards the UE and shall progress the detach procedure as described in clause <IP_ADDRESS> NOTE 4: Internally in the network, before processing the detach request, the MME can perform the necessary signalling procedures for the tracking area updating procedure before progressing the detach procedure Detach containing other causes than "switch off" The network shall proceed with the tracking area updating procedure and shall progress the detach procedure after successful completion of the tracking area updating procedure h) If the TRACKING AREA UPDATE REQUEST message with EPS update type IE indicating "periodic updating" is received by the new MME which does not have the EMM context data related to the subscription, the new MME may send the TRACKING AREA UPDATE REJECT message with EMM cause value #10 "Implicitly detached" .

Similarity: ~0.67
and so on. I hope this clarifies.

@Masfiqur-Mim Thank you very much for the explanation 👍


Visual pages and visual groups are broken for the XMAS plugin

when trying to group nodes into a page, the connecting arcs "fly" away in different directions

this problem is probably caused by incorrect translation of the XMAS node elements

danilovesky at 2014-09-09T21:01:46Z:
Temporary disable pages tool in this plugin.


Tooltip - separate "floating" component and optimise documentation in code

Description / User story
After the discussion on 31.01. about #303 and #742 we made a few decisions how components should be structured. The goal is to also be aligned between design and code.
Currently the Tooltip is not aligned, as there are two components in code but only one in design. This ticket is to optimise the current situation and to follow the new rules.
One decision could be to completely rename the current Tooltip component in code, as it basically is just a reference to the tooltip and provides the needed logic to place the component for example in a slider.
Requirements

[x] #859
[x] #858

Acceptance Criteria

[x] The Tooltip component in code has been renamed to "Tooltip using Floating UI", moved into the "Examples" section in Storybook (and in codebase) and its documentation has been updated accordingly:

[x] Headline: "Tooltip using Floating UI"
[x] Intro: "This example page shows how the Tooltip component can utilize Floating UI to place it in reference to another element, which then controls the visibility, the arrow placement or the offset of the tooltip."
[x] The sections "HasArrow", "Dependencies" and "Elevation" have been removed from the documentation

[x] The Tooltip Bubble component in code has been renamed to: "Tooltip"
[ ] The intro text of the Tooltip bubble has been changed to:

"Tooltip is triggered by hovering the mouse cursor over the element.
It is designed to be unobtrusive and usually consist of a short snippet of text.
To make this work technically the tooltip component can be combined with Floating UI like shown on the example page [Tooltip using Floating UI](link this to the new example page created in the first AC)."

[x] The Has Arrow Text in the Tooltip documentation has been updated to:

"The Tooltip Bubble component can have a pointing arrow, directing the user's attention to the specific element, or appear as a self-contained box. Floating UI can also be utilized to change the direction of the arrow and always point to the referenced element like shown on the example page [Tooltip using Floating UI](link this to the new example page created in the first AC)."

[x] Props Excel has been updated accordingly, comments have been resolved and props changed from red to black font color > @thrbnhrtmnn or @angelicahoyss can support here

Additional information
Pseudo Code / Architecture

Code of Conduct

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

@veilvokay was working on this before, so there might be something to work with then already when starting this task. It might make sense to check out the tooltipp-refactor-playground branch

Updated the ACs as discused @angsherpa456

As discussed with @faselbaum today, we should change the approach again, sorry for the confusion @angsherpa456 .
New idea: We remove the tooltip bubble and only keep the tooltip component. This makes more sense, as this component is way smarter then the tooltip bubble component. The argument, that the tooltip bubble is the equivalent to the tooltip in design is flawed, as most of our components like i.e. the number input have logic, which is not part of the component in design (i.e. clicking the stepper increases or decreases the value). Similar topic for the tooltip, here the logic for the placement of the tooltip is solved in code with the help of the floating ui library, whereas in design this is done by functionality in figma (i.e. making the component wrapper hugging the referencing element).
This new approach would now lead to the following ACs (incl. minor optimisations of the documentation):

Tooltip Bubble has been removed in storybook and in the codebase
Tooltip is now the only tooltip component in Storybook and in the codebase
The tooltip documentation has been updated:

"Floating UI" in the intro text links to the floating ui documentation
The dependencies section has been removed (also in the Table of Content)
The placement prop description in the props panel has been updated to:

Select preferred placement of the component to the related element. If the preferred placement is not in the viewport, the component will adjust the placement on its own.

The text in the placement documentation should be updated to:

The Tooltip component can be positioned in any of the following placements: top, top-start, top-end, right, right-start, right-end, bottom, bottom-start, bottom-end, left, left-start, and left-end. Via the placement prop you can select your preferred placement, which the component will display when the viewport allows it. In case the preferred placement does not allow for the tooltip to be fully displayed, but another placement would work, the placement will be adjusted.