CLIMATE-609 - Add data source flag to dataset origin information

Add a 'source' flag to dataset origin information when loaded from a
data_source. This is set to 'local', 'dap', 'esgf', or 'rcmed'
depending on the data_source used.
Update data_source tests to take new source flag into account.

Merged build triggered. Test Failed.

Merged build started. Test Failed.

Merged build finished. Test Passed.


Installation instructions

Hi,
Can you please provide building/installation instructions?
Thank you!

I managed to run it locally:
npm run build
npm run dev

Thanks for your feedback, just added all the instructions on this README section.


feature(_dev): Add package neofetch

How to categorize this PR?

/kind enhancement
/area os
/os garden-linux
What this PR does / why we need it:
Add package neofetch to feature _dev
Which issue(s) this PR fixes:
Fixes #1720
Special notes for your reviewer:
Do not merge before the custom neofetch packages is included within the Garden Linux repository.
Release note:

- category: feature
- target_group: user

Hm. As of today I fail to build GL:
[.build/khost_dev-amd64-today-0bb18341.tar 2023-10-17 07:00:55] warning: number of platforms != 1
[.build/khost_dev-amd64-today-0bb18341.tar 2023-10-17 07:00:55] exec: /builder/features/server/exec.early
[.build/khost_dev-amd64-today-0bb18341.tar 2023-10-17 07:00:55] Reading package lists...
[.build/khost_dev-amd64-today-0bb18341.tar 2023-10-17 07:00:55] Building dependency tree...
[.build/khost_dev-amd64-today-0bb18341.tar 2023-10-17 07:00:55] E: Unable to locate package neofetch
completed in 0 seconds

make: *** [Makefile:55: .build/khost_dev-amd64-today-0bb18341.tar] Error 100```

Am I missing something there?

/cc @Vincinator @gyptazy

Seems to be fixed, no longer reproducable


jellyfish-wallet-classic

What kind of PR is this?:

/kind feature
What this PR does / why we need it:
WalletClassic implements a simple, single elliptic pair wallet.
Which issue(s) does this PR fixes?:

Fixes #452
Additional comments?:

@ivan-zynesis I agree but this would require some refactoring of Whale, as Whale requires a WalletEllipticPair interface for it's providers

@ivan-zynesis I agree but this would require some refactoring of Whale, as Whale requires a WalletEllipticPair interface for it's providers

Yeah, it requires jellyfish-wallet as jellyfish-wallet-classic is a jellyfish wallet provider.

it just tick over to 97.5, we have 98% coverage now on the badge :)


Feature/update design system

Bump design-system version, implement component library

[x] Bump design-system -> v2.0.1
[x] Use components from<EMAIL_ADDRESS>[x] Remove app-specific components

To test
Run flask app and client locally, ensure styles match PDAP branding and that everything functions as expected.

@kalenluciano this is good feedback. I think I'd like to just address these in #130


QnA Maker and LUIS should be listed in required resources if needed in Publishing Profile

Is your feature request related to a problem? Please describe.
Today, we identify and help you provision LUIS and QnA Maker when you open your bot project, however when you have publishing profiles already created and / or you create a new one you should be told that these are required resources on the Add resources modal.

Describe the solution you'd like
By intelligently adding the required resources based off of your project, this will make it where you don't get an error message when you go to publish.
Describe alternatives you've considered
Using the Next Steps menu to provide details that you should add the required resources to your publishing profiles to ensure that you give the user a heads up that all publishing profiles will now require this to be added and walk them through getting this done.  Maybe even disable publishing until these issues are addressed.

Discovered we need to filter by project ID for the required LUIS or QnA so reactivating this as the issue for making and update PR.


Add conditional compile switches for CERT and CHAL capabilities.

libspdm/issues/2.
Signed-off-by: Kong, Richard<EMAIL_ADDRESS>

I don't recommend to use SPDM_ENABLE_*_CAP in spdm.h.
The spdm.h just follows SPDM spec, and SPDM spec does not have such concept.
All rest seems good to me.

@jyao1 Are you saying I should leave the request/response structures in spdm.h always visibly defined to the compiler (not #if'd out)? I was doing that to ensure we don't miss any code that we should be disabling. Any idea how else I could make sure all code that should be disabled, actually is disabled?

@jyao1 Are you saying I should leave the request/response structures in spdm.h always visibly defined to the compiler (not #if'd out)? I was doing that to ensure we don't miss any code that we should be disabling. Any idea how else I could make sure all code that should be disabled, actually is disabled?

Right. That is my idea. The original purpose of spdm_lib_config.h is to configure the spdm_lib, but not the spec.
I am worried, because that enforces people to include spdm_lib_config.h to properly configure the specification. E.g. spdm-dump, or UEFI consumer.  That is extra complexity.
I can understand that your requirement seems to have a way to configure the specification. As such, no definition will be appeared. I think it is valid request. Capability is one example, I feel SPDM version is another example in the future.
If so, I am thinking to have a separate .h to perform that, such as spdm_spec_config.h. Worth discussing.

Is there any size estimation after we use these flags?

I did not collect any measurements. Figured I would after we did our changes for all the capabilities.


ERROR: Challenge unsuccessful: pending

In the challenge response, I got the status "pending". So I had to change line 135 of __main__.py from:
challenge.poll_until_not({'processing'})

to:
challenge.poll_until_not({'pending','processing'})

Hi @seandroms,
Thanks for the bug report! I hadn't seen this issue in the past, but I suspect this is what happens if the request gets queued on the Let's Encrypt side. Your fix looks like the right one so I'll apply right away.


Getting and error while trying to upload s3

Hi,
I am trying to upload items to s3 but I am getting the following error.
Start asset upload to s3. Encountered an unknown error processing this request, please try again.

I'm getting the same error.


kata-ctl: add code for framework for arch

Add framework for different architectures for check. In the existing
kata-runtime check, the network checks do not appear to be
architecture-specific while the kernel module, cpu, and kvm checks do
have separate implementations for different architectures.
Signed-off-by: Chelsea Mafrica<EMAIL_ADDRESS>

@jodh-intel would you like me to add you as a coauthor since I used a lot of the code from https://github.com/jamesodhunt/rust-arch-specifics/tree/main/src/arch?


Fixes issue when goTo is used on a non preloaded image.

This only fixes when the goTo image is going forward, there is still an issue going backwards and only happens on type: image so there should be a better fix.
The issue is that getImage and therefor findImageSize is executed BEFORE triggering the change event and on some cases no img attribute is set on the item.


Including ApiGenerator.cs in projects with enable causes unsuppressible warnings

The PublicApiGenerator package includes a file as source which results in warnings when included in any project with <Nullable>enable</Nullable>:

GlobalSuppressions.cs is not an option because the warnings are coming from the C# compiler itself. The only recourse is to add pragmas to the source file itself to silence a CS8600, CS8603, and CS8625 (so far). Changes to the source file itself can only be done by the package publisher.

9.x no longer ships sources. I'm guessing there is nothing to fix then?

You're right, that's awesome. Thank you!


Critical CVE detected on latest tag

Hi !
When scanning this image with trivy (vulnerability scanner), it found 4 CRITICAL CVE.
Here is the complete result for the latest tag :
$ trivy image --scanners vuln willfarrell/autoheal:latest

willfarrell/autoheal:latest (alpine 3.13.5)
===========================================
Total: 37 (UNKNOWN: 0, LOW: 0, MEDIUM: 6, HIGH: 27, CRITICAL: 4)

┌──────────────┬────────────────┬──────────┬───────────────────┬───────────────┬─────────────────────────────────────────────────────────────┐
│   Library    │ Vulnerability  │ Severity │ Installed Version │ Fixed Version │                            Title                            │
├──────────────┼────────────────┼──────────┼───────────────────┼───────────────┼─────────────────────────────────────────────────────────────┤
│ apk-tools    │ CVE-2021-36159 │ CRITICAL │ 2.12.5-r0         │ 2.12.6-r0     │ libfetch before 2021-07-26, as used in apk-tools, xbps, and │
│              │                │          │                   │               │ other products, mishandles...                               │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-36159                  │
├──────────────┼────────────────┼──────────┼───────────────────┼───────────────┼─────────────────────────────────────────────────────────────┤
│ busybox      │ CVE-2021-42378 │ HIGH     │ 1.32.1-r6         │ 1.32.1-r7     │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42378                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42379 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42379                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42380 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42380                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42381 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42381                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42382 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42382                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42383 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42383                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42384 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42384                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42385 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42385                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42386 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42386                  │
│              ├────────────────┤          │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2022-28391 │          │                   │ 1.32.1-r8     │ busybox: remote attackers may execute arbitrary code if     │
│              │                │          │                   │               │ netstat is used                                             │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2022-28391                  │
│              ├────────────────┤          │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2022-30065 │          │                   │ 1.32.1-r9     │ busybox: A use-after-free in Busybox's awk applet leads to  │
│              │                │          │                   │               │ denial of service...                                        │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2022-30065                  │
│              ├────────────────┼──────────┤                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42374 │ MEDIUM   │                   │ 1.32.1-r7     │ busybox: out-of-bounds read in unlzma applet leads to       │
│              │                │          │                   │               │ information leak and denial...                              │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42374                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42375 │          │                   │               │ busybox: incorrect handling of a special element in ash     │
│              │                │          │                   │               │ applet leads to...                                          │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42375                  │
├──────────────┼────────────────┼──────────┼───────────────────┼───────────────┼─────────────────────────────────────────────────────────────┤
│ libcrypto1.1 │ CVE-2021-3711  │ CRITICAL │ 1.1.1k-r0         │ 1.1.1l-r0     │ openssl: SM2 Decryption Buffer Overflow                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-3711                   │
│              ├────────────────┼──────────┤                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-3712  │ HIGH     │                   │               │ openssl: Read buffer overruns processing ASN.1 strings      │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-3712                   │
│              ├────────────────┤          │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2022-0778  │          │                   │ 1.1.1n-r0     │ openssl: Infinite loop in BN_mod_sqrt() reachable when      │
│              │                │          │                   │               │ parsing certificates                                        │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2022-0778                   │
│              ├────────────────┼──────────┤                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2022-2097  │ MEDIUM   │                   │ 1.1.1q-r0     │ openssl: AES OCB fails to encrypt some bytes                │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2022-2097                   │
├──────────────┼────────────────┼──────────┤                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│ libssl1.1    │ CVE-2021-3711  │ CRITICAL │                   │ 1.1.1l-r0     │ openssl: SM2 Decryption Buffer Overflow                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-3711                   │
│              ├────────────────┼──────────┤                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-3712  │ HIGH     │                   │               │ openssl: Read buffer overruns processing ASN.1 strings      │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-3712                   │
│              ├────────────────┤          │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2022-0778  │          │                   │ 1.1.1n-r0     │ openssl: Infinite loop in BN_mod_sqrt() reachable when      │
│              │                │          │                   │               │ parsing certificates                                        │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2022-0778                   │
│              ├────────────────┼──────────┤                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2022-2097  │ MEDIUM   │                   │ 1.1.1q-r0     │ openssl: AES OCB fails to encrypt some bytes                │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2022-2097                   │
├──────────────┼────────────────┼──────────┼───────────────────┼───────────────┼─────────────────────────────────────────────────────────────┤
│ ssl_client   │ CVE-2021-42378 │ HIGH     │ 1.32.1-r6         │ 1.32.1-r7     │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42378                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42379 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42379                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42380 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42380                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42381 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42381                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42382 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42382                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42383 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42383                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42384 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42384                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42385 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42385                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42386 │          │                   │               │ busybox: use-after-free in awk applet leads to denial of    │
│              │                │          │                   │               │ service and possibly...                                     │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42386                  │
│              ├────────────────┤          │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2022-28391 │          │                   │ 1.32.1-r8     │ busybox: remote attackers may execute arbitrary code if     │
│              │                │          │                   │               │ netstat is used                                             │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2022-28391                  │
│              ├────────────────┤          │                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2022-30065 │          │                   │ 1.32.1-r9     │ busybox: A use-after-free in Busybox's awk applet leads to  │
│              │                │          │                   │               │ denial of service...                                        │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2022-30065                  │
│              ├────────────────┼──────────┤                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42374 │ MEDIUM   │                   │ 1.32.1-r7     │ busybox: out-of-bounds read in unlzma applet leads to       │
│              │                │          │                   │               │ information leak and denial...                              │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42374                  │
│              ├────────────────┤          │                   │               ├─────────────────────────────────────────────────────────────┤
│              │ CVE-2021-42375 │          │                   │               │ busybox: incorrect handling of a special element in ash     │
│              │                │          │                   │               │ applet leads to...                                          │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2021-42375                  │
├──────────────┼────────────────┼──────────┼───────────────────┼───────────────┼─────────────────────────────────────────────────────────────┤
│ zlib         │ CVE-2022-37434 │ CRITICAL │ 1.2.11-r3         │ 1.2.12-r2     │ zlib: heap-based buffer over-read and overflow in inflate() │
│              │                │          │                   │               │ in inflate.c via a...                                       │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2022-37434                  │
│              ├────────────────┼──────────┤                   ├───────────────┼─────────────────────────────────────────────────────────────┤
│              │ CVE-2018-25032 │ HIGH     │                   │ 1.2.12-r0     │ zlib: A flaw found in zlib when compressing (not            │
│              │                │          │                   │               │ decompressing) certain inputs...                            │
│              │                │          │                   │               │ https://avd.aquasec.com/nvd/cve-2018-25032                  │
└──────────────┴────────────────┴──────────┴───────────────────┴───────────────┴─────────────────────────────────────────────────────────────┘

Could this be addressed somehow ?
Thanks a lot !

@AlexisPPLIN The CVEs are from the outdated alpine image used as the base for autoheal. If you update the Dockerfile for alpine 3.17.3 and build a new copy of autoheal, then you'll pass the trivy scan with no CVEs (for now).

Since latest tag is being built until today, Isn't a good idea use alpine:latest tag to allow low maintenance and lower surface for CVEs?
This container still mantained - by the way?

@leleobhz No idea if this project is still maintained, but I'm building from alpine:latest with the tcp docker proxy patch from issue #48. It seems to be working so far, but I haven't had time to really test or publish the work (yet).

Thanks for the precision @tylerpace !
(If you ever release your work and a new built containers, I would love to be informed ❤)
Like what @leleobhz said, relying on alpine:latest for new builds would be better for security.
But this project seems abandoned and that's a shame since docker still does not have a native solution to restart unhealthy containers.

@AlexisPPLIN I made a fork at https://github.com/tylerpace/docker-autoheal and merged in most of the PRs here. I'm not making any ongoing maintenance promises yet, but I'll at least get to the point of setting up a basic Github actions pipeline that builds from alpine:latest and pushes to a public registry for those that want to YOLO my updates. 😁

Hello @tylerpace
I took the place to build you repo weekly at https://github.com/ZenithTecnologia/docker-autoheal-build/ (Zenith Tecnologia is my Organization).
I strongly suggest you to keep 2 Dockerfiles: Dockerfile for pined version and Dockerfile.latest to 'alpine:latest'.
Anyways, this is a fast way to have a minimal updated image in a public registry :)

Hello @tylerpace
I took the place to build you repo weekly at https://github.com/ZenithTecnologia/docker-autoheal-build/ (Zenith Tecnologia is my Organization).
I strongly suggest you to keep 2 Dockerfiles: Dockerfile for pined version and Dockerfile.latest to 'alpine:latest'.
Anyways, this is a fast way to have a minimal updated image in a public registry :)

Why have two Dockerfiles?
The only reason I can see currently to have two Dockerfiles is so that one can have a version which auto generates a pull request to update via dependabot/renovate.
Just set an ARG, default being pinned or latest.
In the pipeline, have two tags, one which handles the default arg, one which passes the latest tag.
It would simplify builds and reduce code sprawl.
An example: Dockerfile with a build pipeline similar to droneci
Another note, it seems that Alpine:latest is not a rolling release like Ubuntu for example, but references the latest tagged version.
Unsure if tagging per Alpine release would be the best solution in this case.

Hello!
Idea here is not overengineering it too much, but just keep it updated. In fact I have tons of considerations about Alpine+MUSL but since this is a little bashy tool, the only concern I have is about security fixes.
By my own mind, I prefer using RedHat UBI Minimal, RedHat UBI Micro or VMWare Photon as base image, since they cover security updates quickly than other images and have almost same low footprint as Alpine (Photon have ~15mb):
I agree with everything about the rest and since this image still relevant, I suggest we create a little project with all people here commited with this project to modernize and mantain this still-important tool working well.

I agree with everything about the rest and since this image still relevant, I suggest we create a little project with all people here commited with this project to modernize and mantain this still-important tool working well.

I'd be happy to contribute.

I agree with everything about the rest and since this image still relevant, I suggest we create a little project with all people here commited with this project to modernize and mantain this still-important tool working well.

I'd be happy to contribute.
This is my repo (just a fork of @tylerpace's with a few modifications to the Dockerfile + workflow) where I've simplified my above comment, and went back to relying on tags for version control/pinned versions.

I liked you ARG usage for Alpine version because it allows third party builds with other versions w/o maintenance issues (Repo can just be cloned and built against desired version).
I'll attempt some builds for Photon/UBI pushing docker-entrypoint from your master branch to have another basis for autoheal.
This project is necessary - since Docker still not have a rebuild-on-failure feature - and deserves attention and mantainance.

Wow, this issue seems to be quite popular :smile:
AFAIK, we have to following images to replace willfarrell/docker-autoheal (if not updated) :

@modem7 and @tylerpace : modem7/docker-autoheal:1.2.1
@leleobhz  : quay.io/zenithtecnologia/docker-autoheal:latest

I will be using modem7/docker-autoheal:1.2.1 because tagged versions > latest for my job workflow.
In the long run, maybe it would be easier to have only one repo to re-group all this work and give an easy remplacement of willfarrell/docker-autoheal. Idk
Great job everyone !

@tylerpace @AlexisPPLIN @leleobhz - May be worthwhile putting everything into one repo, and having multiple maintainers? May be neater that way.
I'm happy to use my CI/CD system to  build and deploy the images to dockerhub on my repo if that would help out?

@tylerpace @AlexisPPLIN @leleobhz - May be worthwhile putting everything into one repo, and having multiple maintainers? May be neater that way.
I'm happy to use my CI/CD system to  build and deploy the images to dockerhub on my repo if that would help out?

I'm already using your image. I can contribute and maintain too, so how do you think is the best way to we keep maintaining the images?

We'd probably need to get all maintainers who are interested together, then officially request taking over the image (assuming @willfarrell is still active and would give us their blessing).
Once that happens, I can give the above people (including @willfarrell) maintainer access to the repo and go on from there.
Happy to be corrected however!

Once that happens, I can give the above people (including @willfarrell) maintainer access to the repo and go on from there.

I agree if everyone agree. Also this can unify efforts to improve images, create other tags that maybe necessary and keep a proper CI/CD pipeline allowing upstream fixes to be reflected to this image.
This tool is important as Docker does not handle crashes like Kubernetes does - as example - and this tool provides healing without add unecessary complexity to environments.

I've added all 3 of you. Thanks for your interest in maintaining this repo. I don't currently use this in any active projects which is why I've been so inactive.

@willfarrell @modem7 and @tylerpace - I think this is the time we can get together to check the next steps.
I suggest initially we merge @modem7 repo with here and update main docker image / CI/CD pipeline / etc.
This is a good plan?

No worries @willfarrell, thanks for the help !

I suggest initially we merge @modem7 repo with here and update main docker image / CI/CD pipeline / etc.

+1 to use the @modem7 repo in here. No issues with it in the last 2 month.
And maybe it's also time to open a new issue ?

If @willfarrell has added us to this repo, we may as well use it to avoid confusion for those that aren't checking the updates.
I would probably need access to dockerhub as well if we're using my CD system (Drone), and we can set it up for releases/tags quite easily (as I have on my repo).
Happy to do whatever is best for all (we can also use github actions as well which may be better in case my system goes down/I leave the project/I get compromised).

+1 to using @modem7's variant as the one to officially merge here. It's the most updated now, I'm using it too!
+1 to keeping this repo as the primary. I'm sure there are plenty of folks out there still running a very outdated autoheal sitting on latest that would benefit from us publishing an update under this namespace.
+1 to moving CD to Github Actions. That's one less dependency that breaks as maintainers shift on this project. It's also helpful for anyone that forks in the future to get a CD pipeline for 'free'.

@tylerpace and @modem7 I can Write Github Actions. I'll prepare the PR here tomorrow.

Sounds like a plan.
I'll figure out what I've done on my repo, and get a PR made to merge.

Hey !
Do you need any help whatsoever?
I have some free time to work on this repo

Sorry this took so long guys. Work has been hectic as hell.
I've created https://github.com/willfarrell/docker-autoheal/pull/112/ which has a lot of @tylerpace's and some of my contributions. It should certainly set a good starting point for the rest of the work.

@modem7 I also have issues to address, but notting does any sense if both you and @tylerpace was not merged here, so let's address https://github.com/willfarrell/docker-autoheal/pull/112 and close this.

@modem7 I also have issues to address, but notting does any sense if both you and @tylerpace work was not merged here, so let's address #112 and close this.

Agreed - let's have a common starting point, and then we can start sorting the rest out.

When is it planned to release these CVE fixes please?

My server is currently down right now, so I'll need a bit of time whilst I get replacement parts if we're doing it on my repo.
If we're doing it on the original repo, we should be able to do it via github actions.

My server is currently down right now, so I'll need a bit of time whilst I get replacement parts if we're doing it on my repo.
If we're doing it on the original repo, we should be able to do it via github actions.

@modem7 While I now think https://github.com/willfarrell/docker-autoheal/blob/main/.github/workflows/github-build.yml is good enough (But some changes need to be done), CVE must be ported by upstream in a ideal world.
Apparently fixes comes to releases of Alpine, so I'll ask for pinning to 3.18 instead a explicit release version.


#5875 - Make dropdown arrows clickable

Details

Fixed Issues

$ GH_LINK
Tests

QA Steps

Tested On

[x] Web
[x] Mobile Web
[x] Desktop
[x] iOS
[x] Android

Screenshots

Web
https://user-images.githubusercontent.com/39444813/144056992-b927f17b-e1f0-4dfd-9314-3623a3e18921.mov
Mobile Web
https://user-images.githubusercontent.com/39444813/145066810-0c6ff8e0-81d4-4102-8f91-9d22b9aab568.mov
Desktop
https://user-images.githubusercontent.com/39444813/144057394-26ad37cd-5a2c-4efc-bd24-e9f19bf0b972.mov
iOS
https://user-images.githubusercontent.com/39444813/145055770-ce51406c-d424-41ce-bf99-91d26c8f8741.mov
Android
https://user-images.githubusercontent.com/39444813/146194359-f0802809-8532-40a2-b90f-25a3d77138da.mov

Could you update your Fixed Issues section to include the github issue link that you are fixing. Normally you should place the Github issue URL there before putting the PR for review so that the reviewers of your proposal get automatically assigned to review the PR.

Also, you'll need to have tests / QA steps in your description explaining how we and QA team should be testing your PR.
Additionally, I've tested this flow on the latest master branch and on production but the dropdown arrows are perfectly clickable. Was this resolved elsewhere at some point and is this is a non-issue anymore?

Ah yeah sorry about that, forgot to include the issue link.
And yeah now that you mention it, it looks like this issue was fixed here shortly after I got accepted for the job. pointer-events is a better option to make the arrow unclickable compared to z-index (which was used instead), but probably not enough to go through the effort of a change. What do you think @chiragsalian?

Yeah, I don't feel like any more effort needs to be made here. I think we should just go ahead and close out this PR and issue and work on other important tasks.
Thanks for the effort Mateo. I guess this one reason why we state in the contributor guidelines that providing daily updates is important. This way you and everyone else can test the PR daily against dev and production to notice changes immediately.


Table i18n denny

Summary

Add i18n strings to table

Change List (commits, features, bugs, etc)

copy from master

Related Issues

Closes IBM/carbon-addons-iot-react#590

Acceptance Test (how to verify the PR)

tests here

:tada: This PR is included in version 1.98.4 :tada:
The release is available on:

npm package (@release-1.x dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.14.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Importing AdvancedSMCExtensions algorithms

Hi everyone,
I was wondering why the algorithms from src/contrib/inference/AdvancedSMCExtensions.jl are currently not accessible from Turing's API. Are they accessible from any other package?
Thanks!

No, these currently aren't available -- we made some internal changes a while ago and haven't gone back to update the code in that file. I believe they should eventually go into AdvancedPS.jl.


LayerKey for layers

MapWindow has this property called LayerKey that is used like so Map.LayerKey that can store some bit of info as the user sees fit. I load a description of the layer like so
Map.LayerKey(hnd) = shapeType & numShapes & calcTime
Later when a user hovers over the polyline I can show that info in a Tooltip. Does DotSpatial have a property that can hold a string of data like LayerKey?

There is no such property. But, for example, you can easily  create own dictionary in your program to store custom information per layer.


Docker build tasks are failing since today: invalid argument --tag

Required Information
Question, Bug, or Feature?
Type: Bug
Enter Task Name: Docker build
Environment
Azure Pipelines
Hosted Agent
Issue Description
Since today all Docker build tasks are failing in our pipeline:
Starting: Build Backend Container
==============================================================================
Task         : Docker
Description  : Build or push Docker images, login or logout, start or stop containers, or run a Docker command
Version      : 2.181.0
Author       : Microsoft Corporation
Help         : https://aka.ms/azpipes-docker-tsg
==============================================================================
/usr/bin/docker build -f /home/vsts/work/1/s/backend/Dockerfile --label com.visualstudio.XXXXXXXX.image.system.teamfoundationcollectionuri=https://XXXXXXXX.visualstudio.com/ --label com.visualstudio.XXXXXXXX.image.system.teamproject=XXXXXXXX --label com.visualstudio.XXXXXXXX.image.build.repository.name=prj-foobar --label com.visualstudio.XXXXXXXX.image.build.sourceversion=64c164c6cca0a26aaa42770e41d4877dedbf4363 --label com.visualstudio.XXXXXXXX.image.build.repository.uri=
invalid argument "***/foobar/foobar-backend:" for "-t, --tag" flag: invalid reference format
See 'docker build --help'.
##[error]invalid argument "***/foobar/foobar-backend:" for "-t, --tag" flag: invalid reference format
##[error]See 'docker build --help'.
##[error]The process '/usr/bin/docker' failed with exit code 125
Finishing: Build Backend Container

The same pipeline (no changes!) worked fine yesterday:
Starting: Build Backend Container
==============================================================================
Task         : Docker
Description  : Build or push Docker images, login or logout, start or stop containers, or run a Docker command
Version      : 2.176.0
Author       : Microsoft Corporation
Help         : https://aka.ms/azpipes-docker-tsg
==============================================================================
/usr/bin/docker build -f /home/vsts/work/1/s/backend/Dockerfile --label com.visualstudio.XXXXXXXX.image.system.teamfoundationcollectionuri=https://XXXXXXXX.visualstudio.com/ --label com.visualstudio.XXXXXXXX.image.system.teamproject=XXXXXXXX --label com.visualstudio.XXXXXXXX.image.build.repository.name=prj-foobar --label com.visualstudio.XXXXXXXX.image.build.sourceversion=5ee2b484bf8283433a5e99cab949a2bcd0452b98 --label com.visualstudio.XXXXXXXX.image.build.repository.uri=
Sending build context to Docker daemon  138.3MB

Step 1/26 : [...cut...]

The only difference is the task version.
Here is the task definition:
    - task: Docker@2
      displayName: Build Backend Container
      inputs:
        containerRegistry: $(dockerRegistryServiceConnection)
        repository: '$(namespace)/$(image_name_backend)'
        command: 'build'
        Dockerfile: 'backend/Dockerfile'
        buildContext: '.'
        tags: $(image_tags)
        arguments: '--build-arg ENV_FOOBAR_GENERAL_BUILDVERSION=$(Build.BuildNumber)'

The images tags are defined like this:
  image_tags: |
    $(Build.SourceBranchName)
    $(Build.BuildId)
    $(Build.SourceVersion)

Please refer this issue. We have made a fix from our end, it should reach out to all the customers in few days. But in the mean time you can try the workarounds mentioned in the issue.

Please refer this issue. We have made a fix from our end, it should reach out to all the customers in few days. But in the mean time you can try the workarounds mentioned in the issue.

Workaround is working. Thanks!
  image_tags: |-
    $(Build.SourceBranchName)
    $(Build.BuildId)
    $(Build.SourceVersion)

Workaround is working. Thanks!
  image_tags: |-
    $(Build.SourceBranchName)
    $(Build.BuildId)
    $(Build.SourceVersion)

Just saw that the task now uses the fixed version (2.181.2). So the workaround is probably no longer necessary.

Just saw that the task now uses the fixed version (2.181.2). So the workaround is probably no longer necessary.


add pytorch backend flag

see #62

@gusye1234, thanks for the contribution, but I don't think this is the right way to add this support:

first, we need to enable the flag in the WIT/WITX specification, e.g., here
then, we need to re-generate this bindings file so that it includes the new variant (note how the header of this file marks it as auto-generated)

As a separate issue, the WASI ecosystem has begun a transition from WITX specification files to WIT specification files, which means that the generation step for this file should switch to using WIT-based tools (i.e., wit-bindgen). I don't really expect you to have to worry too much about that (@brianjjones, do you want to take a look?) so I will create a separate issue for that: https://github.com/bytecodealliance/wasi-nn/issues/64. @gusye1234, does that make sense? I am on Zulip if you want to discuss in more detail.

(And apologies for contradicting myself in #62... I think I assumed this option was fine to add but now, looking at it more clearly, I think we need to be able to re-generated that file).

Cool! Your suggestion to sync between this auto-generated file and WIT specification file is better.
I should pull a request here and close this one.


Kuma Wallet - Phase 2

Project Abstract
This is a follow-up grant for the previous successfully delivered Cross-chain Wallet - XCW grant under W3F's General Grants Program.
Kuma Wallet is a cross-chain wallet designed to revolutionize the way users interact with EVM and WASM blockchain networks. Built with user-friendliness and security in mind, Kuma Wallet aims to streamline cross-chain asset management and provide a unified, intuitive interface for asset transfers, dApp interactions, and much more.
Grant level

[ ] Level 1:  Up to $10,000, 2 approvals
[x] Level 2:  Up to $30,000, 3 approvals
[ ] Level 3:  Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

[x] The application template has been copied and aptly renamed (project_name.md).
[x] I have read the application guidelines.
[x] Payment details have been provided (bank details via email or Polkadot (USDC & USDT) or BTC address in the application).
[x] The software delivered for this grant will be released under an open-source license specified in the application.
[x] The initial PR contains only one commit (squash and force-push if needed).
[x] The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
[ ] I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

I have read and hereby sign the Contributor License Agreement.

I complely understand. Thank you for the feedback. We are gonna ask HydraDX team about.


WIP: Initial fix for generating ROTM nomination activity for Mentor

This is untested currently.
I wasn't able to access the admin. Facing some weird issue after login which sometimes says Something went wrong. Please contact the administrator and sometimes show CSRF failed.
Logs didn't show anything which would help me in debugging. Still figuring out with my local instance on this and would update here.
About the patch, it would be good to discuss the generic idea of placing things or if team prefers some other way on getting it done.
Thanks :)

@MichaelKohler We need to manually generate this activity once: ACTIVITY_ROTM_NOMINATED. I'm not sure how these activities are generated. I can create a custom migration for it if you want.

@MichaelKohler We need to manually generate this activity once: ACTIVITY_ROTM_NOMINATED. I'm not sure how these activities are generated. I can create a custom migration for it if you want.

Sounds reasonable.

Sure, I'll put this in tomorrow for sure :)

Sure, I'll put this in tomorrow for sure :)

quick ping here ;)

@MichaelKohler I've added a custom migration for now. Will address reviews later today. Sorry for the delay.


Support some datacite.yml in addition/instead of CITATION.cff

Your idea
ATM there is an idea to relay more of information for citations to CITATION.cff and not strive to make dataset_description.json to contain all needed information (e.g. affiliations of the authors etc).
BUT, as far as I see, CITATION.cff development stalled, while it is still lacking some rudimentary needed features such as supporting multiple affiliations for authors (https://github.com/citation-file-format/citation-file-format/issues/268) and unclear how to reference funders (https://github.com/citation-file-format/citation-file-format/issues/491).
While that is happening, there is https://schema.datacite.org/ with a working group, continuous progress, and used widely by anyone minting DOIs via datacite (e.g. we do for DANDI and IIRC OpenNeuro also uses datacite).
A well aged example of a datacite record from @mih for a BIDS dataset could be found  at
https://github.com/psychoinformatics-de/studyforrest-data-phase2/blob/master/datacite.yml . It lacks affiliations but otherwise a good example .
Ideally there should be a tool to convert from datacite to citation.cff format, but ATM I didn't google up any. may be someone could add some support into https://github.com/con/tributors or alike.

FYI bids2cite was my attempt to help 'converting' info from dataset_description to citation.cff OR datacite.yml...
https://bids2cite.readthedocs.io/en/latest/usage_notes.html#command-line-arguments

It's not ideal to have three ways of doing things, but I agree that CITATION.cff seems to be stagnating and BIDS is constrained by backwards compatibility to support CITATION.cff.
IMO if datacite.yml has the features needed and now, it's worth supporting, and I would be inclined to adopt it for OpenNeuro-generated metadata instead of CITATION.cff, which is still on our roadmap.
cc @nellh for your thoughts.

A result of today's maintainer's call was general agreement that supporting multiple citation file formats is reasonable to improve the FAIR-sharing of BIDS datasets that are deposited in public databases. We would prefer that the different formats be mutually exclusive within a dataset, as duplicated metadata would need to be validated or risk becoming contradictory.


Provide @unocss/transformer-variant-group for @unocss/runtime

Clear and concise description of the problem
I use Next.js for my project and @unocss/runtime works perfect for me, but there is no support for variant groups. I tried to make transformers field in window.__unocss and initUnocssRuntime but nothing.
Suggested solution
Add variant groups transformer to the runtime package by default
Alternative
No response
Additional context
If I add shortcuts: { test: "hover:(bg-green-400 p-4) transition-all" } to the window.__unocss it works great.
Validations

[X] Read the Contributing Guidelines.
[X] Read the README.md of using the package.
[X] Already used the Interactive Docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

We are not going to ship every combinations - please use bundler usage for that case, or construct your own CDN build.

It works for shortcuts somehow

Yes - shortcuts do not transform your code. By transforming, it needs a build pipeline.

Got it thanks, this is the killer feature anyway! Will try to use both runtime and build approaches with bypass


fix: enable resource config & remove unnecessary configs from helm-charts

WHAT

Enabling default resource configuration in helm charts
Removing unnecessary configurations from helm charts

WHY
To to fulfill TRG 5.04 and to avoid confusions
FURTHER NOTES
Closes #1274

Fine for me! And thanks for the review :-)
@paullatzelsperger Regarding the upgradability check: This check only checks whether the EDC starts successfully after changing the helm chart version, right? I guess it doesn't check if all necessary database migrations are in place, or? Of course, if the migration fails, the pod will not start successfully - but in the past there have been missing migrations that basically resulted in a corrupted database after the upgrade.
related feature: https://github.com/eclipse-tractusx/tractusx-edc/issues/670

Hi Folks can we merge this?

@paullatzelsperger Regarding the upgradability check: This check only checks whether the EDC starts successfully after changing the helm chart version, right? I guess it doesn't check if all necessary database migrations are in place, or? Of course, if the migration fails, the pod will not start successfully - but in the past there have been missing migrations that basically resulted in a corrupted database after the upgrade.

those upgradeability checks only exist to satisfy TRG 5.11. The only way to be 100% certain that nothing is broken is to hit every table of the database. We have no plans currently to do that. Apart from that, I would expect any serious production deployment of EDC to provide their own migration feature.

@florianrusch-zf I think you gotta rebase


Add metadata prior to hitting submit

User Story
As a wrangler I would like to add metadata to a submission prior to submitting it when I missed something, currently I have to delete the submission and start again, which is very slow.
Acceptance Criteria
Provide a way to add a metadata in a submission and revalidate it

As part of the test plan of Impact 1 - Update metadata and data for a project I did  functional tests:

[x] Update Metadata content https://app.zenhub.com/workspaces/dcp-ingest-product-development-5f71ca62a3cb47326bdc1b5c/issues/ebi-ait/dcp-ingest-central/45

[x] Update a valid metadata: PASS
[x] Update a invalid metadata: PASS

The test xlsx and fastq.gz sequence files I used for testing can be found in gdrive folder impact1 test files (xlsx spreadsheets)

@aaclan-ebi is this now done or do we still need the changes that are blocking this ticket? Sorry, I seem to have got a bit lost here!

@aaclan-ebi is this now done or do we still need the changes that are blocking this ticket? Sorry, I seem to have got a bit lost here!

closing as complete


Abnormal layout of drop-down menus with clr-icon in the header actions

Select one ...  (check one with "x")
[X] bug
[ ] feature request
[ ] enhancement

Expected behavior
Good layout for the drop-down action in the header actions.
Actual behavior
Abnormal layout:

Reproduction of behavior

    <clr-dropdown clrMenuPosition="bottom-right">
        <button class="nav-icon" clrDropdownToggle>
            <clr-icon shape="cog"></clr-icon>
            Preferences
            <clr-icon shape="caret down"></clr-icon>
        </button>
        <clr-dropdown-menu>
            About
            Preferences
            Log out
        </clr-dropdown-menu>
    </clr-dropdown>

Include a link to the reproduction scenario you created by forking one of the Clarity Plunker Templates:
https://plnkr.co/edit/1238YX

Environment details

Angular version: 4.0.X

Clarity version:  0.9.X

OS and version: Mac 10.11.4

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

@yenmade: Hey Yen. Do we want to support this (both icon + text) in dropdowns in the header? If I remember correctly we don't because of the limited space in the header. We either recommend just icon or just text, no?

What about icon and text in clrDropdownItem, is that supported?

@tarundhillon: Yes. I believe that is supported. You should be able to use use:
<button href="..." clrDropdownItem>
  <clr-icon shape="home"></clr-icon>
  Home
</button>

I've tried your example @adityarb88 and there's still a layout problem
code:
...
    <clr-dropdown-menu>
        <button type="button" clrDropdownItem>
            <clr-icon style="color:black" class="is-solid" shape="wrench"></clr-icon>
            Admin
        </button>
        Preferences
        Log out
   </clr-dropdown-menu>
...

Screenshot :

The wrench should be on the left side of "Admin" text. Instead it appears on the other line on the right side.
The only way I manage to have something pretty is to put only one dropdown item with an icon. This way, the wrench is in the same line as the "Admin" text but is still on the right.
It could be great to fix that :)

This needs a little css tweak, example below should help.
`
.menu.item.icon{
position: inherit;
transform: none;
margin-right: 1rem;
}
<clr-dropdown [clrMenuPosition]="'bottom-right'" [clrCloseMenuOnItemClick]="false">
        <button clrDropdownToggle>
                <clr-icon shape="ellipsis-horizontal"></clr-icon>
        </button>
        <clr-dropdown-menu>

                Administration

            <button routerLink="metric" clrDropdownItem>
               <clr-icon class='menu item icon' shape="block" size="30" ></clr-icon>  Metric
            </button>

            <button routerLink="data" clrDropdownItem>
               <clr-icon class='menu item icon' shape="document" size="30" ></clr-icon>  Data File(s)
            </button>

        </clr-dropdown-menu>
    </clr-dropdown>

`

Our recommendation is to use either text or an icon, instead of both.


[CP Staging] fix: wrap distance request inside scrollable view

Details

This PR adds a wrapper ScrollView around the DistanceRequest page.
Fixed Issues

$ https://github.com/Expensify/App/issues/26541
$ https://github.com/Expensify/App/issues/26737
PROPOSAL: https://github.com/Expensify/App/issues/26541#issuecomment-1705702570
Tests

Open the App and click on the Fab menu icon in the LHN.
Select Distance Request.
Resize the screen and verify that the screen is scrollable when of smaller height.

[x] Verify that no errors appear in the JS console

Offline tests

N/A
QA Steps

Open the App and click on the Fab menu icon in the LHN.
Select Distance Request.
Resize the screen and verify that the screen is scrollable when of smaller height.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

https://github.com/Expensify/App/assets/30054992/453c05a3-4ab8-4a09-8d17-3c1c96c8c4aa

Mobile Web - Safari

https://github.com/Expensify/App/assets/30054992/a9ba79c8-5899-4673-bddf-687e661f572b

Desktop

https://github.com/Expensify/App/assets/30054992/b76a1446-1c94-43c3-a989-74c0f9563aba

iOS

https://github.com/Expensify/App/assets/30054992/1783f021-1fb8-4171-a6f9-49e52c530e01

Android

https://github.com/Expensify/App/assets/30054992/4a4543f7-f8af-46fe-8ddf-75e8c7b1e2ad

thank you for thorough checking @ntdiary 👍

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Cherry-picked to staging by https://github.com/mountiny in version: 1.3.63-1 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

@Expensify/applauseleads please QA this PR and check it off on the deploy checklist if it passes.

🚀 Deployed to production by https://github.com/mountiny in version: 1.3.63-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/hayata-suenaga in version: 1.3.65-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/mountiny in version: 1.3.65-7 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Enabling dim_from_weights or loraplus_unet_lr_ratio will cause the error: "train_blocks must be single for split mode" (content updated).

Hi,
Today, when I was running LoRA training for the Flux.1 model (sd-scripts on SD3's breach), the "train_blocks must be single for split mode" error suddenly occurred. This error had not appeared before. After reviewing the parameter settings, I finally found the cause.

F:\kohya_ss\venv\lib\site-packages\transformers\models\clip\modeling_clip.py:480: UserWarning: 1Torch was not compiled with flash attention. (Triggered internally at C:\actions-runner\_work\pytorch\pytorch\builder\windows\pytorch\aten\src\ATen\native\transformers\cuda\sdp_utils.cpp:555.)
  attn_output = torch.nn.functional.scaled_dot_product_attention(
Traceback (most recent call last):
  File "F:\kohya_ss\sd-scripts\flux_train_network.py", line 564, in <module>
    trainer.train(args)
  File "F:\kohya_ss\sd-scripts\train_network.py", line 1177, in train
    noise_pred, target, timesteps, huber_c, weighting = self.get_noise_pred_and_target(
  File "F:\kohya_ss\sd-scripts\flux_train_network.py", line 427, in get_noise_pred_and_target
    model_pred = call_dit(
  File "F:\kohya_ss\sd-scripts\flux_train_network.py", line 393, in call_dit
    assert network.train_blocks == "single", "train_blocks must be single for split mode"
AssertionError: train_blocks must be single for split mode

The issue was that I specified both the "network_weights" and "dim_from_weights" parameters. Once I disabled the "dim_from_weights" parameter, everything worked fine again.
I wonder if anyone else has encountered the same issue. Could it be that dim_from_weights retrieves double blocks, causing the split mode mechanism to malfunction?

Today, I tested several parameter settings again and found that whenever "train_blocks": "single" is set, adding --network_args "loraplus_unet_lr_ratio=4" also triggers the error message: AssertionError: train_blocks must be single for split mode.

--split_mode is now deprecated, so I think this issue might be solved as a side effect. I'd like you to try again.

Hi kohya-ss,
First of all, thank you for your continuous efforts in enhancing and improving sd-scripts. A few days ago, I updated to the latest version and noticed that split_mode has indeed been deprecated and replaced by the powerful blocks_to_swap mechanism. This is an excellent design that allows training all blocks within limited VRAM, albeit at the cost of heavily utilizing system RAM (swap).
However, if possible, I would personally like to see the split_mode mechanism retained. Why? Because split_mode is a very lightweight training method that also allows models to be trained with minimal VRAM usage, and it barely uses any system RAM. The trade-off, of course, is that it can only train a subset of blocks.


Fix/wrong label space calculation in selects

What it solves
Resolves https://github.com/gnosis/safe-react-apps/issues/361
There is a wrong calculation with label spacing with long labels

Looks like you need to regenerate the stories, and the unit tests are failing for some reason.

Hello there! checking in https://github.com/gnosis/safe-react-apps/pull/352
Should we do something about this edge scenarios where labels are inhumanely long? @yagopv

I think this edge case would be really difficult to tackle and we can leave it like this if we don't find any real problem


fix: ACNA-3397 - web action does not have web in the url, resulting in an invalid link

fixes #823
Pre-requisite

Blocked by: needs https://github.com/adobe/aio-lib-runtime/pull/197 merged and released
then, undo @adobe/aio-lib-runtime dep in package.json that uses the PR branch, do a npm i @adobe/aio-lib-runtime@latest
Blocked by: https://github.com/adobe/aio-cli-lib-app-config/pull/38 merged and released
then, undo @adobe/aio-cli-lib-app-config dep in package.json that uses the PR branch, do a npm i @adobe/aio-cli-lib-app-config@latest

How Has This Been Tested?

npm test
tested scenario in #823 with a locally linked app plugin and the above runtime lib PR code

Types of changes

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[X] I have signed the Adobe Open Source CLA.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[X] I have read the CONTRIBUTING document.
[X] I have added tests to cover my changes.
[X] All new and existing tests passed.

Pre-requisites need to be fulfilled before this is merged. https://jira.corp.adobe.com/browse/ACNA-3418


Possible bug while running matrix_properties.yaml example

Hi! I am interested in using your package for my own research, and I've been going through the examples to learn it, but I've come across an error message while trying to execute the line: python3.8 -m tkmatrix --properties matrix_properties.yaml, which you included in your TOI-2257 I&R with multiphase analysis notebook. Running this line does generate the TIC198485881_ir folder, containing the files aperatures.yaml, lc.csv, matrix.log, params_star.csv, and the folder tpfs with all of the fits files within it, but it generates the error message, ValueError: could not broadcast input array from shape (156879,) into shape (), and does not include the a_tls_report.csv or inj-rec.pdf files.
Thank you, I look forward to hearing back from you!

Thank you so much for the help and the quick response! I'll have to try it again tomorrow. I will let you know if there are any other issues.
Thanks!

Hi!
I am still having trouble with running python3.8 -m tkmatrix --properties matrix_properties.yaml. I am no longer receiving error messages, but it has been taking extremely long to run. I am running it on a 24x7 server with 40 CPUs, and after running it for 4 days, the a_tls_report.csv file only contains 100 rows. I created a new .yaml file with only 1 step in radius and period, and it took roughy an hour to complete (and the inj-rec.png is blank). I am not sure why it's going astronomically slow, and I am wondering how long it typically takes you and if there is anything you recommend!
Thank you so much!

Thank you so much! This clears things up! I was able to finish a practice run with just one sector very quickly. This will help me a lot 👍


Pop performance (addresses #15)

I've managed to get a decent speed-up for pop() without an extensive rewrite.
Profiling testPopPerformance() shows that ~ 70% of the execution time for pop() is taken up by MutableCollection.swapAt(_:_:) and another ~ 13% is Array.subscript.getter.
Implementing the swap and the sink inside a call to Array.withUnsafeMutableBufferPointer(_:) gives a speedup of around 9x (on the release build) on my machine and puts the performance of pop() on a level with push(_:) and remove(_:).
I think the performance gap must be a case of the compiler just not figuring out the optimization for pop(), since all of the other public functions which call sink(_:) and swim(_:) are plenty fast.

Thank you, @peteraisher. This is the best of both worlds—code that I can maintain and that addresses the issue. I really want to thank you for the care and consideration you put into it. I and all the other users of SwiftPriorityQueue thank you.


v1.0.0 changes missing?

Hi,
is it correct, that opendistro-build repo misses changes for 1.0.0?
Regards
Andreas

Hi @weand We're in the process of pushing the build scripts for 1.0.0 :-) Will update on thread! Thanks for your patience.

Hi @weand The build scripts have now been updated for 1.0.0. Please feel free to open another issue if you have any suggested improvements or find any bugs.


Add Rotary encoder support in Clicker  & PR comments resolved

This PR covers following points

Added Rotary encoder support for all Clicker functions in Alarms page, Alarm Modal, Settings page & Quickstart page
Added border around clicker to identify which value clicker is active
Event Log settings popup updated to Multistep popup
Added HR alarms in protobuf & Events log
Start/Pause Ventilation is disabled when backend is disconnected
Multistep popup on Cancel of Confirm/Cancel confirmation popup, reopens multistep popup with previous state
Added Clicker in Alarms page & updated Slider CSS for disabled mode

This project is licensed under Apache License v2.0 for any software, and Solderpad Hardware License v2.1 for any hardware - do you agree that your contributions to this project will be under these licenses, too? Yes
Were any of these contributions also part of work you did for an employer or a client? No
Does this work include, or is it based on, any third-party work which you did not create? No

Observations from testing:

It's hard for me to consistently reproduce, but sometimes when I close the Set Alarm Limits or Set Value modals without interacting with any increment/decrement buttons I still get a "Keep Previous Values?" confirmation dialog which is annoying. Sometimes I get this extraneous confirmation, while other times I don't.
The mechanism of showing the active value being changed (e.g. in the SpO2 alarm limits) looks fine. For the visual styling of the highlight, I think it would be better if the entire region, bounded by the dotted lines, were highlighted. This could look like changing the color of the dotted line border, or it could look like changing the background color of the region within the border, or it could look like changing the colors of the UI elements (the number and buttons).
The color contrast of the numbers in the disabled alarm limits slider is too low: white on light gray. We will need to choose some other color for this, either in this PR or a future PR.
Currently the Set Alarm Limits modal is not the same size as the Event Log modal - so when I click the "Settings" button for an alarm from the Event Log, I clearly see that the Alarms modal is a new modal opened on top of the Event Log. To reduce visual clutter, either we should make the Set Alarm Limits modal be the same size as the Events Log modal (i.e. full-size) and have lots of whitespace around the main content; or we should close the Events Log when we click a "Settings" button from it and reopen the Events Log in the same state (including pagination state) when we press the "Confirm" button from the confirmation dialog which closes the Set Alarm Limits modal.
From performance testing on the RPi, the main source of UI choppiness and data dropping (which is reported by the waveform plots resetting themselves) is not in having modals layered on top of each other but in the animations for opening and closing modals. So I think we definitely should simplify the animations (maybe even removing animations if a simple fade still taxes the CPU too much); and we should also consider the layered-modal approach (where all modals are the same size) as that reduces the number of time we'd need to add and remove DOM elements or render animations. Right now the bottleneck in system performance is the CPU; RAM usage with just the dashboard open is ~950 Mb (out of 1.82 Gb available on the 2 GB RPi model, but I believe the production version will use the RPi 4 model with 4 GB RAM). When I open both the event log and the Set Alarm Limits modal, RAM usage temporarily increases to 980 Mb but drops back down to 950 Mb. I get the same RAM usage spike when I close the modals, which suggests that opening and closing modals is more taxing on the system's RAM than just keeping multiple modals around.
I like the left vs. right layout of the increment/decrement buttons on the Alarms screen. I am worried that the numbers inside the disabled slider may be too small to read for some users - if we can also add the big number displays like what we have in the Set Alarm Limits modal, that could improve readability. We might also want to add horizontal dotted lines between the FiO2, SpO2, and HR sections.
For the HFNC-only release of the frontend, we should remove the pagination buttons from the Alarms screen (these are the <, 1, and > buttons above the "Apply Changes" button)

I haven't had a chance to test with the hardware rotary encoder, but otherwise this looks good. In today's meeting let's discuss which revisions to include in this PR and which ones to save for a future PR.

@ethanjli
Have updated PR with following fixes

Removed Animations across app
Resized modal to be consistent across app
Multistep popups layered modal one over the other
Disabled color in slider made consistent with disabled button color
Bug fixed on "Keep Previous Values?" popup reopening inconsistently without user making any changes

Updated with changes related to Event log

Added enum for event log types in protobuf
Added alarms for Settings changed, fio2 & flow
Event log Alarm details updated to show high/low alarm range number

Changes for future PRs, as discussed in the meeting:

Let's move the "back" button in the breadcrumbs modal to be at the left of the breadcrumbs, and a close button will be added in its place
Let's make the Submit button in the breadcrumbs modal be green (like the Confirm button of the confirmation dialog modal), and let's make it be disabled when there are no unsaved changes and enabled when there is at least one unsaved change to any of the ventilation controls
Let's have the headers at the top, the breadcrumbs at the top just under the title in the headers, Cancel/Confirm buttons in the lower right corner, and we'll try to avoid unnaturally wide containers (e.g. dotted line border containers) and instead just have things at natural widths, centered in the modal


[All Currently Active] Chat scrolls up when you scroll down

Expected behavior
All messages stay in place when scrolled down posts
Current behavior
The posts Jump Up by 1
Possible solution
Not automatically move the screen when a new post is made
Steps to reproduce

I have HAVE read the instructions.

Not as noticable on desktop but still there

i don't really know how to fix that

maybe
https://svelte.dev/repl/ad47599b97704db88bd2fb118b9048dc?version=3.47.0

@CST1229 this seems to be caused by #106

Confirmed not fixed as of 12/15/23 (mm/dd/yy)


Use the configured AWS partition when constructing ARNs

Description of your changes
Stores the existing partition id from the provider config into a terraform configuration object, which is available when resolving external names.
Uses the partition as part of the external name config for the resources that currently hardcode a partition of aws in their templated ARN.
Refactors the external name configurations which create arns to use simple helper functions, to reduce code repetition.
The default value of the partition is "aws", which is currently the only supported value, so this should be a nonbreaking change for users.
Fixes #881
Fixes #820
Addresses #855 (although probably not completely)
I have:

[x] Read and followed Crossplane's contribution process.
[x] Run make reviewable to ensure this PR is ready for review.
[ ] Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

@mbbush wonder if we can bring this in - tested today in gov region - pooks pike a working solution

Thanks @haarchri  we could definitely use this fix.

Thanks everyone. This fix would be a life saver.

Is this being prioritized? This is blocking us as well, using GovCloud.

/fresh

Is this being prioritized? This is blocking us as well, using GovCloud.

Yes, it has been prioritized, and if no blockers are found, we plan to include it in the next release.

Is this being prioritized? This is blocking us as well, using GovCloud.

Yes, it has been prioritized, and if no blockers are found, we plan to include it in the next release.

Just curious, when would the next release happen?

Just curious, when would the next release happen?

It is scheduled for Thursday next week.

@turkenf can you give an update to if this was fixed? I looked through the release on the 7th and didn't see it but may have missed it. Thanks

Hello folks, work on this issue is ongoing on this PR, and a new release will be released after the PR is merged.


unbuild utils

As we search for a perfect building solution, this one is at least simple, works, and lets us focus on making primitives without worrying if they'll break or not.
I'm only applying it to the utils for now, but it can be easily ported to the rest.

bye bye cruel world


Problems on setting up prometheus outside kubernetes cluster

Hi,
i am trying to connect prometheus to a kubernetes-cluster. Prometheus is running outside the k8-cluster..
I created a bearer token, which works well when running with curl:
curl -X GET -H "Authorization: Bearer ..." https://ose-master.mgmt.tb/api/v1/services?resourceVersion=0
When i start up prometheus i get the following error(s):
ERRO[0002] github.com/prometheus/prometheus/discovery/kubernetes/kubernetes.go:179: Failed to list *v1.Endpoints: User "system:anonymous" cannot list all endpoints in the cluster  component="kube_client_runtime" source="kubernetes.go:75" ERRO[0002] github.com/prometheus/prometheus/discovery/kubernetes/kubernetes.go:180: Failed to list *v1.Service: User "system:anonymous" cannot list all services in the cluster  component="kube_client_runtime" source="kubernetes.go:75" ERRO[0002] github.com/prometheus/prometheus/discovery/kubernetes/kubernetes.go:181: Failed to list *v1.Pod: User "system:anonymous" cannot list all pods in the cluster  component="kube_client_runtime" source="kubernetes.go:75"
I also tried to inclube the bearer token in kubernetes_sd_configs with no difference.
Is that a problem in connecting ose-kubernetes with prometheus, or am i doing something wrong (since the request works well with curl)
Environment

System information:

Linux 3.10.0-514.21.2.el7.x86_64 x86_64

Prometheus version:

prometheus, version 1.7.1 (branch: master, revision: 3afb3fffa3a29c3de865e1172fb740442e9d0133)
build user:       root@0aa1b7fc430d
build date:       20170612-11:44:05
go version:       go1.8.3

Prometheus configuration file:
scrape_configs:

job_name: 'prometheus'
scrape_interval: 5s
static_configs:

targets: ['localhost:9090']

job_name: 'kubernetes-apiservers'
kubernetes_sd_configs:

role: endpoints
api_server: 'https://ose-master.mgmt.tb'
scheme: https
tls_config:
server_name: ose-master.mgmt.tb.noris.de
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
relabel_configs:
source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
action: keep
regex: default;kubernetes;https

job_name: 'kubernetes-nodes'
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
kubernetes_sd_configs:

role: node
api_server: 'https://ose-master.mgmt.tb'
relabel_configs:
action: labelmap
regex: _meta_kubernetes_node_label(.+)

job_name: 'kubernetes-service-endpoints'
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
kubernetes_sd_configs:

role: endpoints
api_server: 'https://ose-master.mgmt.tb'
relabel_configs:
source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape]
action: keep
regex: true
source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scheme]
action: replace
target_label: scheme
regex: (https?)
source_labels: [__meta_kubernetes_service_annotation_prometheus_io_path]
action: replace
target_label: metrics_path
regex: (.+)
source_labels: [address, __meta_kubernetes_service_annotation_prometheus_io_port]
action: replace
target_label: address
regex: (.+)(?::\d+);(\d+)
replacement: $1:$2
source_labels: [__meta_kubernetes_service_annotation_prometheus_io_username]
action: replace
target_label: basic_auth_username
regex: (.+)
source_labels: [__meta_kubernetes_service_annotation_prometheus_io_password]
action: replace
target_label: basic_auth_password
regex: (.+)
action: labelmap
regex: _meta_kubernetes_service_label(.+)
source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: kubernetes_namespace
source_labels: [__meta_kubernetes_service_name]
action: replace
target_label: kubernetes_name

Logs:

ERRO[0002] github.com/prometheus/prometheus/discovery/kubernetes/kubernetes.go:179: Failed to list *v1.Endpoints: User "system:anonymous" cannot list all endpoints in the cluster  component="kube_client_runtime" source="kubernetes.go:75"
ERRO[0002] github.com/prometheus/prometheus/discovery/kubernetes/kubernetes.go:180: Failed to list *v1.Service: User "system:anonymous" cannot list all services in the cluster  component="kube_client_runtime" source="kubernetes.go:75"
ERRO[0002] github.com/prometheus/prometheus/discovery/kubernetes/kubernetes.go:181: Failed to list *v1.Pod: User "system:anonymous" cannot list all pods in the cluster  component="kube_client_runtime" source="kubernetes.go:75"

Sorry, it was just a misconfiguration combined with an trailing  on the bearer token.
The configuration should work with sth like:

job_name: 'kubernetes-apiservers'
kubernetes_sd_configs:

role: endpoints
api_server: 'https://ose-master.mgmt.tb'

tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
scheme: https
tls_config:
ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
...

@tuner23
Hi, I also met the same problem with you.
I am doubt there is something wrong on my tocken file
could you advice how do you fix your problem?

Hi,
In my case there was a trailing CR (which was not visible via vim). Something like
/usr/bin/perl -pi -e 'chomp if eof' /var/run/secrets/kubernetes.io/serviceaccount/ose.token
helped..

thanks for your responding
however, it is different with my situation
there is normal in my token file
But I think it exists a problem about my setting.
My prometheus can't load token correctly, and it returns the same error with you.
Could you share your prometheus configuration with me?
And my token file format is which I copy the information on k8s secret "token" column directly.
Do I need to encode or decode that information first?
I have tried connect with curl , and it worked.


Errors not being reported for kong plugin Opentelemetry

Is there an existing issue for this?

[X] I have searched the existing issues

Kong version ($ kong version)
3.7.1
Current Behavior
We have installed this plugin for traces in Kong.
Plugin link
We are sending traces to Datadog with this. But the traces are only for requests and errors are not captured at all.

Expected Behavior
Errors should be captured and reported in the UI.
Steps To Reproduce
Install this plugin using Helm.
We have attached this plugin to a service with the kong annotations: konghq.com/plugins: opentelemetry
Configuration reference for the kongplugin on the plugin definition page.
This is connected to otel configuration exposed by Datadog agent on http port 4318.
Anything else?
No response

@pawandhiman10  can you attach you config file for the OTEL plugin?
@samugi can you help to have a look at this issue?

in addition to the config file of the plugin, I would also like to clarify what is meant by "errors" here (i.e. are we talking about error logs during a certain plugin's execution? Or the error_log produced by Kong? Or something else?. @pawandhiman10 could you share an example of the exact data you would expect to be reported?

hello @pawandhiman10
errors in traces are captured and reported by the OpenTelemetry plugin as span events using the exception event key and the exception.message attribute as defined in the OpenTelemetry specification.
I believe Datadog might be expecting slighgly different fields based on this, are you using the OTLP ingestion with the datadog agent? In that case, I would expect the ingestion process of OTLP data to take care of parsing any errors and translating any fields as needed.

@samugi Errors mean 5xx status code errors here.
As per the screenshot earlier, it only displays the 2xx requests and not the 5xx. These are not actual errors but response is 5xx. This is missing.
Below screenshot gives an idea that 5xx is occuring regularly and also increasing sometimes, we are not able to see these numbers in datadog while the same is visible in the load balancer logs.

Yes, currently the ingestion is based on OLTP ingestion with Datadog agent. Could you point me to some reference docs here on how to get the errors (5xx) parsed?

@pawandhiman10 in that case, it might be expected. 500 response status codes are not always reported as errors. Today errors are reported for failures (exceptions) that occur during the execution of plugin phase handlers, errors returned by the internal http client and dns failures.
Could you test with a 500 status code that originates from an exception in a plugin? This can be tested with a plugin that throws an explicit error like: error("fail") from its access phase. The expected behavior is for this to generate a span with name kong.access.plugin.yourplugin with error state and an event that contains the exception message. If Datadog is parsing things correctly, this should be displayed in the UI as well.

@pawandhiman10 what you describe is currently expected. Status codes are reported (whether they 2xx, 4xx, 5xx, etc), but spans are not being set the error state when this happens. Errors are currently reserved for actual errors occurring during the execution of plugins code (exceptions) and a few other scenarios that don't include specific response codes.
Would you be interested in setting an error state to your root span in case of 5xx status code from your upstream? If that is the case, such a change should probably be configurable, for example some might expect 4xx response codes from time to time, while others would consider them error conditions.
We are always interested in improving/updating our tracing instrumentation, but I cannot guarantee this change in particular will be made.
I would recommend, to achieve this behavior, to write your own code (in a custom or serverless plugin) that applies this simple logic for your trace. You can use the tracing and the response PDK modules to achieve this.

@pawandhiman10 if you have access to the collector configuration, you can use the transformprocessor to do that:
processors:
  transform:
    error_mode: ignore
    trace_statements:
      - context: span
        statements:
          - set (status.code, 2) where attributes["http.status_code"] >= 500

Here are the enums available, and the explanation why I've suggested set (status.code, 2):
https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/pkg/ottl/contexts/ottlspan#enums

@julianocosta89 This is managed by Datadog agent currently without any collector config.
@samugi Could you also help me in setting OTEL_TRACES_SAMPLER=always_on with this plugin?
As of the error(5xx) reporting in Datadog, will experiment with the code. Thanks for that.

@pawandhiman10 at the moment the sampling strategy is not configurable for this plugin, what behavior in particular are you attempting to configure?

@samugi This is required I believe from the OTEL page to set the following env variables in Datadog. ref: Link
Enabling opentelemetry send traces in Datadog with probablistic sampling and we need to control the sampling rate of these traces. For that the following envs need to be set: link
DD_APM_PROBABILISTIC_SAMPLER_ENABLED
DD_APM_PROBABILISTIC_SAMPLER_SAMPLING_PERCENTAGE
DD_APM_PROBABILISTIC_SAMPLER_HASH_SEED
I'm not quite sure on how this works but trying to reduce the ingested spans using this opentelemetry plugin.

@pawandhiman10 @julianocosta89 does the following describe your scenario?

If you use a mixed setup of Datadog tracing libraries and OTel SDKs:
Probabilistic sampling will apply to spans originating from both Datadog and OTel tracing libraries.
If you send spans both to the Datadog Agent and OTel collector instances, set the same seed between Datadog Agent (DD_APM_PROBABILISTIC_SAMPLER_HASH_SEED) and OTel collector (hash_seed) to ensure consistent sampling.

Kong's OpenTelemetry plugin only supports head sampling today so your options for sampling, depending on your architecture choices, would be:

Rely solely on Kong's head sampling via tracing_sampling_rate
Configure tracing_sampling_rate to 1 (sample all) and do tail sampling on the Datadog Agent
Configure tracing_sampling_rate to 1 (sample all), use an OpenTelemetry collector as a sink to receive Kong's tracing data, then configure probabilistic sampling in the OTel collector and the Datadog Agent, as suggested in the documentation you have shared

So setting tracing_sampling_rate to 1, is the same as OTEL_TRACES_SAMPLER=always_on

that's right @julianocosta89 1 stands for 100%, i.e. all samples will be traced and reported.

So setting tracing_sampling_rate to 1, is the same as OTEL_TRACES_SAMPLER=always_on

@pawandhiman10 that's what you are looking for


feat: filter tasks with current process ID

Screenshot

Signed-off-by: Qiuxia Fan<EMAIL_ADDRESS>

Updated


The save-state command is deprecated and will be disabled soon

Warning: The save-state command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

The above warning is showing in a lot of our CI runs. We should stop using deprecated save-state.

Duplicate of https://github.com/silverstripe/.github/issues/26