changing request - status code

@TylerZeroMaster You might be right. When I deployed to prod, all tests passed... Let's see how it will go in next deploys.


Fix parsing JSON error on get_sticker_set

Getting error while trying to get_sticker_set(sticker_set_name)
An error while parsing JSON: data did not match any variant of untagged enum TelegramResponse

Looks like the types are not up-to-date
https://core.telegram.org/bots/api#stickerset
https://core.telegram.org/bots/api#sticker

We do not (yet) support Bot API 6.2, so yeah, sticker types are a bit outdated, sorry for that 😓
We usually make all Bot API updates i a single PR, so it's easier to keep track of everything, though...

Ohhh, Okay.
Sorry, I didn't know that. I will close the request and wait for you guys to update instead 😄
(I will try to update it to support v6.2....)


Crash at startup

Mod Version:
DynamicSurroundings-1.12.2-<IP_ADDRESS>.jar
Forge Version:
<IP_ADDRESS>47
Link to client log:
https://paste.ee/p/MRnA5
Link to crash log:
https://paste.dimdev.org/atufilucob.mccrash
Description:
Description of the problem.  In the case of crashes, it is good to know things like the following:
crash at startup

JustEnoughIds - have you tried the lastest published version of that mod?

Yes, now. But still crashing.
https://paste.dimdev.org/kanirocule.mccrash

Update VanillaFix - I know that one is behind.  The key here is finding all the mods that have Mixin embedded and get them updated.

I encountered exactly the same problem just as what has been described above. After VanillaFix and JEIDs has been updated to the latest release the game could be successfully launched.
Successfully launched with VanillaFix-1.0.10-150 and JustEnoughIDs-1.0.3-55.

I am removing the embedded Mixin library and taking a dependency on MixinBootstrap.

Posted <IP_ADDRESS> to CurseForge as BETA.  MixinBoostrap will also need to be installed.


Run tests offline

To aid browser developers to run our tests, our tests need to be able to run offline with local data.  We can also consider an "online" category like our "WebGL" category.

Re-open if this becomes a priority for closed networks or to make the tests more reliable.


fix linker error when using piDigitalPWM due to C fn name mismatch

The piDigitalPWM proc causes a linker error if used, because the
appropriate C function is not called piDigitalPWM (as expected by
the importc pragma), but piPwmWrite.
Of course one could just as well simply change the name of the C function in the wrapper.

Thank you!

@Vindaar, thank you.


Entrypoints for all scripts

I included some modif to the dockerfile by mistake. Nothing that should cause conflicts.

Clean entrypoint mechanism for all scripts. Added synbols-datasets and synbols-view commands.


Wrapping long Label

I have been building a small tui on top of my password manager.
The problem I am running is that the notes Label can be longer than there is space on one line. It seems that go-tui truncate the Label. Is there a way to wrap the text and continue the next line ?
May be the root cause is that I should not use label for notes.

Thank you very much for releasing go-tui it is very easy to get going.

That's really cool! I'm glad to hear you're finding it useful.
There is some basic support for word wrapping. Check out the SetWordWrap method on the Label widget. It should do what you're asking for. Let me know if it does the job!
https://github.com/marcusolsson/tui-go/blob/334ee71303bff817c1daaed05707c32c7e7b9f8d/label.go#L66


Add commit tagging for images

Can one of the admins verify this patch?

@vpavlin snapshot fabric8-ui is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-1574.int.rdu2c.fabric8.io

@vpavlin snapshot fabric8-ui is deployed and available for testing at https://fabric8-ui-fabric8-ui-pr-1574.int.rdu2c.fabric8.io

[test]


fix: update help text icon spacing

Description
updating the help text icon spacing values
Related Issue
DNA-1171
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.
[x] 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.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

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

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


Configure analyzers for better results

Currently, the filename tokenization seems not to work as expected. Filenames splitted up by underscores are hard to search and the dot before the extension seems also to confuse elasticsearch.
For the path: path hierarchy tokenizer
For the filename: edge ngram and lowercase
Beside of this the filename should have a pattern tokenizer like [^\\p{L}\\d]+ (Split on non-letters and numbers) more examples

Serious resources:

https://gist.github.com/alexbrasetvik/7448181
http://stackoverflow.com/a/9432450

If this is too hard, it also seems to work reasonably well to just use the "simple" analyzer which does a serious job on splitting arbitary text at non-character positions.


The QueryString is double URL encoded when running navigateTo on the server side.

Environment

Operating System: Darwin
Node Version:     v20.10.0
Nuxt Version:     3.12.2
CLI Version:      3.12.0
Nitro Version:    2.9.6
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      devtools, css, modules, runtimeConfig, colorMode, ui, googleFonts, gtm, bugsnag, vite, nitro, hooks
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
Reproduction
The code below can be reproduced by running it on the server side.
<script setup lang="ts">
const params = {
  client_id: 'client_id',
  response_type: "code",
  redirect_uri: "http://localhost:3000/sso/callback",
  scope: "openid",
  nonce: "12345",
  state: "12345",
}
navigateTo({ path: 'https://example.com/oauth/authorize', query: params }, { external: true })
</script>

When urlencoded, "/" should be "%2F", but it becomes "%2f25".
Describe the bug
https://github.com/nuxt/nuxt/blob/77685e43e4b4602151f0d2e7fbfa8bc372308907/packages/nuxt/src/app/composables/router.ts#L123
https://github.com/nuxt/nuxt/blob/77685e43e4b4602151f0d2e7fbfa8bc372308907/packages/nuxt/src/app/composables/router.ts#L172
It seems that this issue is occurring because two parts of the code are being executed separately.
Additional context
No response
Logs
No response

Great investigation - thank you.
I'm closing to track in https://github.com/nuxt/nuxt/issues/27554.


Added more Intel RDT capability discovery: CMT,MBM,MBA

Added more Intel RDT capability discovery: CMT,MBM,MBA
Added Memory Bandwith Allocation (MBA) capability discovery.
Refined RDT monitoring capability detection;
Cache Monitoring Technology (CMT) and
Memory Bandwidth Monitoring (MBM)
capabilities can be detected separately.

@okartau Thanks for opening this PR. Like you mentioned, we should wait till we can fully test the changes e2e.

I added more capabilities to same PR, hope thats OK. Note that I leave already existing RDTMON but I added new labels for CMT and MBM.
RDTCMT in most cases overlaps with RDTMON, right?
So we may want to skip adding it.
But as there are separate bits returned by lcpuid(0xf,1) encoding CMT and MBM,
expressing both capabilities separately is kind of complete solution, isnt it.
I have verified this code on E5 v3 and E5v4, and it shows correctly that v3 CPU
has CMT support but no MBM support

I tested this on a machine with an Intel® Xeon® Platinum 8170M processor, with the following results:
[mlehtone@sklep0 node-feature-discovery]$ docker run 5c05eef78c7b --oneshot --no-publish
...
E0524 14:18:24.268227       1 rdt.go:69] support for RDT L2 allocation was not detected: exit status 1
2018/05/24 14:18:24 node.alpha.kubernetes-incubator.io/nfd-rdt-RDTMON = true
2018/05/24 14:18:24 node.alpha.kubernetes-incubator.io/nfd-rdt-RDTCMT = true
2018/05/24 14:18:24 node.alpha.kubernetes-incubator.io/nfd-rdt-RDTMBM = true
2018/05/24 14:18:24 node.alpha.kubernetes-incubator.io/nfd-rdt-RDTL3CA = true
2018/05/24 14:18:24 node.alpha.kubernetes-incubator.io/nfd-rdt-RDTMBA = true
2018/05/24 14:18:24 node.alpha.kubernetes-incubator.io/nfd-pstate-turbo = true
2018/05/24 14:18:24 node.alpha.kubernetes-incubator.io/nfd-memory-numa = true
E0524 14:18:24.276432       1 network.go:48] SR-IOV not supported for network interface: eth0: open /sys/class/net/eth0/device/sriov_totalvfs: no such file or directory
2018/05/24 14:18:24 discovery failed for source [selinux]: Failed to detect the status of selinux, please check if the system supports selinux and make sure /sys on the host is mounted into the container: open /host-sys/fs/selinux/enforce: no such file or directory
2018/05/24 14:18:24 continuing ...

Looks good, let's merge this

+1


Create github-dependents-info

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

Comparison is base (6e7f080) 82.35% compared to head (3b23da3) 82.35%.

:exclamation: Current head 3b23da3 differs from pull request most recent head 3d239f8. Consider uploading reports for the commit 3d239f8 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #30   +/-   ##
=======================================
  Coverage   82.35%   82.35%
=======================================
  Files           4        4
  Lines          85       85
=======================================
  Hits           70       70
  Misses         15       15

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


Decouple the concepts of Task and Command

Decouple the concepts of Task and Command, where a Task is a configurable independence process, and a Commmand is command-line runnable work unit.

This has been partially done at the interface/abstract class level. However most tasks still implement both Task and Command.


Update Code of Conduct page styling

The Code of Conduct page styling needs to be updated as it's currently a bit of a mess. Specifically, at a minimum the following updates should be made

Add additional whitespace between paragraphs to improve readability
Fix the Enforcement Guidelines table formatting

I'm going to leave this for now.


Unable to collapse video if expanded live video automatically switched to the sate with recorded player

steps:

launch any UI test
open "watch" view for testmethod and expand live video player
wait until test is finished and new player is displayed
-> recorded player is displayed using the same size as for expanded live video player. It can't be collapsed anymore
It seems like we should automatically switch to normal view as only testmethod is finished

done


Support listener modification

Listener modification is currently unsupported as seen by:
https://github.com/coreos/alb-ingress-controller/blob/03455ce9f3ff598bb3eb694b4a94643c22ee931d/controller/alb/listener.go#L141-L155
We should add support for this asap.

We now have this in master


Attempted import error: 'blockies-react-svg' does not contain a default export (imported as 'BlockiesSvg').

Hi,
thanks for the great library. I ran into a small issue in a next.js v13 app, when using the lib I get the following error:
Attempted import error: 'blockies-react-svg' does not contain a default export (imported as 'BlockiesSvg').
Using it like this:
import BlockiesSvg from 'blockies-react-svg'

<BlockiesSvg
  address={address.toLowerCase()}
  className="identicon"
  />

tsconfig:
{
  "compilerOptions": {
    "target": "es5",
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "forceConsistentCasingInFileNames": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "jsx": "preserve",
    "incremental": true,
    "plugins": [
      {
        "name": "next"
      }
    ],
    "baseUrl": ".",
    "paths": {
      "@/*": ["./*"]
    }
  },
  "include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts", "app/[walletId]/currencies"],
  "exclude": ["node_modules"]
}

Any idea what might cause this?

Thank you for bringing this to my attention. I haven't used Next.js before, but I will do my best to fix the issue.

Hi, I have fixed the issue in v0.0.12 by clarifying Next.js' module resolution. I'm not sure if this will work for your issue because the problem in my new Next.js 13 app is not the same as the error you reported.
You can try it now, and feel free to ask me any questions.

Error message is gone, thank you!


qFix: Quick Fixes

qFix branch is used to apply quick fixes.

Update gSVM and gMatchedFilter dialogs according to changes made in eegData and eegOperations classes.

Removed bugs from gSVM as per above comment.

Removed bugs from gMatchedFilter as per above comment.


Initial reconciling support

Overview
It might be "Reconciling" panel for the Table controller
References

https://openrefine.org/docs/manual/reconciling

@roll We will review this issue after the launch of the stable version. Thanks!


Dont kill /subscribe websocket connections every 12 hours

In NonBlockingSubscriptionHandler, after 12 hours of missed cattle pings (not websocket native pings), we kill the connection. This causes gms, rce, and all host agents to reconnect. They all recover find under normal circumstances, but this is just not good.

With the release of Rancher 2.0, development on v1.6 is only limited to critical bug fixes and security patches.


Improve supertraits documentation

Some of it feels like it was from the guide. Should all be referency now. And also more cross linking.

The number of examples still feels a bit guide-y to me? Perhaps consider collapsing them down into one or two examples.

I disagree. The examples each showcase a different facet of supertraits, not teach how they work. I did end up removing an example of a struct implementing both traits since it didn't showcase anything specific.

Made the "as usual" link easier to follow in markdown source, added a definition for subtract, and pared down the writing for one example.


On Yarn, "warning<EMAIL_ADDRESS>The engine "browser" appears to be invalid."

warning<EMAIL_ADDRESS>The engine "browser" appears to be invalid.
This appears when using various versions of Yarn (rather than npm) to install jshashes, either individually or in combination.
It happens in all environments, both in my local and in CI builds.
When googling the error string, it appears to be happening in many other builds as well.
It's non-blocking. But, FYI.

Fixed in master.

@xml has this issue been resolved? If yes, please close this issue.

@h2non if this issue has been fixed, shouldn't this issue be closed?

Yeah, this was fixed in v1.0.7.


Adding support for $MESON or another way to point at a customized Meson

In NumPy we had to vendor Meson in order to include a major new feature (for SIMD support) that is not yet available in Meson itself. That is fine, that's how it's supposed to work, since Meson isn't extensible by design - the point is to keep things simple and upstream your needed features/changes.
However, using that vendored Meson also forced us to vendor meson-python. The only reason for that was to be able to point at the correct meson executable. So ideally meson-python would have a way for a package to point at that custom Meson instead. This could be done via a MESON environment variable (similar to the NINJA one), and/or in some other way (a setting in pyproject.toml perhaps.
Part of what's needed here is being able to point at a meson.py (as shipped with Meson itself), and have meson-python translate that to [sys.executable, 'path/to/meson.py']. This has to do with it being a problem on Windows to ship an executable file meson and have it recognized. See  https://github.com/numpy/numpy/pull/24379#issuecomment-1673584945 and following comments for details.
This idea was also touched upon in gh-323. It's related but not the same, so I thought I'd open a separate issue instead. The implementation is probably quite simply, the main thing to decide is what the UX for this should look like.

On the surface, adding support for looking up the meson executable via a$MESON environment variable seems a good idea. However, I wonder how this would work if it is used to point meson-python to a meson that has features that are not included in any distributed version of meson.
In the Python packaging ecosystem there is the assumption that binary distributions can be compiled from source distributions with the tools specified in the package definition. There is even a proposed PEP that looks into extending this beyond Python packages and things that can be installed from PyPI. @rgommers I'm sure you are familiar with it.
This stops working if something not specified in pyproject.toml in the [build-system] is required to compile a package.
A solution I used a while back for a package of mine when there were still bugs to iron out in the Meson Python support, is something like:
[build-system]
build-backend='mesonpy'
requires=[
  'meson-python',
  'meson @ https://github.com/dnicolodi/meson.git',
]

This ensures that the specific version of Meson is installed in the build environment, and the $PATH should be set up properly to have it take precedence over the system one.
Why doesn't something like this work for NumPy? I haven't read the linked issue in detail, but I have the impression that vendoring Meson into NumPy made the problem harder to solve because the vendored Meson cannot be (easily, at least) installed before compiling NumPy. Am I missing something?

The solution proposed above sucks for distributions where the build tools required to build a distribution package need to be packaged themselves. In this case, the distribution would need to merge the patches from the "friendly fork" into their Meson package, or they would need to have an additional numpy-meson package on which the numpy package build-depends upon. For simplicity, the numpy-meson package would need to not be co-installable with the regular meson package.
I admit that this is not ideal, but it looks better than the alternatives, IMHO. Producing the numpy-meson package should be straightforward if a meson package already exits.

This stops working if something not specified in pyproject.toml in the [build-system] is required to compile a package.

Only if it's not part of your own package. It's one or the other:

you either vendor it inside your own source tree, or
you have to distribute it as a separate package and depend on it.

There's trade-offs involved, but there's good reasons (explained below) for why I went with (1) instead of (2).

A solution I used a while back for a package of mine when there were still bugs to iron out in the Meson Python support, is something like:

Indeed, pointing at a fork in a git repo is very convenient while developing a feature or bug fix (and is exactly what we did for numpy). It clearly cannot work for distribution a release though, you have to change to one of the two methods listed above.

haven't read the linked issue in detail, but I have the impression that vendoring Meson into NumPy made the problem harder to solve because the vendored Meson cannot be (easily, at least) installed before compiling NumPy.

Yes, the vendored Meson cannot be installed if you vendor it - it must be run straight from the source tree of your package.

or they would need to have an additional numpy-meson package on which the numpy package build-depends upon. For simplicity, the numpy-meson package would need to not be co-installable with the regular meson package.

This is the alternative solution, but is exactly what I'm trying to avoid. The impact of this is pretty bad:

I'd have to publish a numpy-meson package (easy),
The packagers of the numpy release that need it would need to repackage numpy-meson for each distro, and it would need to remain available for as long as that numpy release is supported (a ton of work for dozen of people),
numpy-meson and meson would conflict, since they both want to install, e.g., /usr/bin/meson. That's not okay in distro land, so now who must patch this? (hard)

And if it's patched by renaming the executable installed by numpy-meson, we still need support for $MESON in meson-python.

In contrast, with the meson vendored in https://github.com/numpy/numpy/tree/main/vendored-meson, no one also but me as the person who did the vendoring has to do much/anything here. The one thing that was a problem is that I also had to vendor meson-python; still works, but I'd like to be able to fix that and unvendor meson-python from numpy, because we don't need any changes beyond pointing at vendored-meson/meson/meson.py.

I was going to suggest that a possible solution is to use the path to the vendored meson in build-system.requires:
[build-system]
build-backend = 'mesonpy'
requires = [
  'meson-python',
  'meson @ file://_vendored/meson',
]

but pip does not accept a relative path for file: URIs. I am not sure I understand why this is the case.

I'm not sure this checks against the PEP specification, but it works:
[build-system]
build-backend = 'mesonpy'
requires = [
  'meson-python',
  '_vendored/meson',
]

that don't use pyproject.toml or disable build isolation.

If they don't use pyproject.toml they are not using meson-python, so of course that would not work. If they disable build isolation, they need to install the build dependencies by themselves, and that includes also the vendored copy of meson. I don't think that this would be problematic.

I'm also still a little confused about why we wouldn't implement $MESON support?

I don't have anything against implementing $MESON support. What I'm not really convinced about is that you can use that for pointing meson-python to a vendored copy of meson with functionality not implemented upstream. Who is responsible for setting the environment variable if I try to build the package from an sdist I downloaded from PyPI? In this case there isn't even a file I can point $MESON to because the source distribution has not been unpacked yet.

I'm not quite sure if it's guaranteed to work by a standard, or if the / is going to work in a cross-platform fashion.

It will probably work in a cross platform fashion because Windows usually just accepts forward slashes or backslashes just fine.
However, it's guaranteed to not work by the spec, since PEP 518 mandates that it is only permissible to list PEP 508 dependency specifiers. The fact that it works anyway is a build frontend bug -- and for the record, the bug is that build will simply pass all arguments to pip as is with no validation. But if you build with isolation disabled then it does check that all dependencies are installed, and this fatally errors out as you'd expect.
The inconsistency is bad, and it's explicitly spelled out in a comment in build that it's "undefined behavior", but I'm fixing that to make it well defined as an error.

If they disable build isolation, they need to install the build dependencies by themselves, and that includes also the vendored copy of meson. I don't think that this would be problematic.

It is problematic imho, we're then back to the "impact of this is pretty bad" of https://github.com/mesonbuild/meson-python/issues/458#issuecomment-1690911120. I really want to avoid creating any work or problems for distro packagers.
Disabling build isolation is standard practice for pretty much all distros, they're by design not going to download stuff from PyPI.

In this case there isn't even a file I can point $MESON to because the source distribution has not been unpacked yet. I think I'm missing something.

You're correct there. In my first comment I said "the main thing to decide is what the UX for this should look like." I think it requires something like a pyproject.toml field with a path pointing to the executable, that works better than an environment variable (which we also want, maybe, but not necessarily right now). We had the same problem with spin, and that's what solved it: https://github.com/scientific-python/spin/pull/97.

The inconsistency is bad, and it's explicitly spelled out in a comment in build that it's "undefined behavior", but I'm fixing that to make it well defined as an error.

PR submitted as https://github.com/pypa/build/pull/665

Disabling build isolation is standard practice for pretty much all distros, they're by design not going to download stuff from PyPI.

The hack I proposed (which is indeed just a hack) does not download anything from PyPI. It installs the vendored Meson copy. But I understand that it is still weird to have to install the vendored build tool. I was not really proposing this as a solution for building distribution packages.

PR submitted as pypa/build#665

Thank you @eli-schwartz for killing my hack immediately 🤣

I'll try and open a PR with my preferred solution for this. It should be pretty minimal. That will hopefully allow unvendoring meson-python from the numpy repo before the next numpy release in a couple of weeks from now.


glacier binary is in conflict with boto's glacier binary

boto is a requirement to run glacier-cli, but when boto is installed, boto creates a glacier script.
https://github.com/boto/boto/blob/develop/setup.py#L59
In the README examples, glacier.py is referred to as just glacier and in this case it won't work because boto will override it.

I like glcr.  But the name of the script in the repo is kind of irrelevant; so long as the installation method is simply ln -s the user is free to call it whatever they want.  Unfortunately that doesn't work for git-annex, so I requested that git-annex should allow the path to be configurable.

I like glcr. I hadn't consider that before and missed it in winny-'s, sorry. And this has gone unresolved for long enough. Provided the name's not already taken (someone please check the Debian archive or something), I'll be happy to accept pull requests renaming the recommended name, using that in a future setup.py and in packaging, etc, if everyone agrees. One requirement - first I'd like git-annex to be updated to use that name first if available, so there is no period when it is broken.

OK cool.  But like I said, I don't think git-annex should be hardcoding the executable name anyway.

I don't think git-annex should be hardcoding the executable name anyway.

I have no issue with that. But we should have a single well-known name that everything that expects the "glacier-cli interface" defaults to.

Totally agree :)

first I'd like git-annex to be updated to use that name first if available, so there is no period when it is broken

It doesn't matter which of the two is updated first - there will be an inevitable period of breakage.

git-annex will not be making the name of the program configurable. Pick a name and I'll use it.

It doesn't matter which of the two is updated first - there will be an inevitable period of breakage.

You can have symlink one to the other during transition period (I would recommend that).


fix: 0.76 version of react native for ios

Default to using react native provided installer for RCT_NEW_ARCH_ENABLED.

@jhen0409  is it possible do a pre-release with this fix? Thanks!


systemd 245 breaks cilium pod to out-of-node traffic

Bug report
General Information
Updating systemd 244.2-2 on Arch to systemd 245.2-1 and 245-3 break pod to out-of-node ipv4 traffic. Reverting to 244.2-2 and rebooting fixes the problem. (ipv6 keeps working on all versions)
I did a sysctl -a diff with 244 vs 245 with cilium running (ready):
< net.ipv4.conf.all.promote_secondaries = 1
> net.ipv4.conf.all.promote_secondaries = 0
< net.ipv4.conf.cilium_host.accept_source_route = 1
> net.ipv4.conf.cilium_host.accept_source_route = 0
< net.ipv4.conf.cilium_host.promote_secondaries = 0
> net.ipv4.conf.cilium_host.promote_secondaries = 1
< net.ipv4.conf.cilium_host.rp_filter = 0
> net.ipv4.conf.cilium_host.rp_filter = 2
< net.ipv4.conf.cilium_net.accept_source_route = 1
> net.ipv4.conf.cilium_net.accept_source_route = 0
< net.ipv4.conf.cilium_net.promote_secondaries = 0
> net.ipv4.conf.cilium_net.promote_secondaries = 1
< net.ipv4.conf.default.accept_source_route = 1
> net.ipv4.conf.default.accept_source_route = 0
< net.ipv4.conf.default.promote_secondaries = 0
> net.ipv4.conf.default.promote_secondaries = 1
< net.ipv4.conf.default.rp_filter = 0
> net.ipv4.conf.default.rp_filter = 2
< net.ipv4.conf.ens192.accept_source_route = 1
> net.ipv4.conf.ens192.accept_source_route = 0
< net.ipv4.conf.ens192.promote_secondaries = 0
> net.ipv4.conf.ens192.promote_secondaries = 1
< net.ipv4.conf.ens192.rp_filter = 0
> net.ipv4.conf.ens192.rp_filter = 2
< net.ipv4.conf.lo.accept_source_route = 1
> net.ipv4.conf.lo.accept_source_route = 0
< net.ipv4.conf.lo.promote_secondaries = 0
> net.ipv4.conf.lo.promote_secondaries = 1
< net.ipv4.conf.lo.rp_filter = 0
> net.ipv4.conf.lo.rp_filter = 2

Cilium version (run cilium version)
1.7.1
Kernel version (run uname -a)
Linux k8s22 5.5.10-arch1-1 #1 SMP PREEMPT Wed, 18 Mar 2020 08:40:35 +0000 x86_64 GNU/Linux
Orchestration system version in use (e.g. kubectl version, Mesos, ...)
Kubernetes 1.17.4
Upload a system dump (run curl -sLO https://github.com/cilium/cilium-sysdump/releases/latest/download/cilium-sysdump.zip && python cilium-sysdump.zip and then attach the generated zip file)

cilium-sysdump-20200319-221054.zip

The breaking change is in /usr/lib/sysctl.d/50-default.conf
25c25,27
< net.ipv4.conf.all.rp_filter = 2
---
> net.ipv4.conf.default.rp_filter = 2
> net.ipv4.conf.*.rp_filter = 2
> -net.ipv4.conf.all.rp_filter
28c30,32
< net.ipv4.conf.all.accept_source_route = 0
---
> net.ipv4.conf.default.accept_source_route = 0
> net.ipv4.conf.*.accept_source_route = 0
> -net.ipv4.conf.all.accept_source_route
31c35,37
< net.ipv4.conf.all.promote_secondaries = 1
---
> net.ipv4.conf.default.promote_secondaries = 1
> net.ipv4.conf.*.promote_secondaries = 1
> -net.ipv4.conf.all.promote_secondaries

a minimal fix for 245 is:
echo 'net.ipv4.conf.lxc*.rp_filter = 0' | sudo tee -a /etc/sysctl.d/90-override.conf && sudo systemctl start systemd-sysctl

there was a systemd bug that we had in the past. Although it is completely unrelated it might help give some help to figure out the underlying issue https://github.com/cilium/cilium/pull/8351

This is very annoying. We should warn users when systemd > 245 is detected.

Add log statement if user is running with systemd version

I have an Ubuntu 20.04 development machine that I use, where I run microk8s.
I've installed Cilium v1.8.1:
$ cilium version
Client: 1.6.8 f534e98df 2020-03-25T13:32:35+01:00 go version go1.12.17 linux/amd64
Daemon: 1.8.1 5ce2bc7b3 2020-07-02T20:04:47+02:00 go version go1.14.4 linux/amd64

It's running systemd 245:
$ systemctl --version
systemd 245 (245.4-4ubuntu3.2)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid

Here's the config (I don't recall whether I modified these, but they seem consistent with the case where connectivity was not working for you:
$ grep rp_filter /etc/sysctl.d/*
/etc/sysctl.d/10-network-security.conf:net.ipv4.conf.default.rp_filter=2
/etc/sysctl.d/10-network-security.conf:net.ipv4.conf.all.rp_filter=2
/etc/sysctl.d/99-sysctl.conf:#net.ipv4.conf.default.rp_filter=1
/etc/sysctl.d/99-sysctl.conf:#net.ipv4.conf.all.rp_filter=1

Interestingly it seems to be set to 0, although I've rebooted this machine recently:
$ sysctl net.ipv4.conf.all.rp_filter
net.ipv4.conf.all.rp_filter = 0

I note that parts of Cilium now disable rp_filter:
$ git grep rp_filter pkg/datapath
pkg/datapath/connector/add.go:  return sysctl.Disable(fmt.Sprintf("net.ipv4.conf.%s.rp_filter", ifName))
pkg/datapath/loader/base.go:            {"net.ipv4.conf.all.rp_filter", "0", false},

Deploying the single-node-connectivity YAML I see that external connectivity works:
https://github.com/cilium/cilium/blob/master/examples/kubernetes/connectivity-check/connectivity-check-single-node.yaml
$ k get po | grep external
pod-to-external-1111-75df4847d7-tjxpq                    1/1     Running   1          23m
pod-to-external-fqdn-allow-google-cnp-77d7586f58-9l5z6   1/1     Running   1          23m

So I think this issue is resolved as of the latest Cilium releases?

I will try 1.8.2 tomorrow evening, but I just tested it on 1.7.6 and it is still broken.
Also 1.7.6 seems to have the same interface specific line:
$ grep -ri rp_filter
pkg/endpoint/connector/add.go:	return sysctl.Disable(fmt.Sprintf("net.ipv4.conf.%s.rp_filter", ifName))
pkg/datapath/loader/base.go:		{"net.ipv4.conf.all.rp_filter", "0", false},

my systemd version right now:
$ systemctl --version
systemd 245 (245.6-8-arch)
+PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid```

picking a random lxc interface:
$ sysctl net.ipv4.conf.lxc4d36398ebb25.rp_filter
net.ipv4.conf.lxc4d36398ebb25.rp_filter = 2
$ sysctl net.ipv4.conf.all.rp_filter
net.ipv4.conf.all.rp_filter = 0
$ sysctl net.ipv4.conf.cilium_host.rp_filter
net.ipv4.conf.cilium_host.rp_filter = 2

pinging an outside destination ip.
$ kubectl run  --restart=Never -it --rm --image=alpine  test2 ash
If you don't see a command prompt, try pressing enter.
/ # ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>): 56 data bytes
^C
--- <IP_ADDRESS> ping statistics ---
19 packets transmitted, 0 packets received, 100% packet loss
/ # exit
pod "test2" deleted

(it works fine with my 90-override.conf described in the second post of this issue)
Maybe Ubuntu 20.04 has a different /usr/lib/sysctl.d/50-default.conf?
$ grep rp_filter /usr/lib/sysctl.d/50-default.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.*.rp_filter = 2
-net.ipv4.conf.all.rp_filter

Maybe Ubuntu 20.04 has a different /usr/lib/sysctl.d/50-default.conf

Good spotting. Ubuntu seems to carry a patch to systemd to explicitly remove those lines. I downloaded the tar from the ubuntu packages site and:
$ grep -R rp_filter systemd_245.4-4ubuntu3.2/debian/patches/*
systemd_245.4-4ubuntu3.2/debian/patches/debian/UBUNTU-drop-kernel.-settings-from-sysctl-defaults-shipped.patch:-net.ipv4.conf.default.rp_filter = 2
systemd_245.4-4ubuntu3.2/debian/patches/debian/UBUNTU-drop-kernel.-settings-from-sysctl-defaults-shipped.patch:-net.ipv4.conf.*.rp_filter = 2
systemd_245.4-4ubuntu3.2/debian/patches/debian/UBUNTU-drop-kernel.-settings-from-sysctl-defaults-shipped.patch:--net.ipv4.conf.all.rp_filter

Furthermore at least in my environment networkd doesn't seem to be enabled:
$ networkctl | grep lxc2cd6411
WARNING: systemd-networkd is not running, output will be incomplete.

357 lxc2cd6411832fb ether    n/a         unmanaged

I have the same WARNING: systemd-networkd is not running, output will be incomplete. [...] unmanaged on Arch Linux. It seems that rp_filter is being set by systemd-sysctl service.
@joestringer What does systemctl status systemd-sysctl return on your machine?

@brb it's Active (exited), but per my last post I think the Ubuntu version of systemd-sysctl won't apply rp_filter by default. That seems like it explains the difference in behaviour to me.

per my last post I think the Ubuntu version of systemd-sysctl won't apply rp_filter by default

@joestringer Ah, damn, missed that comment. Yeah, that explains the difference.

Yep, caught the same problem during first cilium installation (found this bug right after).
Just overrided rp_filter settings in /etc/sysctl.d/90-override.conf
Gentoo, Systemd 245.5

Can confirm this issue is still happening on Cilium 1.8.2 and using the latest 2605 flatcar release channel

I've hit the same problem Ubuntu 20.04.
For future googlers on hetzner systems: Check /etc/sysctl.d/99-hetzner.conf, they set net.ipv4.conf.all.rp_filter=1 there.

I am not sure if related but after attempting a 1.8.2 -> 1.8.3 upgrade on Ubuntu 20.04 / 5.4.0-1021-aws, agent pods end up crashing with the following logs. Rolling back to 1.8.2, pods are healthy and do not contain those errors. 🤷
{"error":"Failed to sysctl -w net.ipv4.conf.eth0.rp_filter=2: could not open the sysctl file /proc/sys/net/ipv4/conf/eth0/rp_filter: open /proc/sys/net/ipv4/conf/eth0/rp_filter: no such file or directory","level":"error","msg":"Error while initializing daemon","subsys":"daemon"}
{"error":"Failed to sysctl -w net.ipv4.conf.eth0.rp_filter=2: could not open the sysctl file /proc/sys/net/ipv4/conf/eth0/rp_filter: open /proc/sys/net/ipv4/conf/eth0/rp_filter: no such file or directory","level":"fatal","msg":"Error while creating daemon","subsys":"daemon"}
{"error":"Operation cannot be fulfilled on ciliumnodes.cilium.io \"ip-10-6-11-13.eu-west-1.compute.internal\": the object has been modified; please apply your changes to the latest version and try again","level":"warning","msg":"Unable to update CiliumNode custom resource","subsys":"ipam"}
{"level":"info","msg":"regenerating all endpoints","reason":"one or more identities created or deleted","subsys":"endpoint-manager"}
{"level":"info","msg":"regenerating all endpoints","reason":"one or more identities created or deleted","subsys":"endpoint-manager"}

@mvisonneau That looks to me like that is a separate regression in v1.8.3 specific to Ubuntu in EKS environments, would you mind opening a new issue for this?

@mvisonneau Is there an eth0 interface on those nodes? If not, then I think this is a separate bug (regression) in v1.8.2 on Ubuntu in EKS environments. If there is an eth0 then it may still be this issue.

@mvisonneau OK great, would you mind filing a separate bug for that to help track fixing the regression? The output from your last couple of comments on this thread would be a great start for such a bug.

On Ubuntu hosted by Hetzner i dont have any config added by hetzner self anymore. But had same issue with systemd. So i added sysctrl configuration and got cilium 1.8.3 working.
ubuntu version 20.04.1
kernel 5.8.10-050810-generic
docker 19.3.13
kubernetes 1.19.2
systemd 245 (245.4-4ubuntu3.2)
net.ipv4.conf.lxc*.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0

A good workaround for this is to enable endpoint-routes --enable-endpoint-routes. It enforces symmetric routing. https://github.com/cilium/cilium/pull/13346 is going to fix endpoint-routes in combination with tunneling.

  enable-endpoint-routes: "true" with default systemd 2.45 (now 46) rp_filter works great using native routing.
Guess i've missed this setting as I set up Native routing in 1.6 initially.

Followup items:

Is there context from upstream systemd release around this change?
Open issue upstream to discuss impact there

@errordeveloper mentioned he can share some systemd configuration he used to mitigate this issue.
If we want to enable endpoint routes mode by default, we will also need to resolve #13121.

I have encountered this on OpenShift, with uses CoreOS.
I can confirm that following two solutions work well:
Either write /etc/sysctl.d/99-override_cilium_rp_filter.conf  with the following contents:
net.ipv4.conf.lxc*.rp_filter = 0
net.ipv4.conf.cilium_*.rp_filter = 0

Or use enable-endpoint-routes: "true", however if you are using tunnelling mode, you will require either Cilium 1.8.5 (not yet released due to be released soon), or 1.9.0 (also due to be released) (see https://github.com/cilium/cilium/pull/13346).

@joestinger https://github.com/cilium/cilium/issues/10645#issuecomment-601451909

Is there context from upstream systemd release around this change?

https://github.com/systemd/systemd/commit/5d4fc0e665a3639f92ac880896c56f9533441307#diff-7816eed8ca6324f23a690cc5f58e6bf7 whch solved issue https://github.com/systemd/systemd/issues/6282

Using flatcar 2605 and above, the minimal fix: echo 'net.ipv4.conf.lxc*.rp_filter = 0' | sudo tee -a /etc/sysctl.d/90-override.conf && sudo systemctl start systemd-sysctl works. But if the node is rebooted and the pod get's a new IP address on the same node, it stops working.

@jaysiyani that sounds like you need to find the correct way to persist configuration on Flatcar, I can have one very concrete example in the docs that you might want to try.

Some additional information on this:
Systemd maintainer have introduced this configuration in attempt of fixing some kind of boot-time race condition, and it seems to improve overall consistency of how the system behaves.
Initially there was https://github.com/systemd/systemd/commit/1836bf9e1d70240c8079e4db4312309f4f1f91fd, which later was followed-up with a bug report https://github.com/systemd/systemd/issues/6282 an a subsequent PR https://github.com/systemd/systemd/pull/14589, which ultimately appears to be the cause of this issue for Cilium.
What I am not quite clear on is why what Cilium does is insufficient in overcoming this system configuration?
My understanding is that systemd only runs it's systemd-sysctl component once at boot, see systemd-sysctl.service.
What also makes this a little harder to understand is that there a multiple places in Cilium code where rp_fileter settings are manipulated:
https://github.com/cilium/cilium/blob/72949b4b49d43e6dbb4714929222acb688ce6dd2/bpf/init.sh#L78
https://github.com/cilium/cilium/blob/9e48678686e213b0b36d616d0bf20f5104eeca04/pkg/datapath/loader/netlink.go#L182
https://github.com/cilium/cilium/blob/72949b4b49d43e6dbb4714929222acb688ce6dd2/pkg/datapath/loader/base.go#L178
https://github.com/cilium/cilium/blob/28d9889795e41026bf5ecd29c069f7b73bdd20f5/pkg/datapath/connector/add.go#L68
https://github.com/cilium/cilium/blob/8078e12f3ad674e69586c15abc4e86156bbc5cdd/pkg/datapath/linux/datapath.go#L56
https://github.com/cilium/cilium/blob/28d9889795e41026bf5ecd29c069f7b73bdd20f5/pkg/datapath/connector/veth.go#L110
https://github.com/cilium/cilium/blob/b323ecadeecbdde0f91dc92dc8e494bcfba29dca/pkg/datapath/connector/ipvlan.go#L196
Let's take what cilium/bpf/init.sh does, what exactly happens after that that override the setting?
I'd like to work out a proper solution for this, as systemd is unlikely to change, or even if it will change in the future, releases that have this feature are going to be around for quite some time.

Some additional information on this:
Systemd maintainer have introduced this configuration in attempt of fixing some kind of boot-time race condition, and it seems to improve overall consistency of how the system behaves.
Initially there was https://github.com/systemd/systemd/commit/1836bf9e1d70240c8079e4db4312309f4f1f91fd, which later was followed-up with a bug report https://github.com/systemd/systemd/issues/6282 an a subsequent PR https://github.com/systemd/systemd/pull/14589, which ultimately appears to be the cause of this issue for Cilium.
What I am not quite clear on is why what Cilium does is insufficient in overcoming this system configuration?
My understanding is that systemd only runs it's systemd-sysctl component once at boot, see systemd-sysctl.service.
What also makes this a little harder to understand is that there a multiple places in Cilium code where rp_fileter settings are manipulated:
https://github.com/cilium/cilium/blob/72949b4b49d43e6dbb4714929222acb688ce6dd2/bpf/init.sh#L78
https://github.com/cilium/cilium/blob/9e48678686e213b0b36d616d0bf20f5104eeca04/pkg/datapath/loader/netlink.go#L182
https://github.com/cilium/cilium/blob/72949b4b49d43e6dbb4714929222acb688ce6dd2/pkg/datapath/loader/base.go#L178
https://github.com/cilium/cilium/blob/28d9889795e41026bf5ecd29c069f7b73bdd20f5/pkg/datapath/connector/add.go#L68
https://github.com/cilium/cilium/blob/8078e12f3ad674e69586c15abc4e86156bbc5cdd/pkg/datapath/linux/datapath.go#L56
https://github.com/cilium/cilium/blob/28d9889795e41026bf5ecd29c069f7b73bdd20f5/pkg/datapath/connector/veth.go#L110
https://github.com/cilium/cilium/blob/b323ecadeecbdde0f91dc92dc8e494bcfba29dca/pkg/datapath/connector/ipvlan.go#L196
Let's take what cilium/bpf/init.sh does, what exactly happens after that that override the setting?
I'd like to work out a proper solution for this, as systemd is unlikely to change, or even if it will change in the future, releases that have this feature are going to be around for quite some time.

It looks like network interface sysctls are applied to new interfaces.
From the docs:

The settings configured with sysctl.d files will be applied early on boot. The
network interface-specific options will also be applied individually for each network interface as it
shows up in the system. (More specifically, net.ipv4.conf.*, net.ipv6.conf.*, net.ipv4.neigh.*
and net.ipv6.neigh.*).

I had a look at the code also, but not quite sure how exactly configuration is applied to each new device, but per above it's clear that some part of systemd does it for sure (albeit not systemd-sysctl itself).
It looks like the best fix would be to make either node init or CNI plugin installer drop a config file, and in addition to that all attempt where Cilium tries to write sysctls should check the value after writing and at least log an error/warning in case the intended value doesn't persist.
Aside from that, another question to ask is - is there a way to enforce sysctls from an eBPF program?

It looks like network interface sysctls are applied to new interfaces.
From the docs:

The settings configured with sysctl.d files will be applied early on boot. The
network interface-specific options will also be applied individually for each network interface as it
shows up in the system. (More specifically, net.ipv4.conf.*, net.ipv6.conf.*, net.ipv4.neigh.*
and net.ipv6.neigh.*).

I had a look at the code also, but not quite sure how exactly configuration is applied to each new device, but per above it's clear that some part of systemd does it for sure (albeit not systemd-sysctl itself).
It looks like the best fix would be to make either node init or CNI plugin installer drop a config file, and in addition to that all attempt where Cilium tries to write sysctls should check the value after writing and at least log an error/warning in case the intended value doesn't persist.
Aside from that, another question to ask is - is there a way to enforce sysctls from an eBPF program?

From talking to @qmonnet it sounds like an eBPF program cannot magically enforce sysctls, so I'll just scratch that idea 😉
There is however CNI tuning plugin. but it looks like it is just writing to /proc/sys/net/*, which is what Cilium does already so it won't be sufficient to overcome systemd's behaviour.
I am thinking perhaps cilium-cni could detect systemd version and write out configs for each interface, how would that sound  to people? I think this would most reliable defence. If we were to just write one file with wildcard as documented, there is a good chance it gets overwritten deleted or overridden with another file. But having a config file for each interface will reduce the chances of collision.

From talking to @qmonnet it sounds like an eBPF program cannot magically enforce sysctls, so I'll just scratch that idea 😉
There is however CNI tuning plugin. but it looks like it is just writing to /proc/sys/net/*, which is what Cilium does already so it won't be sufficient to overcome systemd's behaviour.
I am thinking perhaps cilium-cni could detect systemd version and write out configs for each interface, how would that sound  to people? I think this would most reliable defence. If we were to just write one file with wildcard as documented, there is a good chance it gets overwritten deleted or overridden with another file. But having a config file for each interface will reduce the chances of collision.

could detect systemd version and write out configs for each interface, how would that sound to people?

Long-term, everything will trend towards newer systemd so unless we expect a significant portion of users to be running non-systemd hosts, I don't think the "detect systemd version" piece makes any meaningful difference; I'd skip that to keep things simple.
Coordinating with systemd seems like the right solution, at the moment my understanding is that the initial lifecycle of the device from creation to configuration by {cilium,systemd} is not done in a coordinated manner, which means that we end up arguing with each other and the last one to perform configuration is the one that wins. Seems like that's systemd. Therefore, I think we either need to tell systemd how to configure the devices, or we need a mechanism to know when systemd will no longer mess with the configuration at which point we know it's safe for us to do so. The former approach seems more viable.

If we were to just write one file with wildcard as documented, there is a good chance it can get overwritten, deleted or shadowed by another config file. But having a config file for each interface will reduce the chances of collision.

As long as we're happy with the notion of writing up to say ~100 of these on a given node, and re-writing them on the filesystem every time a new pod is deployed (perhaps dozens of times per minute). I suspect this is probably not noticeable from a performance perspective, given how small the configuration would be. Alternative is we write one configuration file and then just have some background monitor that double-checks that the configuration is still OK (for instance, by validating that a random endpoint's sysctl configuration matches what we expect). Just an idea, we do similar sorts of things via pkg/controller today.

could detect systemd version and write out configs for each interface, how would that sound to people?

Long-term, everything will trend towards newer systemd so unless we expect a significant portion of users to be running non-systemd hosts, I don't think the "detect systemd version" piece makes any meaningful difference; I'd skip that to keep things simple.
Coordinating with systemd seems like the right solution, at the moment my understanding is that the initial lifecycle of the device from creation to configuration by {cilium,systemd} is not done in a coordinated manner, which means that we end up arguing with each other and the last one to perform configuration is the one that wins. Seems like that's systemd. Therefore, I think we either need to tell systemd how to configure the devices, or we need a mechanism to know when systemd will no longer mess with the configuration at which point we know it's safe for us to do so. The former approach seems more viable.

If we were to just write one file with wildcard as documented, there is a good chance it can get overwritten, deleted or shadowed by another config file. But having a config file for each interface will reduce the chances of collision.

As long as we're happy with the notion of writing up to say ~100 of these on a given node, and re-writing them on the filesystem every time a new pod is deployed (perhaps dozens of times per minute). I suspect this is probably not noticeable from a performance perspective, given how small the configuration would be. Alternative is we write one configuration file and then just have some background monitor that double-checks that the configuration is still OK (for instance, by validating that a random endpoint's sysctl configuration matches what we expect). Just an idea, we do similar sorts of things via pkg/controller today.

When I added this to 1.10 feature candidates, I was meaning #14955 should resolve this. It's actually clearer to track #14955 in the project so I've removed this one from 1.10. This doesn't change which release we intend to address this issue more generically.

Just to weigh in here for anyone else who might be searching for it, this affected my systems on NixOS 21.03 (and may indeed affect previous releases). The sysctl configuration mentioned above can be implemented using the boot.kernel.sysctl configuration option

It appears that this might still be a problem, even with --enable-endpoint-routes on, for NodePort and LoadBalancer services when DSR is enabled.
Specifically:

NodePort services where the request hits Node A, but the backend is on Node B (such that the DSR response from the pod on Node B has to get SNAT'd to Node A's IP on the way out)
LoadBalancer services such as those provisioned by MetalLB, where in all cases the DSR response from the pod must get SNAT'd to the LoadBalancer VIP
I suspect the same for manually defined ExternalIP services (effectively the same as the LoadBalancer case described above)

As far as I can tell (not 100% sure, but maybe 85%), the egress SNAT occurring on DSR responses from the backend pod happens before RPF is evaluated, so an rp_filter value of 2 will drop the packet because the resulting source IP on the packet doesn't exist / may not be routable on the node.
The workaround as described above (setting rp_filter=0 on all LXC veths) fixes this case as well. I just want to call out a possible use case where #14955 likely will not fix this because Cilium (correctly, IMO) won't be installing routes for LoadBalancer VIPs or other nodes' IPs that would satisfy RPF.

@eyanulis Your discovery looks correct to me.
I think we should create a controller which does a periodic scan of rp_filter's and at least logs a warning when it detects the rp_filter change.

In case it helps anyone, I can confirm this still happening with systemd 249 (249.3-1-arch), systemd-networkd enabled, and cilium 1.10.3. The sysctl override workaround fixed the issue for me (after recreating all pods).


File Entry Not Found.

I1102 10:06:54 26578 volume_server_handlers_read.go:70] read error: File Entry Not Found. Needle 144628 Memory 0 /1639,0166141074724fc4b9I1102 10:06:54 26578 volume_server_handlers_read.go:70] read error: File Entry Not Found. Needle 237196 Memory 0 /250,01661402621ce66093I1102 10:06:54 26578 volume_server_handlers_read.go:70] read error: File Entry Not Found. Needle 192412 Memory 0 /1791,01661405365135d381I1102 10:06:54 26578 volume_server_handlers_read.go:70] read error: File Entry Not Found. Needle 226212 Memory 0 /405,01661410afd11a48a4I1102 10:06:54 26578 volume_server_handlers_read.go:70] read error: File Entry Not Found. Needle 156928 Memory 0 /2329,0166140414d334bd58I1102 10:06:54 26578 volume_server_handlers_read.go:70] read error: File Entry Not Found. Needle 126444 Memory 0 /1791,016613fe5fe5801ee2I1102 10:06:55 26578 volume_server_handlers_read.go:70] read error: File Entry Not Found. Needle 134472 Memory 0 /1644,01661405f76072a4d2I1102 10:06:55 26578 volume_server_handlers_read.go:70] read error: File Entry Not Found. Needle 241900 Memory 0 /1639,01661401079bf59f39I1102 10:06:56 26578 volume_server_handlers_read.go:70] read error: File Entry Not Found. Needle 43614 Memory 0 /1639,0166140812179f5bd2

I know i have asked you already, but after the recovering or repair of ldb files, we are getting so much such errors,
We have attached 4 volumes with the master... when the master is getting started, everything works fine as its sending images to other volumes but after once it gets connected, there are a lot of such errors..
Is there any way or possibility to overcome this issue? @chrislusf

Also, if there are no such errors, we are getting so many HTTP timeout errors at the moment.
is there any possibility that Master is slow? it was stopped for 3 days and now so many repair and everything.. happened on it? also 4 other volumes are attached with it?

Is there anyway, to stop master for doing anything.. and just server as filer port?

these kind of errors as well
I1102 12:41:51  9063 needle.go:80] Reading Content [ERROR] multipart: Part Read: unexpected EOF
I1102 12:41:51  9063 filer_server_handlers_write.go:106] failing to connect to volume server /everc-fhlcr/snapshots/recordings/2017/11/02/11/40_21_000.jpg Post http://master:8080/278,01661b8efc299f5656: read tcp master:8888-><IP_ADDRESS>:51741: i/o timeout
I1102 12:41:51  9063 filer_server_handlers_write.go:106] failing to connect to volume server /everc-fhlcr/snapshots/recordings/2017/11/02/11/40_11_000.jpg Post http://master:8080/250,01661b8ee8c040eccf: unexpected EOF
I1102 12:41:51  9063 needle.go:80] Reading Content [ERROR] multipart: Part Read: unexpected EOF
I1102 12:41:52  9063 filer_server_handlers_write.go:106] failing to connect to volume server /everc-fhlcr/snapshots/recordings/2017/11/02/11/40_05_000.jpg Post http://master:8080/1984,01661b8edb676f65ad: unexpected EOF
I1102 12:41:52  9063 needle.go:80] Reading Content [ERROR] multipart: Part Read: unexpected EOF
I1102 12:41:52  9063 filer_server_handlers_write.go:106] failing to connect to volume server /everc-fhlcr/snapshots/recordings/2017/11/02/11/40_38_000.jpg Post http://master:8080/2329,01661b8f1ec196978f: read tcp master:8888-><IP_ADDRESS>:34485: i/o timeout
I1102 12:41:52  9063 filer_server_handlers_write.go:106] failing to connect to volume server /everc-fhlcr/snapshots/recordings/2017/11/02/11/41_28_000.jpg Post http://<IP_ADDRESS>:8080/82777,01661b8f865a637149: unexpected EOF
I1102 12:41:52  9063 filer_server_handlers_write.go:106] failing to connect to volume server /everc-fhlcr/snapshots/recordings/2017/11/02/11/40_20_000.jpg Post http://master:8080/1968,01661b8efae0a382a0: read tcp master:8888-><IP_ADDRESS>:34265: i/o timeout
I1102 12:41:53  9063 filer_server_handlers_write.go:106] failing to connect to volume server /everc-fhlcr/snapshots/recordings/2017/11/02/11/41_17_000.jpg Post http://<IP_ADDRESS>:8080/2728,01661b8f70ffeb793d: unexpected EOF
I1102 12:41:53  9063 filer_server_handlers_write.go:106] failing to connect to volume server /everc-fhlcr/snapshots/recordings/2017/11/02/11/40_26_000.jpg Post http://master:8080/1279,01661b8f065477368c: read tcp master:8888-><IP_ADDRESS>:35417: i/o timeout
I1102 12:41:54  9063 filer_server_handlers_write.go:106] failing to connect to volume server /everc-fhlcr/snapshots/recordings/2017/11/02/11/41_06_000.jpg Post http://master:8080/1279,01661b8f5a8220c588: unexpected EOF
I1102 12:41:54  9063 needle.go:80] Reading Content [ERROR] multipart: Part Read: unexpected EOF
I1102 12:41:54  9063 filer_server_handlers_write.go:106] failing to connect to volume server /everc-fhlcr/snapshots/recordings/2017/11/02/11/40_36_000.jpg Post http://<IP_ADDRESS>:8080/2984,01661b8f1a344fdc05: read tcp master:8888-><IP_ADDRESS>:54015: i/o timeout
I1102 12:41:55  9063 filer_server_handlers_write.go:106] failing to connect to volume server /everc-fhlcr/snapshots/recordings/2017/11/02/11/40_08_000.jpg Post http://master:8080/246,01661b8ee239320c1e: read tcp master:8888-><IP_ADDRESS>:38733: i/o timeout

In past, everything was working fine,
As when our actuall master was not working, we attached our 4 volumes with a new filer just to test will they work or not.. this could be a problem? for actual master now?
As now our master is working fine if we dont do any requests.. but when we do post requests.. They start timing out.. and also there are many File Entry Not Found. errors on every volume servers as well.
Can anyone please look at this for once and point to the issue here?

I suspect these files, for example, /everc-fhlcr/snapshots/recordings/2017/11/02/11/40_21_000.jpg, have been updated before. And the ldb files are not restored correctly. So the file id stored in the ldb was pointing to an older version of the file, which is already purged or marked as deleted.
This could be that the ldb file was recovered to a previous snapshot, missing the most recent changes.

Okay, But as you can see the date 2017/11/02/11, Year-Month-Day-Hour, it was yesterdays dates.
I totally agree with you, but how these files can be updated before when the date is very latest. Also all this repair could be the reason of all the issues as timeout and No File Entry?
Is there any way to repair those files correctly?

could it be that the files were added when moving the volume files?

Sorry? We haven't moved volume files anywhere.. the master's volume files are there where they were before.
or maybe I don't understand your question?

As far as I understand at the moment, leveldb repair first use the LOG file to convert it into tables.
And In our filer, we have 2 LOG files, first one is LOG and other one is LOG.old
LOG file looks like this in tail
12:41:11.120493 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
12:41:11.128952 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
12:41:33.985344 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
12:41:33.993604 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
12:41:56.427730 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
12:41:56.436365 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
12:42:19.198132 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
12:42:19.206608 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
12:43:51.041811 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
12:43:51.050075 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
13:47:12.007978 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
13:47:12.127548 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
13:47:31.969015 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
13:47:31.977406 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
13:47:52.363661 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
13:47:52.371888 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
13:48:12.700369 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
13:48:12.765671 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
13:48:32.804390 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
13:48:32.812534 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
13:48:52.630745 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
13:48:52.638917 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
13:49:12.757412 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
13:49:12.825021 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
13:49:32.644021 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
13:49:32.652097 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
13:49:52.464973 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
13:49:52.550792 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
13:50:12.409692 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
13:50:12.424688 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
13:50:32.568867 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
13:50:32.577247 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
13:50:52.451453 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
13:50:52.459542 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
13:51:13.037152 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
13:51:13.054590 skipping CURRENT: corrupted or incomplete
=============== Nov 1, 2017 (CET) ===============
13:51:32.972169 log@legend F·NumFile S·FileSize N·Entry C·BadEntry B·BadBlock Ke·KeyError D·DroppedEntry L·Level Q·SeqNum T·TimeElapsed
13:51:32.980343 skipping CURRENT: corrupted or incomplete

And the LOG.old looks like this
02:11:00.903575 table@build created L3@3380117 N·1 S·158B "\x00\x11\x1e..jpg,v5995507567":"\x00\x11\x1e..jpg,v5995507567"
02:11:00.904364 table@build created L3@3380118 N·1 S·158B "\x00\x110..jpg,v5996131382":"\x00\x110..jpg,v5996131382"
02:11:00.904708 table@build created L3@3380119 N·1 S·158B "\x00\x13\xfa..jpg,v5996829201":"\x00\x13\xfa..jpg,v5996829201"
02:11:00.905142 table@build created L3@3380120 N·2 S·191B "\x00\x14\x10..jpg,v5996828853":"\x00\x14\x11..jpg,v5996819804"
02:11:00.905575 table@build created L3@3380121 N·1 S·158B "\x00\x14\xd0..jpg,v5996829131":"\x00\x14\xd0..jpg,v5996829131"
02:11:00.905936 table@build created L3@3380122 N·1 S·158B "\x00\x15p..jpg,v5996825829":"\x00\x15p..jpg,v5996825829"
02:11:00.906628 table@build created L3@3380123 N·1 S·158B "\x00\x15\xb5..jpg,v5996829331":"\x00\x15\xb5..jpg,v5996829331"
02:11:00.906997 table@build created L3@3380124 N·1 S·155B "\x00\x17p..jpg,v5996131406":"\x00\x17p..jpg,v5996131406"
02:11:00.907948 table@build created L3@3380125 N·1 S·155B "\x00\x17\xb3..jpg,v5996826280":"\x00\x17\xb3..jpg,v5996826280"
02:11:00.908534 table@build created L3@3380126 N·1 S·155B "\x00\x19\xed..jpg,v5996131383":"\x00\x19\xed..jpg,v5996131383"
02:11:00.909121 table@build created L3@3380127 N·1 S·158B "\x00\x1b\x00..jpg,v5996828267":"\x00\x1b\x00..jpg,v5996828267"
02:11:00.909527 table@build created L3@3380128 N·3 S·221B "\x00\x1b\xc7..jpg,v5996829303":"\x00\x1b\xc7..jpg,v5996829116"
02:11:00.910196 table@build created L3@3380129 N·1 S·158B "\x00\x1b\xfa..jpg,v5996827984":"\x00\x1b\xfa..jpg,v5996827984"
02:11:00.910558 table@build created L3@3380130 N·2 S·188B "\x00\x1d\xb2..jpg,v5996828504":"\x00\x1d\xb2..jpg,v5996828233"
02:11:00.911057 table@build created L3@3380131 N·1 S·155B "\x00\x1d\xb7..jpg,v5996131929":"\x00\x1d\xb7..jpg,v5996131929"
02:11:00.911433 table@build created L3@3380132 N·1 S·156B "\x00\x1e\\..jpg,v5996828570":"\x00\x1e\\..jpg,v5996828570"
02:11:00.912032 table@build created L3@3380133 N·1 S·155B "\x00\x1e\x88..jpg,v5996828925":"\x00\x1e\x88..jpg,v5996828925"
02:11:00.912608 table@build created L3@3380134 N·1 S·155B "\x00\x1f\xc8..jpg,v5996828878":"\x00\x1f\xc8..jpg,v5996828878"
02:11:00.913036 table@build created L3@3380135 N·1 S·155B "\x00 \xfb..jpg,v5996828960":"\x00 \xfb..jpg,v5996828960"
02:11:00.913555 table@build created L3@3380136 N·1 S·158B "\x00!]..jpg,v5996828966":"\x00!]..jpg,v5996828966"
02:11:00.913990 table@build created L3@3380137 N·1 S·158B "\x00!\xfb..jpg,v5996829146":"\x00!\xfb..jpg,v5996829146"
02:11:00.914319 table@build created L3@3380138 N·2 S·192B "\x00\"\\..jpg,v5996058748":"\x00\"]..jpg,v5996059985"
02:11:00.914654 table@build created L3@3380139 N·1 S·158B "\x00\"d..jpg,v5996828975":"\x00\"d..jpg,v5996828975"
02:11:00.915252 table@build created L3@3380140 N·1 S·155B "\x00\"r..jpg,v5996771493":"\x00\"r..jpg,v5996771493"
02:11:00.915954 table@build created L3@3380141 N·1 S·158B "\x00$G..jpg,v5996828007":"\x00$G..jpg,v5996828007"
02:11:00.916361 table@build created L3@3380142 N·3 S·218B "\x00&b..jpg,v5996828772":"\x00&b..jpg,v5996828522"
02:11:00.916746 table@build created L3@3380143 N·1 S·158B "\x00'\x16..jpg,v5996825038":"\x00'\x16..jpg,v5996825038"
02:11:00.917075 table@build created L3@3380144 N·4 S·250B "\x00'N..jpg,v5996825437":"\x00'O..jpg,v5996825251"
02:11:00.917601 table@build created L3@3380145 N·2 S·189B "\x00'g..jpg,v5996824534":"\x00'g..jpg,v5996828795"
02:11:00.917892 table@build created L3@3380146 N·1 S·158B "\x00(\xb6..jpg,v5996829317":"\x00(\xb6..jpg,v5996829317"
02:11:00.918218 table@build created L3@3380147 N·1 S·158B "\x00(\xcd..jpg,v5996828982":"\x00(\xcd..jpg,v5996828982"
02:11:00.918609 table@build created L3@3380148 N·1 S·156B "\x00)\v..jpg,v5996828778":"\x00)\v..jpg,v5996828778"
02:11:00.919061 table@build created L3@3380149 N·1 S·158B "\x00)\xac..jpg,v5996829121":"\x00)\xac..jpg,v5996829121"
02:11:00.919548 table@build created L3@3380150 N·1 S·156B "\x00*\xdf..jpg,v5996830383":"\x00*\xdf..jpg,v5996830383"
02:11:00.919813 table@build created L3@3380151 N·2 S·191B "\x00,T..jpg,v5996828885":"\x00,T..jpg,v5996829301"
02:11:00.920359 table@build created L3@3380152 N·2 S·191B "\x00,Y..jpg,v5996829107":"\x00,Y..jpg,v5996830081"
02:11:00.920711 table@build created L3@3380153 N·1 S·156B "\x00.\x1b..jpg,v5996828502":"\x00.\x1b..jpg,v5996828502"
02:11:00.921007 table@build created L3@3380154 N·1 S·156B "\x00.K..jpg,v5996828675":"\x00.K..jpg,v5996828675"
02:11:00.921320 table@build created L3@3380155 N·1 S·158B "\x00.N..jpg,v5996823842":"\x00.N..jpg,v5996823842"
02:11:00.921621 table@build created L3@3380156 N·1 S·155B "\x00.f..jpg,v5996826179":"\x00.f..jpg,v5996826179"
02:11:00.922160 table@build created L3@3380157 N·1 S·158B "\x00.z..jpg,v5996826932":"\x00.z..jpg,v5996826932"
02:11:00.922566 table@build created L3@3380158 N·1 S·158B "\x00/\x9d..jpg,v5996829016":"\x00/\x9d..jpg,v5996829016"
02:11:00.922827 table@build created L3@3380159 N·1 S·155B "\x000*..jpg,v5996830446":"\x000*..jpg,v5996830446"
02:11:00.929614 version@stat F·[0 49 504 5008 50205 9462] S·126GiB[0B 98MiB 999MiB 9GiB 97GiB 18GiB] Sc·[0.00 0.98 1.00 1.00 1.00 0.02]
02:11:00.929861 table@compaction committed F-1 S-6KiB Ke·0 D·231 T·32.935115ms
02:11:00.947499 table@remove removed @3380096
02:11:00.947806 table@remove removed @3379979
02:11:00.947967 table@remove removed @3379980
02:11:00.948061 table@remove removed @3379981
02:11:00.948171 table@remove removed @3379982
02:11:00.948282 table@remove removed @3379983
02:11:00.948407 table@remove removed @3379984
02:11:00.948542 table@remove removed @3379985
02:11:00.948643 table@remove removed @3379986
02:11:00.948737 table@remove removed @3379987
02:11:00.948835 table@remove removed @3379988
02:11:00.948931 table@remove removed @3379989
02:11:00.949018 table@remove removed @3379990
02:11:00.949105 table@remove removed @3379991
02:11:00.949191 table@remove removed @3379992
02:11:00.949289 table@remove removed @3379993
02:11:00.949379 table@remove removed @3379994
02:11:00.949465 table@remove removed @3379995
02:11:00.949550 table@remove removed @3379996
02:11:00.949638 table@remove removed @3379997
02:11:00.949723 table@remove removed @3379998
02:11:00.949809 table@remove removed @3379999
02:11:00.949893 table@remove removed @3380000
02:11:00.949980 table@remove removed @3380001
02:11:00.950066 table@remove removed @3380002
02:11:00.950150 table@remove removed @3380003
02:11:00.950237 table@remove removed @3380004
02:11:00.950321 table@remove removed @3380005
02:11:00.950404 table@remove removed @3380006
02:11:00.950491 table@remove removed @3380007
02:11:00.950578 table@remove removed @3380008
02:11:00.950665 table@remove removed @3380009
02:11:00.950748 table@remove removed @3380010
02:11:00.950833 table@remove removed @3380011
02:11:00.950917 table@remove removed @3380012
02:11:00.951000 table@remove removed @3380013
02:11:00.951088 table@remove removed @3380014
02:11:00.951174 table@remove removed @3380015
02:11:00.951266 table@remove removed @3380016
02:11:00.951352 table@remove removed @3380017
02:11:00.951447 table@remove removed @3380018
02:11:00.951537 table@remove removed @3380019
02:11:00.951627 table@remove removed @3380020
02:11:00.951718 table@remove removed @3380021
02:11:00.951809 table@remove removed @3380022
02:11:00.951899 table@remove removed @3380023
02:11:00.951992 table@remove removed @3380024
02:11:00.952093 table@remove removed @3380025
02:11:00.952183 table@remove removed @3380026
02:11:00.952270 table@remove removed @3380027
02:11:00.952394 table@remove removed @3380028
02:11:00.952491 table@remove removed @3380029
02:11:00.952617 table@remove removed @3380030
02:11:00.952714 table@remove removed @3380031
02:11:00.952813 table@remove removed @3380032

So I took a step a head and removed LOG file and renamed LOG.old to LOG, and then repaired it..
But the results are same. Do you have any idea while looking the logs? what we are missing here?

https://github.com/syndtr/goleveldb/issues/184


Write Double.NaN

Hi,
When I try to open the excel file generated by the Sylvan.Excel. I get the following error.
"We found a preblem with some content in 'xxx.xlsx'. Do you want us try to recover as much as we can? If you trust the source of this workbook, clik Yes."
The code is attached below.
`
public void SylvanExcelTest()
{
var data =
new[]
{
double.NaN,
1.2
}.Select(v => new { Value = v });
 var reader = data.AsDataReader();
 using (var w = ExcelDataWriter.Create("D:\\test2.xlsx"))
 {
     w.Write(reader);
 }

}
`

Yep, this was a bug. It has been fixed with #177, and will be included in the next release.


There are duplicate definitions

Description of the issue
There are a number of entities that share the same definition, but are not equivalent. These entities are:

[ ] has_numerical_output, has_physical_output,
[ ] has_numerical_input, has_physical_input

Ideas of solution
Update the definitions.
has_physical_input:  This seems to be equivalent to the actual RO:has_input, as it assumes the right-hand side to be a material entity and to be altered in the process.
has_numerical_input: Has an input that is a quantity value? This seems off. Maybe we should omit this property altogether and introduce has_information_input that covers all information content entities?
Workflow checklist

[ ] I discussed the issue with someone else than me before working on a solution
[x] I already read the latest version of the workflow for this repository
[x] The goal of this ontology is clear to me

I am aware that

[x] every entry in the ontology should have a definition
[x] classes should arise from concepts rather than from words

I agree that has physical input is the same as has input. I also like the idea of a property has information input (this would also be a good superproperty of has constraint),
A problem is that has input is currently limited to material entities. We could add has information input as a sibling property to has input, which would be a bit confusing. Maybe we should change the definition of has input instead to include all continuants and then use has physical input and has information input as subproperties.

After we have already updated has input and has physical input in #702, we only need to take care of the other half of the problem, has numerical input. I would suggest to

replace has numerical input by has information input, defined as p has physical input c iff: p has input c, and c is an information content entity (analogous to the definition of has physical input).
add missing domains and ranges to the children of has input to further distinguish them
make has constraint a subproperty of has information input
do the same for has ... output

* replace `has numerical input` by `has information input`, defined as _p has physical input c iff: p has input c, and c is an information content entity_ (analogous to the definition of `has physical input`).

You mean, defined as p has information input iff...
Sounds good!

You mean, defined as p has information input iff...

Thanks for spotting this.
If no one has objections, I will implement.


Run tests in docker container

This PR updates the Travis CI tests to run in a docker container that has HTCondor installed. This allows us to have integration tests.

The CI has moved to github actions, which natively supports running in a container, so while this can't be merged as is, the spirit of this PR should be preserved and updated to allow for tests on top of a running htcondor pool.


"index.refresh_interval" is set wrongly

.
.

ElasticSearch
1.4.2

elasticsearch-river-jdbc
<IP_ADDRESS>

Run as
feeder

Hi,
I have a small problem with feeder, as it's setting up index.refresh_interval to 1s after every shut down of feeder process.
tail -f /var/log/elasticsearch/elasticsearch.log
[2015-02-16 17:18:33,367][INFO ][index.shard.service      ] [Tom Thumb] [myidx][0] updating refresh_interval from [30s] to [-1]
[2015-02-16 17:18:33,368][INFO ][index.shard.service      ] [Tom Thumb] [myidx][3] updating refresh_interval from [30s] to [-1]
[2015-02-16 17:18:33,368][INFO ][index.shard.service      ] [Tom Thumb] [myidx][1] updating refresh_interval from [30s] to [-1]
[2015-02-16 17:18:33,369][INFO ][index.shard.service      ] [Tom Thumb] [myidx][2] updating refresh_interval from [30s] to [-1]
[2015-02-16 17:18:33,370][INFO ][index.shard.service      ] [Tom Thumb] [myidx][4] updating refresh_interval from [30s] to [-1]
[2015-02-16 17:18:47,685][INFO ][index.shard.service      ] [Tom Thumb] [myidx][0] updating refresh_interval from [-1] to [1s]
[2015-02-16 17:18:47,687][INFO ][index.shard.service      ] [Tom Thumb] [myidx][3] updating refresh_interval from [-1] to [1s]
[2015-02-16 17:18:47,688][INFO ][index.shard.service      ] [Tom Thumb] [myidx][1] updating refresh_interval from [-1] to [1s]
[2015-02-16 17:18:47,688][INFO ][index.shard.service      ] [Tom Thumb] [myidx][2] updating refresh_interval from [-1] to [1s]
[2015-02-16 17:18:47,689][INFO ][index.shard.service      ] [Tom Thumb] [myidx][4] updating refresh_interval from [-1] to [1s]

I tried to setup index.refresh_interval by Rest API but also in elasticsearch.yml but result was this same, value got overridden every time.
dan

ping @jprante

JDBC plugin disables index refresh for faster indexing. There is no reliable way to ask ES for current refresh interval of an index. Therefore, the default for the restored value is 1s.
You can set explicit refresh interval to be restored for JDBC plugin in the index_settings parameter.
curl -XPUT '0:9200/_river/my_mysql_river/_meta' -d '{
    "type" : "jdbc",
    "jdbc" : {
        "url" : "jdbc:mysql://localhost:3306/test",
        "user" : "",
        "password" : "",
        "sql" : [
            {
                "statement" : "select ... from ..."
            }
        ],
        "index" : "myjdbc",
        "type" : "mytype",
        "index_settings" : {
            "index" : {
                "refresh_interval" : "30s"
            }
        }
    }
}'

Oh somehow I missed this index_settings from documentation. That definitely would help! Thanks once again!

This is still not getting picked up by the river.  eg.  config file for feeder script on linux.  It still sets it back to 1 sec.  Probably missing something, but i thought i would ask.
{
"max_concurrrent_bulk_requests" : 16,
"max_bulk_actions" : 10000 ,
"elasticsearch" : {
"cluster" : "LaunchSearch_dev",
"host" : "localhost",
"port" : 9300
},
"jdbc" : {
"index" : "launch",
"type" : "src_fulfillment_search",
"sql" : [ "select customersurveyinstanceid as "_id", survey_template_name as "survey_template_name", requestid as "request_id", requestname as "request_name", taskduedate as "task_due_date", preferreddate as "preferred_date", region as "region",requestedfor as "requested_for", requestedby as "requested_by",support_group_name as "support_group_name", assignee as "assignee", supportgroupid as "support_group_id", taskname as "task_name", taskstatus as "task_status",customersurveyinstanceid as "instance_id", createdate as "create_date", createdatetime as "create_date_time", ksrnumbersearch as "ksr_number_search", sladate as "sla_date", originatingid as "originating_id",  TO_DATE('1970-01-01', 'YYYY-MM-DD') + modifieddate / 86400 as "modified_date" from elasticsearch.FULFILLMENT_SEARCH where modifieddate BETWEEN to_number(((sysdate - to_date('01-JAN-1970','DD-MON-YYYY')) * (86400)) +21600 - 8100) AND to_number((sysdate  - to_date('01-JAN-1970','DD-MON-YYYY')) * (86400) + 21600) " ]
},
"index_settings" : {
"index" : {
"refresh_interval" : "5s"
}
}
}
}
logs after scheduled feeders run
[2015-04-09 09:23:33,210][INFO ][index.shard.service      ] [Launch_dev_001] [launch][0] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,210][INFO ][index.shard.service      ] [Launch_dev_001] [launch][1] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,210][INFO ][index.shard.service      ] [Launch_dev_001] [launch][2] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,210][INFO ][index.shard.service      ] [Launch_dev_001] [launch][3] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,210][INFO ][index.shard.service      ] [Launch_dev_001] [launch][4] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,210][INFO ][index.shard.service      ] [Launch_dev_001] [launch][5] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,210][INFO ][index.shard.service      ] [Launch_dev_001] [launch][6] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,211][INFO ][index.shard.service      ] [Launch_dev_001] [launch][7] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,211][INFO ][index.shard.service      ] [Launch_dev_001] [launch][8] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,211][INFO ][index.shard.service      ] [Launch_dev_001] [launch][9] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,211][INFO ][index.shard.service      ] [Launch_dev_001] [launch][10] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,211][INFO ][index.shard.service      ] [Launch_dev_001] [launch][11] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,211][INFO ][index.shard.service      ] [Launch_dev_001] [launch][12] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,211][INFO ][index.shard.service      ] [Launch_dev_001] [launch][13] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,211][INFO ][index.shard.service      ] [Launch_dev_001] [launch][14] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,211][INFO ][index.shard.service      ] [Launch_dev_001] [launch][15] updating refresh_interval from [-1] to [1s]
[2015-04-09 09:23:33,211][INFO ][index.shard.service      ] [Launch_dev_001] [launch][16] updating refresh_interval from [-1] to [1s]

Please use index_settings in the jdbc block:
{
    "elasticsearch": {
        "cluster": "LaunchSearch_dev",
        "host": "localhost",
        "port": 9300
    },
    "max_bulk_actions": 10000,
    "max_concurrrent_bulk_requests": 16,
    "jdbc": {
        "sql": [
            "select customersurveyinstanceid as \"_id\", survey_template_name as \"survey_template_name\", requestid as \"request_id\", requestname as \"request_name\", taskduedate as \"task_due_date\", preferreddate as \"preferred_date\", region as \"region\",requestedfor as \"requested_for\", requestedby as \"requested_by\",support_group_name as \"support_group_name\", assignee as \"assignee\", supportgroupid as \"support_group_id\", taskname as \"task_name\", taskstatus as \"task_status\",customersurveyinstanceid as \"instance_id\", createdate as \"create_date\", createdatetime as \"create_date_time\", ksrnumbersearch as \"ksr_number_search\", sladate as \"sla_date\", originatingid as \"originating_id\", TO_DATE('1970-01-01', 'YYYY-MM-DD') + modifieddate / 86400 as \"modified_date\" from elasticsearch.FULFILLMENT_SEARCH where modifieddate BETWEEN to_number(((sysdate - to_date('01-JAN-1970','DD-MON-YYYY')) * (86400)) +21600 - 8100) AND to_number((sysdate - to_date('01-JAN-1970','DD-MON-YYYY')) * (86400) + 21600) "
        ],
        "index": "launch",
        "type": "src_fulfillment_search",
	    "index_settings": {
	        "index": {
	            "refresh_interval": "5s"
	        }
	    }
    },
}

Thank you.  Sorry for the dumb question, i knew it was something simple.


IRC - ignore buffer playback on connect

I'm using Ergo IRC server, which sends playback history for every new user.
Obviously, this is a problem with Matterbridge after a server or bot restart.
To Reproduce: connect Matterbridge to any Ergo server with default settings
Expected behavior: ignore previously relayed messages
Environment (please complete the following information):

OS: Linux
Matterbridge version: 1.26.0 6dafebc7

Additional context

See the applicable section in ergo's manual.
Also see #965

HI @Oreolek , found any solution to this?

nope


Incorrect "auth" structure make the service goes down

Describe the bug
If a message with an incorrect "auth" structure for private channels is received, the service goes down.
TypeError

  explode(): Argument #2 ($string) must be of type string, stdClass given

  at vendor/laravel/framework/src/Illuminate/Support/Str.php:88
     84▕      * @return string
     85▕      */
     86▕     public static function after($subject, $search)
     87▕     {
  ➜  88▕         return $search === '' ? $subject : array_reverse(explode($search, $subject, 2))[0];
     89▕     }
     90▕
     91▕     /**
     92▕      * Return the remainder of a string after the last occurrence of a given value.

      +40 vendor frames

  41  artisan:35
      Illuminate\Foundation\Console\Kernel::handle(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))

To Reproduce
Steps to reproduce the behavior:

Start the service as usual with php artisan websockets:serve
Connect to the service
Send a message to subscribe to a private channel with an unexpected structure. {
       "event": "pusher:subscribe",
       "data": {
               "auth": {},
               "channel": "private-channel"
         }
   }

Expected behavior
Return an exception without causing a crash
** Environment:**

OS: MacOS Sonoma 14.2.1
Laravel: 10
php: 8.2

Tools:

Postman
Terminal

Pull request created to fix this issue: https://github.com/beyondcode/laravel-websockets/pull/1184


about nl_obj & nl_edge setting

I got error when I run './scripts/train_models_sgcls.sh 2'
the error is
'''
./scripts/train_models_sgcls.sh: line 21: 24548 Segmentation fault      (core dumped) python models/train_rels.py -m sgcls -model motifnet -order left right -nl_obj 2 -nl_edge 4 -b 6 -clip 5 -p 100 -hidden_dim 512 -pooling_dim 4096 -lr 1e-3 -ngpu 1 -ckpt checkpoints/vgdet/vg-23.tar -save_dir checkpoints/motifnet2 -nepoch 50 -use_bias
'''
when I set nl_obj & nl_edge = 0, the scripts is worked
so, I don't know what is wrong with the setting. Can someone help me with the problem?

I got error when I run './scripts/train_models_sgcls.sh 2'
the error is
'''
./scripts/train_models_sgcls.sh: line 21: 24548 Segmentation fault (core dumped) python models/train_rels.py -m sgcls -model motifnet -order left right -nl_obj 2 -nl_edge 4 -b 6 -clip 5 -p 100 -hidden_dim 512 -pooling_dim 4096 -lr 1e-3 -ngpu 1 -ckpt checkpoints/vgdet/vg-23.tar -save_dir checkpoints/motifnet2 -nepoch 50 -use_bias
'''
when I set nl_obj & nl_edge = 0, the scripts is worked
so, I don't know what is wrong with the setting. Can someone help me with the problem?

You set default values can you run on your machine? I tried, but it took up a lot of CPU memory during training (more than 64G), and the program being killed by the system. Do you have a problem?

I got error when I run './scripts/train_models_sgcls.sh 2'
the error is
'''
./scripts/train_models_sgcls.sh: line 21: 24548 Segmentation fault (core dumped) python models/train_rels.py -m sgcls -model motifnet -order left right -nl_obj 2 -nl_edge 4 -b 6 -clip 5 -p 100 -hidden_dim 512 -pooling_dim 4096 -lr 1e-3 -ngpu 1 -ckpt checkpoints/vgdet/vg-23.tar -save_dir checkpoints/motifnet2 -nepoch 50 -use_bias
'''
when I set nl_obj & nl_edge = 0, the scripts is worked
so, I don't know what is wrong with the setting. Can someone help me with the problem?

You set default values can you run on your machine? I tried, but it took up a lot of CPU memory during training (more than 64G), and the program being killed by the system. Do you have a problem?

I can't run on my machine when I set default( nl_obj = 1 & nl_edge = 2) values too.  Does that mean I can only run this script on more than 64G CPU. And my cpu memory is 32 G.  However,  when I monitor the CPU memory while running the script, I didn't find that CPU usage was full.

I got error when I run './scripts/train_models_sgcls.sh 2'
the error is
'''
./scripts/train_models_sgcls.sh: line 21: 24548 Segmentation fault (core dumped) python models/train_rels.py -m sgcls -model motifnet -order left right -nl_obj 2 -nl_edge 4 -b 6 -clip 5 -p 100 -hidden_dim 512 -pooling_dim 4096 -lr 1e-3 -ngpu 1 -ckpt checkpoints/vgdet/vg-23.tar -save_dir checkpoints/motifnet2 -nepoch 50 -use_bias
'''
when I set nl_obj & nl_edge = 0, the scripts is worked
so, I don't know what is wrong with the setting. Can someone help me with the problem?

You set default values can you run on your machine? I tried, but it took up a lot of CPU memory during training (more than 64G), and the program being killed by the system. Do you have a problem?

I can't run on my machine when I set default( nl_obj = 1 & nl_edge = 2) values too. Does that mean I can only run this script on more than 64G CPU. And my cpu memory is 32 G. However, when I monitor the CPU memory while running the script, I didn't find that CPU usage was full.

I don't know which ones are occupying memory, maybe we can add QQ discussion (mine: 785091715).

I got error when I run './scripts/train_models_sgcls.sh 2'
the error is
'''
./scripts/train_models_sgcls.sh: line 21: 24548 Segmentation fault (core dumped) python models/train_rels.py -m sgcls -model motifnet -order left right -nl_obj 2 -nl_edge 4 -b 6 -clip 5 -p 100 -hidden_dim 512 -pooling_dim 4096 -lr 1e-3 -ngpu 1 -ckpt checkpoints/vgdet/vg-23.tar -save_dir checkpoints/motifnet2 -nepoch 50 -use_bias
'''
when I set nl_obj & nl_edge = 0, the scripts is worked
so, I don't know what is wrong with the setting. Can someone help me with the problem?

You set default values can you run on your machine? I tried, but it took up a lot of CPU memory during training (more than 64G), and the program being killed by the system. Do you have a problem?

I can't run on my machine when I set default( nl_obj = 1 & nl_edge = 2) values too. Does that mean I can only run this script on more than 64G CPU. And my cpu memory is 32 G. However, when I monitor the CPU memory while running the script, I didn't find that CPU usage was full.

I don't know which ones are occupying memory, maybe we can add QQ discussion (mine: 785091715).

ok I add you now

@Iceland-Leo Have you solved this problem? Please tell me, Thx:)


Android:FlutterView.getBitmap will crash after call it multiple times for a FlutterView in short time.

Steps to Reproduce
In our application, we have only one flutter context(one FlutterView wrapped in multiple FlutterWrapperActivity), so the getBitmap will be called when I want to push/pop when switching activities.
However, in our test, we noticed that getBitmap will cause an abort will be triggered when I call the getBitmap for the FlutterView(which is singleton). The original abort code is given below:
  const SkISize& frame_size = layer_tree->frame_size();
  jsize pixels_size = frame_size.width() * frame_size.height();
  jintArray pixels_array = env->NewIntArray(pixels_size);
  FXL_CHECK(pixels_array);

It's located in platform_view_android.cc.
And the crash message is：
Abort message: '[FATAL:flutter/shell/platform/android/platform_view_android.cc(717)] Check failed: pixels_array.
From my point of view, I should call the FlutterView.getBitmap with a lock to avoid the reentry(as I have only one FlutterView). Or should the
void PlatformViewAndroid::GetBitmapGpuTask
avoid aborting when this situation happens.
Flutter Doctor
[✓] Flutter (Channel beta, v0.1.6-pre.39, on Mac OS X 10.13.4 17E199, locale en-CN)
• Flutter version 0.1.6-pre.39 at /Users/kylewong/Codes/fwn_idlefish/flutter
• Framework revision 5cac396777 (2 days ago), 2018-04-17 13:09:18 +0800
• Engine revision e61bb9a
• Dart version 2.0.0-dev.35.flutter-290c576264
[✓] Android toolchain - develop for Android devices (Android SDK 27.0.3)
• Android SDK at /Users/kylewong/Library/Android/sdk
• Android NDK at /Users/kylewong/Library/Android/sdk/ndk-bundle
• Platform android-27, build-tools 27.0.3
• Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b01)
• All Android licenses accepted.
[✓] iOS toolchain - develop for iOS devices (Xcode 9.3)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 9.3, Build version 9E145
• ios-deploy 1.9.2
• CocoaPods version 1.2.0
[✓] Android Studio (version 3.1)
• Android Studio at /Applications/Android Studio.app/Contents
• Java version OpenJDK Runtime Environment (build 1.8.0_152-release-1024-b01)
[✓] Connected devices (1 available)
• KyleWong's iPhone • 1c8e085cf2ff6fa27643ab4afec4bf4a077688af • ios • iOS 11.3
• No issues found!
Question:
How can I avoid the abort logic? Should I ensure that it's not reenterable or should the framework ensure that even I call it continously, it works fine.

@eseidelGoogle
Is it that good if any check logic fails? Some of them is failure, but it would be annoying if the app crashes directly.

We could change this API to return null or throw an OutOfMemoryError if the allocation fails

@eseidelGoogle
Currently, other apis and check logic seems fine. This one occurs a lot, so I think it's better to change the api to return null instead of abort directly.


Examples open in new window

Allow components to open in a new window to show how they work in a wider layout more reflective of our actual sites

This should be relatively easy to add to all examples once https://github.com/nihruk/design-system/pull/128 is added, leaving the generation of these stand-alone pages as the challenging bit.


Add build target for vkcube-wayland

Attempts to address #590

CI Vulkan-Tools build # 603 passed.

CI Vulkan-Tools build queued with queue ID 5677.


Azure Storage June Release

Update vcpkg ports for Azure SDK release. This release may contain multiple ports.

Adding azure-storage-common to release
cc: @vinjiang, @katmsft, @Jinming-Hu, @EmmaZhu, @antkmsft, @vhvb1989, @gearama, @LarryOsterman


Consider writing HTTPS asset hrefs instead of s3://

It doesn't really make a difference, except it's simpler to load/access assets that have a HTTPS href.
Any thoughts @jessjaco?

If I were a naive user I think I would prefer https. I tried to determine why the e.g. USGS stac catalogs use s3 though. It looks like it's a best practice for requester-pays buckets: https://github.com/radiantearth/stac-spec/blob/master/best-practices.md#requester-pays.
I did notice the s3:// urls don't seem to work with my favorite QGIS stac plugin, though this might be fixed.


Memory not getting released after completing a CC time step

The job failed again, but i do not know why it requires so much memory or crash after clearing the memory
Slack Message

Done in #216


middleware: Separate close and finish events

This cleans up the logging on newer NodeJS versions where finish is the intent to drain and close, while close represents the actual destruction of the underlying resources.

This would resolve #16 too.

is there anything blocking this merge currently?

I ran into this issue while testing this library as part of the work I'm doing in writing a book - I'd love it if this got resolved because #16 is a big annoyance.
Can someone help evaluate and merge this please @rnburn @rgarcia @drhurd ?

cc @austinlparker @iredelmeier

Lemme figure out who has the creds to release this, but yeah, we can get it out


added link to manage subscriptions

Coverage remained the same at 80.936% when pulling 141ffe0375c6f1412a3aa044e7a787c05fbb5366 on backerEmail into aefedb95bd2bb473547c354451921057954555d3 on master.

merging to send the email.


feat: added chip component

Description

Chips are compact elements that represent an input or an action.

Thanks for the interest and PR!
Chip component overlaps a lot with Badge (PR unmerged but already approved), we might want to add the onClick and closeable feature to it instead.
I'll think over it and get back to you.

Thanks for the interest and PR!
Chip component overlaps a lot with Badge (PR unmerged but already approved), we might want to add the onClick and closeable feature to it instead.
I'll think over it and get back to you.

Originally I thought badge component was supposed to be similar to notification badges we have in our OS. Chip components are normally used as things to filter out, tagging stuff, & many more and also commonly named as Chip. That's why decided to add this component.
I see what you mean though. I will also research further on my side.
Also do let me know if there any other components to which I can contribute which might be in your backlog to avoid duplicate work :)


weight

where is ./resnet34.pth?

@06Liz You can download it from this link and rename it to resnet34.pth
https://download.pytorch.org/models/resnet34-b627a593.pth


[New game]: Color Name

🎮 Game Request
The color name will be displayed but with different colors, you  have to tell the name of the color in which the color name is displayed
Point down the features
Made using HTML CSS JS
Score feature
Select program in which you are contributing
GSSoC23
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

/assign

Hey @HarshP6421 !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

Hello @HarshP6421, Time's Uppp!⏰
Sorry for closing your issue!
But it's more than a week since we haven't received anything from your side 😢 .
Come up with new ideas, create a new issue and make sure you finish it within a week! 🔥
All the best! 🚀
Happy Hacking! 💗

Hey @HarshP6421 ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇