text:
RFC: Per-reconciler leader election (and leader-aware reconcilers)

/area API
/kind cleanup
I've been thinking a bit about leader election, and the way we run things today we basically allocate N backup pods that wait to become the leader and effectively do nothing until they become the leader, they are essentially there as scheduling reservations.
How we achieve this is by wrapping the entire controller bootstrap process in a giant resource lock, which kicks things off when it acquires the lock and terminates the process if it should lose it.  This means that our Reconcilers get no benefit from horizontal scaling because no load is spread, and in fact they pay a penalty of having to also run the leader election logic as well.
Given 10 reconcilers living in a single controller, by leader electing at the pod level, leader failovers result in a standby pod spinning up 10 reconcilers worth of state before they can become functional again.  Given that we build none of that state in advance, it doesn't seem like a particularly hot failover.

The tl;dr of what I've been considering is this:

Have per controller.Impl / Reconciler leaders
Run all of the informers and controllers, eliding* reconciliation when not the leader.
When we become the leader, global resync.

* - We may want to run leaderelection-aware reconcilers even when not the leader, e.g. if the resources program routing information for an admission control webhook.
The cons of this approach are:

Higher resource utilization for non-leader pods because they have the full informer cache.
A multiple on the number of leader locks we would need, and a corresponding increase in API Server load.

The pros of this approach are:

Leaders can be spread across replicas, so instead of having 10 on the single leader, if I run 3 replicas, I might only run 3-4 reconcilers per Pod.  So our controllers start to see benefits from horizontal scaling.
Hot failovers, which best case cost O(nop global resync).  This is amplified by the above because generally fewer things should be failing over each time a pod fails.

I think it'd be interesting to try this with our webhooks, which don't currently perform leader election, and in some cases (e.g. Bindings), need the informer cache to program the webhook.  If we decide to move ahead with this approach, then I think we should probably integrate with the // +genreconciler work, which I believe should have all of the information to do all(?) of the heavy lifting for (now) the vast majority of our reconcilers.
I'd love to try this out, but my schedule is chaotic and I don't want to be a bottleneck if others have time and are interested.
cc @pmorie @markusthoemmes @dprotaso @vaikas @vagababov for thoughts (LMK if I am missing any pros/cons)

Here some random thoughts:

how long does it take for a pod with 10 controllers to be functional? If it less than 2 or 3 seconds, then plain k8s pod restart might be faster than Knative HA feature. Do we know?
for worker node upgrade scenario where graceful pod termination is possible, the active pod can wait for the passive pod to become active before terminating. In that case, there is no need for hot failover. BTW, I don't think our controllers support this scenario, do they?

@lionelvillard they do via leader election. There's more to it apart from just hot failover though. For instance, it "reserves" (as-in: runs) a second pod to make sure capacity constraints don't cause the pod to not be able to come up again after a crash.

how long does it take for a pod with 10 controllers to be functional?

This is what we have today (disabled by default), and part of my concern is that this is strictly more expensive than a global resync.

then plain k8s pod restart might be faster

This cannot possibly be true because when the Pod restarts it needs to start the same 10 controllers.

for worker node upgrade scenario where graceful pod termination is possible, the active pod can wait for the passive pod to become active before terminating

This is orthogonal, but plausible.  I think we could achieve this by directing the leaderelection code to have the leader stop renewing its lease once it gets the interrupt.  It will keep reconciling until it becomes the leader, and once it isn't the leader (in this proposal, anywhere) it can terminate.

By faster I meant that k8s pod restart kicks in before Knative leaders have time to react. I did some experiments with the MT ping source adapter, reconciling 1000 resources (fairly small I admit), and most (all?) of time the passive pod never becomes active after the active pod is gracefully killed.
Should I open an issue for the worker node update scenario?

In general, this makes sense.
Though the way losing lease now leads to a restart makes it a bit awkward (do we still restart? but the other controllers did not lose their lease? etc).
Also we can probably move all this to codegen to generate regular and failover aware controllers.

Losing the lease would just revert to the same behavior as before we acquired it.

One principle I think we should adopt: I am game to evaluate this possibility, but I think we should agree not to write our own LE utilities.
I am not personally aware of anyone who has used the upstream LE code from client-go in this manner. Does anyone have examples? I have only seen (that I can readibly remember) the pattern I recreated in the sharedmain pkg where the controller exits once the leader election lock is lost and is restarted in order to try becoming the leader again. If anyone can point to examples of a different pattern in the wild, I would be very interested to see them.
In my view, since I have not seen examples of others doing this, it seems like we would be using the upstream LE code indiosyncratically (ie, we are the only ones with this use case). Potential risks:

We may hit corner cases or scenarios not covered by test or current field usage
We may have trouble driving fixes into upstream for (1) if our use in Knative is perceived as 'not as designed'

I'm really not clear what we think the run-time tradeoff here is:

Leaders can be spread across replicas, so instead of having 10 on the single leader, if I run 3 replicas, I might only run 3-4 reconcilers per Pod. So our controllers start to see benefits from horizontal scaling.

I'm not sure exactly what benefits would be here - can you elaborate? Are we planning the number of leader elected reconcilers per replica? Leaving it to probability? Do we expect performance benefits of some kind? Do we still have to request resources necessary to run all loops simultaneously?

Hot failovers, which best case cost O(nop global resync). This is amplified by the above because generally fewer things should be failing over each time a pod fails.

No question that the current behavior is a cold start, I think we can look at failover speed separately. I previously had wondered to myself how much work it would be to prime informer caches outside the leader election lock, and run the callback only once the leader election lock is obtained. We will need to ensure that is possible in order to implement your idea anyway.

Also, would we be trying to solve this problem if we had not adopted the pattern of running the stateful reconciler and stateless webhook for the same resource in the same process?

Leaving it to probability?

I figured we'd start here, but we can always get smarter.

would we be trying to solve this problem if we had not adopted the pattern of running the stateful reconciler and stateless webhook for the same resource in the same process

Very possibly.  The way I see leaderelection as we have it, we gain effectively nothing by horizontally scaling the controllers other than prescheduling pods.  The goal of the proposed mechanism is to reduce the scope of failovers to a subset of reconcilers running on failed nodes, and to enable us to "warm up" a lot more of our controller infrastructure for faster failovers.
I also don't view what our webhooks are doing today as "stateful" per se, the informer cache is just that: a cache.  We cache to avoid the latency / load of hitting the API server on every request, and (aside from potentially stale caching) which replica you hit has no relevance.
The places our reconcilers write to the API Server today (async from the request path) is likely contentious, but of the ones we run the only state that meaningfully distinguishes between the multiple threads we run vs. horizontally scaled pods is the workqueue logic to avoid simultaneous key processing (and shared caches).  I think for the cases we're talking about I worry about conflicting updates (which we should try and avoid thru leader election), but not competing controllers that spin loop fighting each other in perpetuity.
Contrast this with the KPA reconciler, where multiple replicas may build up different views of the Metric data, and fight over how large the Deployment should be. 😬I get this facet of why horizontally scaling the controllers is hard.

I think it's worth thinking about the cost associated with engineering this idea vs return

I guess what's not sitting well with me is that the "return" on horizontally scaling our controllers is still SPOFs with pretty cold failovers.  I agree with Lionel's sentiment that in clusters with capacity, this might even slow down failovers, while simultaneously increasing the work the SPOF does (very slightly) by enabling leader election.

vs. separating webhook and reconciler and running reconciler HA

This needs more thought than just moving imports and calls because we combine the (idempotent singleton) reconcilers with the admission control logic in a few ways.  One of these is TLS certs, another is the mutating webhooks (which become nontrivial with bindings).

I'll try to sketch something a little more concrete.  I get that this is crazy talk.  I'll do my best to make it seem less crazy 😁

I have a POC of this working with Serving's webhook (currently just hacked into vendor).  I've tested it with LE-disabled, LE-enabled unscaled, LE-enabled scaled to 10, and LE-enabled scaled to 10 with the reconcilers forced across multiple pods (see below).
Note that the webhook-8584d54c6-f8jzv prefix is the Pod name:
kubectl get leases -nknative-serving
NAME                          HOLDER                                                         AGE
webhook.configmapwebhook      webhook-8584d54c6-f8jzv_59d3844d-6a54-4751-aad8-595e1d117b3c   15m
webhook.conversionwebhook     webhook-8584d54c6-hltzh_e868e32e-2274-45e7-9145-5057a8acc807   15m
webhook.defaultingwebhook     webhook-8584d54c6-9h8zb_3aa39eaf-3fa6-4db4-8ef7-cde31fbc2eb5   15m
webhook.validationwebhook     webhook-8584d54c6-whsz8_19b4e145-75fb-4c66-88ec-2cb6d9619dc0   15m
webhook.webhookcertificates   webhook-8584d54c6-cqj5x_9a999a43-9a5e-4f47-8142-b4fa612b3dfe   15m

If I kill just that one pod, only that leader changes:
kubectl get leases -nknative-serving
NAME                          HOLDER                                                         AGE
webhook.configmapwebhook      webhook-8584d54c6-jczjg_91013423-e113-40b8-9e1b-70caf77175e3   24m
webhook.conversionwebhook     webhook-8584d54c6-hltzh_e868e32e-2274-45e7-9145-5057a8acc807   24m
webhook.defaultingwebhook     webhook-8584d54c6-9h8zb_3aa39eaf-3fa6-4db4-8ef7-cde31fbc2eb5   24m
webhook.validationwebhook     webhook-8584d54c6-whsz8_19b4e145-75fb-4c66-88ec-2cb6d9619dc0   24m
webhook.webhookcertificates   webhook-8584d54c6-cqj5x_9a999a43-9a5e-4f47-8142-b4fa612b3dfe   24m

Looking at the logs for the new leader, it correctly global resyncs when it wins the election:
{"level":"info","ts":"2020-04-25T16:26:02.595Z","logger":"webhook","caller":"leaderelection/config.go:230","msg":"\"webhook-8584d54c6-jczjg_91013423-e113-40b8-9e1b-70caf77175e3\" has started leading \"webhook.configmapwebhook\"","commit":"6ec7f43"}
{"level":"info","ts":"2020-04-25T16:26:02.600Z","logger":"webhook","caller":"configmaps/configmaps.go:162","msg":"Webhook is valid","commit":"6ec7f43","knative.dev/traceid":"37f9e8d8-2455-48e6-9412-67965dbdf262","knative.dev/key":"config.webhook.serving.knative.dev"}
{"level":"info","ts":"2020-04-25T16:26:02.600Z","logger":"webhook","caller":"controller/controller.go:464","msg":"Reconcile succeeded. Time taken: 5.092617ms.","commit":"6ec7f43","knative.dev/traceid":"37f9e8d8-2455-48e6-9412-67965dbdf262","knative.dev/key":"config.webhook.serving.knative.dev"}

Our webhooks are singleton reconcilers (so they are a somewhat contrived case), but with the primed informer state we're caught back up in 5ms.  It'll be interesting to see this for proper global resyncs 😈
I've also set things up in a way that we could actually set/unset the client fields based on whether we are leader, which would act as a nice defense-in-depth against accidental mutations from non-leaders.
Right now this is clocking in at about ~300 LoC to change our 5 webhook reconcilers, including a bunch of random refactoring I'm likely going to try to break off independently since it's general goodness.  None of these reconcilers are using // +genreconciler yet either, and I think that unless folks want to opt-in we can make this require no boilerplate code via our codegen.

I'll put together a doc of some kind to organize thoughts here, and a more complete PoC if folks want to take it for a spin.

Ok, I've written up a sketch of what this would look like here.
I'll also toss it on the agenda for API WG Weds to discuss more f2f.

Done

authors: lionelvillard markusthoemmes mattmoor pmorie vagababov

repo: knative/pkg


text:
Update release check list

this updates the release check list to be more granular with the progress
secondly includes badges so you don't have to keep jumping back to the timeline document (hence the change to a markdown file)

@knative/knative-release-leads please take a look
After this merges we should open a tracking issue for 1.10 - we should do it this week

source: gharchive/pull-request

repo: knative/release

license_type: permissive

license_source: bigquery


text:
Check RingingRoom socketio version api

When connecting to ringing room, Wheatley should check the socket io version.
Probably information if minor version differs, warning or error for the major version.
https://github.com/lelandpaul/ringingroom/pull/173
I imagine there'll be a new release of Wheatley in sync with a RR version change, so if RR is higher the message could point towards updating Wheatley from pip.
A higher Wheatley expected version than Ringing Room (e.g. due to releasing Wheatley slightly ahead to be installed on RR or delays in rollout of RR to all global servers)

[belltower] (https://github.com/kneasle/belltower) already does this, so it'll be fixed if/when we switch the backend to belltower.

source: gharchive/issue

authors: centreboard kneasle

repo: kneasle/wheatley

license: MIT

license_source: github-api


text:
OWL: support OWLDisjointClassesAxioms

OWLDisjointClassesAxioms are not currently supported by our owl to rules converter.

Using a bottom class, this is not hard to implement. Using a quadratic number of auxiliary axioms will be acceptable for small numbers of disjoint classes, but for larger lists, it might be better to use a logarithmic number of auxiliary classes and axioms instead.

authors: irina-dragoste mkroetzsch


text:
Nodejs fails start after upgrading it to v.6.7.0

There is an error, which says, that something wrong in function render() in journalctl log. It shows whole page html and error, that this rendered html is not an object

can you post the error message please?

I cannot confirm this locally (we just deployed v6.7, koa@2 on staging - seems to be working as expected).
What version of koa is this?

what is journalctl log even? please post some more context.

Not OP, but journalctl is the system log manager for systemd based versions of Linux. Most likely the Node.JS server is running as a systemd daemon.

Also, I think this error might be coming from your templating library instead of Koa, or at least the error isn't coming from Koa itself (we have no render function).  The full error would be appreciated.

https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V6.md#6.7.0 doesn't reveal anything obvious. Does this issue strictly only appear with node 6.7.0?

We've had 6.7 running (without a templating engine though) on staging under simulated load for a while now - no apparent issues for us. I think this is user-space or 3rd party lib related, not Koa itself (at least not Koa v2).

@howardEagle closing until you give us more info! i'm running 6.7 fine w/ both koa@1 and koa@2

authors: PlasmaPower fl0w howardEagle jonathanong juliangruber

repo: koajs/koa


text:
feat: invalidateMiddleware

To be able to change middleware at run-time.

I'm -1 on this.

You can modify this.middleware before run callback.

@popomore you can but I need to modify it from middleware. I want to update middleware dynamically from a route of my app, currently it's not possible, since the initial function to call before handling requests is always the same.

@z-vr how about just initialising a new app and hot swap referenced callback used by http server instead?

@fl0w what is your concern with this PR

Isn't skipping middlewares already possible by arranging ctx.state flags? I don't see the point of baking this in the framework itself.

Note that I am not part of Koa core team, I am merely expressing my opinion as a contributor. Don’t feel discouraged if you disagree with me.
I feel the PR adds unnecessary bloat to its current simplicity.
The concept of mutating middleware chain during runtime can have many side effects, in particular by introducing state, for instance if you scale your app horizontally. It should be avoided and definitely does not fit as a feature in Koa (IMO). If you want to introduce this yourself - it’s easy enough to dynamically compose a chain (or simply a new Koa app) at runtime and hotswap it - in which case Koa did its job, which is to delegate application logic to the author.
I’m inject no opinion on the actual quality of your PR, that’s not my concern at this point. It is specifically that it introduces an inelegant flow.

@fl0w I liked your idea regarding swapping a listener -- it's very good, thank you! Not sure what to do with the PR, probably will just close it (can someone from the Koa team confirm that it won't be useful please?)

yes we intentionally do not support this feature. if you really want this, what you should do is create a middleware that supports a mutate-able middleware array:
const compose = require('koa-compose')

const middleware = []

app.use((ctx, next) => compose(middleware)(ctx, next)

you'll be able to optimize this function as much as you want

authors: dotnil fl0w jonathanong popomore z-vr


text:
Probably evaluate logic for mass-airdrop

Check logic

closing in favour #1046

repo: kodadot/nft-gallery


text:
Basilisk NFT Marketplace

Thank you for your contribution to the KodaDot NFT gallery.
👇 _ Let's make a quick check before the contribution.
PR type

[ ] Bugfix
[x] Feature
[x] Refactoring

What's new?

[x] PR closes #660
[x] Implementation of Basilisk

Before submitting Pull Request, please make sure:

[x] My contribution builds clean without any errors or warnings
[x] I've merged recent default branch -- main and I've no conflicts
[x] I've tried to respect high code quality standards
[x] I've didn't break any original functionality
[ ] I've posted a screenshot of demonstrated change in this PR

Optional

[ ] I've tested it at </rmrk/collection/26902bc2f7c20c546a-1FVG7>
[ ] I've tested PR on mobile and everything seems works
[x] I found edge cases
#3039
[ ] I've written some unit tests 🧪

Maybe @KngZhi & @Jarsen136 could make a review too :)

It is quite a huge pr, you did all this by one, amazing!

Time to merge as lots of conflicts will arise 🥵 @vikiival
We can follow up with fine-tuning for Basilisk in the next PR 😛

Snekk is verry happy for you

https://deploy-preview-3060--koda-nuxt.netlify.app/bsx/explore

this might be an issue with ss58?
I switched to BSX and showed 2 while the BSX testnet should be 10041 ?

Hey as there are a lot of post reviews, we would like to split load off @vikiival head and we want to speed up BSX integration.
Feel free to take a peek at PRs conversations, which weren't resolved.
Help to contribute and coordinate and put label Basilisk or BSX prefix to name for the PRs so we can merge it to main.
🐍
Found one thing that needs to be fixed, asap so someone could feel free to take charge of that.

authors: KngZhi vikiival yangwao


text:
ci: skip custom sentry on windows

Thank you for your contribution to the KodaDot NFT gallery.
👇 _ Let's make a quick check before the contribution.
PR type

[ ] Bugfix
[ ] Feature
[ ] Refactoring

What's new?

[x] PR closes #4690

Before submitting Pull Request, please make sure:

[x] My contribution builds clean without any errors or warnings
[x] I've merged recent default branch -- main and I've no conflicts
[x] I've tried to respect high code quality standards
[x] I've didn't break any original functionality
[ ] I've posted a screenshot of demonstrated change in this PR

Optional

[ ] I've tested it at </rmrk/collection/26902bc2f7c20c546a-1FVG7>
[ ] I've tested PR on mobile and everything seems works
[ ] I found edge cases
[ ] I've written some unit tests 🧪

Had issue bounty label?

[x] Fill up your KSM address: Payout

Community participation

[x] Are you at KodaDot Discord?

Screenshot

[ ] My fix has changed something on UI; a screenshot is best to understand changes for others.

pay 50 usd

😍 Perfect, I’ve sent the payout
💵 $50 @ 28.11 USD/KSM ~ 1.779 $KSM
🧗 DY4SQF2iD456tH89aQtz5wv1EV3BbSW8wKKuMcwbmXaj1pM
🔗 0x89b3a7347d11ef90d94089833f806f9180e2648923ee72d92e5727b9e0ca407e
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues

authors: preschian yangwao


text:
Yabai not assigning apps to the right space

I am experiencing an issue with my yabai configuration on macOS Ventura 13.0.1 with an M1 Pro MacBook. The issue is related to the configuration codes provided below:
yabai -m space 1 --label web
yabai -m space 2 --label term
yabai -m space 3 --label code
yabai -m space 4 --label docs
yabai -m space 5 --label social
yabai -m rule --add app="^Safari$" space=web
yabai -m rule --add app="^Google Chrome$" space=web
yabai -m rule --add app="^Warp$" space=term border=off
yabai -m rule --add app="^Visual Studio Code$" space=code border=off

The rules for assigning applications to specific spaces are not functioning as intended. The applications "Safari" and "Google Chrome" are not being assigned to the "web" space, and the application "Warp" is not being assigned to the "term" space. Additionally, the border settings for the "Visual Studio Code" application in the "code" space are not being applied correctly.
For instance, when I open vscode in space 2/term, it remains there instead of going to space 3/code.
Any assistance in resolving this issue would be greatly appreciated. Thank you!

Never mind, this function works well, I should type "code" instead of "Visual Studio Code".

repo: koekeishiya/yabai


text:
Chrome: (Preview / Share) Display is very blurry

When viewing a project in a browser the resulting screens are very blurry on Chrome, but not on Safari. This happens on both retina and non-retina screens. Only when viewed at exactly 100% of the designed resolution the result is (sometimes) not blurry. This is however never possible to enforce when sharing.
I am wondering why this is happening and if there is anything that could be done about it. Either by editing the design/export or by changing something in Framer itself.

The examples in the gallery also have this issue, see for example https://share.framerjs.com/rysvoazf50xq/ (not mine)
Attached is a screenshot of this problem

A quick Google search seems to explain that this is an issue with how Chrome is scaling images. The workaround appears to be to share your prototype using "no device." Then it won't scale.

Apparently text can be fixed with antialiasing added: https://github.com/koenbok/Framer/issues/408
I can't confirm either solution, and the antialiasing one doesn't seem to work for me.

authors: briannhinton robinkruyt

repo: koenbok/Framer

license: mit


text:
ODP presentations load without background

ODP presentations show plain. No background and text colors are gone.

not like urs . ODP presentations show nothing , just download source file XX.odt , hope to get answer!

Are you using the proper syntax as described here? In that case you should be seeing a grey screen, and downloading should not be possible.
http://viewerjs.org/instructions/

@socialweb: in what (version of what) application was the presentation created? If the images used are wrapped in some proprietary wrapper, the browser (or in fact other applications) might not understand. A quick fix with problematic documents is to convert to PDF, and use that instead - viewerJS understands both ;)
You can also check your document with http://validator.opendocumentformat.org.

/ViewerJS/#../demo/11.odt
syntax is right
perform well when src=PDF file , but fail to present ODP file =. =

authors: greenwichmt leenaars socialweb

repo: kogmbh/ViewerJS


text:
getLabels() call for a pull request results in downstream 404s

When calling .getLabels() with a pull request object, the pull request object's url is overridden to include /issues/ in the path, rather than /pulls/. This can cause subsequent 404s when attempting to access pull request-specific API endpoints, like getCommits(), which require a pull request url.
See https://github.com/jenkinsci/ghprb-plugin/issues/441 for some backstory.

Fixed in 1.82.

Thanks for the fix! We'll look to incorporate it downstream. :tada:

authors: benpatterson kohsuke

repo: kohsuke/github-api


text:
[BUG]: Crash when stopping gossip

Is there an existing issue for this?

[X] I have searched the existing issues

Current behavior
The p2p node crashed with SIGSEGV and stack trace, here's the end of the logs:
2022-09-21 15:36:08.781367 (p2p.Koinos) [p2p/gossip.go:404] <info>: Gossiped transaction applied - ID: 0x1220cdb0d0c54be0fa9ca548e9d7794f21c559b2110fc7a05d634e4d49d14a9e26d8 from peer Qmb...
2022-09-21 15:36:08.781501 (p2p.Koinos) [p2p/gossip.go:404] <info>: Gossiped transaction applied - ID: 0x1220246530b47ddf885ae8cd66142402940d8553378d52ad49b74d9230b7ff2cf2a4 from peer Qmb...
2022-09-21 15:36:08.792164 (p2p.Koinos) [p2p/gossip.go:404] <info>: Gossiped transaction applied - ID: 0x1220a9f28b6a02237ad47bf83926edd1e35db97ea6bf644b6e7e24e675273df03101 from peer Qmb...
2022-09-21 15:36:08.794310 (p2p.Koinos) [p2p/gossip.go:404] <info>: Gossiped transaction applied - ID: 0x122069ca9766d89fb204648fac3cdf0c1e14228b4f60f9e6d321195629dbc5890a35 from peer Qmb...
2022-09-21 15:36:08.794423 (p2p.Koinos) [p2p/gossip.go:208] <info>: Stopping gossip mode
2022-09-21 15:36:08.794746 (p2p.Koinos) [p2p/gossip.go:132] <warn>: Error getting message for topic koinos.blocks: context canceled
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0xa88b4d]

goroutine 1068775 [running]:
github.com/libp2p/go-libp2p-pubsub.(*Subscription).Next(0x0, {0x1543b28, 0xc00306adc0})
        /go/pkg/mod/github.com/libp2p/go-libp2p-pubsub@v0.7.1/subscription.go:27 +0x2d
github.com/koinos/koinos-p2p/internal/p2p.(*GossipManager).readMessages(0xc000330f50, {0x1543b28, 0xc00306adc0}, 0xc004edea80)
        /koinos-p2p/internal/p2p/gossip.go:130 +0x6c
created by github.com/koinos/koinos-p2p/internal/p2p.(*GossipManager).Start
        /koinos-p2p/internal/p2p/gossip.go:88 +0x1fb

Expected behavior
Not crash
Steps to reproduce
This is a race on gm.sub() so it may be difficult to reproduce.
Environment
- OS: Ubuntu 22.04

Anything else?
Looking at the code and backtrace, it is clear this is a race on gm.sub.
Basically Stop() assumes the thread will immediately exit when cancel() is called.
However it's possible for the following sequence of events to occur:

The context is cancelled and gm.sub is set to nil.
The channel in readMessages() receives data at about the same time.
The select in readMessages() could go into either branch.
According to Golang docs, select picks a branch at random if multiple branches are ready.
Golang happens to pick the ch <- msg.Data branch
The select runs to completion as it's a no-op
The select is the last thing in the readMessages() for loop, so we go back to the top of the loop
The first thing that happens at the top of the loop is calling gm.sub.Next()
This causes SIGSEGV because gm.sub is nil

The proper thing to do is have Stop() wait for the readMessages() goroutine to exit after calling cancel(), then only assign gm.sub = nil after cancel() is finished.

p2p_1                  | 2022-10-21 07:40:01.515568 (p2p.Koinos) [p2p/gossip.go:227] <info>: Publishing transaction - ID: 0x12202a86023b1f926c70c78448bbf5d312e8a0ff97e63a5a99f0f1a9b8934594b1a7
p2p_1                  | 2022-10-21 07:40:01.518263 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x12202a86023b1f926c70c78448bbf5d312e8a0ff97e63a5a99f0f1a9b8934594b1a7 from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:01.530219 (p2p.Koinos) [p2p/gossip.go:227] <info>: Publishing transaction - ID: 0x1220722045ca0f1f1b417c9e42643ed5f2c56b695b969aff6b03685ecffdbe05579c
p2p_1                  | 2022-10-21 07:40:01.533016 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x1220722045ca0f1f1b417c9e42643ed5f2c56b695b969aff6b03685ecffdbe05579c from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:01.553265 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x1220feff091390151c7e5043523a7a18b84d9611fd4da0bc23d9fa1fbe91a746b2cf from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:01.553705 (p2p.Koinos) [p2p/gossip.go:227] <info>: Publishing transaction - ID: 0x1220472225625ed09c8d5b0496e456db113d0a68ae3e10fb961286a499f21c95e05a
p2p_1                  | 2022-10-21 07:40:01.554257 (p2p.Koinos) [p2p/gossip.go:227] <info>: Publishing transaction - ID: 0x1220feff091390151c7e5043523a7a18b84d9611fd4da0bc23d9fa1fbe91a746b2cf
p2p_1                  | 2022-10-21 07:40:02.397483 (p2p.Koinos) [p2p/gossip.go:211] <info>: Stopping gossip mode
p2p_1                  | 2022-10-21 07:40:02.397971 (p2p.Koinos) [p2p/gossip.go:132] <warn>: Error getting message for topic koinos.blocks: context canceled
p2p_1                  | 2022-10-21 07:40:02.401580 (p2p.Koinos) [p2p/gossip.go:227] <info>: Publishing transaction - ID: 0x12203a2fd03e69f8784f21612a093058914c0c34d845cf7b255b3167cf2157b996a0
p2p_1                  | 2022-10-21 07:40:02.407037 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x12203a2fd03e69f8784f21612a093058914c0c34d845cf7b255b3167cf2157b996a0 from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:02.407145 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x1220472225625ed09c8d5b0496e456db113d0a68ae3e10fb961286a499f21c95e05a from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:02.412013 (p2p.Koinos) [p2p/gossip.go:332] <info>: Gossiped block applied - Height: 1644430 ID: 0x12202947d13c8eca9540354aa042c494ce03c10bc0d27d81c90f5bfcc2f3fbe52d09 Prev: 0x12207f666de93a246a1cab30ef5d061564d0d521f95969ee2363e0e79152d4046d51 from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:02.426252 (p2p.Koinos) [p2p/gossip.go:227] <info>: Publishing transaction - ID: 0x12208fe233ab666d27779d855e918662684206d11b1999d64d1c95e5bb36a87225ac
p2p_1                  | 2022-10-21 07:40:02.428477 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x12208fe233ab666d27779d855e918662684206d11b1999d64d1c95e5bb36a87225ac from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:02.435780 (p2p.Koinos) [p2p/gossip.go:227] <info>: Publishing transaction - ID: 0x1220d68f6f2b3cbef1768371a23afcb6a86e0b227ac3e49774a50f61de2d602642b9
p2p_1                  | 2022-10-21 07:40:02.436720 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x1220d68f6f2b3cbef1768371a23afcb6a86e0b227ac3e49774a50f61de2d602642b9 from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:02.462970 (p2p.Koinos) [p2p/gossip.go:227] <info>: Publishing transaction - ID: 0x1220d9da1f844cf714b1e975ffd1dc0241e51fd16ec32da366a27f6059d9bc3840ad
p2p_1                  | 2022-10-21 07:40:02.463489 (p2p.Koinos) [p2p/gossip.go:227] <info>: Publishing transaction - ID: 0x122048f8de214b4209930b0d0c21cfdb09987088aeb478dfd155245eaf5c08512e6c
p2p_1                  | 2022-10-21 07:40:02.463836 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x122048f8de214b4209930b0d0c21cfdb09987088aeb478dfd155245eaf5c08512e6c from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:02.463950 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x1220d9da1f844cf714b1e975ffd1dc0241e51fd16ec32da366a27f6059d9bc3840ad from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:02.498804 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x1220b06fb6d94797815a324b44f78f25b0f9ad1bb4851a2b154cfebec322d29cb051 from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:02.502910 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x1220d334e994f5e3d1e736c36d4ac1c2e312d2c8110772c225c911081f529bbbca77 from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:02.527325 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x12207726022b4065503b0d601374992cf4df7522de53348d973ec887edb4652d0155 from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:02.541019 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x1220b2a347295f3afd0a55945682f868d42b22748b3d4942f91fa9b0af898e3c038b from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:02.553708 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x1220ddbbc369d66561a10b3cd26f5a915cdb01e88dc96ec63762fef90116d20fec2a from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:02.563522 (p2p.Koinos) [p2p/gossip.go:204] <info>: Starting gossip mode
p2p_1                  | 2022-10-21 07:40:02.564074 (p2p.Koinos) [p2p/gossip.go:258] <info>: Started block gossip listener
p2p_1                  | 2022-10-21 07:40:02.564274 (p2p.Koinos) [p2p/gossip.go:342] <info>: Started transaction gossip listener
p2p_1                  | 2022-10-21 07:40:02.572221 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x1220284aa47295ceff1a4ec4fe12d8293bc24006c4ae68f24b64057fa5deef48de77 from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:02.576852 (p2p.Koinos) [p2p/gossip.go:227] <info>: Publishing transaction - ID: 0x1220284aa47295ceff1a4ec4fe12d8293bc24006c4ae68f24b64057fa5deef48de77
p2p_1                  | 2022-10-21 07:40:02.593079 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x1220284f9671f565556a0b579c7e3c2fe94435753ac6b190f84947bad93a5cff56b2 from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | 2022-10-21 07:40:02.593494 (p2p.Koinos) [p2p/gossip.go:227] <info>: Publishing transaction - ID: 0x1220284f9671f565556a0b579c7e3c2fe94435753ac6b190f84947bad93a5cff56b2
p2p_1                  | 2022-10-21 07:40:02.610151 (p2p.Koinos) [p2p/gossip.go:227] <info>: Publishing transaction - ID: 0x122061ab9d845c599b99961308b1493b495c45019de1179341e7766f300a8dcf7208
p2p_1                  | 2022-10-21 07:40:02.617167 (p2p.Koinos) [p2p/gossip.go:399] <info>: Gossiped transaction applied - ID: 0x122061ab9d845c599b99961308b1493b495c45019de1179341e7766f300a8dcf7208 from peer QmcGiTpSm6YrmYo3rWoqrCPez2aJY4VdraBQsGsZKwFRuG
p2p_1                  | panic: runtime error: invalid memory address or nil pointer dereference
p2p_1                  | [signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0xa8cb4d]
p2p_1                  |
p2p_1                  | goroutine 2582706 [running]:
p2p_1                  | github.com/libp2p/go-libp2p-pubsub.(*Subscription).Next(0x0, {0x154b368, 0xc01d76b640})
p2p_1                  | 	/go/pkg/mod/github.com/libp2p/go-libp2p-pubsub@v0.7.1/subscription.go:27 +0x2d
p2p_1                  | github.com/koinos/koinos-p2p/internal/p2p.(*GossipManager).readMessages(0xc0006620f0, {0x154b368, 0xc01d76b640}, 0xc008708060)
p2p_1                  | 	/koinos-p2p/internal/p2p/gossip.go:130 +0x6c
p2p_1                  | created by github.com/koinos/koinos-p2p/internal/p2p.(*GossipManager).Start
p2p_1                  | 	/koinos-p2p/internal/p2p/gossip.go:88 +0x1fb
koinos_p2p_1 exited with code 2

authors: sgerbino theoreticalbts


text:
add support for cron jobs

@ublubu

small comment, lgtm otherwise

repo: koki/short


text:
use link for autumnaton not inline. more drops for Othello

Autumn-aton redirects to a choice, so use link cannot be in-line
Othello also drops handkerchief, dagger, and military jacket

Actually, I think there's a tab in Othello's drops where there should be a space. Does that break things?

I see tabs separating each drop. That is correct.
I see spaces between each word and between the item and the (0).
When I look at Location Details, I see all 4 items.
And when I encounter Othello, all 4 items are listed.

My mistake. I thought drops were supposed to be space separated, not tab separated.

repo: kolmafia/kolmafia


text:
Actually verify that it is a number before trying to parse to an item id

In this scenario, you will be sending 6 imp ales to yourself.
kmail 1 ¶ 470, 1 ¶ 470, 1 ¶ 470, 1 ¶ 470, 1 ¶ 470 to YourNameGoesHere

You will receive a harmless error before it sends the kmail as expected.
4701470147014701470 is out of range, returning 0
Sending kmail to Irrat...
Message sent to Irrat

The issue in question is that after verifying that it starts with a ¶, it doesn't bother checking if it's even a comma delimited list and just blindly attempts to parse the entire string to a number.
This in turn reveals a new problem, in which if you attempt to use
kmail ¶1, ¶2 to YourNameGoesHere

It will attempt to send item no. 12, mariachi pants. Instead of Seal Clubbing Club & Seal Tooth.

Add tests please
On Sat, 19 Feb 2022, 16:28 codecov[bot], @.***> wrote:

Codecov
https://codecov.io/gh/kolmafia/kolmafia/pull/614?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia
Report
Merging #614
https://codecov.io/gh/kolmafia/kolmafia/pull/614?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia
(5295bc5
https://github.com/kolmafia/kolmafia/commit/5295bc5e43d24f11ed0d618bd503afc816a2b777)
into main
https://codecov.io/gh/kolmafia/kolmafia/commit/27ae5dacd5af8e76e42fd00462dd9c0db5e8291b?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia
(27ae5da
https://github.com/kolmafia/kolmafia/commit/27ae5dacd5af8e76e42fd00462dd9c0db5e8291b)
will increase coverage by 0.23%.
The diff coverage is n/a.
[image: Impacted file tree graph]
https://codecov.io/gh/kolmafia/kolmafia/pull/614?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia
@@             Coverage Diff              @@
main     #614      +/-
============================================

Coverage     21.00%   21.24%   +0.23%

Complexity     9021     9094      +73

============================================
Files          1001     1000       -1
Lines        156157   156163       +6
Branches      34709    34713       +4
============================================

Hits          32805    33180     +375
Misses       117416   116932     -484

Partials       5936     6051     +115

Impacted Files
https://codecov.io/gh/kolmafia/kolmafia/pull/614?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia Coverage
Δ
...t/sourceforge/kolmafia/persistence/ItemFinder.java
https://codecov.io/gh/kolmafia/kolmafia/pull/614/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia#diff-c3JjL25ldC9zb3VyY2Vmb3JnZS9rb2xtYWZpYS9wZXJzaXN0ZW5jZS9JdGVtRmluZGVyLmphdmE= 80.27%
<ø> (-0.08%) ⬇
...et/sourceforge/kolmafia/maximizer/CheckedItem.java
https://codecov.io/gh/kolmafia/kolmafia/pull/614/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia#diff-c3JjL25ldC9zb3VyY2Vmb3JnZS9rb2xtYWZpYS9tYXhpbWl6ZXIvQ2hlY2tlZEl0ZW0uamF2YQ== 33.98%
<0.00%> (-6.80%) ⬇
...rceforge/kolmafia/swingui/menu/PartialMRUList.java
https://codecov.io/gh/kolmafia/kolmafia/pull/614/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia#diff-c3JjL25ldC9zb3VyY2Vmb3JnZS9rb2xtYWZpYS9zd2luZ3VpL21lbnUvUGFydGlhbE1SVUxpc3QuamF2YQ== 77.77%
<0.00%> (-6.67%) ⬇
...sourceforge/kolmafia/textui/langserver/Script.java
https://codecov.io/gh/kolmafia/kolmafia/pull/614/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia#diff-c3JjL25ldC9zb3VyY2Vmb3JnZS9rb2xtYWZpYS90ZXh0dWkvbGFuZ3NlcnZlci9TY3JpcHQuamF2YQ== 80.85%
<0.00%> (-4.26%) ⬇
...e/kolmafia/persistence/AdventureQueueDatabase.java
https://codecov.io/gh/kolmafia/kolmafia/pull/614/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia#diff-c3JjL25ldC9zb3VyY2Vmb3JnZS9rb2xtYWZpYS9wZXJzaXN0ZW5jZS9BZHZlbnR1cmVRdWV1ZURhdGFiYXNlLmphdmE= 29.67%
<0.00%> (-3.88%) ⬇
...forge/kolmafia/textui/langserver/FilesMonitor.java
https://codecov.io/gh/kolmafia/kolmafia/pull/614/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia#diff-c3JjL25ldC9zb3VyY2Vmb3JnZS9rb2xtYWZpYS90ZXh0dWkvbGFuZ3NlcnZlci9GaWxlc01vbml0b3IuamF2YQ== 76.92%
<0.00%> (-1.29%) ⬇
...e/kolmafia/persistence/AdventureSpentDatabase.java
https://codecov.io/gh/kolmafia/kolmafia/pull/614/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia#diff-c3JjL25ldC9zb3VyY2Vmb3JnZS9rb2xtYWZpYS9wZXJzaXN0ZW5jZS9BZHZlbnR1cmVTcGVudERhdGFiYXNlLmphdmE= 15.68%
<0.00%> (-0.99%) ⬇
.../kolmafia/textui/command/RefreshStatusCommand.java
https://codecov.io/gh/kolmafia/kolmafia/pull/614/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia#diff-c3JjL25ldC9zb3VyY2Vmb3JnZS9rb2xtYWZpYS90ZXh0dWkvY29tbWFuZC9SZWZyZXNoU3RhdHVzQ29tbWFuZC5qYXZh 6.97%
<0.00%> (-0.53%) ⬇
...eforge/kolmafia/persistence/AdventureDatabase.java
https://codecov.io/gh/kolmafia/kolmafia/pull/614/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia#diff-c3JjL25ldC9zb3VyY2Vmb3JnZS9rb2xtYWZpYS9wZXJzaXN0ZW5jZS9BZHZlbnR1cmVEYXRhYmFzZS5qYXZh 50.99%
<0.00%> (-0.50%) ⬇
.../net/sourceforge/kolmafia/maximizer/Maximizer.java
https://codecov.io/gh/kolmafia/kolmafia/pull/614/diff?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia#diff-c3JjL25ldC9zb3VyY2Vmb3JnZS9rb2xtYWZpYS9tYXhpbWl6ZXIvTWF4aW1pemVyLmphdmE= 32.66%
<0.00%> (-0.48%) ⬇
... and 33 more
https://codecov.io/gh/kolmafia/kolmafia/pull/614/diff?src=pr&el=tree-more&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia
Continue to review full report at Codecov
https://codecov.io/gh/kolmafia/kolmafia/pull/614?src=pr&el=continue&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia
.
Legend - Click here to learn more
https://docs.codecov.io/docs/codecov-delta?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia
Δ = absolute  (impact), ø = not affected, ? = missing data
Powered by Codecov
https://codecov.io/gh/kolmafia/kolmafia/pull/614?src=pr&el=footer&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia.
Last update 27ae5da...5295bc5
https://codecov.io/gh/kolmafia/kolmafia/pull/614?src=pr&el=lastupdated&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia.
Read the comment docs
https://docs.codecov.io/docs/pull-request-comments?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=kolmafia
.
—
Reply to this email directly, view it on GitHub
https://github.com/kolmafia/kolmafia/pull/614#issuecomment-1046054920,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABL4LVF7SC2KS6GYEARKPDU37AL7ANCNFSM5O2W2TOQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because your review was requested.Message ID:
@.***>

This should have been fixed in #603, I think? Does it still not work properly after that?

This should have been fixed in #603, I think? Does it still not work properly after that?

Huh, I missed that commit. I'll need to update and test, but you're probably right.

authors: gausie libraryaddict midgleyc


text:
Regarding making liveries.

Many of you may have noticed i have not been making as much liveries recently. This is mainly because of school,it turns out that it can be really hard to make a bunch of liveries and balance school on top of that. Because of that i will be taking a little break until December 1st. I want you to know that this was not an easy decision giving up something that i love doing so much,but I have to do it to keep up with my grades.But before I go i have one more livery,China Southern A380! (also can you add a screen recording so i can see how a livery is added,thank you!) I cant wait to see how much this community will grow when i get back!
Best Regards
-George

Last words from a legend..

I can't wait for you to be back!

NOOOOOOOOOOOOOOO ! I was working on it for 2 weeks :( Not important, i'll be faster next time. more seriously, i think i shoul prevent when i start a long time project.

@airgeorge
Thank you for supporting LiverySelecor with so many beautiful liveries! I totally understand your problem and hope you will get good marks. Hope to see you soon, winter holiday is coming.
Best regards,
Kolos

@kolos26 one last livery ;). now
Best Regards,
-George

@kolos26 one last livery ;). now Best Regards, -George

NO, I was making that, well I'm gonna make the etihad year of zayed 2018, no one steal it, okay?

is cool

@airgeorge Thanks for this (temporary last) livery.
@BoeingBus747 The Etihad one would be cool. If you create that you can also create the general Etihad livery 'cause they're almost the same.

@airgeorge Thanks for this (temporary last) livery. @BoeingBus747 The Etihad one would be cool. If you create that you can also create the general Etihad livery 'cause they're almost the same.

It's not the weekend so I can't make much progress rn so I should be done in Friday/Saturday and I'll also do the original one at the same time

@airgeorge Thanks for this (temporary last) livery. @BoeingBus747 The Etihad one would be cool. If you create that you can also create the general Etihad livery 'cause they're almost the same.

It's not the weekend so I can't make much progress rn so I should be done in Friday/Saturday and I'll also do the original one at the same time

This is not a horse-race ;) Just do it if you have time and mood.

@airgeorge Thanks for this (temporary last) livery. @BoeingBus747 The Etihad one would be cool. If you create that you can also create the general Etihad livery 'cause they're almost the same.

It's not the weekend so I can't make much progress rn so I should be done in Friday/Saturday and I'll also do the original one at the same time

This is not a horse-race ;) Just do it if you have time and mood.

Yeah I do, plus I can literally save the part without text and then do both of them

Reference in new issue

Great! :D Anyhow, I'm probably going to need a break since biology is getting tough this year

is close to 12/1/22

I hate it when people use the Month/Day/Year format

the only reason i use it is because whenever the school makes us write dates we have to do it in that format


text:
Dash 8 Map please?

I really want to make Dash 8 liveries but I can't find the map. Maybe because I'm just lazy to find or they didn't send the aircraft map. Can someone send me the image or link??

Dash8 is still in development, I'm trying to figure out how to recolor the top of the vertical stab. Until that you can try to repaint this texture, but I don't know yet when will it be avaliable in the addon.
https://www.geo-fs.com/backend/aircraft/repository/E01_166635_247/texture.png

thx so much i'll ad the dash 8 to my addon

thanks :D

i just made new flybe

authors: Ryubunao iuhairways kolos26


text:
Livery request

Pls add livery for the dc-3. (has anyone realized that geofs messed up, it's not the dc-3 but the dc-2, dc-3 has sharper nose.)
https://th.bing.com/th/id/R.eb3830d3f0e8681875a42bcf87b78d65?rik=RoFe6yGJv4mXUg&riu=http%3A%2F%2Fimg.wp.scn.ru%2Fcamms%2Far%2F53%2Fpics%2F258_2.jpg&ehk=Fp1qKzdlyVRO6X1txpBrf2PoFGhd30T6RaTWCpUnNRg%3D&risl=&pid=ImgRaw&r=0

Dc3 liveries are difficult to make. I have a long-long list, but I don't think I will ever get to the end. Btw write me which one you would like

And regarding to the dc3 vs dc2 issue: The nose of the dc3 and c47 variants was not not the same on the thousands of planes built (landing light for example). The most significant difference between the dc3 and dc2 is the vertical stab.
dc3

dc2


text:
buildah: Properly missing components property in syft-generated SBOM

When the Syft SBOM didn't have the components property, the output was generated incorrectly because - the default empty list needed to be added back to image_sbom.

I noticed this because it caused a backtrace in merge_syft_boms.py: https://github.com/containerbuildsystem/cachi2/pull/576  - but they are actually two independent bugs.

/ok-to-test

Just a nitpick: I think the commit message is missing a verb ("handle"?)

Pushed a new version with a fixed up Subject for the commit message

authors: chmeliik owtaylor

repo: konflux-ci/build-definitions


text:
コメントの時刻をJSTにする

アカウント設定でタイムゾーンをJSTにしても、APIで取れる時刻は変わらないみたい。タイムゾーンは/settingで設定できるようにする

momentjs でフォーマットを直したら、時刻がJSTになった。なぜ？

repo: kongou-ae/chatmine


text:
[BUG] Invalid WEB_CMD configuration option: command is non-existent or not executable: curl in validate configuration

Hello!
Describe the bug
Running vagrant up results in
TASK [konstruktoid.hardening : Validate configuration] *************************
fatal: [bullseye_vlan]: FAILED! => {"changed": false, "cmd": ["rkhunter", "--config-check", "--enable", "all", "--disable", "none"], "delta": "0:00:01.077572", "end": "2024-04-05 08:15:25.302208", "msg": "non-zero return code", "rc": 1, "start": "2024-04-05 08:15:24.224636", "stderr": "", "stderr_lines": [], "stdout": "Invalid WEB_CMD configuration option: command is non-existent or not executable: curl", "stdout_lines": ["Invalid WEB_CMD configuration option: command is non-existent or not executable: curl"]}

To Reproduce
Run vagrant up (Virtualbox, OSX)
Expected behavior
I expect this to run without errors.
System (lsb_release -a or similar):
Virtualbox, OSX
ansible-core              2.15.8
ansible-lint              6.22.2
Additional context
This is probably caused by https://github.com/konstruktoid/ansible-role-hardening/blob/4bae6610f263fb08135fb8af66d66dc18b18cc12/defaults/main/suid_sgid_blocklist.yml#L85 but how do you want to go about it in this Vagrant testing context?

the Vagrant boxes were missing curl, and is soon fixed

https://github.com/konstruktoid/ansible-role-hardening/pull/593

Works, thank you! Found another one but I'll followup with PRs

authors: jdaln konstruktoid

repo: konstruktoid/ansible-role-hardening


text:
remove old node version from actions

Applied mkpr on .github/workflows/*.yml
sed /\- 20.12.0/d

Pull Request Test Coverage Report for Build 8624166848
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 94.937%

Totals

Change from base Build 8623378934:
0.0%

Covered Lines:
408

Relevant Lines:
428

💛  - Coveralls

repo: konsumation/db-level


text:
merge from template-github-action

.github/workflows/ci.yml

chore: add actions/checkout@v4.1.7 (jobs.test-node.steps.uses)
chore: add actions/checkout@v4.1.7 (jobs.release.steps.uses)

.github/workflows/codeql_analysis.yml

chore: add actions/checkout@v4.1.7 (jobs.analyze.steps.uses)

.github/workflows/update_package_lock.yml

chore: add actions/checkout@v4.1.7 (jobs.update_package_lock.steps.uses)

.github/workflows/update_readme_api.yml

chore: add actions/checkout@v4.1.7 (jobs.update_readme_api.steps.uses)

Pull Request Test Coverage Report for Build 9489951654
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 95.197%

Totals

Change from base Build 9487367461:
0.0%

Covered Lines:
392

Relevant Lines:
411

💛  - Coveralls


text:
Remove --values-from and prompts from kontena stack registry push

Fixes #3102
kontena stack registry push xyz.yml was prompting for variable values to validate/load the stack file, after this PR it no longer does that.

It wasn't even actually "validating" on purpose, the stack method just happens to run the interpolations.

repo: kontena/kontena


text:
Allow change of access mode in PV selections

When copying PVs we want to allow a user to change the access mode.
This is assumed to be an advanced setting.
By default we will use the same access mode as used on source, for some unique situations this may need to change.
The user will need to understand:

Their application usage
Capabilities of the provisioner on the destination

@vconzola Do we have any mockups for this?

@ibolton336 No. I'm not sure this one has ever been discussed before. Lemme read thru the issue and see if I can understand it enough to create some mockups.

Thanks Vince. Let me know if you find anything out.

authors: ibolton336 jwmatthews vconzola

repo: konveyor/mig-ui


text:
macOS arm64 builds do not work

When attempting to run the arm64 prebuilt release v1.21 binaries on macOS 14.4, the following is produced
zsh: trace trap  /Users/caleb/Downloads/wfs-tools-v1.2.1-macos-arm64/wfs-extract

I was able to reproduce this by exporting the variables LDFLAGS="-L/opt/homebrew/opt/llvm/lib" and CPPFLAGS="-I/opt/homebrew/opt/llvm/include" before compiling. Without these environment variables the compiled builds ran fine.
I was also unable to compile it with gcc or AppleClang, which ought to be noted in the readme.
Here is my build: wfs-tools.zip

Thanks for the report and reproduction.
Can you verify if the artifacts that attached here are working?
https://github.com/koolkdev/wfs-tools/actions/runs/8404738575

As far as I can tell the artefacts run perfectly well.

repo: koolkdev/wfs-tools


text:
[BUG] unexpected CPU eviction

What happened:
unexpected CPU eviction with evictByAllocatable cpuEvictPolicy policy
meanwhile we observed batch allocatable reach zero.
metric: koordlet_node_resource_allocatable{resource=~"kubernetes.io/batch-cpu",node="$node"}/1000

What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
batch resource calculate logic:
currently:
nodeSafetyMargin = capacity * ratio link
batchAllocatable = capacity - nodeSafetyMargin - systemUsed - podHPUsed link
what I expected:
batchAllocatable = min(capacity - systemUsed - podHPUsed, nodeSafetyMargin)
nodeSafetyMargin should be a maximum threshold.
Environment:

App version:
Kubernetes version (use kubectl version):
Install details (e.g. helm install args):
Node environment (for koordlet/runtime-proxy issue):

Containerd/Docker version:
OS version:
Kernal version:
Cgroup driver: cgroupfs/systemd

Others:

/assign @saintube

@j4ckstraw It seems to be two individual issues:

The batch resource fluctuation problem may cause unexpected evictions when evictPolicy=evictByAllocatble, which has a remaining issue and solution in #1906.
The question about the nodeSafetyMargin parameter. This is by design where we always reserve a ratio of node allocatable for the high-priority except their usage. Regardless, I think adding a parameter to limit the upper ratio of the batch resources is reasonable. So it is welcome to contribute this enhancement :)

repo: koordinator-sh/koordinator


text:
Multiplatform equivalent for java.util.concurrent.TimeUnit?

A lot of Kotlin devs are probably used to this API especially for conversion between different units of time. Would you be interested in a (probably very small) PR to add a multiplatform version?

Yeah, I would accept PRs. But, whats the benefit over this?
val time = 10.seconds
val tenSecondsInMilliseconds = time.milliseconds

I think that design is great and I wouldn't want to change or replace it.
It's possible that all the changes would live in the JVM subrepo, and just be a translation layer between Klock and the Java TimeUnit stuff. For example, if I have some coroutine task with a timeout that's defined in Klock common code, it would be nice to either

One benefit of TimeUnit is that it can convert between values without any class instantiation, but that may not be enough of a gain to justify adding it to the API. Maybe all that's needed is a little translation layer within the JVM module for conversions to work with Java/Kotlin APIs which expect a Long and a TimeUnit, like https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.experimental/with-timeout.html. I'll chew it over for a bit and try to get you a PR. And thanks for the great library! :)

Yeah, right now it instantates objects. The same goes for operator overloads:
1.seconds + 1000.milliseconds instantiates 3 objects. But it is safer to do artithmetic this way, and nicer for arguments and for storing times.
Allocation will be zero once inline classes ships: https://github.com/Kotlin/KEEP/pull/103
And/Or project valhalla. Since most of these classes are immutable with a single field.
Still, if you think it makes sense, create a PR :)

Klock 1.0.0 will be released later this week and will use Kotlin 1.3 inline, so I guess that this is not required anymore. I'm closing it. Feel free to reopen if required.

authors: abissell soywiz

repo: korlibs/klock


text:
Preserve filesystem permissions of artifacts (take 2)

This builds on #9 and makes the following changes:

Change extraction loop to use ZipInfo object rather than repeated name lookups
Refactor out install_member -- the body of that for loop was getting too big
Keep only the "normal" permissions bits (0777)

Ignore any "special" permissions bits like setuid, setgid, sticky
It's allowable, but don't pass the file "type" bits (S_IFMT) to chmod

Closes #8

This looks great to me - it resolves my issue #8, and significantly cleans up the extraction process.

authors: JonathonReinhart ellisto

repo: kosma/gitlab-art

license: WTFPL


text:
sendPhoto with notification disabled throws an error

Using bot.sendPhoto with the notify: false option throws the following error:
_http_outgoing.js:456
    throw new TypeError('First argument must be a string or Buffer');
    ^

TypeError: First argument must be a string or Buffer
    at ClientRequest.OutgoingMessage.write (_http_outgoing.js:456:11)
    at Request.write (/tmp/telebot/node_modules/request/request.js:1387:27)
    at FormData.ondata (stream.js:31:26)
    at emitOne (events.js:96:13)
    at FormData.emit (events.js:188:7)
    at FormData.CombinedStream.write (/tmp/telebot/node_modules/combined-stream/lib/combined_stream.js:118:8)
    at FormData.CombinedStream._pipeNext (/tmp/telebot/node_modules/combined-stream/lib/combined_stream.js:106:8)
    at FormData.CombinedStream._getNext (/tmp/telebot/node_modules/combined-stream/lib/combined_stream.js:79:10)
    at FormData.CombinedStream._pipeNext (/tmp/telebot/node_modules/combined-stream/lib/combined_stream.js:107:8)
    at FormData.CombinedStream._getNext (/tmp/telebot/node_modules/combined-stream/lib/combined_stream.js:79:10)

I tracked the error down to methods.js#L289 where form gets passed as data instead of form (according to telebot.js#L262). Changing the line to
return this.request(`/${ url }`, form);

will result in the request going through and the photo being send like expected, but will make the tests fail so i'm sure that's not the root cause. Unfortunately, i'm not familiar enough with the lib to pinpoint it myself.
To reproduce:
const TeleBot = require('telebot');
let t = new TeleBot("TOKEN");
t.sendPhoto("CHAT_ID", "https://telegram.org/img/t_logo.png", {
    notify: false
});

I'm using node v6.7.0, npm v3.10.8 & telebot v1.0.6.

Hi, thank you for your report!
For some reason request library don't like booleans in formData 😕

repo: kosmodrey/telebot


text:
Aesthetic problems with Better Discord Minimal Mode

http://i.imgur.com/kE7dAaY.png
Is there any way to stop this unsightly space between the channels and the servers when using Minimal Mode?

Updated the plugin, it should work with minimal mode now automatically.

authors: kosshishub remeranAuthor

repo: kosshishub/CompactGuilds-BD-plugin


text:
Question on contents of the H1_day0_demultilexed_singlets.RDS file

Hi @kotliary ,
I downloaded the file H1_day0_demultilexed_singlets.RDS and I'm trying to follow your code to build my own SingleCellExperiment, but I'm a bit confused of which rows are the surface markers and which are genes:
You start by loading and splitting by batch,
# read in final singlets make list of seurat objects indexed by batch.
h1 = readRDS(file = "data/H1_day0_demultilexed_singlets.RDS") %>% SetAllIdent(id = "batch")
h1b1 = SubsetData(h1, ident.use = "1")
h1b2 = SubsetData(h1, ident.use = "2")

Then you use h1b1 and h1b2 as your positive ADT counts
# make list of positive protein matrices by batch
stained = list(h1b1, h1b2)
pos_adt = lapply(stained, function(x){x@assay$CITE@raw.data})

then you use the same h1b1 and h1b2 to analyze the RNA data
sc = list(h1b1, h1b2)
sc =  lapply(sc, function(x){ Convert(from = x, to = "sce") })
suppressMessages(library(scater))
sc = lapply(sc, FUN = calculateQCMetrics)

I don't understand what part of the seurat object has the RNA and what part the ADT.
Thank you,
Stephany

Hi Stephany,
Thank you for your interest in our data.
Seurat object is S4  object with the data located in slots that you can access with @ operator.
RNA data are located in h1@raw.data, h1@data, etc.
Meta-data for all cells are in h1@meta.data.
ADT data are from additional assay and are stored in assay slot, which is a list of multiple Seurat objects. You can access ADT raw data as h1@assay$CITE@raw.data.
Hope it helps.
Yuri

authors: kotliary sorjuela

repo: kotliary/baseline


text:
beforeProject / afterProject in TestListener is confusing

These methods won't be invoked in a test listener, so they should be in some kind of project listener.

small example:
class A : StringSpec() {

    override fun listeners(): List<TestListener> = listOf(object : TestListener {
        override fun beforeProject() {
            println("before project")
        }

        override fun afterProject() {
            println("after project")
        }
    })

    init {
        "test1" {
            println("test")
        }
    }
}

// will print:
// test

I removed the bug label, I don't think this is a bug.
It's confusing tho xD

How to deprecate this without breaking client code?
Currently, any user is implementing project listeners using the TestListener.

Maybe just deprecate it from TestListener and then add a new
ProjectListener.
On Tue, 25 Jun 2019, 13:24 Leonardo Colman Lopes, notifications@github.com
wrote:

How to deprecate this without breaking client code?
Currently, any user is implementing project listeners using the
TestListener.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kotlintest/kotlintest/issues/859?email_source=notifications&email_token=AAFVSGVOUKYTCQNI2DU3KTLP4JPEVA5CNFSM4H2XPGI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYRE2MI#issuecomment-505564465,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFVSGX2FJNOJPPUK5QHWDDP4JPEVANCNFSM4H2XPGIQ
.

Added ProjectListener

authors: Kerooker alladywek sksamuel

repo: kotlintest/kotlintest


text:
T.assertNotEquals(block: () -> T) function

Description
Create a new T.assertNotEquals(block: () -> T) function asserting that this value is not equal to the result of calling the block function.
Checklist

[ ] Implement.
[ ] Test.
[ ] Refactor.
[ ] Update Work in progress section in changelog.

We moved this issue to this new project.

repo: kotools/assert


text:
Add width and height

For the web, it doesn't seem to have a better UX for a small text. If width and height are added then it would be better for customization.

Thanks for the feedback @DevyankShaw it will be available in the next version

modifications are now available in the new version 1.4.0
check it out
https://pub.dev/packages/elegant_notification

modifications are now available in the new version 1.4.0
check it out
https://pub.dev/packages/elegant_notification

I just checked it, working as expected. Thanks, @koukibadr for the quick release!

authors: DevyankShaw koukibadr

repo: koukibadr/Elegant-Notification


text:
Issue when calling Rust from JS

Platform: OSX 10.12.6
Compiler: rustc 1.22.0-nightly (150b625a0 2017-10-08)
I have the following code:
extern crate stdweb;
use stdweb::Value;
use stdweb::unstable::TryFrom;

#[no_mangle]
pub extern fn print_value(v: Value) {
    println!("{:?}", &v);
    println!("{:?}", String::try_from(v));
}

fn main() {
    stdweb::initialize();
    stdweb::event_loop();
}

The code appears to compile just fine, but calling _print_value from JS leads to strange results:
_print_value(123)
> String("\u{0}\u{0}\u{0}\u{1}")
> Ok("\u{0}\u{0}\u{0}\u{1}")

_print_value("Hello")
> Maximum call stack size exceeded

The results I expected:
_print_value(123)
> Number(123)
> Err(...)

_print_value("Hello")
> String("Hello")
> Ok("Hello")

Have I been using Value incorrectly or is there a bug during translation from JS values to Value?

Yes, this is currently not supported. Calling a Rust function from JS requires serialization and deserialization of passed parameters (which is not exactly trivial), so you can't just simply call a function like that directly. (It would be possible to get this to work, but it would require support from the compiler - support which we don't have yet.)
What you need to do is to export that function from your main manually and call that, e.g. something like this:
js! {
    global.print_value = @{print_value};
}

Ok, good to know. Is this something that's on the stdweb roadmap? I've been looking at https://github.com/RReverser/asmjs-experiments and it looks like he's figured out how to reverse-engineer embind to bring real interop between JS and Rust values (strings, arrays, and structs especially). Unfortunately it looks like development on the repo has stopped.

Well, I'd definitely would want to support something like this in the future, although I'm not entirely sure if it's even possible to do it fully right now. When I'll have some time I might look into it more closely, but no promises.

@alex-shapiro You might not be interested in this anymore, but newest stdweb will support a #[js_macro] attribute (it's already merged in on master) with which you can mark a function, and that functions will be then export and callable from JavaScript. This, I believe, will do exactly what you've requested. (It only works on wasm32-unknown-unknown target though.)
So, closing.

I've been looking at RReverser/asmjs-experiments and it looks like he's figured out how to reverse-engineer embind to bring real interop between JS and Rust values (strings, arrays, and structs especially). Unfortunately it looks like development on the repo has stopped.

Heh, that feeling when you accidentally come across a mention of your project few years ago after the fact. Too bad I haven't seen this back then.

authors: RReverser alex-shapiro koute

repo: koute/stdweb


text:
help

can you explain to me what to change in order to run the script correctly ?

You should just run the file with no arguments, it will generate HTML-files with passwords and send them to the specified emails

authors: Tfimanayek kovinevmv

repo: kovinevmv/DigiSparkStealer


text:
Implement Channel Leave

Reference: https://api.slack.com/methods/channels.leave
Acceptance Criteria:

[x] Spring Slack Client is extended with given method
[x] Spring Slack Test Client is extended with given method
[x] JavaDoc/KDoc is added

closed by #291

repo: kreait/slack-spring-boot-starter


text:
Suggestion: tell about how Database#each is promisified

The SQLite module documentation refers to the SQLite3 module documentation, which documents Database#each. After the definition of the latter, it's hard to guess how it is promisified in the SQLite module. It's rather mandatory to separately document this.

Agreed and as always PRs are welcomed

Yeah, I got fed up with figure out/get this to work myself and just switched back to SQLite3

Credit Space from the Discord.js discord server. As he put it: "promises can only resolve once, you have to pass a callback for the 'each' part, the promise resolves after all rows have been run iirc" because of this, it's kinda impossible to circumvent callbacks without rewriting sqlite3 itself.
I would have to imagine the promise doesn't resolve until the loop has finished calling the supplied callback for each of the rows found by the query.
db.each(SELECT * FROM table, function(err, row) {       if (err) console.log(err);       console.log(row);     }).then(function() {       console.log("finished callbacks on each row");     });

v4 now has this documented in the readme, thanks

authors: Astrydax Hibou57 theogravity

repo: kriasoft/node-sqlite


text:
update webpack

need to switch to webpack 2.2 or higher, like everybody else

also enabled tree shaking through preventing babel from transpiling to commonjs in babel and babel-loader config. And enabled minified, production build

repo: kriswep/modern-modular-javascript

license: Unlicense


text:
[WIP] Adding krkn report location

Need to be able to specify where the kraken.report file gets created
+ python3.9 /root/kraken/run_kraken.py --config=/tmp/time_scenario_config.yaml
Traceback (most recent call last):
  File "/root/kraken/run_kraken.py", line 442, in <module>
    logging.FileHandler("kraken.report", mode="w"),
  File "/usr/lib64/python3.9/logging/__init__.py", line 1146, in __init__
    StreamHandler.__init__(self, self._open())
  File "/usr/lib64/python3.9/logging/__init__.py", line 1175, in _open
    return open(self.baseFilename, self.mode, encoding=self.encoding,
PermissionError: [Errno 13] Permission denied: '/krkn-hub/kraken.report'

Working as expected
%python run_kraken.py -o /tmp/kraken.report
....
....
2024-01-25 09:43:22,708 [INFO] telemetry collection disabled, skipping.
2024-01-25 09:43:22,708 [INFO] Successfully finished running Kraken. UUID for the run: 217c6431-133b-495f-bc81-b97be4914aff. Report generated at /tmp/kraken.report. Exiting

repo: krkn-chaos/krkn


text:
Performance Tests triggered by comment don't work against PRs originating from a Fork

Describe the bug
When I tried to run /perf tests by commenting on a PR that originated from my fork the action failed. It could not checkout the commit:
To Reproduce

comment /perf on a PR created from a Fork onto kroxylicious/kroxylicious
check the Actions to see your build fail

Expected behavior
We checkout the code from the fork and performance tests are run against that code.
YAML files and logs
build log
Relevant part is:
2023-03-09T04:32:03.0815988Z Initialized empty Git repository in /home/runner/work/kroxylicious/kroxylicious/.git/
2023-03-09T04:32:03.0831207Z [command]/usr/bin/git remote add origin https://github.com/kroxylicious/kroxylicious
2023-03-09T04:32:03.1597143Z [command]/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +refs/heads/micrometer-no-reflection*:refs/remotes/origin/micrometer-no-reflection* +refs/tags/micrometer-no-reflection*:refs/tags/micrometer-no-reflection*
2023-03-09T04:32:03.6362136Z The process '/usr/bin/git' failed with exit code 1

So we are trying to checkout micrometer-no-reflection but our remote is https://github.com/kroxylicious/kroxylicious not the fork.
I guess we want to supply repository: forky/branchy to the checkout action. Unfortunately this isn't emitted by the PR comment commit plugin yet

Probably a question here about whether we could restrict who can triggers perf runs.

FYI @franvila
Probably a question here about whether we could restrict who can triggers perf runs (do we already?)

repo: kroxylicious/kroxylicious


text:
ask

ga buat versi nodejs nya gan?

Gak bro,soalnya dia pawang ular :v

bjirr, kalo nodejs dah banyak yg buat

authors: Ascengi amiruldev20 krypton-byte

repo: krypton-byte/chappie-bot


text:
Remove double exclamation marks when Kotlin 1.3 arrives

I put !! in a couple of places. Once the project is migrated to Kotlin 1.3, they can be probably removed and the code will compile fine thanks to the contracts (https://github.com/Kotlin/KEEP/blob/master/proposals/kotlin-contracts.md).

Two problems:

   contract {
       returns() implies (rawVisualisation.xAxis != null)
   }

"Error in contract description: only references to parameters are allowed in contract description"
2. The compiler forces me to put '@kotlin.contracts.ExperimentalContracts on every level, from the function that the contract it used, all the way up to the place when the function is called. So if the main() function calls function A, then A calls B, and so on to Z which uses a contract, all functions from main and A to Z have to have this annotation.

https://discuss.kotlinlang.org/t/contracts-not-working-as-expected-when-dividing-into-functions/10095/6

Use explicit contracts. Add them as experimental to the build config.

https://youtrack.jetbrains.net/issue/KT-29101


text:
[#299] feat(wrappers): add Vampire/setup-wsl@v1

closes #299

ktlint fails :)

Yeah, strange IntelliJ didn't fix it up properly, fixed now.


text:
Adds Actions Code

This PR somewhat rewrites @sudomateo's setup-packer action to be suitable for more @hashicorp products.
This GitHub Action is specific to nomad-pack.
In this PR, I'm adding GitHub Actions for code quality, easier support for selecting which @hashicorp product to "setup" and documentation on how to use this action.

Thank you @joatmon08 and @DerekStrickland for volunteering your time to review this ❤

repo: ksatirli/setup-nomad-pack


text:
Release pinned azure-storage-blob version 12.9.0

/kind bug
What steps did you take and what happened:
I am running into dependencies issues with Kserve and azure-ai-ml.
My current workflow required the usage of azure-ai-ml. Would it be possible to unpin the version or upgrade azure-storage-blob to >=12.10.0,<13.0.0.
azure-ai-ml (>=1.0.0,<2.0.0) requires azure-storage-blob (>=12.10.0,<13.0.0)

What did you expect to happen:
To install azure-ai-ml and kserve in the same project.

/assign @sivanantha321

repo: kserve/kserve


text:
Update pyproject.toml for 0.11rc1

What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Type of changes
Please delete options that are not relevant.

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Feature/Issue validation/testing:
Please describe the tests that you ran to verify your changes and relevent result summary. Provide instructions so it can be reproduced.
Please also list any relevant details for your test configuration.

[ ] Test A

[ ] Test B

Logs

Special notes for your reviewer:

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Checklist:

[ ] Have you added unit/e2e tests that prove your fix is effective or that this feature works?
[ ] Has code been commented, particularly in hard-to-understand areas?
[ ] Have you made corresponding changes to the documentation?

Release note:

closing this as it is done in https://github.com/kserve/kserve/pull/3040


text:
Add a License to Project

Hey @michellepqa what type of license should be added to the project? (This is another test comment)

Thanks. I added the LICENSE file.

repo: kslupsky/github-projects-playground


text:
🛑 Orchestra is down

In c42f7ae, Orchestra (http://issue.chelsea.kt.co.kr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Orchestra is back up in 4573df2.

repo: kt-chelsea/status


text:
Compatibility with tidy5e-sheet NPC sheet

@ktrieun Hello,
Small PR to handle the new NPC feature from Tidy5e module.
The NPC sheet gets currency in Tidy :)

Thx!


text:
hackage

Hi,
Any chance this library could go on hackage? It's a nice library, I use it to good effect and it fills a niche I can't find elsewhere.

Tony,
Glad you like the package. I plan to push this to hackage before the semester starts (within a month or so). Will this work? I've got a number of planned tools that will depend on it.
Andy

Works well for me, thanks.  Look forward to seeing the resultant toolset.

repo: ku-fpg/javascript-bridge


text:
Mutation using formData does not have proper type

What version of kubb is running?
2.24.0 and canary (0.0.0-canary-20240730194937)
What platform is your computer?
Windows
What version of external packages are you using(@tanstack-query, MSW, React, Vue, ...)
"@kubb/cli": "^0.0.0-canary-20240730194937",     "@kubb/core": "^0.0.0-canary-20240730194937",     "@kubb/plugin-oas": "^0.0.0-canary-20240730194937",     "@kubb/swagger": "^0.0.0-canary-20240730194937",     "@kubb/swagger-client": "^0.0.0-canary-20240730194937",     "@kubb/swagger-tanstack-query": "^0.0.0-canary-20240730194937",     "@kubb/swagger-ts": "^0.0.0-canary-20240730194937",

What steps can reproduce the bug?
Generating a mutation with formData (post body) leads to incorrect types.
The following image shows an example of the conflicting logic of using FormData: the passed in data is a FormData but it was re-assembled in the generated hook function.

I believe the original thought was to pass in a typed object rather than formData. Tracking down how the type XXXX['request'] is defined, see the following image:

Obviously, the request type should not be plain FormData, the correct type should be the one as shown below

The issue was originated from https://github.com/kubb-labs/kubb/blob/03938ea4da087d2b39e4176186e360521c7924be/packages/swagger-tanstack-query/src/components/SchemaType.tsx#L46C36-L46C44
I think there is no need to switch types of request here since the FormData has been handled in the generated code. Here maybe just using TRequest is fine?
How often does this bug happen?
Every time
What is the expected behavior?
No response
Swagger/OpenAPI file?
No response
Additional information
No response

In v3 of Kubb this has been rewritten and also means the issue you have here would not happen again. I need to see if it would be possible to port the same logic back to v2

@stijnvanhulle Great to hear! Thank you for the efforts!

@wuyuanyi135 This has been resolved as part of Kubb v3, see https://github.com/kubb-project/kubb/blob/6f300a90a63e312d2473cd18834f93dca4e9f89e/packages/plugin-client/client.ts where data is not an union of TData and FormData. The type helper that we had before has also been removed in v3.

repo: kubb-labs/kubb


text:
Fix/traefik v15 compatibility

Fixes Traefik v15 issue identified in https://github.com/kube-hetzner/terraform-hcloud-kube-hetzner/pull/1053 by @mxmxchere and @benbehringer.

Merging as urgent (current master is broken).


text:
Make mutating webhook idempotent

Needs https://github.com/kube-logging/logging-operator/pull/1494 before merging.
Fixes #1444.

Will this be ported to main?

authors: OverOrion aslafy-z

repo: kube-logging/logging-operator


text:
remove the kubeconf from crd clusteroperation

Signed-off-by: hang.jiang hang.jiang@daocloud.io

What type of PR is this?

/kind cleanup
What this PR does / why we need it:

remove useless field in CRD clusterOperation

Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

/lgtm

repo: kubean-io/kubean


text:
Multi-AZ deployments

https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/#topology-awareness

[ ] ES: #499, #418

This issue has been resolved in KubeDB release v2021.03.17 . Please open a new bug if you still see this issue.

repo: kubedb/project


text:
[KF 1.3.1] Pin image type to be docker

Reference: https://github.com/kubeflow/pipelines/issues/5714
Make sure that Kubeflow cluster is using docker image type, otherwise pipeline will fail.
Also related: https://github.com/kubeflow/gcp-blueprints/issues/271#issuecomment-846299401

/lgtm
Thank you!

authors: Bobgy zijianjoy

repo: kubeflow/gcp-blueprints


text:
Add Robert Starmer as a contributor

This change is

Hi Robert,
We're always excited about new contributors. Have you already made some contributions? We typically ask people to make some initial contributions before joining the org.
You can read more here.
https://www.kubeflow.org/docs/about/contributing/#your-first-contribution
Thanks

I was going to send a pull request for the minikube setup script (and may
well try to update the multipass code as well.  I must have misread the
contribution process because I understood that I was supposed to join the
org before sending a pull.  I'm happy to put in my pull request first if
that's the right process.
R
On Sun, Dec 30, 2018 at 7:07 PM Jeremy Lewi notifications@github.com
wrote:

Hi Robert,
We're always excited about new contributors. Have you already made some
contributions? We typically ask people to make some initial contributions
before joining the org.
You can read more here.
https://www.kubeflow.org/docs/about/contributing/#your-first-contribution
Thanks
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubeflow/internal-acls/pull/39#issuecomment-450595942,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABbaR3ufqt5YyWlsIBkq4xsRgRR74BRfks5u-VVFgaJpZM4ZkhxZ
.

@robertstarmer Yes please submit the PR first and thanks for taking that on.

authors: jlewi robertstarmer

repo: kubeflow/internal-acls


text:
Make the Tensorflow serving version configurable

/kind feature
Describe the solution you'd like
[A clear and concise description of what you want to happen.]
Is it possible to make the Tensorflow Serving runtime version configurable? Now it defaults to 1.14 but a lot of models are in TensorFlow 2.0. Or is this feature already available?
I tried playing with the runtimeVersion variable by putting it to "2.1.0" but got the following error:
admission webhook "inferenceservice.kfserving-webhook-server.validator" denied the request: Tensorflow RuntimeVersion must be one of 1.11.0, 1.11.0-gpu, 1.12.0, 1.12.0-gpu, 1.13.0, 1.13.0-gpu, 1.14.0, 1.14.0-gpu
Is there a way to control the list of allowed images? I noticed this was recently removed by #917

@Svendegroote91 all the versions can be configured in inference service configmap https://github.com/kubeflow/kfserving/blob/master/install/v0.3.0/kfserving.yaml#L6900, you can add tensorflow 2.0 in the allowed version list and on the inference service yaml you can specify runtimeVersion field to use a specific version if you do not like the default one. Also as you can see the upcoming KFServing 0.4 release is no longer going to maintain this allowed version list so you can specify the version you want to use.

@yuzisun Awesome, thanks for clarifying. Closing the issue.

repo: kubeflow/kfserving


text:
Corrected Some Spelling And Grammatical Errors

What this PR does / why we need it:
Corrected some spelling and grammatical errors.
Which issue(s) this PR fixes
N/A

Pull Request Test Coverage Report for Build 7471919019

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 42.908%

Totals

Change from base Build 7423814404:
0.1%

Covered Lines:
3757

Relevant Lines:
8756

💛  - Coveralls

authors: coveralls daniel-hutao

repo: kubeflow/training-operator


text:
[AWS] Add IAM for service account instruction

Need a guidance for users to understand IAM for service account feature in Kubeflow 1.0 and how users can customize IAM roles for different kubernetes users.
Related changes:

https://github.com/kubeflow/kfctl/pull/225
https://github.com/kubeflow/kubeflow/pull/4751

/cc @Jeffwan

/assign @Jeffwan

PR has been merged and this can be closed.

authors: Jeffwan sarahmaddox

repo: kubeflow/website


text:
Why must a function's Gopkg.toml ignore "github.com/kubeless/kubeless/pkg/functions"

Is this a BUG REPORT or FEATURE REQUEST?:
BUG REPORT
What happened and What you expected to happen:
On my laptop, I can test that my function code builds by doing something like the following:
go build -o /dev/null ./some-func/*.go

However, to have kubeless build my function properly I must have this line in my Gopkg.toml:
ignored = ["github.com/kubeless/kubeless/pkg/functions"]

When this line is in my gopkg.toml and I run dep ensure , running go build locally no longer works because some code is missing from the vendor directory.
How to reproduce it (as minimally and precisely as possible):
Remove
ignored = ["github.com/kubeless/kubeless/pkg/functions"]

From the Gopkg.toml used by your function.
Anything else we need to know?:
Environment:
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.7", GitCommit:"dd5e1a2978fd0b97d9b78e1564398aeea7e7fe92", GitTreeState:"clean", BuildDate:"2018-04-19T00:05:56Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.6-gke.3", GitCommit:"dd22319bfbf58006ac48a872099493894cb2b520", GitTreeState:"clean", BuildDate:"2018-08-29T23:15:45Z", GoVersion:"go1.9.3b4", Compiler:"gc", Platform:"linux/amd64"}

$ kubeless version
Kubeless version: v1.0.0-alpha.8

Cloud provider or physical cluster: gke

So the explanation behind having to ignore vendor/github.com/kubeless/kubeless is because if it's not ignored, go dep will install the latest status (master) which can include changes incompatible with the current released version (the one included in the image at /go/src/github.com/kubeless/kubeless).
In any case it shouldn't be necessary for users to know that, we can remove the vendored version if it exists. (See #914).

authors: andresmgot gaigepr

repo: kubeless/kubeless


text:
[Feature Request]

Description
我根据kube-ovn文档配置vpc网关
1. 第一步：enable vpc网关：

2. 第二步：配置外部网络
apiVersion: kubeovn.io/v1
kind: Subnet
metadata:
  name: ovn-vpc-external-network
spec:
  protocol: IPv4
  provider: ovn-vpc-external-network.kube-system
  cidrBlock: 10.10.6.1/24
  gateway: 10.10.6.1  # IP address of the physical gateway
  excludeIps:
  - 10.10.6.0..10.10.6.10
---
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: ovn-vpc-external-network
  namespace: kube-system
spec:
  config: '{
      "cniVersion": "0.3.0",
      "type": "macvlan",
      "master": "eno8403",
      "mode": "bridge",
      "ipam": {
        "type": "kube-ovn",
        "server_socket": "/run/openvswitch/kube-ovn-daemon.sock",
        "provider": "ovn-vpc-external-network.kube-system"
      }
    }'

3. 第三步：创建vpc
kind: Vpc
apiVersion: kubeovn.io/v1
metadata:
  name: vpc-x
spec:
  staticRoutes:
    - cidr: 0.0.0.0/0
      nextHopIP: 10.0.1.254
      policy: policyDst
  namespaces:
  - vpcw
---
kind: Subnet
apiVersion: kubeovn.io/v1
metadata:
  name: vpcx-net1
spec:
  vpc: vpc-x
  cidrBlock: 10.0.1.0/24
  protocol: IPv4
  namespaces:
    - vpcw

4. 第四步：创建网关pod
kind: VpcNatGateway
apiVersion: kubeovn.io/v1
metadata:
  name: gw1
  namespace: vpcw
spec:
  vpc: vpc-x
  subnet: vpcx-net1
  lanIp: 10.0.1.254
  selector:
    - "kubernetes.io/hostname: kube-ovn-worker"
    - "kubernetes.io/os: linux"
  externalSubnets:
    - ovn-vpc-external-network

5. 第五步：创建nat规则
kind: IptablesEIP
apiVersion: kubeovn.io/v1
metadata:
  name: eipd01
spec:
  natGwDp: gw1
  externalSubnet: ovn-vpc-external-network
---
kind: IptablesDnatRule
apiVersion: kubeovn.io/v1
metadata:
  name: dnat01
spec:
  eip: eipd01
  externalPort: '8888'
  internalIp: 10.0.1.10
  internalPort: '80'
  protocol: tcp
---
kind: IptablesSnatRule
apiVersion: kubeovn.io/v1
metadata:
  name: snat01
spec:
  eip: eips01
  internalCIDR: 10.0.1.0/24

6. 第六步：创建测试pod

整体网络如下显示

7. 发现的问题
上述配置完开始测试。
在gw网关中ping 10.0.1.1可以平通
在gw网关中ping 外部网络 可以ping通
gw网关和测试pod相互无法ping通。
Who will benefit from this feature?
No response
Anything else?
No response

arp表彼此都能找到。就是无法ping通

这个 case gw网关和测试pod相互无法ping通。
请贴一下 gw 网关 pod 的路由，以及 测试 pod 的路由，以及 从 gw 网关 pod ping 测试 pod 不通的细节。
请补充下 kubeovn 的版本

repo: kubeovn/kube-ovn


text:
[BUG] Unable to start on Talos Linux

Kube-OVN Version
v1.13.0
Kubernetes Version
v1.31.1
Operation-system/Kernel Version
Talos (v1.7.6)
6.6.43-talos
Description
When the ovs-ovn daemonset tries to start the openvswitch container fails to start with this error:
/kube-ovn/start-ovs.sh: line 83: /usr/local/sbin/iptables: Operation not permitted

I have tried changing the securityContext to run this container privileged and as root but it still has this error.
Steps To Reproduce

Deploy a Talos Linux cluster
Deploy the helm chart from the master branch
Use these values:

---
cni_conf:
  CNI_CONFIG_PRIORITY: "10"
  MOUNT_LOCAL_BIN_DIR: false
func:
  ENABLE_NP: false
ipv4:
  POD_CIDR: "10.131.0.0/16"
  POD_GATEWAY: "10.131.0.1"
  SVC_CIDR: "10.128.0.0/20"
  JOIN_CIDR: "10.130.0.0/24"
  # PINGER_EXTERNAL_ADDRESS: "1.1.1.1"
  # PINGER_EXTERNAL_DOMAIN: "kube-ovn.io."
namespace: "kube-system"
DISABLE_MODULES_MANAGEMENT: true
OPENVSWITCH_DIR: "/var/kube-ovn/openvswitch"
OVN_DIR: "/var/kube-ovn/ovn"

I have followed the directions in the chart README I used a different path for OPENVSWITCH_DIR and OVN_DIR but I believe this should still work as I believe the primary intention is to move this path to a writeable path under /var.
Current Behavior
Pods in both ovs-ovn and kube-ovn-cni DaemonSets fail to start correctly
Expected Behavior
Pods should be running and healthy

I have tried these exact suggestions provided by @dosu, however, they do not resolve the issue

running iptables in the init container has the same Operation not permitted error.  I have tried both containers with:
securityContext:
      allowPrivilegeEscalation: true
      capabilities:
        allow:
          - ALL
      privileged: true
      runAsUser: 0
      runAsGroup: 0

with no luck.

@dosu running iptables in the init container has the same Operation not permitted error.  I have tried both containers with:
securityContext:
      allowPrivilegeEscalation: true
      capabilities:
        allow:
          - ALL
      privileged: true
      runAsUser: 0
      runAsGroup: 0

with no luck.

it occured to me to try symlinking iptables to /bin/true as is done for several other utilities that can't be used in talos however I have the same results with ovs-vswitchd which I know we can't shortcut.  @dosu any other ideas
/usr/share/openvswitch/scripts/ovs-ctl: 1: ovs-vswitchd: Operation not permitted

@dosu tried this, however, it doesn't resolve the problem

I get an error on the Daemonset that says:
cannot create regular file '/usr/local/bin/kubectl-ko': Read-only file system
And the Controller fails to connect to it kubernetes endpoint.

@nniehoff
I got the same problem, almost identical configuration. Running Talos 1.8.1, kube-ovn 1.13 via Helm.
Relevant values:
  cni_conf:
    CNI_CONFIG_PRIORITY: "10"
  OPENVSWITCH_DIR: "/var/lib/openvswitch"
  OVN_DIR: "/var/lib/ovn"
  DISABLE_MODULES_MANAGEMENT: true

I tried quite a few things and got this workaround - I'm not content with it, but at least it works for now in my test lab.
What I did:

Edited the Daemonset ovn-ovs
Change the image to  v1.12.28 for the openvswitch container (yes, the init container runs with v1.13.0)
Edit the security context and change runAsUser to 0

kubectl -n kube-system edit ds ovs-ovn
...
    spec:
      containers:
      - command:
        - /kube-ovn/start-ovs.sh
        image: docker.io/kubeovn/kube-ovn:v1.12.28
        name: openvswitch
        securityContext:
          capabilities:
            add:
            - NET_ADMIN
            - NET_BIND_SERVICE
            - SYS_NICE
            - SYS_ADMIN
          privileged: true
          runAsUser: 0
...

I'm still getting an error, but I think that the paths are correct.
failed to generate container "XXXXYYYZZZZ" spec: failed to generate spec: failed to mkdir "/etc/origin/openvswitch": mkdir /etc/origin: read-only file system
I've already added the kernel parameter for openvswitch.
machine:
  kernel:
    modules:
    - name: openvswitch

These are the values I'm feeding the Helm chart:
global:
  images:
    kubeovn:
      tag: v1.12.28

ipv4:
  POD_CIDR: "10.244.0.0/16"
  POD_GATEWAY: "10.244.0.1"

DISABLE_MODULES_MANAGEMENT: true
OPENVSWITCH_DIR: /var/lib/openvswitch
OVN_DIR: /var/lib/ovn
cni_conf:
  MOUNT_LOCAL_BIN_DIR: false

Hey, I found there is a problem with caps:
ovs-vswitchd
# getcap /usr/lib/openvswitch-switch/ovs-vswitchd
/usr/lib/openvswitch-switch/ovs-vswitchd cap_net_bind_service,cap_net_admin,cap_sys_module,cap_sys_admin=eip

Talos Linux restricts to run any binary with cap_sys_module
iptables
# getcap /usr/sbin/xtables-legacy-multi
/usr/sbin/xtables-legacy-multi cap_net_admin,cap_net_raw,cap_sys_module=eip
# getcap /usr/sbin/xtables-nft-multi
/usr/sbin/xtables-nft-multi cap_net_bind_service,cap_net_admin,cap_net_raw,cap_sys_admin=eip

Here is the fix with setcap:
https://github.com/aenix-io/cozystack/blob/28c1f78efef29a69982f252a8c2a26c3a5802c10/packages/system/kubeovn/images/kubeovn/Dockerfile#L3-L6

ovn-central log:
Defaulted container "ovn-central" out of: ovn-central, hostpath-init (init)
PROBE_INTERVAL is set to 180000
OVN_LEADER_PROBE_INTERVAL is set to 5
OVN_NORTHD_N_THREADS is set to 1
ENABLE_COMPACT is set to false
ENABLE_SSL is set to true
ENABLE_BIND_LOCAL_IP is set to true
88.99.62.204
 * ovn-northd is not running
 * ovnnb_db is not running
 * ovnsb_db is not running
[{"uuid":["uuid","e9edff06-b4a8-4fe5-8d4c-2312db415c5a"]},{"uuid":["uuid","a8a83f03-148e-489d-a0ce-7c2803c6fb41"]}]
[{"uuid":["uuid","246c0db4-5612-4a4e-9c2d-1fae65f2247c"]},{"uuid":["uuid","835fb199-aa09-4b08-811c-39507d11ca96"]}]
ovsdb-client: failed to connect to "ssl:[88.99.62.204]:6641" (Connection refused)
 * Starting ovsdb-nb
2024-12-05T16:30:37Z|00001|reconnect|INFO|unix:/var/run/ovn/ovnnb_db.sock: connecting...
2024-12-05T16:30:37Z|00002|reconnect|INFO|unix:/var/run/ovn/ovnnb_db.sock: connected
 * Waiting for OVN_Northbound to come up
 * Starting ovsdb-sb
2024-12-05T16:30:37Z|00001|reconnect|INFO|unix:/var/run/ovn/ovnsb_db.sock: connecting...
2024-12-05T16:30:37Z|00002|reconnect|INFO|unix:/var/run/ovn/ovnsb_db.sock: connected
 * Waiting for OVN_Southbound to come up
 * Starting ovn-northd
I1205 16:30:37.739458     668 ovn.go:105] no --kubeconfig, use in-cluster kubernetes config
W1205 16:30:37.828397     668 ovn.go:383] no available northd leader, try to release the lock
E1205 16:30:38.834590     668 ovn.go:245] stealLock err signal: alarm clock

All right it is started working after I disabled NetworkManager support with this patch:
https://github.com/aenix-io/cozystack/blob/b7a51ba0bb4b47c7a0866cec0e9a0a2e43c473a5/packages/system/kubeovn/images/kubeovn/patches/disable-nm-syncer.diff
See https://github.com/kubeovn/kube-ovn/issues/4643 for more details,
so final working solution:
https://github.com/aenix-io/cozystack/blob/94b40b646b1c2d5ddc2eb3d72db10921fff83bea/packages/system/kubeovn/images/kubeovn/Dockerfile#L50-L54
Also ipset were added to setcap, because without it kube-ovn can't execute this binary

authors: PeterFalken kvaps nniehoff tamay86