text:
Use PSP from policy API group

This PR updates PSP examples to use policy/v1beta1 API group. This make them identical to what we already have in the kubernetes examples/ directory.
Related PRs in k8s repo: https://github.com/kubernetes/kubernetes/pull/54933 and https://github.com/kubernetes/kubernetes/pull/60145
PTAL @liggitt @tallclair
CC @simo5

For 1.10 Features: set Milestone to 1.10 and Base Branch to release-1.10

How to set Milestone to 1.10 ?

i’ll add the milestone through the gui
/assign

@php-coder the updates to the YAML and related YAML validation testing aren't passing through CI:
test/examples_test.go:176: undefined: policy.PodSecurityPolicy
test/examples_test.go:177: cannot use t (type runtime.Object) as type *extensions.PodSecurityPolicy in argument to "k8s.io/kubernetes/pkg/apis/extensions/validation".ValidatePodSecurityPolicy: need type assertion
test/examples_test.go:315: undefined: policy.PodSecurityPolicy
test/examples_test.go:316: undefined: policy.PodSecurityPolicy
test/examples_test.go:317: undefined: policy.PodSecurityPolicy
FAIL	k8s.io/website/test [build failed]

@heckj Ok, thanks! I'll look at it and update tomorrow.

@heckj It's green now.
@liggitt PTAL.

@heckj PTAL

/approve

authors: heckj php-coder


text:
fix: namespaces endpoint

This PR...
Changes

Fixes

Checklist

[ ] tested locally
[ ] added new dependencies
[ ] updated the docs
[ ] added a test

We can't really show all possible namespaces or do we?

source: gharchive/pull-request

authors: jasmingacic mortada-codes

repo: kubeshop/kuskgateway-api-server

license: MIT

license_type: permissive

license_source: github-api


text:
tech: add helpers for modal windows

Changes

add useModal hook for open/close handlers along with active state
get rid of createModalConfig in favor of passing pure callback from useModal
use global modal handler instead of locally displaying the modal

Fixes

How to test it

screenshots

Checklist

[x] tested locally
[ ] added new dependencies
[ ] updated the docs
[ ] added a test

I ran E2E tests locally, and they work well. Merging then.

repo: kubeshop/testkube-dashboard


text:
Update Jenkinsfile-online

ewdewdede

just do it

This is a public repo for all developer, the pull request is not necessary. you can fork this repo and update this for yourself.

repo: kubesphere/devops-maven-sample


text:
🐛 Make placement translator respect create-only setting on object

Summary
This PR makes the placement translator respect the create-only annotation introduced in #1099 .  This will allow us to go back to using kcp v0.11.0, which is good because kube-bind depends on some of the functionality that is disabled in our patched version of kcp.
This PR also moves the declaration of the annotation key into the relevant API file, because it is part of the interface.
This PR also makes the code consistently decode the annotation by comparing its value to "false".
Related issue(s)
Fixes #

/cc @waltforme
/cc @pdettori
/cc @ezrasilvera
/cc @yana1205

The force-push to 31bf804fa expands the unit test of the what-resolver.

The force-push to 7ae992d66 expands the set-binder unit test.

Just to make sure I got it - As far as I saw, you do allow a createOnly resource to still change the createOnly  annotation back to false , right ?

The placement translator is a state-based controller, continually reacting to the latest desired state. The kube API machinery has no way to prevent changes to annotations.

/lgtm

/approve

authors: MikeSpreitzer ezrasilvera waltforme

repo: kubestellar/kubestellar


text:
Use domainName instead of userDomainName when Token with User Name authentication type is selected

When creating an OpenStack provider with Token with User Name authentication type, the domainName/domainId is needed in the secret, while the userDomainName is not a must.
Currently, there is no Domain Name filed on creating provider page, the provider will be in connectonfailed status. Need to change the User Domain Name field to Domain Name

@qiyuann @mmartinv hi,
the Jira ticket say to use userDomainName:
https://issues.redhat.com/browse/MTV-542?focusedId=22280243&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-22280243
do you have a newer version of the fields to use ?

merged: https://github.com/kubev2v/forklift-console-plugin/pull/596
@qiyuann please close after verification

User Domain Name is changed to Domain Name now, the provider could reach to Ready status.

source: gharchive/issue

authors: qiyuann yaacov


text:
[Feature] vela cli uses namespace from kubeconfig if env not set

If vela env set has not been used, and a vela command requiring a namespace is used without specifying namespace, then use the namespace from the current KUBECONFIG rather than default.
Example commands would include:

vela status
vela up
vela list
... or any other command which accepts -n | --namesapce

Current behaviour:
$ kubectl config view --minify -o jsonpath='{.contexts[?(@.name == "'$(kubectl config view -o=jsonpath='{.current-context}')'")].context.namespace}'
my-namespace

$ kubeconfig get application
NAME                COMPONENT               TYPE           PHASE              HEALTHY   STATUS      AGE
my.app              my.app.component        webservice     workflowSucceeded  true      Ready:1/1   44h

$ vela list my.app
APP     COMPONENT       TYPE    TRAITS  PHASE   HEALTHY STATUS  CREATED-TIME

$ vela status my.app
Error: failed to load application my.app from namespace default: applications.core.oam.dev "my.app" not found

Desired behaviour:
$ kubectl config view --minify -o jsonpath='{.contexts[?(@.name == "'$(kubectl config view -o=jsonpath='{.current-context}')'")].context.namespace}'
my-namespace

$ kubeconfig get application
NAME                COMPONENT               TYPE           PHASE              HEALTHY   STATUS      AGE
my.app              my.app.component        webservice     workflowSucceeded  true      Ready:1/1   44h

$ vela list my.app
APP     COMPONENT         TYPE        TRAITS   PHASE               HEALTHY  STATUS     CREATED-TIME
my.app  my.app.component  webservice  gateway  workflowSucceeded   healthy  Ready:1/1  2022-11-22 16:44:15 +0000 GMT

$ vela status my.app
{status output...}

(vela list and vela status find app in kubeconfig current namespace my-namespace)
Initially discussed with @wonderflow and @FogDong in this slack thread

can you provide some resources to go though and get some hints to resolve this?

can you provide some resources to go though and get some hints to resolve this?

can you provide some resources to go though and get some hints to resolve this?

@PratikforCoding is that targetted at me? I'm afraid I don't know how to resolve it, I've nothing else I can add aside the repro in my OP.

authors: Kolossi PratikforCoding

repo: kubevela/kubevela


text:
use bitnami charts as dependencies

Suggestion for improvement and simplification
Instead of defining MySQL and Redis "charts" as subcharts just use existing charts from Bitnami:

https://artifacthub.io/packages/helm/bitnami/mysql
https://artifacthub.io/packages/helm/bitnami/redis

@christianknell, thanks, that's a good finding! Do you know if the volumes would be compatible between mysql and bitnami/mysql images?
@christianknell, @tanmay-bhat, do you think we can get some community help to use dependent subcharts for mysql and redis?

@rubenhak the Bitnami charts are run as non-root user. So i think the PVC can't be used right away because the file permissions wouldn't match. But the Bitnami charts come with an option to set these file permissions on initialization: https://artifacthub.io/packages/helm/bitnami/mysql?modal=values&path=volumePermissions.
So from my perspective they should be compatible, but i haven't tried this so far.
If you decide to switch to the Bitnami charts i can help you with development. See https://github.com/christianknell/helm-charts/tree/main/charts/shlink-backend for an example on how to define the dependencies and use the values in your own chart.

@christianknell, I guess we can compromise one time upgradability to use Bitnami sub-charts.
A help would be awesome! I looked through the chart definition, could see the chart dependency and the "mysql.enabled" flag, but couldn't see how other mysql variables are passed to the chart. Can you show how this would work with subcharts?

@rubenhak: i will have a try to use an existing pvc, when i start the transition to the Bitnami sub-charts.
Sub-charts are defined through "an extra hierachy" in your values.yaml. You can see in this example values.yaml the key mysql which takes the values for the mysql sub-chart. This works the same way with every sub-chart in Helm. See also this description in the documentation.

@rubenhak: I would try to migrate to the Bitnami charts between Christmas and new year's eve. Could you move this issue to the new helm repository please?

authors: christianknell rubenhak

repo: kubevious/kubevious


text:
ParallelMigrationsPerCluster have incorrect description

What happened:
parallelMigrationsPerCluster is described as follow(staging/src/kubevirt.io/api/core/v1/types_swagger_generated.go):
"parallelMigrationsPerCluster":      "ParallelMigrationsPerCluster is the total number of concurrent live migrations\nallowed cluster-wide. Defaults to 5",
But i can migrate  virtualmachines less than 5 at the same time.  Actually, the total number of concurrent live migrations is 4 when parallelMigrationsPerCluster = 5,  The code is as follows：

What you expected to happen:
I can migrate  5 virtualmachines   at the same time.
How to reproduce it (as minimally and precisely as possible):
migrate  virtualmachines numbers  more than 5 at the same time
Additional context:
Environment:

KubeVirt version (use virtctl version): latest
Kubernetes version (use kubectl version): k3s version v1.25.7+k3s-e7fe07fd
VM or VMI specifications: N/A
Cloud provider or hardware configuration: N/A
OS (e.g. from /etc/os-release): centos7
Kernel (e.g. uname -a): 5.10.167
Install tools: N/A
Others: N/A

Does setting parallelMigrationsPerCluster to 1 allow 0 migration then? Should be easy to test.
The code looks correct to me though, unless the current migration attempt is counted as a running migration, which it shouldn't.
@vladikr FYI

Does setting parallelMigrationsPerCluster to 1 allow 0 migration then? Should be easy to test. The code looks correct to me though, unless the current migration attempt is counted as a running migration, which it shouldn't. @vladikr FYI

Yes，When I configured it to 1, the migration was stuck all the time。 so i think this is a problem。
“findRunningMigrations" get the number of migrations based on the virtv1.VirtualMachineInstanceMigration, which includes the ones to be migrated at this time.

ParallelOutboundMigrationsPerNode are also such issues too

@BugMosquito I've checked the code and findRunningMigrations() correctly ignores migrations in pending state, I'm trying to test this as well.

@BugMosquito I tested KubeVirt main (59d9d7755dc406f4bd92f9e5dfb8ef64b7b1c149) and didn't experience this bug.
I set my KubeVirt like this:
spec:
  certificateRotateStrategy: {}
  configuration:
    migrations:
      parallelMigrationsPerCluster: 1

and I was able to migrate 1 VM at a time.
Can you re-check this and in case collect logs and relevant manifests?

authors: BugMosquito acardace jean-edouard

repo: kubevirt/kubevirt


text:
Failed to compile Kubevirt's functional tests

I'm getting the following error:
09:05:47 [check-patch.el7.x86_64] [ERROR]	Error scanning k8s.io/apimachinery/pkg/apis/meta/v1beta1: cannot find package "." in:
09:05:47 [check-patch.el7.x86_64] 	/root/.glide/cache/src/https-k8s.io-apimachinery/pkg/apis/meta/v1beta1

Link to the job: http://jenkins.ovirt.org/job/kubevirt_kubevirt-ansible_standard-check-pr/26/consoleFull

@gbenhaim I had this problem locally, make distclean before make helped me.

There seems to be an issue in the glide cache. Either delete the build container or run "make distclean".

Thanks! I will try it.

The suggested advice solved the issue, thanks.

authors: cynepco3hahue gbenhaim rmohr


text:
Fix duplicate check in kubevirt operator controller

What this PR does / why we need it:
The duplicate check in the kubevirt operator wasn't working because we were casting the kubevirt object incorrectly.
NONE

ouch, nice catch...

authors: davidvossel slintes


text:
[virt-launcher]: Perform graceful shutdown though ACPI without depending on virt-handler

What this PR does / why we need it:
Currently, when a signal such as SIGTERM arrives to virt-launcher, the following happens:

virt-launcher edits its domain metadata by calling MarkGracefulShutdownVMI()
VMController (which is part of virt-handler package) identifies that as part of its control loop and calls virt-lacunher's SignalShutdownVMI()
virt-launcher then shuts down the domain with ACPI.

Now, when a signal such as SIGTERM arrives to virt-launcher, it will skip informing virt-handler and take care to shut down itself. This will make graceful shutdown mechanism more resilient and reliable, especially if virt-handler is not responsive.
One example for a scenario this might be very helpful is on a host shutdown (without draining), on which virt-handler and virt-launcher will get SIGTERM at the same time. On this scenario virt-launcher cannot count on virt-handler to shut it down.
Release note:

Improve resiliency and reliability of virt-launcher graceful shutdowns

@vladikr

/cc @vladikr

/retest

/cc @davidvossel

Here are a few things to consider about this change.
Having the shutdown logic managed by virt-handler currently allows for both visibility (events are fired when graceful shutdown is starting) and eventual consistency (shutdown is continually tried by reconcile loop). In addition to this, it centralizes the shutdown procedure to a single component, which leaves less questions from a debug standpoint about what component is controlling what flow.

Well, I don't think we have a single shutdown logic in general. The VMI can shutdown independently, just by a guest OS user shutdown, getting a SIGTERM from a node-level component / privileged user, or even a k8s user deleting a vmipod.
I think it has value if virt-launcher, when getting a SIGTERM, will attempt to send an ACPI shutdown without relying on virt-handler, which may not be running for some reason.
Regardless of whether the virt-handler has managed to send an ACPI shutdown or not, the virt-launcher will still send a SIGTERM to QEMU, using the finalShutdownCallback [1].
Eventual consistency can be achieved in this case as well as the virt-launcher already has a finalShutdownCallback that is being called after gracePeriodSeconds.

One example for a scenario this might be very helpful is on a host shutdown (without draining), on which virt-handler and virt-launcher will get SIGTERM at the same time. On this scenario virt-launcher cannot count on virt-handler to shut it down.

If virt-handler can shutdown at the exact same time as virt-launcher, we have bigger issues here than ACPI. The VMI wouldn't be able to migrate during the node drain. Daemonsets are typically drained last.

it will skip informing virt-handler and take care to shut down itself.

Perhaps we already have a race between the virt-handler and the virt-launcher shutting down.

virt-handler will still attempt the shutdown due to the vmi.DeletionTimestamp != nil. So it will cause a race between virt-launcher and virt-handler to shutdown the VMI. I'm not completely sure what happens if both virt-handler and virt-launcher race to call shutdown. It might cause some unexpected noise. For example, errors commonly occurring due to virt-handler attempting to shutdown and already shutdown domain.

I think we can coordinate it by setting a shutdown flag in virt-launcher to prevent this.
I agree that we need better coordination between the virt-launcher and the virt-handler.

Is this PR a result of an issue that's occurring now? Understanding how this manifests itself in the wild in a negative way might help the discussion a bit.

I think this is a result of a direct node shutdown. (@iholder-redhat knows the details better) In this case, all processes (including child processes) will get a SIGTERM.
So I'm not sure that this PR will necessarily help us in this case, but I'm in favor of having virt-launcher attempt to send ACPI shutdown directly and not relying on the virt-handler.
[1] https://github.com/kubevirt/kubevirt/blob/main/cmd/virt-launcher/virt-launcher.go#L467

Here are a few things to consider about this change.
Having the shutdown logic managed by virt-handler currently allows for both visibility (events are fired when graceful shutdown is starting) and eventual consistency (shutdown is continually tried by reconcile loop). In addition to this, it centralizes the shutdown procedure to a single component, which leaves less questions from a debug standpoint about what component is controlling what flow.

I think that the biggest plus of the current logic is that a VMI shutdown is part of virt-handler's sync-loop and I'd keep it like that to make sure we don't miss anything (even if the shutdown itself is running on the same node and communication happens on a unix socket).

One example for a scenario this might be very helpful is on a host shutdown (without draining), on which virt-handler and virt-launcher will get SIGTERM at the same time. On this scenario virt-launcher cannot count on virt-handler to shut it down.

If virt-handler can shutdown at the exact same time as virt-launcher, we have bigger issues here than ACPI. The VMI wouldn't be able to migrate during the node drain. Daemonsets are typically drained last.

I don't think node draining comes into play here, when a node is drained we protect the VMI with a PDB and we migrate it to another node, no SIGTERM or any other signal is delivered to virt-launcher. (right?)

it will skip informing virt-handler and take care to shut down itself.

virt-handler will still attempt the shutdown due to the vmi.DeletionTimestamp != nil. So it will cause a race between virt-launcher and virt-handler to shutdown the VMI. I'm not completely sure what happens if both virt-handler and virt-launcher race to call shutdown. It might cause some unexpected noise. For example, errors commonly occurring due to virt-handler attempting to shutdown and already shutdown domain.
Is this PR a result of an issue that's occurring now? Understanding how this manifests itself in the wild in a negative way might help the discussion a bit.

I believe both sides have good points (removing all logic from virt-handler or not), what I'd suggest instead is to keep the shutdown logic as is and just have a special case for when virt-handler receives a SIGTERM only on that occasion I'd have virt-handler trying to shutdown using ACPI as it means something at the OS-level is happening and we just cannot fight the init system if it decided to deliver SIGTERM to everyone as a result of the host shutting-down, this special-casing shouldn't interfere with any other logic.

Some clarifications:

I got this idea from a similar bug that deals with direct node shutdown (shutting down a node without draining it properly first). This PR does not resolve the bug and does not address its root issue - but might be helpful for similar situations. I think @vladikr phrased it perfectly: I think it has value if virt-launcher, when getting a SIGTERM, will attempt to send an ACPI shutdown without relying on virt-handler, which may not be running for some reason.
It's not that all of the shutdown logic is removed from virt-handler now. The only responsibility that is transferred to virt-launcher is shutting itself down when receiving a deadly signal such as SIGTERM. virt-handler still manages all other shutdown reasons and virt-launcher won't ever shut itself down unless a SIGTERM is received.
As @acardace put it: what I'd suggest instead is to keep the shutdown logic as is and just have a special case for when virt-handler receives a SIGTERM (I assume he meant virt-launcher there). That's exactly right. All logic remains the same, but receiving a SIGTERM is indeed a special case since we have to shut down as quickly as we can under the assumption that every process in the OS got SIGTERM at the same time as us or even before. In such a scenario the current logic would work only under the assumption that virt-handler is available and responsive, that it would be quick enough to shut all virt-launchers down in time, while we do not control OS' grace periods. Many side-effects can arise in such an extreme case (networking might not work since services also got SIGTERM, etc').

Also, I fully agree with @davidvossel's point - a single component that manages everything and can monitor and alert is great, both for simplicity and visibility. But all of this doesn't apply on a direct OS shutdown where everyone gets SIGTERM and there's an urgent need to shut down ASAP.

It's not that all of the shutdown logic is removed from virt-handler now. The only responsibility that is transferred to virt-launcher is shutting itself down when receiving a deadly signal such as SIGTERM. virt-handler still manages all other shutdown reasons and virt-launcher won't ever shut itself down unless a SIGTERM is received.

what shutdown procedure is virt-handler responsible for that doesn't also result in virt-launcher receiving SIGTERM?
I think that unless a guest is internally shutdown, all the external ways of shutting down a VMI involve marking the VMI for deletion. By marking a VMI for deletion (deletiontimestamp!=nil), the pod is also marked for deletion which in turn will result in SIGTERM being sent to virt-launcher.
If we shift the responsibility of graceful shutdown to virt-launcher, i'd like virt-launcher to be the only component attempting to coordinate the shutdown. In this PR, I believe both virt-handler's reconcile loop and virt-launcher's gracefulSHutdownCallback() are both trying to do the same thing concurrently.

It's not that all of the shutdown logic is removed from virt-handler now. The only responsibility that is transferred to virt-launcher is shutting itself down when receiving a deadly signal such as SIGTERM. virt-handler still manages all other shutdown reasons and virt-launcher won't ever shut itself down unless a SIGTERM is received.

what shutdown procedure is virt-handler responsible for that doesn't also result in virt-launcher receiving SIGTERM?

All of them :smiley:
Eventually, every shutdown that virt-handler initiates involves calling to ShutdownVirtualMachine(), and after the grace period is over, KillVirtualMachine(). These are virt-launcher's client functions. This means that virt-handler doesn't directly send SIGTERM to virt-launcher nor directly doing any operation to shut down - but instead it asks virt-launcher to perform the graceful shutdown for itself.
This PR does not change any of this.

I think that unless a guest is internally shutdown, all the external ways of shutting down a VMI involve marking the VMI for deletion. By marking a VMI for deletion (deletiontimestamp!=nil), the pod is also marked for deletion which in turn will result in SIGTERM being sent to virt-launcher.

Further to what I've written above, the only this does PR changes is the scenario in which virt-launcher is directly receiving SIGTERM. This can't be caused by virt-handler trying to shut down virt-launcher as I wrote above.
This can be caused though by a sudden node shutdown without draining. In such a scenario the OS can trigger a direct SIGTERM to virt-launcher. This is what this PR deals with.
In such a scenario, today, virt-launcher marks itself as needing shutdown. Then, virt-handler sees this mark, and uses its regular mechanism to shutdown virt-launcher, which is calling virt-launcher's ShutdownVirtualMachine() and (if grace period expires) KillVirtualMachine() as described above.
To sum it all up, when the OS sends SIGTERM directly to virt-launcher, this happens:

virt-launcher gets SIGTERM and marks itself for deletion
virt-handler sees the mark and calls virt-launcher's ShutdownVirtualMachine()
virt-launcher shuts itself down gracefully

In the specific scenario in which virt-launcher gets a direct SIGTERM from the OS, steps (1) and (2) are not only unnecessary, but they are dangerous since virt-handler might not be responsive, or response too slowly, therefore we're jeopardizing the ability of virt-launcher to terminate itself without a good reason.

If we shift the responsibility of graceful shutdown to virt-launcher, i'd like virt-launcher to be the only component attempting to coordinate the shutdown. In this PR, I believe both virt-handler's reconcile loop and virt-launcher's gracefulSHutdownCallback() are both trying to do the same thing concurrently.

Today:
virt-handler has the responsibility to trigger shutdown
virt-launcher has the responsibility of performing the shutdown.
With this PR's changes:
Only when a direct SIGTERM is sent from OS - virt-launcher would have the responsibility of performing the shutdown without waiting for virt-handler to trigger it.

Eventually, every shutdown that virt-handler initiates involves calling to ShutdownVirtualMachine(), and after the grace period is over, KillVirtualMachine(). These are virt-launcher's client functions. This means that virt-handler doesn't directly send SIGTERM to virt-launcher nor directly doing any operation to shut down - but instead it asks virt-launcher to perform the graceful shutdown for itself.

The kubelet sends SIGTERM to virt-launcher every time a VMI is deleted because we're deleting the pod in virt-controller when we see the VMI is being deleted.
That's why I asked the question "what shutdown procedure is virt-handler responsible for that doesn't also result in virt-launcher receiving SIGTERM?". I believe the answer is none of them due to the pod deletion + kubelet tear down.

Further to what I've written above, the only this does PR changes is the scenario in which virt-launcher is directly receiving SIGTERM. This can't be caused by virt-handler trying to shut down virt-launcher as I wrote above.

but kubelet is shutting down virt-launcher.
Sequence of events.

delete VMI
virt-controller deletes vmi pod
virt-handler sees vmi is being deleted and starts shutdown
virt-launcher receives and traps SIG_TERM sent by kubelet.
eventually vmi pod terminates.

Right now, items 3 and 4 get routed through virt-handler due to virt-launcher only trapping the SIG_TERM and alerting virt-handler that a graceful shutdown needs to be processed.
I think what we have in your PR is both virt-handler and virt-launcher are both converging on libvirt to shutdown the domain at the same time.

With this PR's changes:
Only when a direct SIGTERM is sent from OS - virt-launcher would have the responsibility of performing the shutdown without waiting for virt-handler to trigger it.

my concern is that with your PR, virt-handler still signals virt-launcher to do the shutdown under nearly every ordinary shutdown sequence we have today where the VMI is shutdown by deleting the VMI object.

The kubelet sends SIGTERM to virt-launcher every time a VMI is deleted because we're deleting the pod in virt-controller when we see the VMI is being deleted.

That's a good point, I didn't realize that until now. Thanks for educating me here.
That makes me fully agree with what you wrote earlier:

If we shift the responsibility of graceful shutdown to virt-launcher, i'd like virt-launcher to be the only component attempting to coordinate the shutdown.

Looking at the code again I see that the only case in which virt-handler deals with shutting down is, as you said, the case in which the VMI is being deleted.
If VMI is being deleted, virt-handler doesn't need to do anything. SIGTERM will be sent to virt-launcher which will handle the shutdown.
I will add a commit that would remove virt-handler shut down logic entirely.

Hey @davidvossel,
After digging deeper into the code I've come to realize this is more complicated that I thought. The main challenge here is updating the grace period.
Currently, since the handler is solely responsible for shutdowns, it:

Gets the most updated grace period (directly from the VMI's spec)
Calculates whether the grace period exceeded
Triggers SignalShutdownVMI() as long as grace period didn't exceed, KillVMI() otherwise.

The problem with moving the logic into virt-handler's hands is that virt-launcher can't really know the updated grace period since it can't talk directly to the API server and ask for a VMI object. This basically means that the VMI's grace period field would become meaningless.
Consider this example:
> k create -f my-vmi.yaml # In this yaml file, a grace period of 100 seconds is defined
...
> k edit vmi my-vmi # The vmi's grace period is changed to 50 seconds
...
> k delete -f my-vmi.yaml

Currently the delete operation would trigger a SIGTERM to virt-launcher. virt-launcher would "mark itself for shutdown", virt-handler would notice that and will manage shutdown logic as I described above. In other words - the new defined grace period will take effect. But if logic will move to virt-launcher - then during a SIGTERM it won't have any idea what is the currently updated grace period.
One possible solution is to, somehow, get notified if grace period is updated and tell virt-launcher (through gRPC) that grace period should be updated. Not sure how or if that's possible / reasonable.
Another options is to disallow the update of grace period entirely (or to set it back during reconciliation loop). This might (?) be a reasonable approach, except we have virtctl which needs to have this capability, especially for stop --force --grace-period=0. Currently virtctl simply updates grace period for the VMI and then deletes it - similarly to the shell example above. To overcome this virtctl would have to ask launcher client to shut down the VMI (though SignalShutdownVMI() or other similar gRPC call) and ask for a new grace period directly from virt-launcher and only then delete the VMI. While this approach is possible it will make code more error prone and harder to understand, since the responsibility is moved to whoever tries to shutdown a VMI which will need to be aware of all of this.
Considering the above I'm not sure what is the right path forward here. When opening this PR my assumption was that SIGTERM for virt-launcher is a rare event that can be dealt with separately, but this is not the case as I understand now.
WDYT?
@vladikr would appreciate your thought on this as well.

Considering the above I'm not sure what is the right path forward here. When opening this PR my assumption was that SIGTERM for virt-launcher is a rare event that can be dealt with separately, but this is not the case as I understand now.

Should we consider the option of "proceed as is"? and accept that if someone issues a shutdown locally on a node that their VMs likely will not receive a ACPI shutdown?
I believe the situation we're talking about solving here is graceful shutdown of VMs when virt-handler isn't a part of the picture. This would mean termination is occurring outside of the k8s ecosystem at the host level. Do pods even have their grace periods observed in the scenario we're solving for?
It would be nice for virt-launcher to be able to coordinate the shutdown, but if this is getting overly complicated it's unclear if the benefits outweigh the risks and complexity involved.

Should we consider the option of "proceed as is"? and accept that if someone issues a shutdown locally on a node that their VMs likely will not receive a ACPI shutdown?
I believe the situation we're talking about solving here is graceful shutdown of VMs when virt-handler isn't a part of the picture. This would mean termination is occurring outside of the k8s ecosystem at the host level. Do pods even have their grace periods observed in the scenario we're solving for?
It would be nice for virt-launcher to be able to coordinate the shutdown, but if this is getting overly complicated it's unclear if the benefits outweigh the risks and complexity involved.

Yup.. a bit disappointing but I tend to agree.
Thanks a lot for exploring this with me.
/close

Yup.. a bit disappointing but I tend to agree.
Thanks a lot for exploring this with me.

@iholder-redhat lets consider this idea on hold for now until we have a use case that forces us to re-evaluate our position. Right now I don't think the risk/reward adds up in favor of us making the change, but I'm certainly open to the idea if new info comes into the picture.

authors: acardace davidvossel iholder-redhat vladikr


text:
Run chcon on local storage path in disks-images-provider

Signed-off-by: Alex Kalenyuk akalenyu@redhat.com

What this PR does / why we need it:
Testing on environments that are not kubevirtci, we won't have https://github.com/kubevirt/kubevirtci/blob/main/cluster-provision/k8s/1.23/k8s_provision.sh#L172-L173
done for us. Let's make sure disks-images-provider does that.
Right now this doesn't happen which results in a broken hotplug test on OpenShift environment.
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 #
Special notes for your reviewer:
Release note:

NONE

/lgtm

/retest

@zhlhahaha @akalenyu My apologies, these changes won't affect Ubuntu host case.

/uncc @zhlhahaha

/approve

/approve

Thanks!

/retest

/cherrypick release-0.49

authors: akalenyu awels enp0s3


text:
deps: Bump google/cel-go to v0.20.1

Description
Supersedes https://github.com/kubewarden/cel-policy/pull/21

Test

Additional Information
Tradeoff

Potential improvement

Closing, included in https://github.com/kubewarden/cel-policy/pull/30.

repo: kubewarden/cel-policy


text:
Set up a Github runner

We use to have a self-hosted github runner to run our e2e tests in the past. But due some issue we lost the instance and we rely on the VM created by @kravciak which could die anytime as well. Therefore, we need to create a new runner in GCP for our CI jobs.

By the way, if you want a no-maintenance method to achieve that, you can use cirun.io for the same.

authors: aktech jvanz

repo: kubewarden/kubewarden-end-to-end-tests


text:
Update developing operators docs for the release

This is reflecting the changes we did in the next released version.

let's hold this until we do the next release

Already partially done in #94 and the rest is in #98

repo: kudobuilder/www


text:
Aarch64 builds for Linux and MacOS

Should solve #22 and #24

Just a big thank you to @kuelumbus and the developers/maintainers for this project and specifically the support of M1 chips.

authors: brifordwylie kuelumbus

repo: kuelumbus/rdkit-pypi


text:
Collapse sidebar navigation when space is lacking

Description

Collapse the sidebar navigation automatically when there isn’t enough space for it
Allow expanding it by pressing a button

I’m closing this because we didn’t run into a pressing need for this since.

repo: kumahq/kuma-gui


text:
Create a User Dashboard component

A file already exists in the user folder for userDashboard.
Edit that component and display the user's email and name.

Hey @kunaljain0212  can you assign me this work?

Sure go ahead!

Hey I have seen the project files but I am unable to understand from where I have to fetch the user name and email, so can you please help me.

https://github.com/kunaljain0212/Apni-Dukaan-Backend/blob/master/routes/user.js
This is the backend repo for this project. In the above-mentioned file, we already have a route to get user details. You can use that particular route for fetching user details.

Is someone working on this currently? can I pick this up?

Sure go ahead! @khush021

If you are facing problem in setting up the backend then you can use this link:
https://apni-dukaan-backend.herokuapp.com/
To use this link create a .env file as example.env and add this backend link to the backend variable.

Is there any issue with the backend because these APIs are not returning any response
https://apni-dukaan-backend.herokuapp.com/products
https://apni-dukaan-backend.herokuapp.com/signin

The backend is designed such that you'll have to use /api before accessing any route.
For ex. https://apni-dukaan-backend.herokuapp.com/api/products

okay got it

Can you please guide me how to pass values from one component to another. I am trying to use access name and email from signIn to userDashboard

For a signed in user we have a middleware which sets a property user in the req object whenever any restricted route is accessed. So what you can do is make the user dashboard a restricted route which it practically should be and then just fetch the user details from the user property of the req object.

got it

I raised a request, can you please review it

@khush021 Can you give the component a bit of styling? If not please open an issue for the same.

created issue


text:
[New game]: Dice game

🎮 Game Request
Engaging two-player dice game where the objective is to be the first to reach a total score of 100 points. Players take turns rolling a die and accumulate points during their turn. The twist is that if a player rolls a 1, their current turn's score is reset to 0, and their turn ends. Players must strategize when to roll and when to hold to avoid losing points and give themselves the best chance to win.
Game Rules
Point down the features

Two Players: The game is played with two players.

Turn-Based Play: Players alternate turns rolling a single die.

Scoring: On their turn, a player can roll the die as many times as they wish. Each roll adds the die's value to the player's temporary score for that turn.

Rolling a 1: If a player rolls a 1, their temporary score for that turn is reset to 0, and their turn ends immediately.

Holding: A player can choose to hold at any time during their turn, adding their temporary score to their total score and ending their turn.

Winning the Game: The first player to reach a total score of 100 points wins the game.

Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

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

/assign

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

repo: kunjgit/GameZone


text:
pen pointer fight game wtr to #3889

I have added a new game named "Pen Pointer Fight" wrt issue #3889. @kunjgit kindly review the pull request and incorporate the changes.

Thank you @bhumika-1127 ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

@kunjgit I have update the readme.md. Kindly review and let me know.

/assign

@kunjgit Kindly review the PR. I have made the necessary changes and resolved the conflict.

@kunjgit Kindly review the PR.

Thank you  @bhumika-1127 , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


text:
Update README.md

PR Description 📜
Duplicate games in readme.md
Fixes #757
Thank you soo much for contributing to our repository 💗

Thank you @SimranLahrani842 ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

@SimranLahrani842 LGTM

@SimranLahrani842 LGTM

Resolved merge conflicts please merge my PR.

we have to keep both on the GameZone 👀 !!!

Thank you  @SimranLahrani842 , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


text:
this.static_field is not allowed

In Lang-304, NPEX generated the following patch:
if (this.LocaleSet == null)
return false;
But, this patch is invalid since LocaleSet is static field.

Resolved.

authors: SeongjoonHong intotking

repo: kupl/npex


text:
Naming collision with vbmc

While this isn't a show stopper for my uses. I think it could impact or even confuse other people.
Is there a reason you named the cli vbmc which conflicts with another project?
What if you named it vcbmc and vcbmcd (vCenter BMC) ... or vsbmc (yes, those names may be awful, but you get the idea)? Thoughts?

Thanks for creating issue.
It's one of the things that I thought might be a problem someday.
This project started as a "fork" of the original VirtualBMC from OpenStack, so to be precise, I didn't "give" it the same name, but I "leave" the name without giving new one.
Since this was a personal project and I wasn't using KVM, I didn't have to worry about name conflicts. And I figured I could coexist if I use both in separated containers.
In the first place, since it is a "Virtualized BMC", I think the abbreviations "VirtualBMC" and "vbmc" are very good name. The "vSphere BMC" is also attractive for my project, but difficult to use because its abbrevation "vbmc" is as same as original one...

Thanks for explaining the background. That makes sense.
The full name would avoid confusion for sure. What are your thoughts about something shorter likevsbmc? That would keep it short but would still be different?
I'm asking in case someone finds a reason to rename it :)... I figured it was worth getting the conversation out there for any other lurkers out there using it.

Released as 0.1.0. Thanks for your contribution!

Great work :+1:

authors: codekow kurokobo

repo: kurokobo/virtualbmc-for-vsphere


text:
Added method 'withSound', updated example in readme

Added method 'withSound' to define the notification sound, udpated the readme example to include the new method

Title of PR should be:
[1.x] Add method withSound

withSound() is not working in laravel 9. I had to customize the package as per your commit. Please recheck it.

Old PR, also duplicate of #45

repo: kutia-software-company/larafirebase


text:
Test rust API against the dynamic library/single file header

Moved from #2136 as it's the only outstanding part and so that issue can be closed.
The rust API advertises support for linking against the pre-built dynamic library and using the single file header, and that has been manually tested in the past, but it should be tested in CI to make sure that all the functions and symbols used are actually available in the single file header and the restricted dynamic library.

This was actually completed in #3519

repo: kuzudb/kuzu


text:
Merge BMFileHandle and FileHandle

Description
Merge BMFileHandle and FileHandle.

I do wonder a little if the FileHandle in its current state is doing too much (even before the merge).

Yeah. I have the same concern too. My previous thought is to decouple the read/write to file to a util class that will take in FileHandle instead to get the fileInfo for reads and writes. While FileHandle will appear to be manly interact with BufferManager.
BMFileHandle could handle writing through the buffer manager, and FileHandle could handle direct writes through writePagesToFile, etc. Then they could both internally share some metadata (the FileInfo, number of pages, page states, etc.). This makes sense to me. Let me think a bit how this can be done in a separate PR.


text:
many measures of the same type in the same payload

We need a solution to have many measures of the same type in a payload.

https://github.com/kuzzleio/kuzzle-device-manager/issues/168

authors: Aschen TisserantG

repo: kuzzleio/kuzzle-device-manager


text:
Discrete collision detection with GJK is broken when same object that shape is Rectangle or Cuboid are given

rustc --version: rustc 1.21.0 (3b72af97e 2017-10-09)
OS: Windows 10 Pro 1709
collision-rs version: master branch (3cb6779)

Issue

Rectangle: Can't detect collision.
Cuboid: Cant't detect collision and GJK::distance() panics.

Code
use cgmath::{Basis2, Decomposed, Quaternion, Rad, Rotation2, Rotation3, Vector2, Vector3};
use collision::algorithm::minkowski::{GJK2, GJK3};
use collision::primitive::*;

fn transform(x: f32, y: f32, angle: f32) -> Decomposed<Vector2<f32>, Basis2<f32>> {
    Decomposed {
        disp: Vector2::new(x, y),
        rot: Rotation2::from_angle(Rad(angle)),
        scale: 1.,
    }
}
fn transform_3d(x: f32, y: f32, z: f32, angle_z: f32) -> Decomposed<Vector3<f32>, Quaternion<f32>> {
    Decomposed {
        disp: Vector3::new(x, y, z),
        rot: Quaternion::from_angle_z(Rad(angle_z)),
        scale: 1.,
    }
}

{
    let gjk = GJK2::new();
    let trans = &transform(0., 0., 0.);

    let shape = &Rectangle::new(10., 10.);
    println!("{:?}", gjk.intersect(shape, trans, shape, trans)); // None
    println!("{:?}", gjk.distance(shape, trans, shape, trans)); // None
}
{
    let gjk = GJK3::new();
    let trans = &transform_3d(0., 0., 0., 0.);

    let shape = &Cuboid::new(10., 10., 10.);
    println!("{:?}", gjk.intersect(shape, trans, shape, trans)); // None
    println!("{:?}", gjk.distance(shape, trans, shape, trans)); // thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src\libcore\option.rs:335:20
}

Continuous collision detection works properly.
By the way, I got
thread 'main' panicked at 'Simplex processing failed to deduce that this simplex [Vector3 [NaN, NaN, NaN], Vector3 [NaN, NaN, NaN], Vector3 [NaN, NaN, NaN]] is an edge case', C:\Users\Ix5231\.cargo\git\checkouts\collision-rs-2c62c906efffa0e5\3cb6779\src\algorithm\minkowski\gjk\simplex\simplex3d.rs:147:12

at GJK::distance() when I tried Sphere. Is it a bug?

If you use the exact same shape Gjk will get divide by zero I guess. It's a bit difficult to get around so it's not being handled at all atm, so yes, you will have undefined results. It's quite rare you'll have exactly overlapping shapes with the same primitive.

As for me, it seems pretty logical when there's no intersection between absolutely equal shapes from math side.

This is an edge case, I think it occurs because all support points will be the origin.

The problem will become calculating a collision normal, in what direction should that be if they are exactly overlapping?

I think there should be simply no collision, but also no panic.

Not sure that's the best idea. This would also occur for two different shapes that are exactly overlapping.

So, I checked into it now, and the basic issue for exactly overlapping shapes, is that all support points become the origin.

Which makes sense when you realise that a support point is the point in a direction on one shape - the point in the same direction on the other shape, which will always be the same point of they are exactly overlapping.

Ok, so the basic issue is that the search direction used for calculating the support points become degenerate (zero vector), because the lines between the points pass through the origin.

So, the good news is that i've fixed the discrete tests. The bad news is that the continuous tests now fail.

So, you will now get a collision from exact overlaps, the collision normal is degenerate though, it can point in any direction. Some more care when applying the contact resolution should fix this.
And tbh, I don't see this scenario occur in the wild very often.

authors: Rhuagh ix5231 torkleyy vitvakatu

repo: kvark/collision-rs

license_source: bigquery


text:
own data do not give good 3D reconstruction

Hello there, I tried your code to test on my own data. You can find my training image example as follows,

I collected 50 images to cover 360-degree view. I used your code for reconstruction, the results are like this,

There are some holes and blur on the background.
As you said, some background can help for 3D rendering, but apparantly, NeRF cannot handle objects with complicated background, right? Can you share your opinion to us? Thank you!

Hello sir, did you use the colmap colab notebook? If so mine isn't working in the installation part for some reason. If you made any changes to it can you share them with me?

I think the problem you are facing is due to collecting good images like there is too much background the model might be learning, try with a small object on a monotone background like a white screen/sheet.

authors: Holmes-Alan asad-ak


text:
Tidal range display

0.7 introduced the display of the tidal range neap/spring/normal which is very nice :)
Checking the values however, I was wondering how spring/neap is done. Usually, I would expect spring around full/new moon, neaps around first and last quarter with a period of ~4 days for each phase (normal is sometimes shorted to 3 days due to solar vs. lunar days).
In Trail Sense I see e.g. normal for 3rd and 4th of September 2020, while the official tables give a spring from 2nd  (full moon) till the 5th, then a normal from 6th..9th and neap from 10th (3rd quarter)..13th so I think the spring/neap period in Trail Sense is shorter?
Note that I use tables for the German Bight. In this areas we see a delay of tides of some days as the North Sea is a bit special compared to the free oceans. See e.g. Tide timing
isRelatedTo: #125

Thank you, maybe I was a bit too ambitious with this feature - I didn't consider how local variations could affect this as well. The algorithm is really simple: is the moon is full/new then it is a spring tide and same for neap tides and the quarter moons.
The algorithm should really be if the moon was full in the last ~80-90 hours, then spring. I'll try to address this and compare against some tide tables.
With that said, I may mark this feature as experimental under the newly added setting in 0.8.0

is the moon is full/new then it is a spring tide and same for neap tides and the quarter moons.

BTW: this isn't too bad, especially if you allow for a spring delay of n days. One would need to look up the n required for the current place, but they are actually tabulated or you can derive it from an old fashioned printed or electronic tide table by checking the lowest low / highest high next to full/new moon.


text:
Open current beacon in TS Maps

When currently navigating to a beacon, provide a button to open it in TS Maps (if installed)

Done, just that the quick action isn't used by default


text:
SPM: dependency graph is unresolvable

Tried to add Commander to a SPM project with the following Package.swift:
// swift-tools-version:4.0

import PackageDescription

let package = Package(
	name: "LocalizableCheck",
	dependencies: [
		.package(url: "https://github.com/kylef/Commander.git", from: "0.8.0"),
		.package(url: "https://github.com/kylef/PathKit.git", from: "0.8.0"),
		.package(url: "https://github.com/sharplet/Regex.git", from: "1.1.0"),
	],
	targets: [
		.target(
			name: "LocalizableCheck",
			dependencies: [
				"PathKit",
				"Regex"
			]
		)
	]
)

When I try swift package update, I get the following error:

error: dependency graph is unresolvable; found these conflicting requirements:
Dependencies:
https://github.com/kylef/PathKit.git @ 0.8.0..<1.0.0

Note that it complains about PathKit, but it happens when I add Commander to the project. Without Commander there's no issue. I have no clue why this is, but I'm guessing this is because of the common dependency on Spectre, with different version requirements from: "0.8.0" and .upToNextMinor(from:"0.8.0").

I've released PathKit 0.9.0 which updates the version of Spectre. This should allow you to continue after updating PathKit.

Tested and it works now, thx!

I think I am incurring into the same issue:
// swift-tools-version:4.0
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "XCodeTools",
    dependencies: [
        // Dependencies declare other packages that this package depends on.
        .package(
            url: "https://github.com/kylef/PathKit.git",
            from: "0.9.0"
        ),
        .package(
            url: "https://github.com/kylef/Stencil.git",
            from: "0.10.0"
        )
    ],
    targets: [
        // Targets are the basic building blocks of a package. A target can define a module or a test suite.
        // Targets can depend on other targets in this package, and on products in packages which this package depends on.
        .target(
            name: "XCodeTools",
            dependencies: ["XCodeToolsCore"]
        ),
        .target(
            name: "XCodeToolsCore",
            dependencies: []
        ),
    ]
)

Once I try swift package update I get:
Fetching https://github.com/kylef/Stencil.git
Fetching https://github.com/kylef/PathKit.git
Fetching https://github.com/kylef/Spectre.git
error: dependency graph is unresolvable; found these conflicting requirements:

Dependencies:
    https://github.com/kylef/Stencil.git @ 0.10.0..<1.0.0

Same issue here, any update of this?

Using Stencil master branch fixed my problem, I think Stencil need a new tag for this issue.  (kylef/Stencil#206)

authors: djbe kylef luca-i marcuswu0814

repo: kylef/Commander


text:
[refine] Add possibility of manual webhook setup on existing GitHub repository.

DESCRIPTION
AC

[ ] Research

mistake

authors: KarolJaksik ksputo

repo: kyma-incubator/hack-showcase


text:
React on sisb deletion

Description
Changes proposed in this pull request:

the main controller starts/stops ServiceInstance controller which watches if the last SI (SB) was removed. If yes, and the BTP operator is in deletion state (and watining for SI/SB removal) then triggers btpoperator reconciliation by changing state to HardDelete
small changes in env tests

Related issue(s)
https://github.com/kyma-project/btp-manager/issues/228

/hold

testing scenario:

run k3d, install latest btp manager, for example: /run_module_image.sh europe-docker.pkg.dev/kyma-project/prod/unsigned/component-descriptors/kyma.project.io/module/btp-operator:v0.3.3
modify the image - use from this PR
Apply secret and operator yamls: kubectl apply -f examples/btp-manager-secret.yaml and kubectl apply -f examples/btp-operator.yaml
create service instance, for example:

apiVersion: services.cloud.sap.com/v1alpha1
kind: ServiceInstance
metadata:
  name: btp-auditlog-4
  namespace: default
spec:
  serviceOfferingName: auditlog-api
  servicePlanName: default
  externalName: btp-auditlog-2

Delete btp operator resource (deletion is stopped)
delete service instance (and remove finalizer from the SI)
expected result: btp operator is finally removed

/unhold

repo: kyma-project/btp-manager


text:
Remove loki output

Description
As follow up of the disabled loki output (https://github.com/kyma-project/telemetry-manager/issues/461), the output should get removed finally. The API was not usable for nearly one year and not documented anywhere, so it can be safely removed.
Criterias

Verify that there is no cluster using the output
There is no loki output in the alpha and beta version available
No occurence of the API is available in the docu, code, tests
Validation/reason is cleaned up

Reasons

Attachments

Release Notes

The grafana-loki output removed from both versions of LogPipeline removed
The test and validation code related to the grafana-loki removed
The grafana-loki output was removed from documents and examples
All customer clusters from all environments checked for the existence of LogPipelines with grafana-loki output, and no occurrence was found

authors: a-thaler hisarbalik

repo: kyma-project/telemetry-manager


text:
StoryBook 'Show Code' under the Docs section does not display the expected html code

Describe the bug
The Show Code section under Docs section of DataTable does not show the Pagination related source code.
To Reproduce
Steps to reproduce the behavior:

Go to https://kyndryl-design-system.github.io/shidoka-applications/?path=/docs/components-data-table--docs#data-table
Click on 'Show code' button on the right bottom corner.
Scroll down to Code section.
See the Code.

Expected behavior
The code should display the Pagination related HTML tags (code).
Screenshots

Hi there. The Show Code option on the Docs page is limited, because it only shows compiled output. Take a look at individual stories, and the Code tab in the Addons panel, to see the original source.


text:
Logging

Replace System.out calls with logger.
OSGi.getInstance().getLog() might be used.

I think 'll remain with this. User can provide own IProgressMonitor.

repo: kyrillzotkin/ClassSupplier


text:
[Fix] Consistency check to run immediately when FlowStats is first received.

Fixes #114

Fixed consistency check to run immediately when FlowStats is first received.

Local tests
Using this branch

Once FlowStats is first received and consistency check started, after 4ms in the same cycle, it detected a missing flow:

kytos $> 2022-10-24 11:02:58,745 - INFO [kytos.core.atcp_server] [atcp_server.py:131:connection_made] (MainThread) New connection from 127.0.0.1:57598
2022-10-24 11:02:58,746 - INFO [kytos.core.atcp_server] [atcp_server.py:182:connection_lost] (MainThread) Connection lost with client 127.0.0.1:57598. Reason: Request closed by client
2022-10-24 11:02:58,851 - INFO [kytos.core.atcp_server] [atcp_server.py:131:connection_made] (MainThread) New connection from 127.0.0.1:57612
2022-10-24 11:02:58,858 - INFO [kytos.napps.kytos/of_core] [main.py:138:handle_features_reply] (thread_pool_sb_0) Connection ('127.0.0.1', 57612), Switch 00:00:00:00:00:00:00:01: OPENFLO
W HANDSHAKE COMPLETE
2022-10-24 11:02:58,877 - INFO [kytos.napps.kytos/flow_manager] [main.py:571:_send_flow_mods_from_request] (Thread-93) Send FlowMod from request dpid: 00:00:00:00:00:00:00:01, command: a
dd, force: False, flows_dict: {'flows': [{'priority': 1000, 'table_id': 0, 'cookie': 12321848580485677057, 'match': {'dl_type': 35020, 'dl_vlan': 3799}, 'actions': [{'action_type': 'outp
ut', 'port': 4294967293}]}]}
2022-10-24 11:02:58,887 - INFO [werkzeug] [_internal.py:225:_log] (Thread-93) 127.0.0.1 - - [24/Oct/2022 11:02:58] "POST /api/kytos/flow_manager/v2/flows/00:00:00:00:00:00:00:01 HTTP/1.1
" 202 -
2022-10-24 11:03:00,380 - INFO [kytos.napps.kytos/flow_manager] [main.py:333:check_consistency] (thread_pool_sb_2) check_consistency on switch 00:00:00:00:00:00:00:01 has started
2022-10-24 11:03:00,384 - INFO [kytos.napps.kytos/flow_manager] [main.py:361:check_missing_flows] (thread_pool_sb_2) Consistency check: missing flow on switch 00:00:00:00:00:00:00:01.
2022-10-24 11:03:00,385 - INFO [kytos.napps.kytos/flow_manager] [main.py:365:check_missing_flows] (thread_pool_sb_2) Flow forwarded to switch 00:00:00:00:00:00:00:01 to be installed. Flo
w: {'flows': [{'cookie': 0, 'match': {'in_port': 1, 'dl_vlan': 105}, 'actions': [{'action_type': 'output', 'port': 1}], 'table_id': 0, 'priority': 101, 'idle_timeout': 0, 'hard_timeout':
 0}]}
2022-10-24 11:03:00,385 - INFO [kytos.napps.kytos/flow_manager] [main.py:336:check_consistency] (thread_pool_sb_2) check_consistency on switch 00:00:00:00:00:00:00:01 is done
kytos $>

Testing out with an alien flow, 6ms after in the same cycle the alien flow was detected:

2022-10-24 11:06:50,899 - INFO [kytos.napps.kytos/flow_manager] [main.py:336:check_consistency] (thread_pool_sb_0) check_consistency on switch 00:00:00:00:00:00:00:01 is done
2022-10-24 11:06:51,699 - INFO [kytos.core.atcp_server] [atcp_server.py:182:connection_lost] (MainThread) Connection lost with client 127.0.0.1:57612. Reason: Request closed by client
2022-10-24 11:07:10,153 - INFO [kytos.core.atcp_server] [atcp_server.py:131:connection_made] (MainThread) New connection from 127.0.0.1:37000
2022-10-24 11:07:10,663 - INFO [kytos.napps.kytos/of_core] [main.py:138:handle_features_reply] (thread_pool_sb_2) Connection ('127.0.0.1', 37000), Switch 00:00:00:00:00:00:00:01: OPENFLO
W HANDSHAKE COMPLETE
2022-10-24 11:07:10,692 - INFO [kytos.napps.kytos/flow_manager] [main.py:571:_send_flow_mods_from_request] (Thread-102) Send FlowMod from request dpid: 00:00:00:00:00:00:00:01, command:
add, force: False, flows_dict: {'flows': [{'priority': 1000, 'table_id': 0, 'cookie': 12321848580485677057, 'match': {'dl_type': 35020, 'dl_vlan': 3799}, 'actions': [{'action_type': 'out
put', 'port': 4294967293}]}]}
2022-10-24 11:07:10,698 - INFO [werkzeug] [_internal.py:225:_log] (Thread-102) 127.0.0.1 - - [24/Oct/2022 11:07:10] "POST /api/kytos/flow_manager/v2/flows/00:00:00:00:00:00:00:01 HTTP/1.
1" 202 -
kytos $>

kytos $> 2022-10-24 11:07:12,203 - INFO [kytos.napps.kytos/flow_manager] [main.py:333:check_consistency] (thread_pool_sb_0) check_consistency on switch 00:00:00:00:00:00:00:01 has starte
d
2022-10-24 11:07:12,209 - INFO [kytos.napps.kytos/flow_manager] [main.py:408:check_alien_flows] (thread_pool_sb_0) Consistency check: alien flow on switch 00:00:00:00:00:00:00:01
2022-10-24 11:07:12,210 - INFO [kytos.napps.kytos/flow_manager] [main.py:413:check_alien_flows] (thread_pool_sb_0) Flow forwarded to switch 00:00:00:00:00:00:00:01 to be deleted. Flow: {
'flows': [{'switch': '00:00:00:00:00:00:00:01', 'table_id': 0, 'match': {'in_port': 1}, 'priority': 1000, 'idle_timeout': 0, 'hard_timeout': 0, 'cookie': 4097, 'id': '13bc34e4a7a3d61cd0d
0ebb7c49991ff', 'stats': {'byte_count': 0, 'duration_sec': 9, 'duration_nsec': 789000000, 'packet_count': 0}, 'cookie_mask': 0, 'instructions': [{'instruction_type': 'apply_actions', 'ac
tions': [{'port': 2, 'action_type': 'output'}]}]}]}
2022-10-24 11:07:12,217 - INFO [kytos.napps.kytos/flow_manager] [main.py:336:check_consistency] (thread_pool_sb_0) check_consistency on switch 00:00:00:00:00:00:00:01 is done
kytos $>

Using the current master branch

Notice below that it took more than one consistency check cycle to confirm that it was missing (so, it wasn't taking advantage of this initial iteration that could've been react promptly):

kytos $> 2022-10-24 11:16:58,262 - INFO [kytos.core.atcp_server] [atcp_server.py:131:connection_made] (MainThread) New connection from 127.0.0.1:37328
2022-10-24 11:16:58,770 - INFO [kytos.napps.kytos/of_core] [main.py:138:handle_features_reply] (thread_pool_sb_0) Connection ('127.0.0.1', 37328), Switch 00:00:00:00:00:00:00:01: OPENFL
OW HANDSHAKE COMPLETE
2022-10-24 11:16:58,807 - INFO [kytos.napps.kytos/flow_manager] [main.py:569:_send_flow_mods_from_request] (Thread-93) Send FlowMod from request dpid: 00:00:00:00:00:00:00:01, command:
add, force: False, flows_dict: {'flows': [{'priority': 1000, 'table_id': 0, 'cookie': 12321848580485677057, 'match': {'dl_type': 35020, 'dl_vlan': 3799}, 'actions': [{'action_type': 'ou
tput', 'port': 4294967293}]}]}
2022-10-24 11:16:58,814 - INFO [werkzeug] [_internal.py:225:_log] (Thread-93) 127.0.0.1 - - [24/Oct/2022 11:16:58] "POST /api/kytos/flow_manager/v2/flows/00:00:00:00:00:00:00:01 HTTP/1.
1" 202 -
2022-10-24 11:17:00,298 - INFO [kytos.napps.kytos/flow_manager] [main.py:331:check_consistency] (thread_pool_sb_2) check_consistency on switch 00:00:00:00:00:00:00:01 has started
2022-10-24 11:17:00,308 - INFO [kytos.napps.kytos/flow_manager] [main.py:334:check_consistency] (thread_pool_sb_2) check_consistency on switch 00:00:00:00:00:00:00:01 is done
kytos $>
kytos $>

kytos $> 2022-10-24 11:18:27,804 - INFO [kytos.napps.kytos/flow_manager] [main.py:331:check_consistency] (thread_pool_sb_0) check_consistency on switch 00:00:00:00:00:00:00:01 has start
ed
2022-10-24 11:18:27,816 - INFO [kytos.napps.kytos/flow_manager] [main.py:359:check_missing_flows] (thread_pool_sb_0) Consistency check: missing flow on switch 00:00:00:00:00:00:00:01.
2022-10-24 11:18:27,821 - INFO [kytos.napps.kytos/flow_manager] [main.py:363:check_missing_flows] (thread_pool_sb_0) Flow forwarded to switch 00:00:00:00:00:00:00:01 to be installed. Fl
ow: {'flows': [{'cookie': 0, 'match': {'in_port': 1, 'dl_vlan': 105}, 'actions': [{'action_type': 'output', 'port': 1}], 'table_id': 0, 'priority': 101, 'idle_timeout': 0, 'hard_timeout
': 0}]}
2022-10-24 11:18:27,822 - INFO [kytos.napps.kytos/flow_manager] [main.py:334:check_consistency] (thread_pool_sb_0) check_consistency on switch 00:00:00:00:00:00:00:01 is done
kytos $>

I'll also run e2e tests with this PR.

Good catch, @viniarck ! It looks good to me! Please share the results of the e2e tests when you have them.

Thanks for reviewing, @italovalcy. Sure thing, it's on https://github.com/amlight/kytos-end-to-end-tests/pull/178, once you have more feedback about that PR let's continue this conversation on that one, thanks.

Good catch, @viniarck ! It looks good to me! Please share the results of the e2e tests when you have them.

Thanks for reviewing, @italovalcy. Sure thing, it's on amlight/kytos-end-to-end-tests#178, once you have more feedback about that PR let's continue this conversation on that one, thanks.

I've also run it again locally, isolated from this e2e branch since that branch was also validating a new e2e change, so, I'll go ahead and merge this, and then we'll continue on that one, thanks, Italo:
❯ docker logs kytos-end-to-end-tests-kytos-1
Starting enhanced syslogd: rsyslogd.
/etc/openvswitch/conf.db does not exist ... (warning).
Creating empty database /etc/openvswitch/conf.db.
Starting ovsdb-server.
Configuring Open vSwitch system IDs.
Starting ovs-vswitchd.
Enabling remote OVSDB managers.
+ sed -i 's/STATS_INTERVAL = 60/STATS_INTERVAL = 3/g' /var/lib/kytos/napps/kytos/of_core/settings.py
+ sed -i 's/CONSISTENCY_MIN_VERDICT_INTERVAL =.*/CONSISTENCY_MIN_VERDICT_INTERVAL = 3/g' /var/lib/kytos/napps/kytos/flow_manager/settings.py
+ sed -i 's/LINK_UP_TIMER = 10/LINK_UP_TIMER = 1/g' /var/lib/kytos/napps/kytos/topology/settings.py
+ sed -i 's/DEPLOY_EVCS_INTERVAL = 60/DEPLOY_EVCS_INTERVAL = 5/g' /var/lib/kytos/napps/kytos/mef_eline/settings.py
+ sed -i 's/LLDP_LOOP_ACTIONS = \["log"\]/LLDP_LOOP_ACTIONS = \["disable","log"\]/' /var/lib/kytos/napps/kytos/of_lldp/settings.py
+ sed -i 's/LLDP_IGNORED_LOOPS = {}/LLDP_IGNORED_LOOPS = {"00:00:00:00:00:00:00:01": \[\[4, 5\]\]}/' /var/lib/kytos/napps/kytos/of_lldp/settings.py
+ sed -i 's/CONSISTENCY_COOKIE_IGNORED_RANGE =.*/CONSISTENCY_COOKIE_IGNORED_RANGE = [(0xdd00000000000000, 0xdd00000000000009)]/g' /var/lib/kytos/napps/kytos/flow_manager/settings.py
+ sed -i 's/LIVENESS_DEAD_MULTIPLIER =.*/LIVENESS_DEAD_MULTIPLIER = 3/g' /var/lib/kytos/napps/kytos/of_lldp/settings.py
+ kytosd --help
+ sed -i s/WARNING/INFO/g /etc/kytos/logging.ini
+ test -z ''
+ TESTS=tests/
+ python3 scripts/wait_for_mongo.py
Trying to run hello command on MongoDB...
Trying to run 'hello' command on MongoDB...
Trying to run 'hello' command on MongoDB...
Ran 'hello' command on MongoDB successfully. It's ready!
+ for i in {1..1}
+ echo 'iter 1'
+ python3 -m pytest tests/ --timeout=300 -k flow_manager
iter 1
============================= test session starts ==============================
platform linux -- Python 3.9.2, pytest-6.2.5, py-1.11.0, pluggy-1.0.0
rootdir: /tests
plugins: timeout-2.0.2
timeout: 300.0s
timeout method: signal
timeout func_only: False
collected 208 items / 152 deselected / 56 selected

tests/test_e2e_20_flow_manager.py ................                       [ 28%]
tests/test_e2e_21_flow_manager.py ..                                     [ 32%]
tests/test_e2e_22_flow_manager.py ...............                        [ 58%]
tests/test_e2e_23_flow_manager.py X......................                [100%]

------------------------------- start/stop times -------------------------------
=== 55 passed, 152 deselected, 1 xpassed, 137 warnings in 2833.64s (0:47:13) ===
+ tail -f


text:
[Feature] Migrated from storehouse to MongoDB

Fixes #75 and #77
Description of the change

Migrated from storehouse to MongoDB
DB collections diagram (I'll update this on kytos-ng.github.io repo soon):

Release notes
Added

MongoDB integration with pymongo
Flows are stored now on MongoDB flows collections
Consistency checks executions are stored on MongoDB flow_checks collection
FlowController and DB models
scripts/storehouse_to_mongo.py script to migrate data from storehouse to MongoDB

Changed

Removed log.info send FlowMod from the request hot path for now
Refactored consistency check to leverage flow_id and match_id

Deprecated

Storehouse file system backend

Removed

Storehouse backend and its locks
match13_strict to simplify application logic since match strict was primarily for matching an exact flow, which without wildcards is simpler to do and maintain by using flow_id (flow.id) instead

e2e tests with this branch
+ python3 -m pytest tests/ -k flow_manager
============================= test session starts ==============================
platform linux -- Python 3.9.2, pytest-6.2.5, py-1.11.0, pluggy-1.0.0
rootdir: /tests
plugins: timeout-2.0.2
collected 190 items / 134 deselected / 56 selected

tests/test_e2e_20_flow_manager.py ................                       [ 28%]
tests/test_e2e_21_flow_manager.py ..                                     [ 32%]
tests/test_e2e_22_flow_manager.py ...............                        [ 58%]
tests/test_e2e_23_flow_manager.py X......................                [100%]

Benchmarks

Using a single or two flows in the request which on average is the request load pattern that mef_eline will typicall have, and putting a load of 60 requests / sec:

MongoDB:

❯ jq -ncM '{method: "POST", url: "http://localhost:8181/api/kytos/flow_manager/v2/flows/00:00:00:00:00:00:00:01", body: { "force": true, "flows": [ { "priority": 10, "match": { "in_port"
: 1, "dl_vlan": 100 }, "actions": [ { "action_type": "output", "port": 1 } ] } ] } | @base64, header: {"Content-Type": ["application/json"]}}' | vegeta attack -format=json -rate 60/1s -d
uration=60s | tee results.bin | vegeta report
Requests      [total, rate, throughput]         3600, 60.02, 60.01
Duration      [total, attack, wait]             59.989s, 59.982s, 6.742ms
Latencies     [min, mean, 50, 90, 95, 99, max]  5.639ms, 25.178ms, 12.458ms, 63.162ms, 84.636ms, 129.578ms, 175.396ms
Bytes In      [total, mean]                     133200, 37.00
Bytes Out     [total, mean]                     439200, 122.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      202:3600
Error Set:

Storehouse:

❯ jq -ncM '{method: "POST", url: "http://localhost:8181/api/kytos/flow_manager/v2/flows/00:00:00:00:00:00:00:01", body: { "force": true, "flows": [ { "priority": 10, "match": { "in_port"
: 1, "dl_vlan": 100 }, "actions": [ { "action_type": "output", "port": 1 } ] } ] } | @base64, header: {"Content-Type": ["application/json"]}}' | vegeta attack -format=json -rate 60/1s -d
uration=60s | tee results.bin | vegeta report
Requests      [total, rate, throughput]         3600, 60.02, 59.98
Duration      [total, attack, wait]             1m0s, 59.982s, 40.27ms
Latencies     [min, mean, 50, 90, 95, 99, max]  6.8ms, 96.359ms, 65.211ms, 247.198ms, 301.328ms, 452.76ms, 549.812ms
Bytes In      [total, mean]                     133200, 37.00
Bytes Out     [total, mean]                     439200, 122.00
Success       [ratio]                           100.00%
Status Codes  [code:count]                      202:3600
Error Set:

MongoDB, MongoDB is 4x ish times faster on average with higher concurrency capabilities.
Next

Enhance and handle issue #80
Continue investigating core queues bottle issue #79

Very nice to have mongodb for flow_manager and it is very satisfying to see the performance improvements enabled by this PR. I've reviewed the code and also run a few tests and it looks good to me!
I've tested this PR in different ways:

Running manual tests to understand what is going on step by step
Running the migration scripts/procedure
Running end-to-end tests (found a minor issue in the end-to-end related to ordering after enabling some tests for sdntrace/sdntrace-cp)
restarting Kytos multiple times and checking the switches's flow table wouldn't be affected
deleting flows from switches's flow tables and checking if kytos would recreate then
etc.

My only comment would regarding the removal of log.info from the hot path of send_flow_mods. I think that logging is quite useful for troubleshooting and actually understand what is going on in the application (especially when you have to do that a few hours later an event). I know we are going towards having ES, APM, etc. in place, but having the log messages usually pays off when you are trying to make sense out of a problem (old school troubleshooting style). So that, I suggest include the log.info back to send_flow_mods, unless there is a huge impact and we cannot improve other ways.
Once again, congratulations!

@italovalcy I really appreciated your review and thanks for also exploring this as well, good to know. I'll check it out this e2e test that you mentioned to better understand. Regarding the log.info, I've replied to you on another thread.

Appreciated your reviews @italovalcy and @ajoaoff.


text:
King attack evaluation

Results from testing in panic4:
STC:
Elo   | 19.11 +- 9.67 (95%)
SPRT  | 8.0+0.08s Threads=1 Hash=8MB
LLR   | 2.89 (-2.25, 2.89) [0.00, 5.00]
Games | N: 2894 W: 923 L: 764 D: 1207
Penta | [80, 306, 553, 391, 117]

http://chess.grantnet.us/test/34357/
LTC:
Elo   | 19.09 +- 9.60 (95%)
SPRT  | 40.0+0.40s Threads=1 Hash=64MB
LLR   | 2.91 (-2.25, 2.89) [0.00, 5.00]
Games | N: 2642 W: 766 L: 621 D: 1255
Penta | [49, 272, 561, 363, 76]

http://chess.grantnet.us/test/34358/
+42 bytes (same thing was +19 bytes in panic4)

Merged in #254


text:
Commander Context Guild is null

Describe the bug
When accessing the guild from the context of a command from Commander, it returns null
To Reproduce
final bot = Nyxx([Token], GatewayIntents.allUnprivileged);
var c = Commander(bot, prefix: '%');

var cGroup = CommandGroup(name: 'commandGroup', aliases: ['q']);

cGroup.registerSubCommand('subCommand', (context, message) => {
        context.sendMessage(MessageBuilder.content('Some Text : ${context.guild.id.toString()}')),  // <- Fails due to guild == null;
});

Expected behavior
I should be able to access the guild information
Desktop (please complete the following information):

OS: macOS 11.4 (20F71)
OS: Ubuntu 16.04.7 LTS (gcloud)
Dart version: 2.14.0-48.0.dev
Nyxx version
nyxx: ^2.0.0-rc.10
nyxx_commander: ^2.0.0-rc.10
nyxx_interactions: ^2.0.0-rc.13

Additional context
The bot has Administrator permissions.
This was working on older versions of Nyxx
I can access other properties of context, such as message just fine

Thanks, looking into now. Will try repro :)

Ok this is the designed behaviour see:
https://github.com/l7ssha/nyxx/blob/dev/nyxx_commander/lib/src/CommandContext.dart#L15
https://github.com/l7ssha/nyxx/blob/dev/nyxx_commander/lib/src/Commander.dart#L119
The guild on the context is nullable and in the commander it tries to get the guild from cache only if not found returning null which means the guild must not be in your cache. If you get the message and do:
final bot = Nyxx([Token], GatewayIntents.allUnprivileged);
var c = Commander(bot, prefix: '%');

var cGroup = CommandGroup(name: 'commandGroup', aliases: ['q']);

cGroup.registerSubCommand('subCommand', (context, message) => {
        final guild = await context.message.guild.getOrDownload()
        context.sendMessage(MessageBuilder.content('Some Text : ${guild.id.toString()}')),
});

That should work for you.

Ok this is the designed behaviour see:
https://github.com/l7ssha/nyxx/blob/dev/nyxx_commander/lib/src/CommandContext.dart#L15
https://github.com/l7ssha/nyxx/blob/dev/nyxx_commander/lib/src/Commander.dart#L119
The guild on the context is nullable and in the commander it tries to get the guild from cache only if not found returning null which means the guild must not be in your cache. If you get the message and do:
final bot = Nyxx([Token], GatewayIntents.allUnprivileged);
var c = Commander(bot, prefix: '%');

var cGroup = CommandGroup(name: 'commandGroup', aliases: ['q']);

cGroup.registerSubCommand('subCommand', (context, message) => {
        final guild = await context.message.guild.getOrDownload()
        context.sendMessage(MessageBuilder.content('Some Text : ${guild.id.toString()}')),
});

That should work for you.

"The getter 'guild' isn't defined for the type 'Message'.
Try importing the library that defines 'guild', correcting the name to the name of an existing getter, or defining a getter or field named 'guild'."
I can't directly do context.guild.getOrDownload() either.
Checking the Message class there's no field for guild, but there is for GuildMessage which I'm assuming is the class that's supposed to be used there? In which case context.message isn't returning the correct class?

You need to check if the .message is a guild message if it is cast it to a GuildMessage

Is it intended for messages sent by webhooks to be registered as a DM?
_CastError (type 'DMMessage' is not a subtype of type 'GuildMessage' in type cast)
All my issues seem to really come down to this. The same message sent by a user works just fine.

Is it intended for messages sent by webhooks to be registered as a DM?
its just like that because guild id wasnt sent with message payload. Naming maybe is a little unfortunate in that case, but it comes down to that message doesn't have any guild info, besides that it was sent in guild

Is this an issue from Discord's side then? The guild info should be included with the registered webhook from their end, not with the request. A simple JSON like
{"content": "%springbok"} should work?

guild_id in message in optional (https://discord.com/developers/docs/resources/channel#message-object-message-structure) so nothing we can do really.

The guild info should be included with the registered webhook from their end, not with the request. A simple JSON like
{"content": "%springbok"} should work?

I dont really understand about what are you talking there. Seems like out of scope of this issue

Is this an issue from Discord's side then? The guild info should be included with the registered webhook from their end, not with the request. A simple JSON like
{"content": "%springbok"} should work?

This dosen't make any sense, Unless you have a docs link to explain what you are trying to explain?

Closing for off topic, but here's a docs page to what I'm trying to explain.
The webhook in Discord is already registered to a guild and a channel, what I don't understand is why this info is no longer readable by the library (it used to be)

authors: HarryET Mirageofmage l7ssha


text:
Allow more hosts to be displayed

Currently only 2-3 hosting users are visible.

Fixed by PR #22


text:
Bug in Transformer-XL shift method

Hi!
In the original paper implementation they are using dims [1:] : x = x_padded[1:].view_as(x) their code but in your implementation you are using [:-1]:  x = x_padded[:-1].view_as(x) your code which produces wrong matrix at the output.

from typing import Optional, List. is wrong

authors: Bearnardd hacihasanzade


text:
Update init.py

There was a typo in the latex code.

Thanks

authors: gstamatiou vpj


text:
Fix registry modal sizing when working with very long keys.

Fixes #244 where very long registry keys would scroll off the page due to the dialog not resizing properly.
This PR also fixes the unreported issue that if you pasted a long key into the new key or edit key windows, the modal window would not reposition, causing it to go off screen.
This bug was caused by an interplay of the various Polymer elements being used. The main culprit being that the iron-resize event that paper-dialog listens to so that it knows when to resize/reposition does not get fired by a iron-autogrow-textarea which is a lower level component that paper-textarea wraps.
This is resolved by first simplifying the component interaction stack by removing the use on paper-dialog-scrollable and moving the job of scrolling to the dialog itself. Secondly, the value update event on the textarea is hooked, and used to fire an iron-resize event that the dialog can catch, causing both the position and sizing to be set correctly.

@maffoo PTAL.

LGTM

authors: adamcw maffoo

repo: labrad/scalabrad-web

license: mit


text:
BUG:  miss mountPath from build clusterfile

Sealos Version
7045a3b
How to reproduce the bug?

It may be necessary to put the data in a fixed directory to prevent it from being automatically cleared by buildah.
What is the expected behavior?
No response
What do you see instead?
No response
Operating environment
- Sealos version:
- Docker version:
- Kubernetes version:
- Operating system:
- Runtime environment:
- Cluster size:
- Additional information:

Additional information
No response

https://github.com/labring/sealos/pull/2048

authors: cuisongliu fanux

repo: labring/sealos


text:
Feature: support pod image pull policy with  IfNotPresent

What is the problem this feature will solve?
k8s pods have IfNotPresent image(not cluster application image) pull policy Invalid in the cluster deployed by sealos.
Sealos always goes to public image registry to pull the image, although the image has been manually loaded locally.
If you have solution，please describe it
No response
What alternatives have you considered?
No response

This is a bug, and already fixed in main. You can tag the image, sealos will not pull again.

authors: fanux willzhang


text:
BUG: add master  error

Sealos Version
4.2.0
How to reproduce the bug?
sealos add --masters
What is the expected behavior?
add success
What do you see instead?
can't apply rootfs type images and version  not [v1beta1 v1beta2]
Operating environment
- Kubernetes version: 1.25.7

Additional information
No response

The mirror version is wrong. Please download the mirror corresponding to the version.

So how do I solve

@cuisongliu

kubernetes:v1.24.0-4.2.0

info new cluster version v1.24.0 behind the current version v1.25.7

@cuisongliu Can only be reset？

authors: cuisongliu overstarry


text:
Does readContractState support internal writes?

If so, how do you set it to true?

cc @ropats16 @7i7o

Hello @arcj0, a new version 1.5.0 has been released which supports passing evaluationOptions to readContractState.
For example, you can pass internalWrites like this or any other supported options inside evaluationOptions.
const readResult = await readContractState({
  environment: "mainnet",
  contractTxId: "contract-transaction-id",
  evaluationOptions: {
    internalWrites: true,
  },
});

Please feel free to leave a comment if you encounter any issues.

repo: labscommunity/arweavekit


text:
Ceci n'est pas un vélo

[une image de SUV]
Non désolé monsieur, votre véhicule n'est pas un vélo cargo.
@jonathanfallon

:car:
« Ceci est un vélo »
Magritte

authors: jonathanfallon laem

repo: laem/attestation-bagnole


text:
ad Update giphy-genertor.yml

giphy

Change needed

not goog


text:
Add a basic CI workflow

This is based on the lalrpop CI at
https://github.com/lalrpop/lalrpop/blob/master/.github/workflows/test.yaml, but greatly simplified, as this project is simpler, and it's only current user is lalrpop, so the CI can be more minimal.

This works on my fork: https://github.com/dburgener/ascii-canvas/pull/1
I'm not sure why it's not running the actions here. Possibly something in the project settings? I don't seem to have access to the settings page in this repo, so I can't look through those. @Pat-Lafon do you have access to the settings here?

It could be settings but it could also be because there are no workflows yet in the repo. We shall see I guess.

I've merged and there now seems to be a running workflow from the push to master

Great, thanks.  I guess that was it then.  I considered that, but since it worked in my fork, I was skeptical, since I didn't think there was special fork handling.  Probably it's because it's my fork where I'm full owner-everything privileges, there's a permissions thing.

authors: Pat-Lafon dburgener

repo: lalrpop/ascii-canvas


text:
POC: Prover trait

TITLE
Description
Description of the pull request changes and motivation.
Type of change
Please delete options that are not relevant.

[ ] New feature
[ ] Bug fix
[ ] Optimization

Checklist

[ ] Linked to Github Issue
[ ] Unit tests added
[ ] This change requires new documentation.

[ ] Documentation has been added/updated.

[ ] This change is an Optimization

[ ] Benchmarks added/run

This ideas are incorporated in PR #596

repo: lambdaclass/lambdaworks


text:
Update deploy functions to integrate with Foundry

This closes #66.

Codecov Report

Merging #73 (487ca0b) into main (d8ddc07) will increase coverage by 0.36%.
The diff coverage is 96.00%.

@@            Coverage Diff             @@
##             main      #73      +/-   ##
==========================================
+ Coverage   79.81%   80.17%   +0.35%
==========================================
  Files          25       25
  Lines        3196     3249      +53
==========================================
+ Hits         2551     2605      +54
+ Misses        645      644       -1

Impacted Files
Coverage Δ

src/cli/commands/deploy.rs
0.00% <0.00%> (ø)

src/zks_wallet/wallet.rs
82.87% <96.15%> (+0.77%)
:arrow_up:

src/zks_provider/mod.rs
90.61% <100.00%> (+0.03%)
:arrow_up:

src/zks_utils.rs
54.96% <100.00%> (+4.96%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

authors: IAvecilla codecov-commenter


text:
arm build failing

Failure: https://github.com/lancedb/lance/actions/runs/6631701633/job/18015778470
Looks like same issue as here:
https://github.com/briansmith/ring/issues/1728

I think amazon linux 2 compatible with on 2_26, does that work?

but was that just for x86?
yeah, if we want to upgrade manylinux for ARM only I think it's fine

Nevermind there was actually a workaround in the upstream thread 💯

repo: lancedb/lance


text:
seznam.cz - clickable cover, add new tab for kinobox

done :)

repo: landsman/kinobox-browser-plugin


text:
🛑 rexingsports.cn is down

In 4402f16, rexingsports.cn (https://www.rexingsports.cn) was down:

HTTP code: 567
Response time: 1273 ms

Resolved: rexingsports.cn is back up in fc859d0.

repo: lanen/bs-site


text:
🛑 vipgifts.net is down

In bb1cd3c, vipgifts.net (https://vipgifts.net) was down:

HTTP code: 567
Response time: 430 ms

Resolved: vipgifts.net is back up in 68d98e1 after 38 minutes.


text:
🛑 vipgifts.net is down

In ddb4974, vipgifts.net (https://vipgifts.net) was down:

HTTP code: 567
Response time: 828 ms

Resolved: vipgifts.net is back up in 67cd4e9 after 23 minutes.


text:
🛑 rexingsports.cn is down

In 6ad7db9, rexingsports.cn (https://www.rexingsports.cn) was down:

HTTP code: 567
Response time: 608 ms

Resolved: rexingsports.cn is back up in 673dedb after 19 minutes.


text:
Add ChatModels wrapper for Cloudflare Workers AI

Thank you for contributing to LangChain!

[x] PR title: "community: chat models wrapper for Cloudflare Workers AI"

[x] PR message:

Description: Add chat models wrapper for Cloudflare Workers AI. Enables Langgraph intergration via ChatModel for tool usage, agentic usage.

[x] Add tests and docs: If you're adding a new integration, please include

a test for the integration, preferably unit tests that do not rely on network access,
an example notebook showing its use. It lives in docs/docs/integrations directory.

[x] Lint and test: Run make format, make lint and make test from the root of the package(s) you've modified. See contribution guidelines for more: https://python.langchain.com/docs/contributing/

Additional guidelines:

Make sure optional dependencies are imported within a function.
Please do not add dependencies to pyproject.toml files (even optional ones) unless they are required for unit tests.
Most PRs should not touch more than one package.
Changes should be backwards compatible.
If you are adding something to community, do not re-import it in langchain.

If no one reviews your PR within a few days, please @-mention one of baskaryan, efriis, eyurtsev, ccurme, vbarda, hwchase17.

@baskaryan could i get a review on this when you get a chance? thanks!

hello, @eyurtsev could i get some reviews on this? thanks!

Awesome work on this one, thank you for contributing this!

@vbarda could I get a review on this when you get a chance please?
PR has passed all lint and formatting tests. It has also community support of 5 upvotes on the PR.

@efriis thanks for looking into this PR! Looks like a few linting checks failed on the documentation notebook. I will be looking into this but in the meantime if you have any other suggestions please let me know

repo: langchain-ai/langchain


text:
Issue: Qdrant Retrieval Not Including Similarity Scores

Title: QdrantVectorStore Not Returning Similarity Scores with Documents
Details:
Encountering an issue with the QdrantVectorStore in LangChain where the similaritySearchVectorWithScore method does not return similarity scores alongside the retrieved documents. The expected behavior, based on the method's naming and typical usage, is to receive a similarity score per document, essential for evaluating the relevance of each result. Currently, these scores are absent in the retrieval output. Seeking clarification on whether this is a bug or a missing feature, and how to enable or rectify this for accurate relevance assessment in document retrieval.

Any update?

repo: langchain-ai/langchainjs


text:
Adding awesome batch

Adding awesome batch according to https://github.com/sindresorhus/awesome#readme

@patbaumgartner thanks! I am not sure I understand what is the point of this badge, could you please clarify?
cc @LizeRaes

@langchain4j it's an visual indicator that you are following the idea of awesome repositories.
See:

Awesome Java
Awesome Kubernetes
Awesome JS
and others.

See also their documentation: https://github.com/sindresorhus/awesome/blob/main/awesome.md

Thank you @patbaumgartner !
We better respect the rules of being awesome from now on 😎

authors: LizeRaes langchain4j patbaumgartner


text:
some advise

1 希望可以开发一个 使用base64加密字符串的组件吗   输入字符串   输出加密后的字符串
2 AI调用的时候，系统提示词不能使用prompt   有无其他方法
3 保存的createRecord 组件存在丢值问题  希望解决

Please write in English.

repo: langflow-ai/langflow


text:
Ability to use a language without CLI / configuration

It would be great to have a utility function like
export function createServicesForGrammar(grammar: string, module?: Module<LangiumServices>, sharedModule?: Module<SharedLangiumModule>): LangiumServices

Use cases:

Write unit tests for our framework without generating code for them (low overhead => more language-specific tests!)
Run the framework in a playground on langium.org

Main challenge: implement a generic AstReflection operating with data collected in memory. This in turn requires to move parts of the grammar type inference from langium-cli to langium.

repo: langium/langium


text:
examples are not minimal pairs in (15) agreement.tex

The examples in a, b, c are not minimal pairs. For non-experts it is difficult to see what is going on.

It depends. If the data comes from fieldwork and it’s difficult to get new data (or new “clean” data), no. If Steve has data that’s minimal pair like sure.
Overall, minimal pairs are cute, but hardly needed to make the point, except that they ensure against claims of non-representative sample(s) kinda thing.
My 2 cents,
Best,
JP

I asked Steve.


text:
Changes from round of JOSS review

PR Summary
This is to address comments in #427 . Thanks @guadabsb15 for the suggestions!

Add discussion of sanity checks to getting started
Make build/bin more consistent in documentation
Add comment about python path
Make sure figures display in all browsers by making png versions

PR Checklist

[ ] Adds a test for any bugs fixed. Adds tests for new features.
[ ] Format your changes by using the make format command after configuring with cmake.
[ ] Document any new features, update documentation for changes made.
[ ] Make sure the copyright notice on any files you modified is up to date.
[ ] After creating a pull request, note it in the CHANGELOG.md file.
[ ] LANL employees: make sure tests pass both on the github CI and on the Darwin CI

If preparing for a new release, in addition please check the following:

[ ] Update the version in cmake.
[ ] Move the changes in the CHANGELOG.md file under a new header for the new release, and reset the categories.
[ ] Ensure that any when='@main' dependencies are updated to the release version in the package.py

Changed things back to builddir and did a consistency sweep through the docs. Hopefully I got them all now. I also removed the unit tests from getting started.

repo: lanl/singularity-eos


text:
enhance the panel view

display the folder name of workspace

I think it's better to display it as the first line in file explorer

like this?

like this?

Yes!

repo: lapce/lapce


text:
opcache.ini change out of sync

I have modified the php-fpm opcache.ini files, check the server cat /usr/local/etc/php/conf.d/opcache. ini, opcaache.ini file is not updated, opcache failure

@sowork please consider using issue template. It will be easier for the devs to find out your problem

authors: sowork vladyslavstartsev

repo: laradock/laradock


text:
Tailwind 0.1.2

Tailwind v0.1.2 was released. This PR updates the preset to download the lastest version.

0.1.3 is out :P

Just started reviewing :) :octocat: Sent from GH.

authors: DCzajkowski m1guelpf michaeldyrynda

repo: laravel-frontend-presets/tailwindcss