[Feat] erofs snapshotter and differ

Implements #9361

initialize erofs snapshotter and erofs differ
parallel unpacking with hack methods for now, will change to 'rebase' snapshotter interface.

here is a demo: https://asciinema.org/a/xag95aykaleaIiYxEqhz4y0RN
and here is a demo config file to try it out:
`version = 2
root = "/home/t4/containerd"
state = "/run/containerd"
oom_score = -999
[grpc]
address = "/var/run/containerd/containerd.sock"
uid = 0
gid = 0
max_recv_message_size = 16777216
max_send_message_size = 16777216
[debug]
address = "/var/run/containerd/debug.sock"
uid = 0
gid = 0
level = "info"
[metrics]
address = "<IP_ADDRESS>:4243"
grpc_histogram = true
[cgroup]
path = ""
[plugins]
[plugins."io.containerd.service.v1.diff-service"]
default = ["erofs","walking"]
[plugins."io.containerd.grpc.v1.cri"]
dynamic_cri_conf_path = "/etc/containerd/dynamic/dynamic.toml"
stats_collect_period = 10
stream_server_port="4244"
[plugins."io.containerd.grpc.v1.cri".containerd]
snapshotter = "erofs"
[plugins."io.containerd.grpc.v1.cri".cni]
bin_dir = "/opt/cni/bin"
conf_dir = "/etc/cni/net.d"
conf_template = ""
[plugins."io.containerd.grpc.v1.cri".registry]
config_path = "/etc/containerd/hosts"
[plugins."io.containerd.snapshotter.v1.overlayfs"]
quota_driver = "sparsefile"
[plugins."io.containerd.differ.v1.erofs".media_handlers]
[plugins."io.containerd.differ.v1.erofs".media_handlers."application/vnd.docker.image.rootfs.foreign.diff.tar.gzip"]
binary_name = "mkfs.erofs"
args = ["--tar=f","-E","noinline_data","--aufs","--gzip"]
[plugins."io.containerd.differ.v1.erofs".media_handlers."application/vnd.oci.image.layer.v1.tar+gzip"]
binary_name = "mkfs.erofs"
args = ["--tar=f","-E","noinline_data","--aufs","--gzip"]
[plugins."io.containerd.differ.v1.erofs".media_handlers."application/vnd.oci.image.layer.nondistributable.v1.tar+gzip"]
binary_name = "mkfs.erofs"
args = ["--tar=f","-E","noinline_data","--aufs","--gzip"]
[plugins."io.containerd.differ.v1.erofs".media_handlers."application/vnd.docker.image.rootfs.diff.tar.gzip"]
binary_name = "mkfs.erofs"
args = ["--tar=f","-E","noinline_data","--aufs","--gzip"]`

An EROFS snapshotter does look like it could be useful.  However, a few questions:

Why does EROFS need a custom differ?
If the parallel unpack is a "hack" for now, can we remove that part and wait until rebase (or a different mechanism) is implemented?
Can the snapshotter be implemented as an out-of-process proxy plugin first so we can get some experience/get bugs out a bit?  That's what we did with the devmapper snapshotter, for example.

An EROFS snapshotter does look like it could be useful. However, a few questions:

Why does EROFS need a custom differ?
If the parallel unpack is a "hack" for now, can we remove that part and wait until rebase (or a different mechanism) is implemented?
Can the snapshotter be implemented as an out-of-process proxy plugin first so we can get some experience/get bugs out a bit?  That's what we did with the devmapper snapshotter, for example.

bc currently walking differ will do untar by default (and cannot be skipped), for erofs, untar won't be necessary since erofs
supports tar indexing and several binaries provided in erofs-util package (mkfs.erofs) needs to be invoked to generate erofs index file. So there are two options
a. change current walking differ, register serveral binaryHandlers in config file
b. implement a new differ
option a seems lighter but puts too much requirements on config file for end-users, I though maybe we shoud just create a new differ..
ofc! Current implementation is merely for poc, lots of implementations are extremely dirty. The goal is rebase and rewrite unpacker.go after 'rebase' snapshotter interface(https://github.com/containerd/containerd/issues/8881#issuecomment-1654612733) mentioned by Derek is implemented.
yea I think implementing erofs snapshotter as proxy seems more elegant. But unlike other snapshotters, since erofs snapshotter puts requirements on differ as well, I am not so certain which approach is the best...Waiting for advices from the commuitiy :)

erofs-util package (mkfs.erofs) needs to be invoked to generate erofs index file

In detail on the EROFS side, mkfs.erofs (in erofs-utils 1.7+) provides an ability to directly convert tarball (or tgz) streams into EROFS format without a explicit tar unpack process. Btw, and such blobs can form a valid rootfs to end users.

/cc

ofc! Current implementation is merely for poc, lots of implementations are extremely dirty.

Sounds good, let me mark this as a draft to reflect that status.  Feel free to mark it ready when it is no longer a POC.

mkfs.erofs (in erofs-utils 1.7+) provides an ability to directly convert tarball (or tgz) streams into EROFS format without a explicit tar unpack process.

How does mkfs.erofs handle whiteout markers within the tar stream?  Does it already handle image-spec whiteouts?

Personally, I have no objection to that if it's mainly due to be considered as experimental in the beginning

Yes, that's exactly it.  But if it requires a separate differ that might not be an option.

How does mkfs.erofs handle whiteout markers within the tar stream? Does it already handle image-spec whiteouts?

Yes, it already handles whiteouts and other aufs meta semantics.

yea I think implementing erofs snapshotter as proxy seems more elegant. But unlike other snapshotters, since erofs snapshotter puts requirements on differ as well, I am not so certain which approach is the best...Waiting for advices from the commuitiy :)

Containerd supports remote differs now in the main branch (as well as 1.7 iirc) so even if we do need a new differ here it can all live outside of the core repo

in addition to gVisor, later also a single virtio-blk/virtio-pmem each image for popular secure containers as well

Do you see advantages for this snapshotter over the blockfile snapshotter for these virtualization cases? Currently the blockfile snapshotter has this same strength, you get a single file you can map into the guest via virtio-block/pmem/etc.

in addition to gVisor, later also a single virtio-blk/virtio-pmem each image for popular secure containers as well

Do you see advantages for this snapshotter over the blockfile snapshotter for these virtualization cases? Currently the blockfile snapshotter has this same strength, you get a single file you can map into the guest via virtio-block/pmem/etc.

EROFS snapshotter will joint different layers (so that common layers can share between images) into one block device/pmem, and only needs ONE erofs mount. if pmem is used, it can even do layer memory share in addition to just image share.

yea I think implementing erofs snapshotter as proxy seems more elegant. But unlike other snapshotters, since erofs snapshotter puts requirements on differ as well, I am not so certain which approach is the best...Waiting for advices from the commuitiy :)

containerd supports differ proxy plugins now in the main branch (as well as 1.7) so even if we do need a new differ here it can all live outside of the core repo

I'm not sure your concern honestly. Personally, as I said:

If some current snapshotter fulfills all the advantages (parallelism to generate layer blobs as well as without unpacking, generating one blockdevice with layer blob merging for these virtualization cases, layer-level pmem memory sharing, fsverity data/metadata integrity enabling, etc.).
As I said, we'd like to enable an in-tree Linux kernel filesystem for quite long time with active development/maintainence to make full use of this filesystem to end users.

I'm not sure your concern honestly. Personally, as I said:

I don't have any qualms with it living in containerd/containerd, maybe I should've made that more clear 😁. I was just stating if the other maintainers would prefer to get feedback for the snapshotter as a proxy plugin first, this is possible even if we need a separate differ because we also support this now.

the other maintainers would prefer to get feedback for the snapshotter as a proxy plugin first, this is possible even if we need a separate differ because we also support this now.

As I said, I'm fine with this as experimental first as long as it's quite easy for end users to use.
But EROFS is not quite like out-of-tree zfs or aufs, users might not quite easy to use this snapshotter directly. Also we'd like to actively develop, maintain it as well as keep it simple without complex features like somewhat lazy pulling.
I do hope we could have a plan to make it in-tree later.

IMO, it's good to introduce erofs(tarfs) snapshotter into in-tree to work with https://github.com/containerd/containerd/issues/7654, because I think it's good example to developers how to use containerd to handle artifact from registry. According to OCI evolution, the image can be any different media-type.
It can be a good example.

Just from end-user's view to comment.

@cardyok @fuweid @samuelkarp This idea is best at avoiding lots of small files written on the host disk, but its design and implementation could be improved. The core idea is to convert .tgz blobs into other formats that can be loop-back mounted. We actually have lots of choices available, such as sparse raw images with ext4/xfs/(any regurlar fs), squashfs non-sparse image, and of course EROFS as well. We can even make use of reflink in xfs to replace overlayfs, even for the writable layer.
We'd better give users the freedom to choose a fs that best fit their application.
And I don't think it makes much sense to decompress .tgz to .tar and makes a EROFS index. I believe it's more straight-forward to simply convert .tgz to EROFS blobs format.
And I also find some existing PRs have similar positions:
https://github.com/containerd/containerd/pull/8511
https://github.com/containerd/containerd/pull/3130

Hi,

convert .tgz blobs into other formats that can be loop-back mounted

Honestly, that is an implementation details, as an in-kernel fs, EROFS has its own way to integrate later for various ways without loop devices (for runC, but it's still working in progress with filesystem guys).

We can even make use of reflink in xfs to replace overlayfs, even for the writable layer. We'd better give users the freedom to choose a fs that best fit their application.

I don't think the EROFS snapshotter block users to choose other snapshotters.  I'm not sure what you mean honestly.
For RunC, if overlayfs is not used, each filesystem instance will have their own page cache and thus cause duplicated memory.
And I've been discussed with an overlayfs maintainer Amir Goldstein recently to figout the best form of the EROFS writable layer.  But I think that is quite out of topic honestly.

EROFS has its own (or later preferred) way to integrate later among various ways
This is implementation detail in the perspective view of users.

if overlayfs is not used
why not?

support parallel layer applying and merging features
yes, parallelism is preferable, and it's also possible with other fs.

This is implementation detail in the perspective view of users.

For example, EROFS has their own way for runC without loop devices, such as fscache. However it needs Linux 5.19+ kernels at least.

why not?

It depends on specific use cases and it will be measured by our kernel filesystem developers.
Not why or why not.

yes, parallelism is preferable, and it's also possible with other fs.

If you'd like to improve any other snapshoters (like blockfile snapshotter), wonderful! Please consider contribute to these snapshotters to make them support this.
If not, please don't churn in this topic.
If containerd maintainers don't want to support linux EROFS filesystem as one of their solutions for specific reasons, please point it out.

EROFS has their own way for ...

Yes, this is exactly a piece of detail

if overlayfs is not used

overlayfs is of course an option, and should not be excluded.

If containerd maintainers don't want to support linux EROFS

I never mean that. Don't be so ...
I do think supporting EROFS is good for container ecology. But this PR has design and implementation issues that should be improved.

if overlayfs is not used

overlayfs is of course an option, and should not be excluded.

Overlayfs is never excluded in this topic since using EROFS as the writable layer is still the only way for the latest upstream kernel.

If containerd maintainers don't want to support linux EROFS

I never mean that. Don't be so ... I do think supporting EROFS is good for container ecology. But this PR has design and implementation issues that should be improved.

EROFS has an offical userspace converter (shipped with erofs-utils v1.7+) from tar layers (including aufs-like whiteout metadata) to EROFS images.
And EROFS subimages can be merged to form a filesystem image as one EROFS mount, see:
https://erofs.docs.kernel.org/en/latest/merging.html
Why loop devices is used here just because it's a minimal requirement for all current kernels.

Synced with @cardyok offline. He will continue to work on this. Removed stable label.

Let me take a look!
cc @stevvooe @dmcgowan @estesp @ktock since you all have attended "EROFS: Past, Present, and Future" at Open Source Summit NA today :)

From the talk at Container Plumbing Days on Monday, it sounds like EROFS works as a proxy snapshotter and proxy differ?  Is there a link to that implementation?

I've refined another implementation and get rid of almost all hacks in https://github.com/containerd/containerd/pull/10705


Grid Standardization: Add support for scopes

Is your feature request related to a problem? Please describe.
We must allow syft.js to connect to PyGrid. In order to do so, we need to have some concept of a "scope".
Describe the solution you'd like
Scope, as it pertains to grid.js (the only socket library syft.js currently works with), is simply a private "room" where multiple workers can train and predict together. A worker should only ever be a part of 1 scope at a time. Likewise, a scope can include one or many users. This will be mandatory for implementing WebRTC and eventually adding plan and protocol support to PyGrid.
Additional context
Here is some required reading for fully understanding the requirements of this ticket.
In particular, please read the get-protocol section.

@cereallarceny I'll be working on it. :nerd_face:

It's yours! :)


Consider using computed properties instead of lazy properties

The current implementation of lazy properties will significantly increase the memory space required for a given object, as one copy will reside in the buffer backing store and another will at a minimum have a pointer for complex objects or the same size for scalars.
It would probably be interesting to evaluate using computed properties instead that directly returns the data from the backing store (as it should be properly aligned by virtue of the alignment/padding of flat buffers in general, as long as the start of the buffer is aligned appropriately).
It would probably make most sense to do this for simple types like scalars, strings, structs etc, while retaining lazy properties for the more complex ones (embedded tables, arrays) that might be accessed repeatedly.
The rationale would be that the allowance for essentially zero-copy operation without the additional per-instance property storage would give both smaller footprint, which both is good in terms of resource consumption, but may also give possibly better runtime performance due to lower CPU cache utilization (should measure both using larger working sets of objects...).

I just manually switched to computed getters in bench.swift and got slower performance
Lazy run
4077 ms encode
353 ms decode
4883 ms use
593 ms dealloc
5829 ms decode+use+dealloc
Total counter is<PHONE_NUMBER>000000
Encoded size is 315 bytes, should be 344 if not using unique strings
Where before a got
Lazy run
4034 ms encode
541 ms decode
3737 ms use
9 ms dealloc
4287 ms decode+use+dealloc
Total counter is<PHONE_NUMBER>000000
Encoded size is 315 bytes, should be 344 if not using unique strings
Only decode becomes faster, where use and deal become worst.
Hm I will try again with converting only scalar properties to computed, as we discussed it before.

The mixed approach seems to be not really significant:
Eager run
=================================
3943 ms encode
2531 ms decode
1029 ms use
869 ms dealloc
4430 ms decode+use+dealloc
=================================
Total counter is<PHONE_NUMBER>000000
Encoded size is 315 bytes, should be 344 if not using unique strings
=================================


Google Pay doesn't work when dynamically changing the Stripe account and Stripe public key.

Platform

[ ] Web
[ ] iOS
[ X] Android

In our project, we need to change the values of 'stripeAccount' and the Stripe public key. Everything is working correctly for Apple Pay.
For Google Pay, the data is taken only that is set in the 'strings.xml' file and does not change if it is modified in the Ionic code.
In our project, we are using version 3.9.1 of the plugin. We have the following dependencies in the project:
 "dependencies": {     "@angular/animations": "^12.2.1",     "@angular/cdk": "^12.2.1",     "@angular/common": "~12.1.1",     "@angular/compiler": "~12.1.1",     "@angular/core": "~12.1.1",     "@angular/forms": "~12.1.1",     "@angular/material": "^12.2.1",     "@angular/platform-browser": "~12.1.1",     "@angular/platform-browser-dynamic": "~12.1.1",     "@angular/router": "~12.1.1",     "@capacitor-community/stripe": "^3.9.1",     "@capacitor/android": "3.1.2",     "@capacitor/app": "1.0.2",     "@capacitor/camera": "^1.3.1",     "@capacitor/clipboard": "^1.0.8",     "@capacitor/core": "3.1.2",     "@capacitor/haptics": "1.0.2",     "@capacitor/ios": "3.1.2",     "@capacitor/keyboard": "1.0.2",     "@capacitor/push-notifications": "^1.0.4",     "@capacitor/splash-screen": "^1.1.6",     "@capacitor/status-bar": "1.0.2",     "@capacitor/storage": "^1.2.0",     "@googlemaps/js-api-loader": "^1.13.5",     "@ionic-native/core": "^5.35.0",     "@ionic-native/splash-screen": "^5.35.0",     "@ionic-native/status-bar": "^5.35.0",     "@ionic/angular": "^6.2.6",     "@ngrx/store": "^12.4.0",     "@ngxs/store": "^3.7.2",     "@stripe/stripe-js": "^1.35.0"<EMAIL_ADDRESS>"^3.53.2",     "cropperjs": "^1.5.12",     "install": "^0.13.0",     "jwt-decode": "^3.1.2",     "moment": "^2.29.1",     "ngx-material-timepicker": "^5.5.3",     "ngx-stripe": "^12.8.2",     "rxjs": "~6.6.0",     "tslib": "^2.2.0",     "zone.js": "~0.11.4"   },   "devDependencies": {     "@angular-devkit/build-angular": "^12.1.1",     "@angular-eslint/builder": "^12.7.0",     "@angular-eslint/eslint-plugin": "~12.0.0",     "@angular-eslint/eslint-plugin-template": "~12.0.0",     "@angular-eslint/template-parser": "~12.0.0",     "@angular/cli": "~12.1.1",     "@angular/compiler": "~12.1.1",     "@angular/compiler-cli": "~12.1.1",     "@angular/language-service": "~12.0.1",     "@capacitor/cli": "3.1.2",     "@ionic/angular-toolkit": "^2.1.2",     "@types/jasmine": "~3.6.0",     "@types/jasminewd2": "~2.0.3",     "@types/node": "^12.11.1",     "@typescript-eslint/eslint-plugin": "4.16.1",     "@typescript-eslint/parser": "4.16.1",     "eslint": "^7.6.0",     "eslint-plugin-import": "2.22.1",     "eslint-plugin-jsdoc": "30.7.6",     "eslint-plugin-prefer-arrow": "1.2.2",     "jasmine-core": "~3.8.0",     "jasmine-spec-reporter": "~5.0.0",     "karma": "~6.3.2",     "karma-chrome-launcher": "~3.1.0",     "karma-coverage": "~2.0.3",     "karma-coverage-istanbul-reporter": "~3.0.2",     "karma-jasmine": "~4.0.0",     "karma-jasmine-html-reporter": "^1.5.0",     "protractor": "^7.0.0",     "ts-node": "~8.3.0",     "typescript": "~4.2.4"   },
Here are our settings in the 'AndroidManifest.xml' file:
screen
And here are the settings in 'strings.xml':
screen
Please advise on how to configure the plugin for Google Pay so that we can use different data.

This implementation seems impossible because GooglePayLauncher must be executed onCreate.
https://stripe.com/docs/google-pay?platform=android&locale=en-US#instantiate
もしかすると、
https://github.com/stripe/stripe-android
で何かしらのヒントをもらうことができるかもしれません。

This Issue is closed because there is no activity. If you still have problems, please create a new Issue.


Certain dialogs don't open anymore since 5.0.0

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

We're opening a new dialog from within a dialog using dialogService.open, but the return value is undefined and the modal doesn't open.
Expected behavior

The new modal should open
Minimal reproduction of the problem with instructions
I'll see if I can make a reproduction, might be because both components extend the same abstract class, which is also a component
The bug seems to originate from commit b852ea3d1019f3fc2625cbc92af8fdd001f70a4e, the value for componentOrTemplate.name is the same for both components, while the content of componentOrTemplate is actually different.
What is the motivation / use case for changing the behavior?

Environment

Angular version: 17.3.9

Browser:
- [ ] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX

For Tooling issues:
- Node version: XX
- Platform:

Others:

This bug is triggered because the bundler assigns 2 separate components (classes) to variables with the same name (_a2, r, etc.). This causes componentOrTemplate.name to be the same for 2 separate components, so if one of the 2 components is opened as dialog, the other won't open because of the changes in b852ea3

Hi, do you want to open a PR with a fix?

Sure, although I'd probably change it to the implementation of v4 with a nanoid() function that generates a random id. If that's okay then I'll have the PR up in a few minutes

https://github.com/ngneat/dialog/blob/35dfce30506e36fce14a86aee5228632944ae973/projects/ngneat/dialog/src/lib/dialog.service.ts#L220-L236
Because that's how the id property was populated in 4.1.1, the last version before 5.0.0.
I might be able to change it to use a different, non-random value (a derivative of the component name perhaps), but in that case it still implicitly blocks opening 2 modals of the same component. That would still be a breaking change when compared to 4.1.1, right?

We changed it to a name because it's unique

But I see the issue, we need a way to generate a unique id for the component without passing id explicitly

Yeah, I'd propose to change
if (isComponent(componentOrTemplate)) {
  mergedConfig.id ??= componentOrTemplate.name;
}

with
if (isComponent(componentOrTemplate)) {
  mergedConfig.id ??= nanoid();
}

In that case, if an id is provided, it'll work as intended, but if no id is provided a random (probably unique) id is generated.

But it will generate a new id each time. The goal of the change was to prevent reopen a dialog when it's opened without passing an id

Hmm, right. I've looked through the data available at runtime, but there's no exposed data that can help in that case. There is an internal Angular property ɵcmp that might contain a few selectors in the selectors property, but not all components have selectors

A different solution would be to map each function to a unique id in a defaultComponentIds: Map<Type<any>, string>. What do you think about that?


Does not play nice with Inertia test assertions

I might have this setup incorrectly (which is a separate issue) but I did find this problem.
When using Inertia, there are some included test helpers, assertInertia being one, that when the magic test middleware is enabled, will cause these tests to fail. I haven't dug into why, but I assume it has to do with the extra stuff that the middleware adds to a response. Removing the middleware fixes it.
As a side note, the documentation could be clearer around where the package should be installed/enabled. If it's a dev dependency, then adding a middleware seems like the wrong approach (since it will break in prod?) (also sorry for double dipping on twitter! I found this issue afterwards)

@daronspence dude, sorry about the delay, but I'm looking into this now haha. I'll give you an update

@daronspence the middleware thing has been corrected on v0.16. Thanks for reporting!
I figured out what's causing the Inertia issue (it is Magic Test's scripts), but I haven't been able to figure out a solution yet. I'll keep you posted...


Fix default translations so GoogleBot can crawl the website

We would need to modify i18next(ify) code to make it not look up in these directories…


[Backport] Adds release notes for <IP_ADDRESS> (#918)

Description
Backports release notes for version <IP_ADDRESS> to 1.3 branch
See main PR here: https://github.com/opensearch-project/security-dashboards-plugin/pull/918
Category
Maintenance
Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #919 (5f206fd) into 1.3 (1e7235c) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##              1.3     #919   +/-   ##
=======================================
  Coverage   71.98%   71.98%
=======================================
  Files          87       87
  Lines        1906     1906
  Branches      242      247    +5
=======================================
  Hits         1372     1372
  Misses        480      480
  Partials       54       54

Continue to review full report at Codecov.

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

Codecov Report

Merging #919 (fc7b8cc) into 1.3 (1e7235c) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head fc7b8cc differs from pull request most recent head 7d0f0c1. Consider uploading reports for the commit 7d0f0c1 to get more accurate results

@@           Coverage Diff           @@
##              1.3     #919   +/-   ##
=======================================
  Coverage   71.98%   71.98%
=======================================
  Files          87       87
  Lines        1906     1906
  Branches      242      247    +5
=======================================
  Hits         1372     1372
  Misses        480      480
  Partials       54       54

Continue to review full report at Codecov.

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

Please rebase and merge to preserve both of the 2 commits.


KAFKA-7161: check invariant: oldValue is in the state

Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

@guozhangwang @bbejeck , can you review this one?

@guozhangwang I've realized something about the two threads that we have above.
I think the reducers can return null, in which case, we would store null in the state store, and then we could legitimately load null from the store even if we get a non-null oldValue.
In other words, since the reducers can produce null as a result, and we can't distinguish between a null result and a missing key, we probably can't offer the protection I was hoping to.
We could insist that reducers (and aggregators) don't produce null, but that seems excessive.

@guozhangwang @bbejeck Because of what I wrote in my last comment, I've reverted the invariant. Do you want to keep the unit test I wrote for KTableReduce?

@guozhangwang @bbejeck Because of what I wrote in my last comment, I've reverted the invariant. Do you want to keep the unit test I wrote for KTableReduce?

That's a good point, and lgtm for keeping the unit test.

The failures are not related to this PR, merging to trunk now.

@redvasily Just to close the loop for you, it turns out that your reducers are allowed to return null as the aggregate value, and if they do, they'll receive null as an input the next time. This isn't what happened to you, but it means we can't offer a hard guarantee that you should never see null.
So the fully correct guarantee would be your reducers should never get null as an input:

if the topology hasn't been illegally changed
if the reducers don't produce null as an output

The same goes for aggregators.


feat: HttpHeaders Link

Looking forward to this!

@picosam There you have it!

I will release it in few hours.


drivers: uart_console.c: usb_enable() broken

This commit 6da7e4159216faf835345480ca92b3c33e29d932 broke usb_enable().
usb_enable() takes a user_status_callback parameter.  This no longer works properly when uart_console_init() is called because this function now calls usb_enable() with a null pointer.  When the application calls usb_enable(), usb_enable() immediately returns because it has already been enabled.

@jfischer-phytec-iot I believe you made the commit.  You may have overlooked this issue?

The commit 6da7e41 fixed a bug and described it in the commit message.
The design does not provide a way to manually initialize the USB stack when using the console.

@jfischer-phytec-iot The changes in 2.2 require the application to Initialize the usb stack.
You have introduced breaking change to a published API, please do not close this issue.
@carlescufi @pabigot

@jfischer-phytec-iot The changes in 2.2 require the application to Initialize the usb stack.

Yes, the console driver is the application in this case. And again the commit fixed the issue regarding "USB_UART_DTR_WAIT".

You have introduced a breaking change to a published API, please do not close this issue.

I did not.

I don't agree that the console driver is itself an application.  From the 2.2 release notes:
  * The usb_enable() function, which was previously invoked automatically
    by the USB stack, now needs to be explicitly called by the application
    in order to enable the USB subsystem.
  * The usb_enable() function now takes a parameter, usb_dc_status_callback
    which can be set by the application to a callback to receive status events
    from the USB stack. The parameter can also be set to NULL if no callback is required.

I have a use case where I want a console on USB when USB is connected, but I also want to be able to make use of the status callbacks.  Which means the console becomes a device that can come and go.
I don't know exactly how that can be supported in Zephyr, but having the console driver take over the USB subsystem before the application using it can take advantage of a USB feature is a problem.  So is having the application block during initialization because the console isn't available.
I agree the referenced commit did not break the API, but it did expose an existing behavior that can be said to break the promise of how the USB subsystem works from an application's perspective.  We need to come up with a way to support both use cases.

@pabigot The use case you describe is exactly what I am doing ... use the console on USB when USB is connected ... and I want to minimize power consumption when USB is disconnected.
Could this issue be resolved by adding a Kconfig option for "early usb console start" or maybe using the existing "early console start" option?

@carlescufi Could you please  re-open this issue?

This bug report is not true and will stay closed. You have to open an enhancement request if you need.

@sslupsky could you please open a new Enhancement describing the functionality that you would like implemented?

@carlescufi It is clearly stated here in this report what the broken functionality is.  The consequence of the referenced commit is that when the application calls usb_enable(), it fails to set the user callback because USB has already been enabled.  This capability was implemented as part of the changes to the USB API in version 2.2.  Specifically, the release notes describe the USB API on this matter as follows:
* USB

  * The usb_enable() function, which was previously invoked automatically
    by the USB stack, now needs to be explicitly called by the application
    in order to enable the USB subsystem.
  * The usb_enable() function now takes a parameter, usb_dc_status_callback
    which can be set by the application to a callback to receive status events
    from the USB stack. The parameter can also be set to NULL if no callback is required.

Clearly, the API states USB is enabled explicitly by the application.  The referenced commit broke that requirement by enabling USB before the application.  Moreover, the referenced commit has broken a number of existing applications in the tree including:
samples/subsys/usb/cdc_acm_composite
samples/subsys/usb/hid
samples/subsys/usb/dfu
samples/subsys/usb/hid-mouse
Consequently, the statement "this bug report is not true" is clearly false.  This report is in fact not requesting an enhancement, this report documents what is clearly a bug that arose as a result of the referenced commit.

I've opened #27071 to explore this, though I'm still working my way through the consequences.  I don't believe any of the above listed examples break due to this change, though I suspect they would if CONFIG_USB_UART_CONSOLE=y were enabled alongside; I'll be testing that as part of my follow-up.

@pabigot Yeah, that CONFIG flag would need to be set to trigger the issue.

@sslupsky I think you are mostly right in that the enable was documented as having to be called by the application, and that is not quite the case if you enable certain classes. That said, this is a wider problem than just the console, so thanks @pabigot for opening #27071. I have marked that as a USB bug now, and we can continue the discussion there.


Use local webhook cleanup script where needed

Use the hack/clean_local_webhook.sh script in the new make webhook-cleanup target and also call it during make run (which has ENABLE_WEBHOOKS=false by default).

recheck


New mock_environment function with valid contract address

an attempt at #2211
Problem is that this requires massive refactoring when changing existing tests. The borrow checker bites you whenever you use mock_environment(&deps.api) inside a call where you also pass deps, so you need to create the env first and then pass it to the function.
mock_dependencies_with_balances and mock_dependencies_with_balance are also affected by the invalid address problem and got new variants here too.

Problem is that this requires massive refactoring when changing existing tests. The borrow checker bites you whenever you use mock_environment(&deps.api) inside a call where you also pass deps, so you need to create the env first and then pass it to the function.

I see, not great.
How do you feel about https://github.com/CosmWasm/cosmwasm/pull/2217 as an 80/20 solution and recommend advanced users to have their own version of mock_env where needed?

Closing here for now, since we'll postpone to 3.0


plan k8s deployment architecture for bsd, schema store & biovalidator

have a meeting to discuss:

[x] deployment diagram
[x] one namespace per env with bsd, schema, biovalidator vs namespace per service

Deployment diagram available here
Deployment details at confluence page


Where to put large test data?

I have test data for this project that is 1.5 GB large (102 MB zipped). Where would I put such data in a Github project? There's a 1 GB project limit and 100 MB file size limit.

@WelliSolutions you should install git-lfs which comes with 1 GB free storage. That should easily fit your 102 MB zipped JSON file.


Add getCustomEmojiStickers method

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (7d72a48) to head (d2c0f25).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff             @@
##              master       #54   +/-   ##
===========================================
  Coverage     100.00%   100.00%
- Complexity      1161      1168    +7
===========================================
  Files            247       248    +1
  Lines           4242      4256   +14
===========================================
+ Hits            4242      4256   +14

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Furina A1 can sometimes double stack

https://gcsim.app/sh/DpLwqb9tKw6C
At frame 386 (6.43s), Furina A1 is healing too fast.

https://github.com/user-attachments/assets/8824107d-1b42-4d22-b0c3-b4236e9780c8


CRC cleanup should remove crc.json's configuration

As can be seen in:
https://github.com/code-ready/crc/blob/361f05bc677b943505ce63a9903ec6127c597185/pkg/crc/preflight/preflight.go#L177-L184
only actions to undo preflights are performed. This can also be confirmed as follows:
Setting a config value
gbraad@WINT14 > ~ > crc config view
gbraad@WINT14 > ~ > crc config set consent-telemetry yes
Successfully configured consent-telemetry to yes
gbraad@WINT14 > ~ > crc config view
- consent-telemetry                     : yes

Delete does not remove config values (expected)
gbraad@WINT14 > ~ > crc delete
Do you want to delete the OpenShift cluster? [y/N]: y
Deleted the OpenShift cluster
gbraad@WINT14 > ~ > crc config view
- consent-telemetry                     : yes

Cleanup does not remove config values (unexpected?)
gbraad@WINT14 > ~ > crc cleanup
INFO Removing hosts file records added by CRC
INFO Removing pull secret from the keyring
INFO Removing older logs
INFO Removing CRC Machine Instance directory
INFO Removing the crc VM if exists
INFO Removing dns server from interface
INFO Will run as admin: Remove dns entry for default switch
Cleanup finished
gbraad@WINT14 > ~ > crc config view
- consent-telemetry                     : yes

Suggested solution

remove crc.json when crc cleanup is performed
or remove crc.json when crc cleanup -f is performed

Note
We suggest people to run:
$ crc delete -f
$ crc cleanup
$ crc setup
$ crc start --log-level debug

But this will actually not reset the configuration and might run into similar issues.

We decided that we will not implement this as the situation that causes issues that need this solution aren't happening too often.


⚠ API - Lens has degraded performance

In 29f3259, API - Lens ($LENS_API_URL) experienced degraded performance:

HTTP code: 503
Response time: 344 ms

Resolved: API - Lens performance has improved in 3d1c11a after 6 minutes.


Uncaught (in promise) TypeError: url_1.URL is not a constructor

Uncaught (in promise) TypeError: url_1.URL is not a constructor.
node_modules\get-proxy-settings\dist\proxy-settings.js:43:21

Are you using this in a browser environment?


Removing unused variable autoplayStopOnLast which prevented stop looping

Couldn't find the variable autoplayStopOnLast, means it will always be false. Then it will never stop auto play and will always endless loop swiper.
This PR fixes #1539.

means it will always be false - it is only by default. If you set it to true in parameters then it will be true. It is pretty useful thing, no need to remove it. I'll better add it to documentation instead of removing and then adding it by someone request again :smile:

I agree that it would be helpful, but it is not initialized and also not documented. Would save me a couple of hours because it looked like relic from an older release.

Did you test that setting? For me it made no difference of I set it to true or false. I'm using the following code:
var dpSlider' . $module->id . ' = new Swiper("#mod-dpslider-' . $module->id . '", {
	direction: "horizontal",
	calculateHeight: true,
	speed: 1000,
	paginationClickable: true,
	nextButton: ".swiper-button-next",
	prevButton: ".swiper-button-prev",
	spaceBetween: 10,
	slidesPerView: 1,
	loop: true,
	autoplay: 2,
	autoplayStopOnLast: ' . (!$params->get('loop', 1) ? 'true' : 'false') . ',
	centeredSlides: true
});

It doesn't make any difference if the parameter loop is true or false. It always restarts the swiper to the beginning and runs in an endless loop.

Yes, it works as expected with loop disabled. With loop there is no much sense in it

For sure there is. If you want to start the slideshow automatically till the last slide and then stop. BUT you still want to offer that the user can hit the > button to move to the first slide.


cosmic-settings: 1.0.0-alpha.1 -> 1.0.0-alpha.3

Things done
Builds and runs on NixOS.

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 353841 run on x86_64-linux 1

1 package built:

cosmic-settings


build --all-targets

This makes sure that we build all the examples as well.

Nope, I thought cargo test was not building the examples, but to do that, you actually have to run cargo test --tests.


Code using Platform.programWithFlags crashes on startup

Q
A

Does your title concisely summarize the problem?
I hope so 😄

Did you include a minimal, reproducable example? Is it an SSCCE?
Yes

What OS and browser are you using? What versions?
Ubuntu server 16.04 / node 7.2.0

What version of Elm are you using?
0.18.0

Given this Main.elm file (pastebin), which utilizes Platform.programWithFlags, elm-make generates code that crashes upon execution.
Steps to reproduce:
$ elm-make Main.elm --output output.js
$ node output.js

This results in the following error:
ReferenceError: _elm_lang$core$Json_Decode$andThen is not defined

adding import Json.Decode seems to side-step the issue, though the compiler now warns about an unused module

It's probably related to https://github.com/elm-lang/core/issues/703, but this case does not use ports directly.

I just realized I duplicated https://github.com/elm-lang/elm-platform/issues/184. Sorry! It's difficult to search for possible duplicates in all repos.


doc: Add 'apt-get install python3-wheel' to linux installation docs

When going through the SDK install instructions at http://docs.zephyrproject.org/getting_started/installation_linux.html , I ran into error messages like:
  ----------------------------------------
  Failed building wheel for PyYAML
  Running setup.py clean for PyYAML
  Running setup.py bdist_wheel for hub ... error
  Complete output from command /usr/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-g71dzj01/hub/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/tmp5b8oqe1gpip-wheel- --python-tag cp36:
  usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
     or: -c --help [cmd1 cmd2 ...]
     or: -c --help-commands
     or: -c cmd --help

  error: invalid command 'bdist_wheel'

After doing a bit of research about errors about bdist_wheel errors, I found that running a apt-get install python3-wheel solves the problem in my debian box. Therefore, this PR adds that package to the list of dependencies in ubuntu and debian-like systems.

Codecov Report

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

@@           Coverage Diff           @@
##           master    #6567   +/-   ##
=======================================
  Coverage   53.45%   53.45%
=======================================
  Files         437      437
  Lines       41390    41390
  Branches     7934     7934
=======================================
  Hits        22127    22127
  Misses      16043    16043
  Partials     3220     3220

Continue to review full report at Codecov.

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

Strange, does this mean we can remove https://github.com/zephyrproject-rtos/zephyr/blob/master/scripts/requirements.txt#L1
?
Out of curiosity, did the wheel pip package installation fail when you installed the pip packages?

Out of curiosity, did the wheel pip package installation fail when you installed the pip packages?

I don't quite remember and, amazingly enough, I can't seem to reproduce the original problem. :neutral_face:

Strange, does this mean we can remove [...] ?

Yes, as far as I'm aware. In fact, I could just apt-get install python3-breathe python3-sphinx python3-sphinx-rtd-theme python3-docutils python3-yaml python3-ply python3-pyelftools and get rid of most of the stuff in requirements.txt.
But keep in mind that this PR updates the instructions for Debian-like systems, not RedHat-like systems, so it's not safe to make that change just yet.

Alas, no.  We've found problems using just the latest versions of documentation tools: requirements.txt specifies specific versions of breathe, sphinx, and docutils that we've found "compatible".

Alas, no. We've found problems using just the latest versions of documentation tools: requirements.txt specifies specific versions of breathe, sphinx, and docutils that we've found "compatible".

@dbkinder Is there a specific version requirement for wheel?

I've reproduced the original problem in a Debian virtual machine. Something interesting is that running the apt-get install command in the "Getting started" guide somehow pulls python-pip-whl as a dependency instead of python3-wheel.
This is because both the Debian and Ubuntu packages for python-pip depend on python-pip-whl, but only recommend python3-wheel, and the instructions specifically tell the user to run apt-get with --no-install-recommends.
Also:

Now I can answer @SebastianBoe's question:

Out of curiosity, did the wheel pip package installation fail when you installed the pip packages?

No, I can see no errors for wheel, sphinx, breathe, and some others. Not all dependencies need to build a wheel, see the Building wheels for collected packages line in the screenshot above.

Alas, no. We've found problems using just the latest versions of documentation tools: requirements.txt specifies specific versions of breathe, sphinx, and docutils that we've found "compatible".

In that case, I won't be touching the requirements.txt file. As far as I can tell, everything works fine when having both a system-wide python3-wheel (via apt-get) and a user-wide python3-wheel (via pip).


python310Packages.pytoml: remove

The pytoml project is no longer being actively maintained. Consider using the toml package instead.
Description of changes
Depends on #225695 and #225693

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg eval


VPN on-demant activation for mobile clients

Is your feature request related to a problem? Please describe.
Prevent activation of VPN while connected to the local environment.
Describe the solution you'd like
Implement on-demand VPN activation with the option to exclude WiFi networks at locations that Netbird clients already cover to prevent unnecessary network overhead.
Describe alternatives you've considered
Manually enabling/disabling the VPN is tiresome, especially for other, less technically inclined users.
Additional context
Wireguard client (and some other wireguard-based solutions) already support this option.

Hi @pax0707
What kind of network overhead are you experiencing?
Do you use network routes feature?

Hi, if I may add a comment here:
In our corporate network we have a ton of subnets that is routed quite efficiently via the local "default gateway".
If we deploy routes via the "network routes" feature, they will always be prefered, so all the traffic is running via that routing peer, instead of the (more efficent) direct way.
So it would be nice if those network routes are only active if they cannot be reached directly.

Hi, if I may add a comment here: In our corporate network we have a ton of subnets that is routed quite efficiently via the local "default gateway". If we deploy routes via the "network routes" feature, they will always be prefered, so all the traffic is running via that routing peer, instead of the (more efficent) direct way. So it would be nice if those network routes are only active if they cannot be reached directly.

Thank you for sharing your case @aho-amiblu.
You might be able to achieve the suggested behaviour by using posture checks. You can create one that is blocking access when peer is connected to a specific network (peer network range check) and add it to a policy that allows access to your routing peers. Once the client is in the network with more efficient routes, the posture check will remove access to that routing peer and therefore the NetBird route itself.


MAINTAINERS.md: Remove Max Inden (mxinden)

I have not been very active as a maintainer of Alertmanager in the last couple of month and I don't think this will change in the near future. Thus I think it is time for me to remove myself from the maintainers list.
I will stick around within the Prometheus ecosystem and stay subscribed to all notifications of the Alertmanager repository for a bit longer.
I learned a lot, thanks everyone!
Signed-off-by: Max Inden<EMAIL_ADDRESS>

:wave:

Thank you @mxinden !

Thanks a lot for everything @mxinden! It's been quite a ride!


Add the Project System

While work in the project-system repo may effect .NET Core, I don't know that it belongs in this list. @karelz ?

@leecow I think it belongs. It's the project system for .NET SDK-style projects.

Agreed cc @davkean

I would have make it "Language/Tooling" and include MSBuild too. Bugs are often moved between project-system/msbuild/sdk/cli.


Unknown browser query Android

The readme specifies "Android" as being a supported browser to target, but it is not defined in the source code.
Getting the error:
BrowserslistError: Unknown browser query Android
Relevant source: https://github.com/ai/browserslist/blob/master/index.js#L155

You need to always specify browser version, like Android >= 4


Package Caches and Offline Installs

If I create an offline installation layout using only a few selected workloads and then install these same workloads from that layout with either the --Cache or --NoCache options along with the --NoWeb option, would caching to a different directory still take place OR would neither of the cache options, including --Path Cache="{ProgramPath}", even apply to offline layout installs?
In addition, does specifying --NoWeb for an install from an offline layout simply disable the package caching altogether as well, thereby causing those other cache options to be ignored if they are specified?
And also, if the cache options still do apply to installs from an offline layout without the use of --NoWeb, would specifying --NoCache for such an install actually delete the contents of the offline layout (which I do not want to happen) as it would still be considered cached data?
If you could please list the answer in the document that would greatly be appreciated in order to avoid confusion.

Document details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 5e97b834-fa82-6aa0-5913-4d5a8ed23366
Version Independent ID: e988e3ea-8565-ca88-6ade-ab67425a51ae
Content: Use command-line parameters to install Visual Studio
Content Source: docs/install/use-command-line-parameters-to-install-visual-studio.md
Product: visual-studio-windows
Technology: vs-installation
GitHub Login: @ornellaalt
Microsoft Alias: ornella

@VikingByNature -- Collin, thank you for your questions.  Please consider these resources:

Visual Studio on Q&A
Visual Studio MSDN Forum
Stack Overflow
Reddit

@ornellaalt -- Ornella, please look into this issue.

#reassign: @anandmeg

Hi @VikingByNature Collin,
I'm just now seeing your questions that you submitted quite a while ago.  Please be advised that I made a significant overhaul to all the offline layout documentation a couple months ago, so hopefully that clarifies some of your questions.  It used to be the case that with the installer that shipped in VS 2019 and below, it didn't really support the idea of having layouts in different directories, but we addressed this in the VS 2022 installer which released in Nov 2021.  Furthermore, the --noWeb parameter is really intended to be used on the client to prevent the client from reaching out to the internet to acquire bits.  --noWeb is not really relevant in scenarios where you're trying to manage the layout.
Can you please review the updated online documentation regarding offline layouts (links below), and let me know if you have any further questions?  If you do have a question, please also try to frame it in the context of both what you're trying to achieve as well as how you're trying to achieve it, because we might have a solution for you that may not be down the same implementation path that you went down.
https://docs.microsoft.com/en-us/visualstudio/install/create-a-network-installation-of-visual-studio
https://docs.microsoft.com/en-us/visualstudio/install/create-an-offline-installation-of-visual-studio
Thanks,  Christine

#reassign: @christineruana

We don't need to keep this open any longer.  Hopefully my answer above works for @VikingByNature and if not, please feel free to re-open or start another issue.
#please-close


Install stubs with Mypy Nox routine

Something like mypy --install-types.

Manual for now, may automate later.


simple-js-oauth displays Error: secret option required for sessions in log and UI

I tried running simple-js-oauth. It starts, but I get the error when I open http://localhost:8000. See the error at the end of this issue.
To workaround the problem, I googled the error and found a one-line workaround. I edited server.js to set a missing secret in the app object.
const app = express();
app.use(session({ secret: 'somevalue' })); // The fix
const moment = require("moment");

Please consider adding the missing secret, otherwise simple-js-oauth doesn't run properly and gives the following error in UI and log.
Error: secret option required for sessions
    at session (/Users/jcranford/github/workspaces/plaid/tutorial-resources/worktree/oauth2/vanilla-js-oauth/start/node_modules/express-session/index.js:200:12)
    at Layer.handle [as handle_request] (/Users/jcranford/github/workspaces/plaid/tutorial-resources/worktree/oauth2/vanilla-js-oauth/start/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/Users/jcranford/github/workspaces/plaid/tutorial-resources/worktree/oauth2/vanilla-js-oauth/start/node_modules/express/lib/router/index.js:323:13)
    at /Users/jcranford/github/workspaces/plaid/tutorial-resources/worktree/oauth2/vanilla-js-oauth/start/node_modules/express/lib/router/index.js:284:7
    at Function.process_params (/Users/jcranford/github/workspaces/plaid/tutorial-resources/worktree/oauth2/vanilla-js-oauth/start/node_modules/express/lib/router/index.js:341:12)
    at next (/Users/jcranford/github/workspaces/plaid/tutorial-resources/worktree/oauth2/vanilla-js-oauth/start/node_modules/express/lib/router/index.js:275:10)
    at expressInit (/Users/jcranford/github/workspaces/plaid/tutorial-resources/worktree/oauth2/vanilla-js-oauth/start/node_modules/express/lib/middleware/init.js:40:5)
    at Layer.handle [as handle_request] (/Users/jcranford/github/workspaces/plaid/tutorial-resources/worktree/oauth2/vanilla-js-oauth/start/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/Users/jcranford/github/workspaces/plaid/tutorial-resources/worktree/oauth2/vanilla-js-oauth/start/node_modules/express/lib/router/index.js:323:13)
    at /Users/jcranford/github/workspaces/plaid/tutorial-resources/worktree/oauth2/vanilla-js-oauth/start/node_modules/express/lib/router/index.js:284:7

Hmm, I took a look but I wasn't able to reproduce this issue as described. When running the code according to the README, it worked. Also, there is no folder called simple-js-oauth in this repo, although there is vanilla-js-oauth, which already sets the secret in the app object in server.js line 13.


1 django vulnerability found in requirements.txt

CVE-2019-3498 More information
low severity
Vulnerable versions: >= 2.1.0, < 2.1.5
Patched version: 2.1.5
In Django 1.11.x before 1.11.18, 2.0.x before 2.0.10, and 2.1.x before 2.1.5, an Improper Neutralization of Special Elements in Output Used by a Downstream Component issue exists in django.views.defaults.page_not_found(), leading to content spoofing (in a 404 error page) if a user fails to recognize that a crafted URL has malicious content.

remedy is to update the requirements to have
django>=2.1.5
allowing it to use a version that does not have the above vulnerability.

fixed in #178


Fill in detail for V2 registry api specification

These changes fill in a lot of missing detail in the API endpoint definitions. Please the generated SPEC.md file for the results. This file will be submitted to docker core for review, as a companion to docker/docker#9784.
Note that this PR contains part of the content from #7, which should be merged before this.
cc @icecrime @jfrazelle @dmp42 @dmcgowan @jlhawn
Replaces #15, because old repository lost its fork status.

LGTM

LGTM


rook setup

Signed-off-by: shylesh kumar<EMAIL_ADDRESS>

Hey, interesting that you went the extra mile of building rook instead of just pulling the latest image


Access to Deepseek chat is blocked for no reason.

I am experiencing issue with access to my account  (fskyeff@gmail.com). I use Deepseek chat only for translations.
Suddenly access was blocked. I can't enter Deepseek chat without VPN anymore. Please fix this issue.
It says "Sorry, your request has been intercepted because it appears to be an attack. Event ID:31-inst-179-20241029230411-de1d4797" This is mistake.
I made no attacks against site. I left site open for an hour and when I returned access was blocked.

+1 但是我是使用VPN的，希望可以允许


Document stress-test procedure and results

Ref:

https://github.com/fractal-analytics-platform/fractal-server/issues/1507#issuecomment-2120615085
https://github.com/fractal-analytics-platform/fractal-server/tree/timeouts

The reproducible stress-test is now available at https://github.com/fractal-analytics-platform/fractal-containers/tree/main/slurm-stress. When using fractal-server 2.0.6, the ./monitor_threads.sh script clearly shows the open-threads accumulation (by repeatedly submitting batches of Fractal jobs, we observed at least 160 open threads - when using two workers).
For the record, we were not actually able to reproduce the timeouts in #1507, not even by simulating jobs with 200 images each. The first breaking point we hit is the SLURM one (https://github.com/fractal-analytics-platform/fractal-server/issues/1459#issuecomment-2120584669). This could be due to many different reasons, not necessarily captured by this stress test.


Feature Request : Add ALIAS support (preview)

Hi Ross,
As per Ref Cloud DNS has support of ALIAS in preview.
Although I'm not really comfortable with coding and adding a PR, I am completely  volonteer to test it if needed.
Best regards,
Marc

Will throw this into the hopper, but tbh I'm building up quite a list at this point and not getting to spend a lot of time working through it. Others may get to it before I do.

https://github.com/octodns/octodns-googlecloud/pull/25
This looks to work for me when testing locally. I'm not super familiar with the python testing framework so I think I've got everything in there with tests passing now, but let me know if this is all we need.

Fixed by https://github.com/octodns/octodns-googlecloud/pull/25

@ross On what cadence do you usually generate new releases? I'd like to test this against our staging environment now that it's merged.
Cheers and thanks!

Ad-hoc. Figured I'd give @WhatshallIbreaktoday a chance to say whether it worked for them or not and then cut one here.

Works like a charm !
Warning regarding ALIAS is no more shown, and the change is nooped and applied on my test zone.
Thanks you both !


Draft - Import container images

@sebader this is how i'd envision the import of external container images e.g. for nginx-ingress and other dependencies.
Import can be automated up to a certain degree - authentication for example is currently not part of this PR. Deployment cannot - the parameters are heavily depending on each individual helm chart and the tasks are itself also not really standardized, yet.
This is not tested - and I'm not saying that we should do it like that.

This PR now contains the images for ingress-nginx and cert-manager and imports them as part of the pipeline:

Could we test this by applying a policy which will only allow images from either mcr.microsoft.com or myacr.azurecr.io?

Could we test this by applying a policy which will only allow images from either mcr.microsoft.com or myacr.azurecr.io?

Yes, should be possible using something (doesn't contain the specific ACR, yet) like this: https://github.com/Azure/Mission-Critical-Online/blob/ba6a76e0b5133ad1add7aacff56a7819f8ccddf6/src/infra/workload/releaseunit/modules/stamp/policy.tf#L57-L75

yeah sure, we can also still keep the branch around


Store translations locally - trigger update from API - Mobile WebApp

I have a webserver containing translations i.e.
/api/en/translations will return a JSON string with all English translations
In my WebApp I already have 3 files, locale/en.json, locale/de.json, locale/nl.json
But I want to be able to overwrite these translation files so I can easily refresh translations from the server.
What's the best way to do this? Maybe I should use the localstorage instead?
And if so, how can I manually refresh the translations then? Because I want to check for an internet connection first.
Thanks in advance!

Please ask "how do I..." questions on Stackoverflow: http://stackoverflow.com/questions/tagged/angular-translate - you'll reach a bigger audience.
This issue tracker is mainly the feature-/bugtracker for angular-translate. But you're always free to add a feature request later on.
Thanks.

I'm sorry I will do this! I should've known!
Thanks 👍


EXAMPLE - /milestone

The milestone command is used to add a PR or issue to an existing milestone. Note that the milestone must already exist, prow-github-actions will not create a milestone with this command.

/milestone test-milestone


[PW-8389] Set oneclick as default customer payment method after saving card details

When a shopper selects card payment and checks the box to 'save for next use', we store the payment method in checkout, but the next time the shopper goes to checkout, the previously used PM (i.e. credit card) is pre-selected instead.
It would be an improvement to pre-select oneclick after customer pays with and saves credit card.

Hi Peterojo,
Thank you for your suggestion. We appreciate your feedback and understand the value this feature could add.
Currently, this functionality isn’t on our development roadmap and is not expected to be implemented in the near future, as it depends on Adyen’s feature planning and prioritization. However, we’ll certainly take it into consideration for future updates.
We’ll keep you informed if this option becomes available.
Best regards

Hi,
Sorry for the confusion. This functionality has already been implemented in the Adyen plugin.
To allow customers to store their card details for future transactions, please enable the "Stored Payment Methods | Adyen Payment" option. This requires that both "Stored Payment Methods | Adyen Payment" and "Cards | Adyen Payment" are enabled, allowing customers to save their card information. This is only working for registered users.
Could you please let us know if this resolves your issue?
Thank you in advance for your response.
Best regards