text:
[Bug]: fix(vacuum): correctly state that vacuum was released in 0.5.6 not 0.6 (fixes #2956)

Description of changes
Change a single warning to correctly state the version where vacuum was introduced.
Test plan
No test needed this is only a string in a warning that is not tested.
Documentation Changes
Docstring updated, no change needed in other docs.

@Benzhaomin, you need to make some sort of a change on your code and push to make the PR title check pass. I suggest you rebase off the latest main and force push.

Thanks @tazarov, this should be ready to go now 🚀

authors: Benzhaomin tazarov

repo: chroma-core/chroma


text:
[ENH] Add new value type for spann posting lists

Description of changes
Summarize the changes made by this PR.

Improvements & Bug fixes

...

New functionality

...

Test plan
How are these changes tested?

[ ] Tests pass locally with pytest for python, yarn test for js, cargo test for rust

Documentation Changes
Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs repository?

#3022  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @sanketkedia and the rest of your teammates on  Graphite

Merge activity

Nov 13, 5:09 PM EST: A user started a stack merge that includes this pull request via Graphite.

source: gharchive/pull-request

license_type: permissive

license_source: github-api


text:
Next release

This is the next release of the chromatic action
This upgrades to the latest chromatic-cli package & adds support for the "preserve-missing" option

@tmeasday Do you think I can release this as v1? There are no breaking public facing changes.
But it does contain the major version bump of the chromatic-cli package.
If we choose to release this as v2, there's a high chance users won't get this update/improvement for months, since upgrading to new action releases is manual, and there's no update notifier from github AFAIK.
Personally I'm really tempted to just release this as v1, but I understand if you just want to be on the safe side, and tell users to upgrade when support requests come up.

testing here:
https://github.com/chromaui/storybook-composition/pull/1/commits/44972ba140501e01c8b697c4ccd1e2456a210062

Did you check in node_modules by accident?

@ghengeveld I'm not sure if there were any known breaking changes in v5 in the end, do you recall?

I'm OK with releasing as v1 if not.

The --only flag was changed, so technical that's a breaking change. Not really a big deal though because nobody will be using it. Also jsdom was removed but shouldn't be noticeable.

So let's ship as action v1.

I'm going to proceed and release as v1

Did you check in node_modules by accident?

No this is by design, we can't use the user's installed chromatic0cli version, because it could be incompatible, and they might not have 1 at all. We also don't want to install dependencies for the action, because that wastes about 17 seconds of time running the action. The fastest way to get an action to run, is if it has everything it needs checked in.

authors: ghengeveld ndelangen tmeasday

repo: chromaui/action

license: MIT


text:
replace "interface{}" with "any"

This PR replaces interface{} with any by running the command:
gofmt -w -r 'interface{} -> any' .

any appears in Go 1.18.

@alexandear I do appreciate what you're doing here, but this change makes it non-backwards compatible in general without really gaining anything other than a syntax change. Myself, I'm not a fan of backwards compatibility, but this seems like a superficial change that create hassles for users who may be stuck using a older version of Go. I know there are a number of different orgs, who for a number of different reasons, are stuck on Go 1.16 (or on even older versions of Go). This would force them to upgrade their entire Go toolchain to at least Go 1.18, which suffice to say, may not be possible due to compatibility with other packages/libs, or for any number of other reasons (political or otherwise).
That said, I'd be happy to consider integrating this kind of a change later this year after 1.21 or 1.22 next year, after Go 1.18+ has been out for a bit longer. It's worth noting that Go 1.17 received an update as recently as a few months ago, and is still being supported by the Go team.

@kenshaw thank you for the detailed explanation. chromedp already can't be compiled with go < 1.18. This explicitly states in the release notes.
Also, I tried to compile chromedp with go 1.17:
go1.17 build
# github.com/chromedp/chromedp
./eval.go:81:19: undefined: reflect.Pointer
./eval.go:84:9: undefined: reflect.Pointer

So, that's why I made the PR.

@alexandear I must have missed when this change happened. I've pushed a commit, and tagged it, reenabling support for Go 1.16.

My bad. I used reflect.Pointer without realizing that it is only available since go 1.18.

@ZekeLu not your fault. They changed the name from reflect.Ptr to reflect.Pointer in go1.18. I have no idea why. To be honest, looking at that code, I'm pretty sure I can rewrite it without relying on a specific reference to reflect.Ptr, but I don't have the time at the moment to bother. The fix I pushed earlier today is more than adequate for now.

reflect.Ptr still exists in Go 1.20. It's defined as const Ptr = Pointer

authors: ZekeLu alexandear kenshaw

repo: chromedp/chromedp

license: mit

license_source: bigquery


text:
scripts: skip schemathesis

Commenting-out schemathesis since it is giving too much problem in CI right now.
It fails randomly and after many retries it might pass.
We need to deploy a change in Cloud and this is preventing it.

@nicolasparada
Hi, could you, please share some information about how Schemathesis fails? I am keen to dig into it and improve the experience for you.

@Stranger6667 can you provide steps on how to run it locally with the latest image
I've ran it locally with
schemathesis/schemathesis          stable    462f59903e92   2 days ago     99.1MB

and
docker run --pull=always --rm --network=host -v $PWD:/spec:ro schemathesis/schemathesis:stable run --hypothesis-suppress-health-check=too_slow --header Authorization: --header X-Project-Token: --stateful=links --workers 8 /spec/open-api.yml --base-url=http://localhost:5000/

I couldn't get it to fail consistently but rather it was failing randomly

here is the log of what was failing internally
docker run --pull=always --rm -v /home/runner/work/calyptia-cloud/calyptia-cloud/spec/:/spec:ro redocly/openapi-cli lint /spec/open-api.yml
latest: Pulling from redocly/openapi-cli
ca7dd9ec2225: Pulling fs layer
4487691952c0: Pulling fs layer
206c50ffab46: Pulling fs layer
f6d4361cf153: Pulling fs layer
12cf46a8cd52: Pulling fs layer
aaed5f965b97: Pulling fs layer
0fa91aa56ecc: Pulling fs layer
36fba6be8742: Pulling fs layer
45b42[72](https://github.com/chronosphereio/calyptia-cloud/actions/runs/9066193873/job/24910174911#step:7:73)e5445: Pulling fs layer
f84a56b4bbc9: Pulling fs layer
...
f20db81c571f: Pull complete
f3bc862c431a: Pull complete
b61e6f1b7832: Pull complete
Digest: sha256:4d3d3f7ba56ed336f26fc71e7e2d125acf[73](https://github.com/chronosphereio/calyptia-cloud/actions/runs/9066193873/job/24910174911#step:7:74)a2b78f89f24be14edaf742ad1226
Status: Downloaded newer image for redocly/openapi-cli:latest
No configurations were provided -- using built in recommended configuration by default.

validating /open-api.yml...
[1] open-api.yml:2:1 at #/info

Info object should contain `license` field.

1 | openapi: 3.0.3
2 | info:
  | ^^^^
3 |   title: Calyptia Cloud API
4 |   version: "1.0"

Warning was generated by the info-license rule.

[2] open-api.yml:24:5 at #/tags/0/description

Tag object should contain `description` field.

22 |         default: "5000"
23 | tags:
24 |   - name: user
   |     ^^^^^^^^^^
25 |   - name: project
26 |   - name: token

Warning was generated by the tag-description rule.

[3] open-api.yml:25:5 at #/tags/1/description

Tag object should contain `description` field.

23 | tags:
24 |   - name: user
25 |   - name: project
   |     ^^^^^^^^^^^^^
26 |   - name: token
27 |   - name: membership

Warning was generated by the tag-description rule.

[4] open-api.yml:26:5 at #/tags/2/description

Tag object should contain `description` field.

24 | - name: user
25 | - name: project
26 | - name: token
08a9b9e8253e: Pull complete
Digest: sha256:c660bb6d4483e1bce92a37793b319e8525a983e4b0a4442d5a9dec9ef8b14d54
Status: Downloaded newer image for schemathesis/schemathesis:stable
======================= Schemathesis test session starts =======================
Schema location: file:///spec/open-api.yml
Base URL: http://localhost:5001
Specification version: Open API 3.0.3
Random seed: 402624790509195061149623[76](https://github.com/chronosphereio/calyptia-cloud/actions/runs/9066193873/job/24910174911#step:7:77)404454220239
Workers: 8
Collected API operations: 171
Collected API links: 20
API probing: ...
API probing: SUCCESS
Schema analysis: ...
Schema analysis: SKIP

/usr/local/lib/python3.12/site-packages/hypothesis/internal/conjecture/engine.py:231: HypothesisWarning: The recursion limit will not be reset, since it was changed from another thread or during execution of a test.
  with ensure_free_stackframes():
/usr/local/lib/python3.12/site-packages/hypothesis/internal/conjecture/engine.py:231: HypothesisWarning: The recursion limit will not be reset, since it was changed from another thread or during execution of a test.
  with ensure_free_stackframes():
/usr/local/lib/python3.12/site-packages/hypothesis/internal/conjecture/engine.py:231: HypothesisWarning: The recursion limit will not be reset, since it was changed from another thread or during execution of a test.
  with ensure_free_stackframes():
/usr/local/lib/python3.12/site-packages/hypothesis/internal/conjecture/engine.py:231: HypothesisWarning: The recursion limit will not be reset, since it was changed from another thread or during execution of a test.
  with ensure_free_stackframes():
/usr/local/lib/python3.12/site-packages/hypothesis/internal/conjecture/engine.py:231: HypothesisWarning: The recursion limit will not be reset, since it was changed from another thread or during execution of a test.
  with ensure_free_stackframes():
/usr/local/lib/python3.12/site-packages/hypothesis/internal/conjecture/engine.py:231: HypothesisWarning: The recursion limit will not be reset, since it was changed from another thread or during execution of a test.
  with ensure_free_stackframes():
/usr/local/lib/python3.12/site-packages/hypothesis/internal/conjecture/engine.py:231: HypothesisWarning: The recursion limit will not be reset, since it was changed from another thread or during execution of a test.
  with ensure_free_stackframes():
/usr/local/lib/python3.12/site-packages/hypothesis/internal/conjecture/engine.py:231: HypothesisWarning: The recursion limit will not be reset, since it was changed from another thread or during execution of a test.
  with ensure_free_stackframes():
............E..................................................................................................E...........................................................

==================================== ERRORS ====================================
___________ POST /v1/core_instances/{coreInstanceID}/cluster_objects ___________
Runtime Error

Unexpected error during testing of this API operation:
_____________________ POST /v1/projects/{projectID}/invite _____________________
Runtime Error

Unexpected error during testing of this API operation:

Add this option to your command line parameters to see full tracebacks: --show-trace

Need more help?
    Join our Discord server: https://discord.gg/R9ASRAmHnA
=================================== SUMMARY ====================================

Performed checks:
    not_a_server_error                    17005 / 17005 passed          PASSED

WARNINGS:
  - Most of the responses from `GET /v1/projects` have a 401 status code. Did you specify proper API credentials?
  - Most of the responses from `POST /v1/projects` have a 401 status code. Did you specify proper API credentials?
  - Most of the responses from `POST /v1/join_project` have a 401 status code. Did you specify proper API credentials?
  - Most of the responses from `POST /v1/agents` have a 401 status code. Did you specify proper API credentials?
  - Most of the responses from `POST /v1/aggregators` have a 401 status code. Did you specify proper API credentials?
  - Most of the responses from `POST /v1/config_validate_v2` have a 401 status code. Did you specify proper API credentials?
  - Most of the responses from `POST /v1/config_validate/{agentType}` have a 401 status code. Did you specify proper API credentials?

Tip: Use the `--report` CLI option to visualize test results via Schemathesis.io.
We run additional conformance checks on reports from public repos.

======================= 169 passed, 2 errored in 2[80](https://github.com/chronosphereio/calyptia-cloud/actions/runs/9066193873/job/24910174911#step:7:81).10s =======================
Error: Process completed with exit code 1.

@jasmingacic
I think you need to add the --show-trace CLI argument, but I am afraid that the issue only occurs when a certain branch in the schema is validated, and since this is a randomized process, it does not fail every time.
In any event, a stack trace from such a random failure would help + if you can link the tested schema it will help me to dig into it locally

Run ./scripts/setup-tests.sh
+++ dirname -- ./scripts/setup-tests.sh
++ cd -- ./scripts
++ pwd
+ SCRIPT_DIR=/home/runner/work/calyptia-cloud/calyptia-cloud/api/scripts
+ CLOUD_PORT=5000
+ CLOUD_EXPOSED_PORT=5001
+ CLOUD_URL=http://localhost:5001
+ CLOUD_IMAGE_TAG=main
+ CLOUD_IMAGE=ghcr.io/chronosphereio/calyptia-cloud/all-in-one@sha256:149a84dd7899e2c30244ee92a58919e3d204559fcccfaedc7d8d0fede1d4972d
+ TOKEN_DIR=/home/runner/work/calyptia-cloud/calyptia-cloud/api/scripts/resources
+ TOKENFILE=/home/runner/work/calyptia-cloud/calyptia-cloud/api/scripts/resources/token
+ TEST_AUTH0_DOMAIN=***
+ TEST_AUTH0_MANAGEMENT_CLIENT_ID=***
+ TEST_AUTH0_MANAGEMENT_CLIENT_SECRET=***
+ mkdir -p /home/runner/work/calyptia-cloud/calyptia-cloud/api/scripts/resources
+ rm -f /home/runner/work/calyptia-cloud/calyptia-cloud/api/scripts/resources/token
+ touch /home/runner/work/calyptia-cloud/calyptia-cloud/api/scripts/resources/token
+ chmod 666 /home/runner/work/calyptia-cloud/calyptia-cloud/api/scripts/resources/token
+ docker rm -f cloud
Error response from daemon: No such container: cloud
+ docker run --pull=always -d --name cloud -e AUTH0_DOMAIN=*** -e AUTH0_MANAGEMENT_CLIENT_ID=*** -e AUTH0_MANAGEMENT_CLIENT_SECRET=*** -e DEBUG=true -e DEFAULT_TOKEN_FILE=/token/token -v /home/runner/work/calyptia-cloud/calyptia-cloud/api/scripts/resources:/token:Z -p 5001:5000 ghcr.io/chronosphereio/calyptia-cloud/all-in-one@sha256:149a84dd7899e2c30244ee92a58919e3d204559fcccfaedc7d8d0fede1d4972d
ghcr.io/chronosphereio/calyptia-cloud/all-in-one@sha256:149a84dd7899e2c30244ee92a58919e3d204559fcccfaedc7d8d0fede1d4972d: Pulling from chronosphereio/calyptia-cloud/all-in-one
Digest: sha256:149a84dd7899e2c30244ee92a58919e3d204559fcccfaedc7d8d0fede1d4972d
Status: Image is up to date for ghcr.io/chronosphereio/calyptia-cloud/all-in-one@sha256:149a84dd7899e2c30244ee92a58919e3d204559fcccfaedc7d8d0fede1d4972d
204a3b3e2302fe72312475b16ba445777cc65fe8d28cd0ae42f7614d09a7a16e
+ echo 'Waiting for Cloud container to be ready'
Waiting for Cloud container to be ready
++ curl -sL --write-out '%{http_code}' http://localhost:5001/healthz -o /dev/null
+ [[ 000 -eq 200 ]]
+ echo -n .
+ sleep 1
++ curl -sL --write-out '%{http_code}' http://localhost:5001/healthz -o /dev/null
+ [[ 200 -eq 200 ]]
.
+ echo
+ echo 'Container responding'
+ echo 'Waiting for token to be created'
+ [[ -f /home/runner/work/calyptia-cloud/calyptia-cloud/api/scripts/resources/token ]]
+ echo
+ echo 'Found token file'
Container responding
Waiting for token to be created

Found token file
+++ dirname -- ./scripts/run-tests.sh
++ cd -- ./scripts
++ pwd
+ SCRIPT_DIR=/home/runner/work/calyptia-cloud/calyptia-cloud/api/scripts
+ CLOUD_URL=http://localhost:5001
+ SPEC_DIR=/home/runner/work/calyptia-cloud/calyptia-cloud/spec
+ WORKER_COUNT=8
+ TOKEN_DIR=/home/runner/work/calyptia-cloud/calyptia-cloud/api/scripts/resources
+ TOKENFILE=/home/runner/work/calyptia-cloud/calyptia-cloud/api/scripts/resources/token
+ [[ -z '' ]]
+ [[ ! -f /home/runner/work/calyptia-cloud/calyptia-cloud/api/scripts/resources/token ]]
++ cat /home/runner/work/calyptia-cloud/calyptia-cloud/api/scripts/resources/token
+ TOKEN=
+ docker run --pull=always --rm -v /home/runner/work/calyptia-cloud/calyptia-cloud/spec/:/spec:ro redocly/openapi-cli lint /spec/open-api.yml
latest: Pulling from redocly/openapi-cli
ca7dd9ec2225: Pulling fs layer
...
43b37876d8d6: Pull complete
746b8a833f6a: Pull complete
08a9b9e8253e: Pull complete
Digest: sha256:c660bb6d4483e1bce92a37793b319e8525a983e4b0a4442d5a9dec9ef8b14d54
Status: Downloaded newer image for schemathesis/schemathesis:stable
======================= Schemathesis test session starts =======================
Schema location: file:///spec/open-api.yml
Base URL: http://localhost:5001
Specification version: Open API 3.0.3
Random seed: 331763138746818265437434184712049282046
Workers: 8
Collected API operations: 171
Collected API links: 20
API probing: ...
API probing: SUCCESS
Schema analysis: ...
Schema analysis: SKIP

/usr/local/lib/python3.12/site-packages/hypothesis/internal/conjecture/engine.py:231: HypothesisWarning: The recursion limit will not be reset, since it was changed from another thread or during execution of a test.
  with ensure_free_stackframes():
/usr/local/lib/python3.12/site-packages/hypothesis/internal/conjecture/engine.py:231: HypothesisWarning: The recursion limit will not be reset, since it was changed from another thread or during execution of a test.
  with ensure_free_stackframes():
....E.............E........................................................................................................................................................

==================================== ERRORS ====================================
_____________________________ POST /v1/aggregators _____________________________
Runtime Error

HypothesisProvider.draw_string() got an unexpected keyword argument 'min_value'
_____________________ POST /v1/projects/{projectID}/tokens _____________________
Runtime Error

Unexpected error during testing of this API operation:

Add this option to your command line parameters to see full tracebacks: --show-trace

Need more help?
    Join our Discord server: https://discord.gg/R9ASRAmHnA
=================================== SUMMARY ====================================

Performed checks:
    not_a_server_error                    16894 / 16894 passed          PASSED

WARNINGS:
  - Most of the responses from `GET /v1/projects` have a 401 status code. Did you specify proper API credentials?
  - Most of the responses from `POST /v1/aggregators` have a 401 status code. Did you specify proper API credentials?
  - Most of the responses from `POST /v1/projects` have a 401 status code. Did you specify proper API credentials?
  - Most of the responses from `POST /v1/agents` have a 401 status code. Did you specify proper API credentials?
  - Most of the responses from `POST /v1/join_project` have a 401 status code. Did you specify proper API credentials?
  - Most of the responses from `POST /v1/config_validate_v2` have a 401 status code. Did you specify proper API credentials?
  - Most of the responses from `POST /v1/config_validate/{agentType}` have a 401 status code. Did you specify proper API credentials?

Tip: Use the `--report` CLI option to visualize test results via Schemathesis.io.
We run additional conformance checks on reports from public repos.

======================= 169 passed, 2 errored in 288.17s =======================
Error: Process completed with exit code 1.

this is what we were getting in the release pipeline

Thank you!

HypothesisProvider.draw_string() got an unexpected keyword argument 'min_value'

It is very helpful even without --show-trace! Looks like the second failure might benefit from it. However, I think the stack trace should always be displayed in such cases (I'll make the proper change)

Sorry for the delay, the issue will be fixed in the next release (was caused by a data race in a dependency).

authors: Stranger6667 jasmingacic nicolasparada

repo: chronosphereio/calyptia-api


text:
Enable searching for a card within the Kanban board

If you have several tasks/cards spread across multiple Kanban lists it can be difficult to find a specific card if you can't search for it by name.

Yep sounds like a nice idea, will release this shortly.

source: gharchive/issue

authors: bmazeraski chrskerr

repo: chrskerr/task-list-kanban


text:
Question mark in SQL

hello，everyone， What happens to SQL statements in Zipkin?

Has anyone met the problem of acquaintance,

repo: chuan-yun/Molten


text:
one_lin3r is a repository of security-related commands

Hi Igor,
I wonder if one-lin3r database of commands is worth inserting in cht.sh.
Pro:

Already organized by OS
Seems that the concepts covered are not yet addressed in cht.sh, and names don't collide

Con:

Uses Python class definitions, so migration might be more than simple formatting. But, I've seen worse.

https://github.com/D4Vinci/One-Lin3r/tree/master/one_lin3r/core/liners
Thanks, your weather command is lovely.

@matt-hayden Matt hi!
Wow! What a cool project! Thank you a lot for mentioning it. It is definitely worth binding to cheat.sh.
What do you think: at what namespace should it be bound?
Should it be just cheat.sh/one_lin3r? Or should it be distributed among the mentioned
commands, so that if you make say curl cheat.sh/ncat you'll find
the one_lin3r lines there too?
What do you think about it?

I don't have an affinity for the namespace one_lin3r because of the extra typing -- of course preserving credit to the author.
I believe that nmap is the only non-operating-system that's promoted to the "multi" catchall. I would demote it and duplicate it across BSD and Linux. nmap on Windows is not reliable enough to use in code, imho.

authors: chubin matt-hayden


text:
cd section fails in shell mode

Cannot use cd command to change my context for queries.
I think it's a regression to an old issue #73

Yes, it is a bug; I confirm it.

authors: chubin juliuswz


text:
Option for shorter output.

It would be great to have options for shorter/longer output. Like:
$ curl 'http://wttr.in/?now'

               Overcast
      .--.     64 °F
   .-(    ).   ↑ 18 mph
  (___.__)__)  9 mi
               0.0 in

Another one I would use is curl http://wttr.in/?week, where just a 5 day forecast it shown with only one row of output.
I'm sorry I don't have a pull request to go with this. I just wanted to put the idea out there.

You can get shorter output by using
curl -s -N http://wttr.in/Frankfurt | head -n 7

I believe this can be closed...
$ curl "http://wttr.in/?Q0"
      .-.      Light Rain
     (   ).    55 – 57 °F
    (___(__)   ↗ 6 mph
     ‘ ‘ ‘ ‘   8 mi
    ‘ ‘ ‘ ‘    0.0 in```

@nathan-v Right! Thank you for reminding me about this issue!! (and you don't need http:// actually).

Thanks, the 'number of days' thing is perfect.

Thank you @cjwelborn ! I hope to publish tomorrow another feature, that you like even more (I hope).

@chubin, awesome, I'm looking forward to it 😀.

authors: bndr chubin cjwelborn nathan-v


text:
In the alignment flow, if you upload samples, you have no indication whether are done unless you reload.

This is pretty minor.
At the least we should make it possible for the user to hit start alignment and the right things happens: the alignments wait for their respective copy jobs to be finished.

Alignment waits for status to be READY. (Or VERIFYING if #532 is implemented).

repo: churchlab/millstone


text:
Uploading samples can potentially create duplicates

We were using the "Upload Samples From Server" flow.  After creating the template pointing to the server locations, we pressed submit.  Upon reload, we observed that 2 samples had been created for each.  It's as if we pressed submit twice.
The code should prevent this from happening.

This was caused by duplicated listeners in JavaScript. Open specific bugs for where this is still happening.


text:
🛑 91家纺 is down

In 37b332d, 91家纺 (https://www.91jf.com/) was down:

HTTP code: 403
Response time: 1268 ms

Resolved: 找家纺网 is back up in c35d6dd after .

repo: chwang-team/status-hao


text:
🛑 91家纺 is down

In 205c336, 91家纺 (https://www.91jf.com/) was down:

HTTP code: 403
Response time: 1379 ms

Resolved: 找家纺网 is back up in e02e436 after .


text:
Lupusec: offlineList bzw. -count

Zunächst mal: Vielen Dank für die schnelle Implementierung des Lupusec-Adapters.
Ich frage mich allerdings, wie die Liste offlineList zustande kommt.

Meine Geräte sind alle online und eine Möglichkeit an "last contact" heranzukommen kann ich in den Objektdaten gar nicht erkennen.
Ich denke nicht, dass man dafür den Wert "ts" an den Datenpunkten heranziehen kann. Der dürfte lediglich den Zeitpunkt der letzten Änderung darstellen. Wenn ein Gerät aber z.B. seit Monaten fehlerfrei läuft, wird sich dieser Wert kaum ändern.

Der Wert "cond_ok" kann Werte von 0 (Fehler) und 1 (OK) annehmen.
Gruß
Bernd

Hallo danke für die Rückmeldung. Das müssen wir nun leider testen welcher Datenpunkt am besten geeignet ist für die zeit Angabe. Da es kein connected/reachable Datenpunkt gibt nimmt er den Zeitstempel vom rssi wert. Ich bin davon ausgegangen das der rssi wert regelmäßig aktualisiert wird (nicht geändert!). Evtl kannst du in Erfahrung bringen und mir berichten welcher Datenpunkt sich evtl regelmäßig aktualisiert. Der zuletzt geändert Zeitstempel wäre dabei egal. Ich danke dir schon mal.
Grüße Christian

Also zumindest wenn "cond_ok" = 1 könnte man den DP komplett als OK ansehen und bräuchte gar keinen zusätzlichen Zeitpunkt zu ermitteln. Der DP braucht dann nicht in die Liste "offlineList" aufgenommen werden.
Wenn "cond_ok" = 0 wird's möglicherweise kompliziert.
Ein Kontaktsensor wird ja mehr oder weniger regelmäßig aktualisiert. Da könnte man den ts vom DP "status" oder "status_ex" nehmen und schauen, wann der sich zuletzt erfolgreich aktualisiert hat.
Bei Geräten wie z.B. "Sirene" wird das schwierig. Solange das System korrekt aufgesetzt ist und keine Fehlalarme aufgetreten sind, hat sich der Status einer Sirene hoffentlich zuletzt vor ziemlich langer Zeit geändert. Ich habe da gerade keine Idee, wo man dann den ts hernehmen könnte.
Im Gegenteil: Das was ich so an "ts" an meinen Datenpunkten sehen kann, ist mehr oder weniger sinnfrei.
Der Kontaktsensor der Haustüre hat heute bereits mehrfach ausgelöst. Trotzdem steht im "ts" des DP "status_ex" ein Wert 1642757166569. Das kann vorne und hinten nicht stimmen.
Vielleicht kann der Entwickler des Adapters da Licht ins Dunkel bringen https://github.com/schmupu/ioBroker.lupusec
Mir persönlich würde es reichen, wenn ein Datenpunkt nur bei "cond_ok" = 0 in die Liste aufgenommen wird. Der Zeitpunkt ist dabei eher zweitrangig.

Ok danke für die Info. Werde es später, wenn Zeit ist, es hinzufügen und wenn man dann in Experten Einstellungen beim Adapter auf -1 stellt wird der Datenpunkt für die Erreichbarkeit genutzt.

Bitte mal updaten und testen ob es nun passt. Daher in den Settings unter Expert Settings danach mal bei Lupusec auf -1 stellen.  Wegen den Zeiten kann ich wohl erstmal nichts ändern, das liegt halt am Lupusec Adapter da er die Datenpunkte scheinbar nicht aktualisiert.

Ok super. Ähm nicht bewusst. Hab aber als Hauptpfad lupusec.*.rssi, sehe aber da ist auch ein rssi Objekt. Denke die Werte werden dann doppelt rausgesucht. Werde es nachher nochmal ändern und den Hauptpfad auf ein anderes Objekt legen.

Der richtige Pfad wäre vermutlich sowas wie "lupusec.x.devices.*", wobei die Schwierigkeit wahrscheinlich in der # der Instanz steckt. Bei mir ist es z.B. nicht die "0", sondern aufgrund eines Installationsfehlers die "1".
Bin zwar selbst Entwickler, aber JS ist jetzt nicht meine Kernkompetenz :-(
Vielleicht kann man das Durchlaufen des Baums auf die Objekte einschränken, die neben "rssi" auch ein "cond_ok" anbieten?

Ja genau, ich muss nur als Hauptpfad ein Datenpunkt nehmen den es nur einmal gibt. Das wäre in dem Fall der cond_ok. Hab es gestern nicht mehr geschafft, werde es aber heut Mittag ändern. Danach sollte hoffentlich alles wie gewünscht laufen. :)

Nur keine Eile ... dass Du das so schnell eingebaut hast nötigt mir auch so Respekt ab.

Alles gut, es ist nur eine Zeile ändern und eine andere hinzufügen, somit hält sich der Aufwand in Grenzen! :)
Hab es nun geändert und es sollte nun hoffentlich wie gewünscht laufen.

Cool ... so sieht das echt gut aus. Danke!


text:
Connection delays with 1.6 to 1.7 upgrade on a 100+ nodes k8s 1.16 cluster

Bug report
General Information

Cilium version (run cilium version)

root@ip-10-93-137-53:~# cilium version
Client: 1.7.9 e7ae39019 2020-09-01T18:39:45-07:00 go version go1.13.15 linux/amd64
Daemon: 1.7.9 e7ae39019 2020-09-01T18:39:45-07:00 go version go1.13.15 linux/amd64

Kernel version (run uname -a)

root@ip-10-93-137-53:~# uname -a
Linux ip-10-93-137-53 4.15.0-115-generic #116~16.04.1-Ubuntu SMP Wed Aug 26 17:36:48 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Orchestration system version in use (e.g. kubectl version, Mesos, ...)

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.3", GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"clean", BuildDate:"2020-05-21T14:50:54Z", GoVersion:"go1.14.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

Link to relevant artifacts (policies, deployments scripts, ...)
Generate and upload a system zip:
The cluster has company specific information. So not uploading sysdump.
cilium pod's init log to understand features enabled:
cilium_init.log

How to reproduce the issue
client: curl on a macbook
client ------TCP1----> ELB ------TCP2----> K8s worker ---FORWARD--> nginx worker ------> service pod
It appears that with cilium 1.7, TCP connection setup takes longer than usual. It can happen if k8s worker nodes are dropping TCP SYNs. In this case client (when bypassing ELB) or ELB has to retransmit the TCP SYNs resulting in the delay during the connection setup. TCP1 gets established quickly, but TCP2 gets delayed. This manifests as server hello being received after a delay on the client end.
With 1.7, we see delays in setting up of the connections from the k8s worker node participating in load-balancing traffic from ELB.
(⎈ |dev-c15a-labawsuse-admin:kube-system)curl_delay $ ./test.sh
14:36:11.542605 * Trying 2a0a:4b00:1f7:801e:ef41:502c:a5d:b4db:443...
14:36:11.543085 * TCP_NODELAY set
14:36:11.642760 * Connected to  (2a0a:4b00:1f7:801e:ef41:502c:a5d:b4db) port 443 (#0)
14:36:11.646086 * ALPN, offering http/1.1
14:36:11.663677 * successfully set certificate verify locations:
14:36:11.663734 * CAfile: /Users/nrana/opt/anaconda3/ssl/cacert.pem
CApath: none
14:36:11.664176 * TLSv1.3 (OUT), TLS handshake, Client hello (1):
14:36:17.371698 * TLSv1.3 (IN), TLS handshake, Server hello (2):
14:36:17.372159 * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
14:36:17.372291 * TLSv1.3 (IN), TLS handshake, Certificate (11):
14:36:17.373604 * TLSv1.3 (IN), TLS handshake, CERT verify (15):
14:36:17.373879 * TLSv1.3 (IN), TLS handshake, Finished (20):
14:36:17.373986 * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
14:36:17.374054 * TLSv1.3 (OUT), TLS handshake, Finished (20):

The pcap capture is from the nginx host. As we can see the TCP SYN itself reaches the node after 5 secs at 14:36:17 vs 14:36:11 when the client started the connection setup.
Test scripts used
This script keeps running curl and exits if there is a delay of more than 3 seconds.
cat test.sh
#!/bin/bash

if [[ $# -eq 0 ]];
then
    url="https://<fqdn>/echo"
else
    url=$1
fi

delay=3
while [ true ]
do
    start=`date +%s`
    curl -w "@curl-format.txt" -s --ipv4 --trace-time -v $url
    echo
    end=`date +%s`

    runtime=$((end-start))
    if [ $runtime -ge $delay ]
    then
        break
    fi
done

echo "Handshake took longer than $delay seconds: $runtime"
echo "exiting test..."

This following test bypasses AWS ELB and directly sends the request to the specified k8s worker node. That node forwards the request to the nginx k8s node (using kube-proxy iptables or cilium forwarding).
$ cat node-port.sh
#!/bin/bash
dip=$1
delay=3
scriptDuration=60
scriptStart=`date +%s`

while [ true ]
do
    start=`date +%s`
    curl -w "@curl-format.txt" -s --haproxy-protocol  -k --trace-time -v --resolve $host:30465:$dip https://$host:30465/inrotation.txt -H "Host: $host"
    end=`date +%s`
    runtime=$((end-start))
    if [ $runtime -ge $delay ]
    then
        echo "Handshake took longer than $delay seconds: $runtime"
        echo "exiting test..."
        break
    fi

    scriptRunTime=$((end-scriptStart))
    if [ $scriptRunTime -ge $scriptDuration ]
    then
        echo "Ran for $scriptDuration seconds successfully, exiting"
        break
    fi
done

This following test runs node-port.sh against all nodes of the cluster, bypassing ELB.
$ cat runTestAllNodes.sh
for node in $(kubectl get nodes -o wide | grep -v INT | grep -v master | awk '{print $6}')
do
    echo
    echo ">>> RUNNING on $node"
    ./node-port.sh $node
    echo "<<< DONE on $node"
done

runTestAllNodes.sh test result with cilium 1.7:
1.7-all-nodes-test.log.gz
$ grep time_app all-nodes-test.log | grep -v "0."
time_appconnect: 19.429814s
time_appconnect: 1.300437s
time_appconnect: 1.225390s
time_appconnect: 1.239791s
time_appconnect: 1.233259s
time_appconnect: 1.235974s
time_appconnect: 1.440181s
time_appconnect: 1.244038s
time_appconnect: 1.241509s
time_appconnect: 19.533314s
time_appconnect: 1.178103s
time_appconnect: 1.510683s
time_appconnect: 1.242825s
time_appconnect: 1.228714s
time_appconnect: 1.234639s
time_appconnect: 19.468425s
time_appconnect: 1.236721s
time_appconnect: 1.444458s
time_appconnect: 19.464529s
time_appconnect: 19.438658s
time_appconnect: 19.514127s
time_appconnect: 1.242912s
time_appconnect: 1.052972s
time_appconnect: 1.244528s
time_appconnect: 19.808824s
time_appconnect: 1.243116s
time_appconnect: 19.473240s
time_appconnect: 1.233405s
time_appconnect: 1.253107s
time_appconnect: 19.410588s
time_appconnect: 19.499735s
time_appconnect: 1.246178s
time_appconnect: 19.414737s
time_appconnect: 19.412350s
time_appconnect: 19.458430s
time_appconnect: 1.689954s
time_appconnect: 1.404454s
time_appconnect: 19.575672s
time_appconnect: 1.241366s
time_appconnect: 1.262291s
time_appconnect: 1.250611s
time_appconnect: 1.075596s
time_appconnect: 19.470899s
time_appconnect: 1.240626s
time_appconnect: 1.241299s
time_appconnect: 1.246301s
time_appconnect: 1.143131s
time_appconnect: 1.143642s
time_appconnect: 1.250771s
time_appconnect: 1.279985s
time_appconnect: 19.458716s
runTestAllNodes.sh test result with cilium 1.6:
1.6-all-nodes-test.log.gz
(⎈ |dev-c15a-labawsuse-admin:harness-delegate)curl_delay $ grep time_app 1.6-all-nodes-test.log | grep -v "0."
time_appconnect: 1.232426s
time_appconnect: 1.437736s
time_appconnect: 1.364282s
time_appconnect: 1.061703s
time_appconnect: 1.228092s
time_appconnect: 1.237797s
time_appconnect: 1.445933s
time_appconnect: 1.236047s
time_appconnect: 1.227650s
time_appconnect: 6.289174s
time_appconnect: 1.446460s
time_appconnect: 1.247768s
time_appconnect: 1.426705s
time_appconnect: 1.543135s
time_appconnect: 1.470899s
time_appconnect: 1.129491s
time_appconnect: 1.762592s
time_appconnect: 1.583169s
time_appconnect: 1.029330s
time_appconnect: 1.424878s
time_appconnect: 1.365455s
time_appconnect: 1.417927s
time_appconnect: 1.137588s
time_appconnect: 1.376337s
time_appconnect: 1.392282s
time_appconnect: 1.343857s
time_appconnect: 1.365737s
time_appconnect: 2.402398s
time_appconnect: 1.396372s
time_appconnect: 1.337604s
time_appconnect: 1.368370s
time_appconnect: 1.291826s
time_appconnect: 1.016252s
time_appconnect: 1.079500s
time_appconnect: 1.228793s
time_appconnect: 1.252302s
time_appconnect: 1.233515s
The curl client for the above tests was running on a mac book. We can see above that for cilium 1.7, client TCP connection setup to the k8s worker node is taking up to 19s. If we look at how a mac kernel's typical behavior for TCP SYNs retransmission, it seems that the 8th retransmitted packet makes it through.
This is evident from the retransmission behavior of Mac based TCP client as shown below in a sample packet capture. The default retransmission times for mac are : {1, 1, 1, 1, 1, 2, 4, 8, 16, 32, 64, 64, 64}
With Linux, the behavior is slightly different. The packets are retranmitted at {1, 3, 7, 15, 31, 65 }th seconds.
And if include ELB in the curl test, we observe server hello delays similar to the intervals above in our tests:
grep -B 1 "time_appconnect:  [1-9]" curl-delay.log
       time_connect:  0.101098s
    time_appconnect:  1.272165s
--
       time_connect:  0.099376s
    time_appconnect:  1.416461s
--
       time_connect:  0.104694s
    time_appconnect:  1.312507s
--
       time_connect:  0.116003s
    time_appconnect:  3.436879s
--
       time_connect:  0.098239s
    time_appconnect:  2.278533s
--
       time_connect:  0.111997s
    time_appconnect:  2.593224s
--
       time_connect:  0.108467s
    time_appconnect:  4.377752s
--
       time_connect:  0.101142s
    time_appconnect:  2.794053s
--
       time_connect:  0.123960s
    time_appconnect:  2.135441s
--
       time_connect:  0.135513s
    time_appconnect:  3.324246s
--
       time_connect:  0.131735s
    time_appconnect:  4.841471s
--
       time_connect:  0.100949s
    time_appconnect:  4.262275s
--
       time_connect:  0.110196s
    time_appconnect:  3.167280s
--
       time_connect:  0.105047s
    time_appconnect:  15.219555s
--
       time_connect:  0.106077s
    time_appconnect:  2.364657s
--
       time_connect:  0.101587s
    time_appconnect:  3.769322s
--
       time_connect:  0.113066s
    time_appconnect:  2.928472s
--
       time_connect:  0.124887s
    time_appconnect:  2.163788s
--
       time_connect:  0.141268s
    time_appconnect:  7.765396s
--
       time_connect:  0.114381s
    time_appconnect:  2.177919s
--
       time_connect:  0.136068s
    time_appconnect:  2.922563s
--
       time_connect:  0.112571s
    time_appconnect:  9.829308s
--
       time_connect:  0.371588s
    time_appconnect:  2.168459s
--
       time_connect:  0.102246s
    time_appconnect:  3.488918s
--
       time_connect:  0.290870s
    time_appconnect:  10.606300s
--
       time_connect:  0.104572s
    time_appconnect:  3.303413s

This indicates the ELB (most likely a linux based system) is also retransmitting TCP SYNs before it can get a successful TCP conn setup.

Hi @nr17 , thanks for the detailed report!
In the absence of a Cilium sysdump, I'm wondering about the other kinds of information we can get, for instance:

What kinds of services are involved here? I presume nodeport?
Are there any network policies in place?
Is it possible to gather cilium monitor output that captures evidence that packets are received to the k8s worker? If there were drops that are related to your specific flow, that would be ideal as it would give specific information about the drops, why, and context that Cilium has at the time.
Is it possible to reproduce the behaviour from within the cluster or from another IP behind the ELB which is not part of the cluster? For instance, can we tie it down to requests going through a specific worker's nodeport IP?
If one node's nodeport can be isolated to observe the problem, can we trace which backend the failing connections are translated to? What other info can we get here? If kube-proxy is involved, the iptables rules may have counters (iptables-save -c); There may be other info we can get from Cilium itself but it's a little hard to know exactly where to look without knowing how Cilium is configured.

More information inline:

What kinds of services are involved here? I presume nodeport?
We have a kubernetes Loadbalancer type and a clusterIP type service involved.
client -->ELB-->k8s loadbalancer service (nginx)--> clusterIP service

Are there any network policies in place?
yes. Most namespaces have a policy similar to the following anonymized example:

apiVersion: v1
items:
- apiVersion: cilium.io/v2
  kind: CiliumNetworkPolicy
  metadata:
    annotations:
    labels:
      heritage: Tiller
    name: harness-delegates
    namespace: harness-delegate
  specs:
  - egress:
    - toEndpoints:
      - matchLabels:
          k8s:io.kubernetes.pod.namespace: kube-system
          k8s:k8s-app: kube-dns
      toPorts:
      - ports:
        - port: "53"
          protocol: ANY
        rules:
          dns:
          - matchPattern: '*'
    - toServices:
      - k8sService:
          namespace: default
          serviceName: kubernetes
    - toFQDNs:
      - matchName: api.k8s.<cluster-fqdn>
      - matchName: <fqdn1>
      - matchName: <fqdn2>
      - matchName: <fqdn3>
      - matchName: <fqdn4>
      - matchPattern: '*.dev-fqdn5'
      - matchPattern: '*.dev-fqdn6'
      toPorts:
      - ports:
        - port: "443"
          protocol: TCP
    endpointSelector:
      matchLabels:
        app: <app-name>
        harness.io/name: <appl-name>-<cluster-name>
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Is it possible to gather cilium monitor output that captures evidence that packets are received to the k8s worker? If there were drops that are related to your specific flow, that would be ideal as it would give specific information about the drops, why, and context that Cilium has at the time.
That is the hardest part. Its difficult to pin-point which node out of 100+ nodes is experiencing packet drops.

Is it possible to reproduce the behaviour from within the cluster or from another IP behind the ELB which is not part of the cluster? For instance, can we tie it down to requests going through a specific worker's nodeport IP?
I did not try. I could reproduce it for the following 2 flows (with all 100+ nodes). I wasn't able to reproduce it consistently for a single K8s worker node, hence had to try it on all nodes (1 min for each node) using a script.

client ------TCP1----> ELB ------TCP2----> K8s worker ---FORWARD--> nginx worker ------> service pod
client ------TCP1------> K8s worker ---FORWARD--> nginx worker ------> service pod

If one node's nodeport can be isolated to observe the problem, can we trace which backend the failing connections are translated to? What other info can we get here? If kube-proxy is involved, the iptables rules may have counters (iptables-save -c); There may be other info we can get from Cilium itself but it's a little hard to know exactly where to look without knowing how Cilium is configured.
I shared part of the initialization log from one of the cilium pods in the issue. It should have the flags/configuration to know how cilium has been configured.

We have rolled back the cluster to 1.6 for now and plan to stay with 1.6 until this is resolved. I wasn't able to reproduce this in a smaller test cluster. I can try it on the test cluster once again.

I am able to reproduce the issue with the flow #2:
client ------TCP1------> K8s worker ---FORWARD--> nginx worker ------> service pod
The test needs to run for few minutes before it encounters the issue. The test exits immediately after letting this connection complete to help stop the capture at that point in time. I captured the packets on the "K8s worker" node, and can see the evidence of TCP SYNs retransmissions and that particular connection attempt getting dropped completely after 7 retransmissions. Subsequently, curl re-attempts the request with a new TCP connection which succeeds.
23612 304.086359254 10.23.255.238 → 10.93.161.68 TCP 80 53760 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=210721919 TSecr=0 SACK_PERM=1
23613 304.168508581 10.23.255.238 → 10.93.161.68 TCP 68 29920 → 31614 [ACK] Seq=765 Ack=7722 Win=131072 Len=0 TSval=210722002 TSecr=3794489633
23614 305.098603835 10.23.255.238 → 10.93.161.68 TCP 80 [TCP Retransmission] 53760 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=210722919 TSecr=0 SACK_PERM=1
23615 306.109386411 10.23.255.238 → 10.93.161.68 TCP 80 [TCP Retransmission] 53760 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=210723919 TSecr=0 SACK_PERM=1
23616 307.120093828 10.23.255.238 → 10.93.161.68 TCP 80 [TCP Retransmission] 53760 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=210724919 TSecr=0 SACK_PERM=1
23617 308.128123679 10.23.255.238 → 10.93.161.68 TCP 80 [TCP Retransmission] 53760 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=210725919 TSecr=0 SACK_PERM=1
23618 309.135991652 10.23.255.238 → 10.93.161.68 TCP 80 [TCP Retransmission] 53760 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=210726919 TSecr=0 SACK_PERM=1
23619 311.150821588 10.23.255.238 → 10.93.161.68 TCP 80 [TCP Retransmission] 53760 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=210728919 TSecr=0 SACK_PERM=1
23620 315.188178954 10.23.255.238 → 10.93.161.68 TCP 80 [TCP Retransmission] 53760 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=210732919 TSecr=0 SACK_PERM=1

23621 323.250723130 10.23.255.238 → 10.93.161.68 TCP 80 44211 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=210740920 TSecr=0 SACK_PERM=1
23622 323.251502277 10.93.161.68 → 10.23.255.238 TCP 76 31614 → 44211 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=8911 SACK_PERM=1 TSval=1892165730 TSecr=210740920 WS=512
23623 323.352478795 10.23.255.238 → 10.93.161.68 TCP 68 44211 → 31614 [ACK] Seq=1 Ack=1 Win=131456 Len=0 TSval=210741019 TSecr=1892165730
23624 323.368653443 10.23.255.238 → 10.93.161.68 TLSv1 585 Client Hello
23625 323.369390865 10.93.161.68 → 10.23.255.238 TCP 68 31614 → 44211 [ACK] Seq=1 Ack=518 Win=67072 Len=0 TSval=1892165848 TSecr=210741032
23626 323.370455949 10.93.161.68 → 10.23.255.238 TLSv1.3 2672 Server Hello, Change Cipher Spec, Application Data
23627 323.370496752 10.93.161.68 → 10.23.255.238 TCP 1560 31614 → 44211 [PSH, ACK] Seq=2605 Ack=518 Win=67072 Len=1492 TSval=1892165849 TSecr=210741032 [TCP segment of a reassembled PDU]
23628 323.379382848 10.93.161.68 → 10.23.255.238 TLSv1.3 2806 Application Data, Application Data, Application Data
23629 323.469962391 10.23.255.238 → 10.93.161.68 TCP 80 44211 → 31614 [ACK] Seq=518 Ack=1303 Win=130176 Len=0 TSval=210741135 TSecr=1892165849 SLE=3907 SRE=4097
23630 323.470048709 10.23.255.238 → 10.93.161.68 TCP 80 44211 → 31614 [ACK] Seq=518 Ack=2625 Win=128832 Len=0 TSval=210741135 TSecr=1892165849 SLE=3907 SRE=4097
23631 323.470095483 10.23.255.238 → 10.93.161.68 TCP 68 44211 → 31614 [ACK] Seq=518 Ack=4097 Win=127360 Len=0 TSval=210741135 TSecr=1892165849
23632 323.470138579 10.23.255.238 → 10.93.161.68 TCP 68 [TCP Window Update] 44211 → 31614 [ACK] Seq=518 Ack=4097 Win=131072 Len=0 TSval=210741135 TSecr=1892165849
23633 323.485364045 10.23.255.238 → 10.93.161.68 TCP 68 44211 → 31614 [ACK] Seq=518 Ack=6701 Win=128448 Len=0 TSval=210741143 TSecr=1892165858
23634 323.485443204 10.23.255.238 → 10.93.161.68 TCP 68 44211 → 31614 [ACK] Seq=518 Ack=6835 Win=130560 Len=0 TSval=210741143 TSecr=1892165858
23635 323.485488401 10.23.255.238 → 10.93.161.68 TLSv1.3 148 Change Cipher Spec, Application Data
23636 323.485532209 10.23.255.238 → 10.93.161.68 TLSv1.3 210 Application Data
23637 323.486221625 10.93.161.68 → 10.23.255.238 TCP 68 31614 → 44211 [ACK] Seq=6835 Ack=740 Win=68096 Len=0 TSval=1892165964 TSecr=210741144
23638 323.486379938 10.93.161.68 → 10.23.255.238 TLSv1.3 387 Application Data
23639 323.486459964 10.93.161.68 → 10.23.255.238 TLSv1.3 387 Application Data
23640 323.487670455 10.93.161.68 → 10.23.255.238 TLSv1.3 316 Application Data
23641 323.592865075 10.23.255.238 → 10.93.161.68 TCP 68 44211 → 31614 [ACK] Seq=740 Ack=7154 Win=130752 Len=0 TSval=210741257 TSecr=1892165965
23642 323.599854733 10.23.255.238 → 10.93.161.68 TCP 68 44211 → 31614 [ACK] Seq=740 Ack=7473 Win=130432 Len=0 TSval=210741257 TSecr=1892165965
23643 323.599924070 10.23.255.238 → 10.93.161.68 TCP 68 44211 → 31614 [ACK] Seq=740 Ack=7721 Win=130176 Len=0 TSval=210741257 TSecr=1892165966
23644 323.599975514 10.23.255.238 → 10.93.161.68 TLSv1.3 92 Application Data
23645 323.600019429 10.23.255.238 → 10.93.161.68 TCP 68 44211 → 31614 [FIN, ACK] Seq=764 Ack=7721 Win=131072 Len=0 TSval=210741260 TSecr=1892165966
23646 323.600840333 10.93.161.68 → 10.23.255.238 TCP 68 31614 → 44211 [FIN, ACK] Seq=7721 Ack=765 Win=68096 Len=0 TSval=1892166079 TSecr=210741258
23647 323.697888857 10.23.255.238 → 10.93.161.68 TCP 68 44211 → 31614 [ACK] Seq=765 Ack=7722 Win=131072 Len=0 TSval=210741361 TSecr=1892166079

When this happened, I was running "cilium monitor --type drop" on that node and it showed no drops. I'll look into iptables counters next.
@joestringer Are there any other commands I can run during the test to provide more information?

I traced the retransmitted packets using iptables TRACE target. Hopefully it gives some more insights on how packet is being processed.
19888 574.443786038 10.23.255.238 → 10.93.161.68 TCP 80 10847 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=214521137 TSecr=0 SACK_PERM=1
19889 574.574882611 10.23.255.238 → 10.93.161.68 TCP 68 [TCP Out-Of-Order] 38034 → 31614 [FIN, ACK] Seq=764 Ack=7722 Win=131072 Len=0 TSval=214521261 TSecr=1357157174
19890 575.493765422 10.23.255.238 → 10.93.161.68 TCP 80 [TCP Retransmission] 10847 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=214522137 TSecr=0 SACK_PERM=1
19891 576.524750576 10.23.255.238 → 10.93.161.68 TCP 80 [TCP Retransmission] 10847 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=214523137 TSecr=0 SACK_PERM=1
19892 577.561820855 10.23.255.238 → 10.93.161.68 TCP 80 [TCP Retransmission] 10847 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=214524137 TSecr=0 SACK_PERM=1
19893 578.472620454 10.23.255.238 → 10.93.161.68 TCP 80 [TCP Retransmission] 10847 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=214525137 TSecr=0 SACK_PERM=1
19894 579.465606343 10.23.255.238 → 10.93.161.68 TCP 80 [TCP Retransmission] 10847 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=214526138 TSecr=0 SACK_PERM=1
19895 581.482515465 10.23.255.238 → 10.93.161.68 TCP 80 [TCP Retransmission] 10847 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=214528138 TSecr=0 SACK_PERM=1
19896 585.563366172 10.23.255.238 → 10.93.161.68 TCP 80 [TCP Retransmission] 10847 → 31614 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=214532138 TSecr=0 SACK_PERM=1

cat 10847-drop-2.log
[6024175.564697] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000)
[6024175.564706] TRACE: mangle:PREROUTING:policy:1 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000)
[6024175.564712] TRACE: nat:PREROUTING:rule:1 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000)
[6024175.564789] TRACE: nat:KUBE-SERVICES:rule:135 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000)
[6024175.564796] TRACE: nat:KUBE-NODEPORTS:rule:11 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000)
[6024175.564801] TRACE: nat:KUBE-MARK-MASQ:rule:1 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000)
[6024175.564807] TRACE: nat:KUBE-MARK-MASQ:return:2 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000) MARK=0x4000
[6024175.564813] TRACE: nat:KUBE-NODEPORTS:rule:12 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000) MARK=0x4000
[6024175.564862] TRACE: nat:KUBE-SVC-SIHBGXESXOXE7DPQ:rule:5 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000) MARK=0x4000
[6024175.564873] TRACE: nat:KUBE-SEP-6BFXYBUSLTWBG63D:rule:2 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000) MARK=0x4000
[6024175.564883] TRACE: mangle:FORWARD:policy:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000) MARK=0x4000
[6024175.564888] TRACE: filter:FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000) MARK=0x4000
[6024175.564894] TRACE: filter:CILIUM_TRANSIENT_FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000) MARK=0x4000
[6024175.564898] TRACE: mangle:POSTROUTING:policy:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000) MARK=0x4000
[6024175.564902] TRACE: nat:POSTROUTING:rule:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000) MARK=0x4000
[6024175.564908] TRACE: nat:KUBE-POSTROUTING:rule:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC955310000000004020000) MARK=0x4000
[6024176.614685] TRACE: raw:PREROUTING:policy:3 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC959190000000004020000)
[6024176.614694] TRACE: mangle:PREROUTING:rule:1 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC959190000000004020000)
[6024176.614702] TRACE: mangle:CILIUM_PRE_mangle:return:4 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC959190000000004020000)
[6024176.614707] TRACE: mangle:PREROUTING:policy:2 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC959190000000004020000)
[6024176.614717] TRACE: mangle:FORWARD:policy:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC959190000000004020000)
[6024176.614722] TRACE: filter:FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC959190000000004020000)
[6024176.614728] TRACE: filter:CILIUM_FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC959190000000004020000)
[6024176.614732] TRACE: mangle:POSTROUTING:rule:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC959190000000004020000)
[6024176.614736] TRACE: mangle:CILIUM_POST_mangle:return:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC959190000000004020000)
[6024176.614740] TRACE: mangle:POSTROUTING:policy:2 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC959190000000004020000)
[6024177.645678] TRACE: raw:PREROUTING:policy:3 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC95D010000000004020000)
[6024177.645755] TRACE: mangle:PREROUTING:rule:1 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC95D010000000004020000)
[6024177.645793] TRACE: mangle:CILIUM_PRE_mangle:return:4 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC95D010000000004020000)
[6024177.645833] TRACE: mangle:PREROUTING:policy:2 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC95D010000000004020000)
[6024177.645879] TRACE: mangle:FORWARD:policy:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC95D010000000004020000)
[6024177.645918] TRACE: filter:FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC95D010000000004020000)
[6024177.645965] TRACE: filter:CILIUM_FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC95D010000000004020000)
[6024177.646003] TRACE: mangle:POSTROUTING:rule:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC95D010000000004020000)
[6024177.646052] TRACE: mangle:CILIUM_POST_mangle:return:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC95D010000000004020000)
[6024177.646091] TRACE: mangle:POSTROUTING:policy:2 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC95D010000000004020000)
[6024178.682745] TRACE: raw:PREROUTING:policy:3 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC960E90000000004020000)
[6024178.682754] TRACE: mangle:PREROUTING:rule:1 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC960E90000000004020000)
[6024178.682763] TRACE: mangle:CILIUM_PRE_mangle:return:4 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC960E90000000004020000)
[6024178.682768] TRACE: mangle:PREROUTING:policy:2 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC960E90000000004020000)
[6024178.682776] TRACE: mangle:FORWARD:policy:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC960E90000000004020000)
[6024178.682781] TRACE: filter:FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC960E90000000004020000)
[6024178.682787] TRACE: filter:CILIUM_FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC960E90000000004020000)
[6024178.682792] TRACE: mangle:POSTROUTING:rule:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC960E90000000004020000)
[6024178.682795] TRACE: mangle:CILIUM_POST_mangle:return:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC960E90000000004020000)
[6024178.682799] TRACE: mangle:POSTROUTING:policy:2 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC960E90000000004020000)
[6024179.593548] TRACE: raw:PREROUTING:policy:3 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC964D10000000004020000)
[6024179.593619] TRACE: mangle:PREROUTING:rule:1 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC964D10000000004020000)
[6024179.593658] TRACE: mangle:CILIUM_PRE_mangle:return:4 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC964D10000000004020000)
[6024179.593699] TRACE: mangle:PREROUTING:policy:2 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC964D10000000004020000)
[6024179.593739] TRACE: mangle:FORWARD:policy:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC964D10000000004020000)
[6024179.593780] TRACE: filter:FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC964D10000000004020000)
[6024179.593829] TRACE: filter:CILIUM_FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC964D10000000004020000)
[6024179.593865] TRACE: mangle:POSTROUTING:rule:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC964D10000000004020000)
[6024179.593905] TRACE: mangle:CILIUM_POST_mangle:return:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC964D10000000004020000)
[6024179.593942] TRACE: mangle:POSTROUTING:policy:2 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC964D10000000004020000)
[6024180.586536] TRACE: raw:PREROUTING:policy:3 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC968BA0000000004020000)
[6024180.586545] TRACE: mangle:PREROUTING:rule:1 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC968BA0000000004020000)
[6024180.586553] TRACE: mangle:CILIUM_PRE_mangle:return:4 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC968BA0000000004020000)
[6024180.586558] TRACE: mangle:PREROUTING:policy:2 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC968BA0000000004020000)
[6024180.586568] TRACE: mangle:FORWARD:policy:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC968BA0000000004020000)
[6024180.586573] TRACE: filter:FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC968BA0000000004020000)
[6024180.586579] TRACE: filter:CILIUM_FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC968BA0000000004020000)
[6024180.586583] TRACE: mangle:POSTROUTING:rule:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC968BA0000000004020000)
[6024180.586587] TRACE: mangle:CILIUM_POST_mangle:return:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC968BA0000000004020000)
[6024180.586591] TRACE: mangle:POSTROUTING:policy:2 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC968BA0000000004020000)
[6024182.603466] TRACE: raw:PREROUTING:policy:3 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9708A0000000004020000)
[6024182.603484] TRACE: mangle:PREROUTING:rule:1 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9708A0000000004020000)
[6024182.603500] TRACE: mangle:CILIUM_PRE_mangle:return:4 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9708A0000000004020000)
[6024182.603511] TRACE: mangle:PREROUTING:policy:2 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9708A0000000004020000)
[6024182.603529] TRACE: mangle:FORWARD:policy:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9708A0000000004020000)
[6024182.603540] TRACE: filter:FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9708A0000000004020000)
[6024182.603552] TRACE: filter:CILIUM_FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9708A0000000004020000)
[6024182.603561] TRACE: mangle:POSTROUTING:rule:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9708A0000000004020000)
[6024182.603570] TRACE: mangle:CILIUM_POST_mangle:return:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9708A0000000004020000)
[6024182.603578] TRACE: mangle:POSTROUTING:policy:2 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9708A0000000004020000)
[6024186.684312] TRACE: raw:PREROUTING:policy:3 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9802A0000000004020000)
[6024186.684320] TRACE: mangle:PREROUTING:rule:1 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9802A0000000004020000)
[6024186.684327] TRACE: mangle:CILIUM_PRE_mangle:return:4 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9802A0000000004020000)
[6024186.684332] TRACE: mangle:PREROUTING:policy:2 IN=eth0 OUT= MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=10.93.161.68 LEN=64 TOS=0x00 PREC=0x00 TTL=56 ID=0 DF PROTO=TCP SPT=10847 DPT=31614 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9802A0000000004020000)
[6024186.684340] TRACE: mangle:FORWARD:policy:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9802A0000000004020000)
[6024186.684345] TRACE: filter:FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9802A0000000004020000)
[6024186.684350] TRACE: filter:CILIUM_FORWARD:rule:1 IN=eth0 OUT=cilium_host MAC=02:ed:1c:0f:e6:e7:02:38:31:84:2b:d5:08:00 SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9802A0000000004020000)
[6024186.684354] TRACE: mangle:POSTROUTING:rule:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9802A0000000004020000)
[6024186.684358] TRACE: mangle:CILIUM_POST_mangle:return:1 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9802A0000000004020000)
[6024186.684362] TRACE: mangle:POSTROUTING:policy:2 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9802A0000000004020000)

Last trace is
[6024186.684362] TRACE: mangle:POSTROUTING:policy:2 IN= OUT=cilium_host SRC=10.23.255.238 DST=100.96.26.110 LEN=64 TOS=0x00 PREC=0x00 TTL=55 ID=0 DF PROTO=TCP SPT=10847 DPT=443 SEQ=1689139364 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040522010303060101080A0CC9802A0000000004020000)

100.96.26.110 is the IP of nginx pod.

After some more investigation, it seems that the TCP SYN from forwarding node to nginx node is not getting SNATed correctly.
These are the captures on the nginx node. 10.93.161.68 is the forwarding k8s worker node. 100.96.26.226 is nginx pod IP. 100.96.17.151 is IP address for cilium_host on 10.93.161.68.
successful case:
48 12.529057171 100.96.17.151 → 100.96.26.226 TCP 78 13608 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=221834283 TSecr=0 SACK_PERM=1
49 12.529154288 100.96.26.226 → 100.96.17.151 TCP 74 443 → 13608 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=8911 SACK_PERM=1 TSval=97765904 TSecr=221834283 WS=512
50 12.630578764 100.96.17.151 → 100.96.26.226 TCP 66 13608 → 443 [ACK] Seq=1 Ack=1 Win=131456 Len=0 TSval=221834377 TSecr=97765904

Drop case
 4792 49.822231806 10.93.161.68 → 100.96.26.226 TCP 78 43769 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=220206027 TSecr=0 SACK_PERM=1
 4794 50.855973114 10.93.161.68 → 100.96.26.226 TCP 78 [TCP Retransmission] 43769 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=220207045 TSecr=0 SACK_PERM=1
 4795 51.230273318 10.93.161.68 → 100.96.26.226 TCP 78 [TCP Retransmission] 43769 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=220207416 TSecr=0 SACK_PERM=1
 4796 51.606858775 10.93.161.68 → 100.96.26.226 TCP 78 [TCP Retransmission] 43769 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=220207787 TSecr=0 SACK_PERM=1
 4799 51.997835574 10.93.161.68 → 100.96.26.226 TCP 78 [TCP Retransmission] 43769 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=220208158 TSecr=0 SACK_PERM=1
 4800 52.362804211 10.93.161.68 → 100.96.26.226 TCP 78 [TCP Retransmission] 43769 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=220208529 TSecr=0 SACK_PERM=1
 4801 52.904911224 10.93.161.68 → 100.96.26.226 TCP 78 [TCP Retransmission] 43769 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=220209065 TSecr=0 SACK_PERM=1
 4802 53.991603095 10.93.161.68 → 100.96.26.226 TCP 78 [TCP Retransmission] 43769 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=220210137 TSecr=0 SACK_PERM=1
 4803 56.153149627 10.93.161.68 → 100.96.26.226 TCP 78 [TCP Retransmission] 43769 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=220212281 TSecr=0 SACK_PERM=1

iptables TRACE log in the previous comment should be helpful for further investigation (Note that it is for a different dropped TCP connection).

It seems the root cause is a periodic flush of iptables, perhaps initiated by garbageCollect()
In drop case, there is no cilium specific iptable rule in PREROUTING chain of mangle table to forward the packet to the custom CILIUM_PRE_mangle chain. This condition happens for a very brief moment causing the incoming TCP SYN packet to be processed in an unintended manner.

SYN-port-fail-56344.log
SYN-port-succ-48055.log
Attached iptables TRACE logs for successful and drop cases.

Possible commit which introduced the issue: https://github.com/cilium/cilium/commit/3285cbc53fb41913e6d20fad38667b12961b47ad
https://github.com/cilium/cilium/commit/3285cbc53fb41913e6d20fad38667b12961b47ad#diff-e487db840fd85b399fd8893b55e0ac17R327 This line causes reinitialization of iptables (delete + create). This leads to the TCP SYN getting forwarded with “node’s host IP” instead of cilium_host IP to the k8s target pod when it arrives at that point of time. All the retransmissions also get forwarded the same way. e.g.
10.93.161.68 → 100.96.26.226 TCP 78 47137 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1314 WS=64 TSval=219260225 TSecr=0 SACK_PERM=1

We are using 4.15 kernel and see the following lines in cilium
4715 level=debug msg="Detected IPCache delete operation support: true" subsys=map-ipcache
4716 level=debug msg="Detected IPCache dump operation support: false" subsys=map-ipcache
4717 level=info msg="Periodic IPCache map swap will occur due to lack of kernel support for LPM delete operation. Upgrade to Linux 4.15 or higher to avoid this." subsys=map-ipcache

As a work-around, I believe that using 4.16 (or above) kernel will avoid the call to TriggerReloadWithoutCompile() and this issue can be avoided.

I ran the same tests with the newer kernel and the issue was not observed with kernel 5.4.0.

repo: cilium/cilium


text:
Documentation: Provide a migration guide for replacing calico with cilium

Proposal / RFE
Quite often in Slack we're facing questions about how to migrate from Calico --> Cilium. As our Docs are providing installation guides basically only for greenfield setups (apart from the CNI chaining instructions), this most likely isn't reflecting the reality with k8s Cluster running in staging and prod environments out there in the wild with other CNIs than Cilium.
Proposal is to provide a step-by-step migration guide which is as smooth as possible.
Referring to this conversation

@muffin87 @brandshaide he just had this blogpost submitted https://cilium.io/blog/2020/10/06/skybet-cilium-migration

I think that the referred blog post should provide the necessary context to resolve this question. If you try this out and find there are any other interesting discussion points or issues, then feel free to post your observations on this issue below, or file a new issue.
Closing.

authors: aanm brandshaide joestringer


text:
Unable to configure TLS for hubble-ui frontend (nginx)

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
Currently hubble-ui frontend (nginx) configuration is hardcoded in templates thus it is impossible to reconfigure it to listen on secure port.
expected behaviour:
Hubble-ui frontend (nginx) configuration can be overridden from values file, at least ssl configuration.
Cilium Version
1.13.x, 1.14.x
Kernel Version
N/A
Kubernetes Version
N/A
Sysdump
No response
Relevant log output
No response
Anything else?
No response
Code of Conduct

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

Thanks for the report, I think it would make sense to make this configurable.

This is still actual issue, please reopen....

authors: joestringer riuvshyn


text:
CI: runtime.RuntimeFQDNPolicies Enforces ToFQDNs policy

Top 2 errors/warnings:
Failed to re-allocate IP of endpoint. Not restoring endpoint.
Detected allocation CIDR change to 10.1.0.0/16, previous router IP 10.15.0.1

Expected command: docker exec -i  app1 curl -s  -D /dev/stderr --output /dev/stderr -w '%{http_code}' --connect-timeout 5 http://world1.cilium.test

These flakes happen because cilium somehow uses the cilium_host interface IP to
create the CIDR allocation range. This then blocks endpoint restores and causes
connect timeouts (perhaps it also deletes routes).
A bad situation looks like:
Apr 08 22:41:01 runtime cilium-agent[30203]: level=info msg="Initializing node addressing" subsys=daemon
Apr 08 22:41:01 runtime cilium-agent[30203]: level=info msg="Restored IPv4 internal node IP: 10.15.0.1" subsys=node
Apr 08 22:41:01 runtime cilium-agent[30203]: level=info msg="Using autogenerated IPv4 allocation range" subsys=node v4Prefix=10.1.0.0/16
Apr 08 22:41:01 runtime cilium-agent[30203]: level=info msg="Using autogenerated IPv6 allocation range" subsys=node v6Prefix="f00d::a01:0:0:0/96"
Apr 08 22:41:01 runtime cilium-agent[30203]: level=info msg="Initializing IPAM" subsys=daemon v4Prefix=10.1.0.0/16 v6Prefix="f00d::a01:0:0:0/112"

Where the IPV4 is set to the correct one: 10.15.0.1, but the allocation range
is to 10.1.0.0, a correct situation, should allocate the CIDR 10.15.0.0
Apr 08 22:20:46 runtime cilium-agent[10958]: level=info msg="Initializing node addressing" subsys=daemon
Apr 08 22:20:46 runtime cilium-agent[10958]: level=info msg="Restored IPv4 internal node IP: 10.15.0.1" subsys=node
Apr 08 22:20:46 runtime cilium-agent[10958]: level=info msg="Using autogenerated IPv4 allocation range" subsys=node v4Prefix=10.15.0.0/16
Apr 08 22:20:46 runtime cilium-agent[10958]: level=info msg="Using autogenerated IPv6 allocation range" subsys=node v6Prefix="f00d::a0f:0:0:0/96"
Apr 08 22:20:46 runtime cilium-agent[10958]: level=info msg="Initializing IPAM" subsys=daemon v4Prefix=10.15.0.0/16 v6Prefix="f00d::a0f:0:0:0/112"

The callgraph for the bad case looks like:
daemon/damon.go:NewDaemon()
    pkg/node/node_address.go:Autocomplete() (daemon/daemon.go:1083)
        Restored IPv4 internal node IP (pkg/node/node_address.go:233)
        SetIntervalIPv4(10.15.0.1) (pkg/node/node_address.go:234)
        If option.Config.Device == “undefined”
          InitDefaultprefix() (pkg/node/node_address.go:244)
          Using autogenerated IPv4 allocation range (pkg/node/node_address.go:97)

The fix for this can be change InitDefaultprefix() to use GetInternalIPv4()
(and IPv6), but André mentioned that this can be a problem in the Kubernetes
case, where in the past, the cilium_host cause a lot of trouble on PodCIDR
assigned by Kubelet.
Simple solution to avoid the flake is to use the following
https://github.com/cilium/cilium/pull/7665, this is ok to avoid other flakes,
but the behavior is not the right one for the test.
Code that affect this:
AutoComplete:
https://github.com/cilium/cilium/blob/cde6e43e00ff5411934ef6dc78705233a526a571/pkg/node/node_address.go#L226-L256
InitDefaultPrefix:
https://github.com/cilium/cilium/blob/cde6e43e00ff5411934ef6dc78705233a526a571/pkg/node/node_address.go#L67-L99
firstGlobalV4Addr function
https://github.com/cilium/cilium/blob/cde6e43e00ff5411934ef6dc78705233a526a571/pkg/node/node_address_linux.go#L29-L54
Also happens in IPv6, so need to be fixed in both places.

Hi!
I was checking, and there is no way that the IP change, in the firstGlobalV4Addr
always is returned the first IP, but in the bad cases the ip for the enp0s8 is
returned and things can't be restored correctly.
So, the netlink library is always correct, but we just found that in one failed
case the ip a show is not sorted by the ifindex, so the IP returned is not the
correct one, so endpoint CIDR mismatch and things started to fail.
Here is the IP add list, see the diference for the ifindex:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
258: br-4c9f0ef10b49: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ba:f0:7b:4b brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-4c9f0ef10b49
       valid_lft forever preferred_lft forever
    inet6 fe80::42:baff:fef0:7b4b/64 scope link
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:05:1d:ad brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 84101sec preferred_lft 84101sec
    inet6 fe80::a00:27ff:fe05:1dad/64 scope link
       valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:b6:5e:81 brd ff:ff:ff:ff:ff:ff
    inet 172.28.128.3/24 brd 172.28.128.255 scope global dynamic enp0s8
       valid_lft 701sec preferred_lft 701sec
    inet6 fe80::a00:27ff:feb6:5e81/64 scope link
       valid_lft forever preferred_lft forever
260: veth0ff3e2f@if259: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-4c9f0ef10b49 state UP group default
    link/ether 06:20:09:7b:27:44 brd ff:ff:ff:ff:ff:ff link-netnsid 4
    inet6 fe80::420:9ff:fe7b:2744/64 scope link
       valid_lft forever preferred_lft forever
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:4f:c0:b0:c6 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:4fff:fec0:b0c6/64 scope link
       valid_lft forever preferred_lft forever
262: veth6e20d9f@if261: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-4c9f0ef10b49 state UP group default
    link/ether 42:19:bf:e0:cd:8c brd ff:ff:ff:ff:ff:ff link-netnsid 5
    inet6 fe80::4019:bfff:fee0:cd8c/64 scope link
       valid_lft forever preferred_lft forever
6: veth230b97e@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether ca:e5:8b:c4:15:a8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::c8e5:8bff:fec4:15a8/64 scope link
       valid_lft forever preferred_lft forever
264: veth43955a4@if263: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-4c9f0ef10b49 state UP group default
    link/ether f6:dc:30:c7:32:c7 brd ff:ff:ff:ff:ff:ff link-netnsid 6
    inet6 fe80::f4dc:30ff:fec7:32c7/64 scope link
       valid_lft forever preferred_lft forever
8: veth9884bd0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether 9e:32:0d:1b:37:ce brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet6 fe80::9c32:dff:fe1b:37ce/64 scope link
       valid_lft forever preferred_lft forever
266: veth1d3d1f0@if265: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-4c9f0ef10b49 state UP group default
    link/ether 5e:66:6d:28:07:b0 brd ff:ff:ff:ff:ff:ff link-netnsid 7
    inet6 fe80::5c66:6dff:fe28:7b0/64 scope link
       valid_lft forever preferred_lft forever
10: veth99215c3@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether 2a:72:5b:f2:98:8c brd ff:ff:ff:ff:ff:ff link-netnsid 2
    inet6 fe80::2872:5bff:fef2:988c/64 scope link
       valid_lft forever preferred_lft forever
268: vethe9513d2@if267: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-4c9f0ef10b49 state UP group default
    link/ether da:58:38:de:33:d9 brd ff:ff:ff:ff:ff:ff link-netnsid 8
    inet6 fe80::d858:38ff:fede:33d9/64 scope link
       valid_lft forever preferred_lft forever
13: cilium_vxlan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 92:ed:a7:ab:af:97 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::90ed:a7ff:feab:af97/64 scope link
       valid_lft forever preferred_lft forever
270: vetha9c9714@if269: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-4c9f0ef10b49 state UP group default
    link/ether ba:85:67:8b:63:4d brd ff:ff:ff:ff:ff:ff link-netnsid 9
    inet6 fe80::b885:67ff:fe8b:634d/64 scope link
       valid_lft forever preferred_lft forever
272: vethc0d9c02@if271: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether 26:e6:5f:07:4c:6f brd ff:ff:ff:ff:ff:ff link-netnsid 10
    inet6 fe80::24e6:5fff:fe07:4c6f/64 scope link
       valid_lft forever preferred_lft forever
274: lxc740cbf5e292e@if273: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether c6:ea:80:71:ea:84 brd ff:ff:ff:ff:ff:ff link-netnsid 11
    inet6 fe80::c4ea:80ff:fe71:ea84/64 scope link
       valid_lft forever preferred_lft forever
276: lxceaa38f1c3b4a@if275: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 12:51:0c:39:32:a9 brd ff:ff:ff:ff:ff:ff link-netnsid 12
    inet6 fe80::1051:cff:fe39:32a9/64 scope link
       valid_lft forever preferred_lft forever
278: lxc0a7247ef75bf@if277: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether f2:ed:66:e9:48:fa brd ff:ff:ff:ff:ff:ff link-netnsid 13
    inet6 fe80::f0ed:66ff:fee9:48fa/64 scope link
       valid_lft forever preferred_lft forever
280: lxcf2f622517713@if279: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether f6:91:44:d3:db:df brd ff:ff:ff:ff:ff:ff link-netnsid 14
    inet6 fe80::f491:44ff:fed3:dbdf/64 scope link
       valid_lft forever preferred_lft forever
282: lxc9b64e1d37de0@if281: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 96:f4:1b:9b:4b:7b brd ff:ff:ff:ff:ff:ff link-netnsid 15
    inet6 fe80::94f4:1bff:fe9b:4b7b/64 scope link
       valid_lft forever preferred_lft forever
284: lxccadd15f2693f@if283: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 7a:25:e5:e0:68:d5 brd ff:ff:ff:ff:ff:ff link-netnsid 16
    inet6 fe80::7825:e5ff:fee0:68d5/64 scope link
       valid_lft forever preferred_lft forever
285: cilium_net@cilium_host: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 7e:dd:f2:9d:05:a2 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::7cdd:f2ff:fe9d:5a2/64 scope link
       valid_lft forever preferred_lft forever
286: cilium_host@cilium_net: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether b6:00:75:c9:7a:b6 brd ff:ff:ff:ff:ff:ff
    inet 10.1.0.1/32 scope link cilium_host
       valid_lft forever preferred_lft forever
    inet6 fc00::10ca:1/128 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::b400:75ff:fec9:7ab6/64 scope link
       valid_lft forever preferred_lft forever
288: cilium_health@if287: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether e2:03:66:60:ce:e7 brd ff:ff:ff:ff:ff:ff link-netns cilium-health
    inet6 fe80::e003:66ff:fe60:cee7/64 scope link
valid_lft forever preferred_lft forever

This can be possible due to the changes that we have made in the IPRoute from
late Febrary in the base box?
https://github.com/cilium/packer-ci-build/commit/630f84944b89888b0b23bea0d092bce872c5d7c9
https://github.com/cilium/packer-ci-build/commit/011130367f7479a135431f43d1d84f4861551ffc
Open questions
Should these be sorted by IFindex the firstGlobalV4Addr address?
Can this be a issue with our iproute version?
Best,
Eloy

authors: eloycoto tgraf


text:
[v1.8] helm: Fix preflight check resource quota conflict

Custom backport due to different Helm templates on v1.8.

#14295 -- helm: Fix preflight check resource quota conflict (@gandro)

Once this PR is merged, you can update the PR labels via:
$ for pr in 14295; do contrib/backporting/set-labels.py $pr done 1.8; done

test-backport-1.8

test-upstream-k8s

authors: aanm gandro


text:
workflows: fix permissions

contents permission is required to be able to access the repository with actions/checkout. It worked incidentally because the repo is public but let's make it cleaner.
pull-requests permission is required to allow retrieving information from the PR API. Likewise, it worked incidentally only because the repo is public.

@aanm I don't think this PR needs to be backported considering it only affects CI 3.0 jobs, which are not present in any stable branch. Removing labels.


text:
Add a note about conflicting node CIDRs #20204

Fixes #20204
Signed-off-by: Wojtek Czekalski me@wczekalski.com
Please ensure your pull request adheres to the following guidelines:

[x] For first time contributors, read Submitting a pull request
[x] All code is covered by unit and/or runtime tests where feasible.
[x] All commits contain a well written commit description including a title,
description and a Fixes: #XXX line if the commit addresses a particular
GitHub issue.
[x] All commits are signed off. See the section Developer’s Certificate of Origin
[x] Provide a title or release-note blurb suitable for the release notes.
[x] Thanks for contributing!

Fixes: #20204
I am not a great doc writer but I hope this is enough to get the ball rolling. My team collectively spent 1 day debugging this so I hope we can save others from it.

Could you please squash all commits into a single commit?

Done.
Thanks everyone for the quick turnaround. Such open source leadership makes me really bullish about the project!