The new version says "A newer version P5 is available. Do you want to dwonload it?" (p5-win)

Maybe a bug.
I tried to download it three times but it always shows the same message.
Is there any way to check the version number of the editor?
p.s.
The new editor? sometimes creates an infinite sketch.js holder.

hmmm. Can you try downloading the new version directly from the releases page and let me know if the message is still popping up? https://github.com/processing/p5.js-editor/releases/tag/v0.5.0

I'm experiencing this as well FYI.  I'm at ITP @antiboredom if it helps you to take a look in person.

Sorry, mac 10.10.4

Ok thanks ! I'm it it!

version 0.5.0 is listed as version 0.4.0 under the about menu.

Sorry about this guys I believe it should be fixed now (you'll need to re-download the latest release however).
In either case I'm going to add a new issue about making the update dialog not appearing each time.

I can confirm this is fixed for me!


Blog post explanation, example and source don't match.

The drawings and coordinates in your blog post don't match the example calculations you made later in the post.
The blog post has a point of one of the triangles at [1,-1] whereas the code has it at [1,-2].
https://github.com/jthomperoo/gjk-ts-implementation/blob/1319ce6ef17b285fc1849ae6e056c349079aff49/src/index.ts#L62
The example in the blog post says it uses [1,-1] but values that are calculated are actually for the [1,-2].
(Also, nice post.)

Hey, good catch! I'll fix that now, thanks!

Ended up being a lot less work to just update the blog post!
Thanks again for pointing this out, fixed now :)


input small number breaks the row

@ashachaf can't replicate this one, is this still a problem ?

Unable to reproduce


powerbiclient installation

Hello all,
when install powerbiclient package, using this command "pip install powerbiclient"
this error is shown:
ERROR: Could not find a version that satisfies the requirement powerbiclient (from versions: none)
ERROR: No matching distribution found for powerbiclient
Best Regards.

Hi @zeinabwalid, what version of python are you using ? Also, can you upgrade the pip version and try installing ?


dropping measurements from a database yields Error: database not open but command succeeds

as in title. the response is an error even though the command succeds and drops the specified measurements
I tried it with the internal AdminInterface, influxql and node-influx.

while investigating this issue this one appeared right now (yielded by dropMeasurements too)
[Error: open /usr/local/var/influxdb/wal/test_db/testrp/15/01.000003.wal: no such file or directory]
which totally confuses me since i dont have a db named "test_db" and i never had.
ls /usr/local/var/influxdb/wal returns _internal    rsmq_monitor those are the only 2 databases on my Influxdb instance

@erdii what version of InfluxDB are you running?
Can you paste in a CLI session showing the results of SHOW DATABASES and DROP MEASUREMENT foo, where foo is the measurement that yields the error?
From the behavior you describe my best guess is that somehow test_db was created by someone else and then removed.
Does the error persist through a restart of the influxd process? The metastore that maintains the database list is kept in RAM and reloaded on restart. If there is a ghost test_db somehow in the metastore, a restart should purge it.

Another strange issue that might be relevant, which is not actually an issue in tsm1.
https://github.com/influxdb/influxdb/issues/4303

I'm running InfluxDB <IP_ADDRESS> on OS X 10.11.1 installed via Brew
Strange.. I can't reproduce it anymore... I haven't changed anything in my Installation ( I guess I have^^ )...

> SHOW DATABASES
name: databases
---------------
name
_internal
rsmq_monitor

> USE rsmq_monitor
Using database rsmq_monitor
> SHOW MEASUREMENTS
name: measurements
------------------
name
probe

> SELECT * FROM probe
name: probe
-----------
time				attr	count	key	qname	recv	sent
2015-10-29T14:44:21.535Z	1234
2015-10-29T14:46:38Z			150	queue1	q1	119850	120000
2015-10-29T14:46:43Z			100	queue1	q1	119900	120000
2015-10-29T14:46:48Z			50	queue1	q1	119950	120000
2015-10-29T14:46:53Z			0	queue1	q1	120000	120000
2015-10-29T14:46:53Z			2	queue2	q2	10	12
2015-10-29T14:49:34Z			150	queue1	q1	119850	120000
2015-10-29T14:49:39Z			100	queue1	q1	119900	120000
2015-10-29T14:49:44Z			50	queue1	q1	119950	120000
2015-10-29T14:49:49Z			2	queue2	q2	10	12
2015-10-29T14:49:49Z			0	queue1	q1	120000	120000

> DROP MEASUREMENT probe
ERR: database not open
> SELECT * FROM probe
>

Without the test_db issue this is a duplicate of https://github.com/influxdb/influxdb/issues/3551


stream options: add tracing options

Commit Message: stream options: add tracing options
Additional Description:  Move tracing options from RequestOptions to StreamOptions to allow tracing context in bidi grpc streams. It simplifies https://github.com/envoyproxy/envoy/pull/33665 as it does not require changes in class/method signatures (context). We'd still have parent_span as parameter in AsyncRequestImpl and other send methods which might not be clear what is being used, the one from options or the one from parameters.
Risk Level: Low
Testing: Tested on local setup tracing propagation using extauthz, ratelimit (GRLS), lua and jwtauthn (setChildSpanName).

Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a

Thanks for your contribution. This is LGTM to me. Will let @mattklein123 take a look.

I am not clear to the history of the StreamOptions and RequestOptions and didn't know why the span related options is placed in the RequestOptions.
I initially think it's because a stream may have longer lifetime than the single request. So, we didn't put the request level span related options into the StreamOptions. But seems now we have set the ParentContext to the StreamOptions, so my guess should be off the charts.
cc @mattklein123  Could you take a quick look when you have free time? Thanks.

This LGTM but is there any test that can cover this or is this needed for a different change? If so would it be better to just merge this into the other change as it is really small?
/wait-any

There are existing tests covering RequestOptions [1] [2], not yet through StreamOptions as it will be used in https://github.com/envoyproxy/envoy/pull/33665. I'm happy either way.

There are existing tests covering RequestOptions [1] [2], not yet through StreamOptions as it will be used in https://github.com/envoyproxy/envoy/pull/33665. I'm happy either way.

I would just close and merge into the other PR. Thanks.


Fixes an issue with next hop self detection, issue #8254

Fixes an issue, #8254, with self detection used by next hop and parent selection.  Requires #8275 for the full fix.

[approve ci autest]

[approve ci autest]

@SolidWallOfCode Can you re-approve this?  I had to rebase and fix a merge conflict after you merged your PR.

[approve autest freebsd]

[approve freebsd]

[approve ci freebsd]


Add Phil Peble as a maintainer (and fix table formatting)

Phil Peble is a _long_time Emissary user who's taken on the job of wrangling docs into shape for emissary-ingress.dev, as well as being comfortable enough with Python, Go, and Emissary to help review and fix things. I'm nominating him as our newest maintainer. :slightly_smiling_face: (I'm also fixing the table formatting a touch too.)
Maintainers, please vote yay with a :+1: comment below (or, I guess, nay with a :-1:?). We'll do this by lazy consensus, closing either when we have enough votes or a week out. Thanks!
Signed-off-by: Flynn<EMAIL_ADDRESS>

3 votes is enough! Welcome to the team, @ppeble!! 🙂


added logo file original and exports, updated readme w/ logo

as the title says :)
closes #132

:smile:


Access new workspace page from home

I'm gonna extract this center-form and generic form Panel behavior to its own component before merging this as well.


[SPARK-47990][BUILD] Upgrade zstd-jni to 1.5.6-3

What changes were proposed in this pull request?
The pr aims to upgrade zstd-jni from 1.5.6-2 to 1.5.6-3.
Why are the changes needed?
1.This version fix a potential memory leak problem, as follows:

2.https://github.com/luben/zstd-jni/compare/v1.5.6-2...v1.5.6-3
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Pass GA.
Was this patch authored or co-authored using generative AI tooling?
No.

Recently, the library zstd-jni has been upgraded a bit frequently, but the memory leak problem, I think, at least before the release of Spark 4.0, needs to merge this pr into spark codebase.

cc @dongjoon-hyun @LuciferYang

Merged to master


Add terms for INSDC /regulatory_classes that lack an SO match

Hi SO,
Some of the INSDC /regulatory_class terms currently lack a match to an SO term. Since we'd like to map all terms to SO (see issue #378 for more background), can you consider making an SO entry for the following?
1) enhancer_blocking_element
This is related to the SO entries for insulator (SO:0000627) and boundary_element (SO:0002020). The SO definition for SO:0000627 actually fits the description for enhancer_blocking_element, but the organization of these related terms needs modification. Unfortunately the literature has been using the term 'insulator' to mean multiple different biological functions, yet we need to be more specific for annotation purposes. The major functions of an insulator are: 1) barrier or boundary function (as in the SO:0002020 description); and 2) enhancer-blocking function (as in the SO:0000627 description). PMID:12154228 provides a good overview, with the major functions shown in Figure 1. Other reviews that differentiate between these basic properties include PMIDs 22326678, 22265227 and 12154228. Insulator biological functions are even more nuanced than the above two properties, and nowadays insulators are more generally considered to be elements involved in higher-order chromatin organization, e.g., PMIDs 25781057, 24277632, 23706817 or 22265227.
So my suggestion would be to make parent:child terms, where insulator (SO:0000627) is the parent (with a modified definition to be more inclusive of all functions). The term boundary_element (SO:0002020) and a new SO entry for enhancer_blocking_element would be children. The alias insulator should be included in all these related entries since it's used in multiple ways in the literature.
INSDC already has a /regulatory_class for insulator, as follows:
Qualifier: /regulatory_class="insulator"
Definition: a chromatin boundary element or barrier that can block the encroachment of condensed chromatin from an adjacent region. May also include enhancer-blocking activity.
NCBI is currently mapping this to SO:0000627 (same term), even though the SO definition is different. Depending on how you reorganize the SO terms, SO:0002020 may be a more appropriate mapping based on the INSDC definition.
And the INSDC term for enhancer_blocking_element is:
Qualifier: /regulatory_class="enhancer_blocking_element"
Definition: a transcriptional cis regulatory region that when located between an enhancer and a gene's promoter prevents the enhancer from modulating the expression of the gene. Sometimes referred to as an insulator but may not include the barrier function of an insulator.
2) imprinting_control_region
There are SO terms for types of imprinting (SO:0000134, SO:0000135, SO:0000136) or for imprinted genes (SO:0000888, SO:0000889), but there is no term for an imprinting control region. INSDC term:
Qualifier: /regulatory_class="imprinting_control_region"
Definition: a regulatory region that controls epigenetic imprinting and affects the expression of target genes in an allele- or parent-of-origin-specific manner. Associated regulatory elements may include differentially methylated regions and non-coding RNAs.
Acronyms/aliases include ICR, imprinting center (IC), differentially methylated region (DMR) or differentially methylated domain (DMD). Relevant reviews include PMIDs 23287029, 18282507, 17467259 and 16575166. This would likely need to be a child of regulatory_region (SO:0005836).
3) response_element
There are SO terms for specific types of response elements (SO:0001839, SO:0001181, SO:0001853 or SO:0002045), but there is no generic term for response_element, which could be a parent to the specific terms. Here is the INSDC term:
Qualifier: /regulatory_class="response_element"
Definition: a regulatory element that acts in response to a stimulus, usually via transcription factor binding
Thanks for considering these new terms! Please let me know if you need more information.
Catherine
NCBI - RefSeq

These look good. I'll work on it this week.

Hi SO,
Just inquiring about the status of this issue and related issues #378 and #386. NCBI is planning a new human genome annotation, and we'd like to have all our feature mark-ups consistent with SO in our FTP files ( e.g., the SO_type column 3 classifications in our GFF3 files). This is important for user data mining, especially for RefSeq Functional Elements, which are already public and will be included in the upcoming annotation release.
Thanks!
Catherine
NCBI - RefSeq

We are waiting for @murphyte to review the mappings before we add them to SO.


Fix on state for robot vacuum cleaners

:recycle: Current situation
Currently, the on property of the device is used to determine whether it is running. That makes the device always active since it is always "turned on" according to the API, as long as its battery is not empty.
:bulb: Proposed solution
We use the working statuses 'InDustCollecting' and 'Clearing' to indicate on state. Those are the statuses that are the indication That the device is actually currently cleaning.
:gear: Release Notes

Fix a bug where robot vacuums would always display as on

:heavy_plus_sign: Additional Information

Testing

Reviewer Nudging

Awesome! Thanks I will merge this in to beta for testing.


Fixed README  links

Simply changed the broken hyperlinks in the markdown files and rearranged the order of languages in some of the READMEs for uniformity. Closes #681

Looks good @DebadityaPal, thanks!


(BKR-511) Beaker fails to launch Vagrant VMs when run within Bundler

Unset the RUBYLIB variable before shelling out to run vagrant.  Fixes dependency on outdated version of bundler

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/1761/
Test PASSed.

Lgtm


chore: upload deb package to artifacts only

Upload deb package to artifacts only, for circleci cant't upload debian package file to cos.

have a CI running successfully in your own repository?

have a CI running successfully in your own repository?

https://github.com/api7/apisix-build-tools/actions/runs/2655676599
https://app.circleci.com/pipelines/github/api7/apisix-build-tools/154/workflows/12db3bf2-e065-441b-b00c-c9c9ea2104d5/jobs/221/artifacts


VM cannot connect to k8s service without kube-proxy

What happened:
A VM launched by kubevirt is unable to connect to services created with ClusterIP in k8s
We ran iperf3 to test connectivity for both UDP and TCP on native pods and VM
Using pod from a k8s Deployment
Pod -> Pod [OK]
Pod -> Service (ClusterIP) [OK]
Pod -> Internet [OK]
From VM console
VM -> Pod [OK]
VM -> Service (ClusterIP) [FAIL]
VM -> Internet [OK]
I also checked that I was able to reach other services/pods/internet from the virt-launcher compute container
This happens after transitioning from cilium legacy to cilium with eBPF.
Please let me know what traces you need
What you expected to happen:
VM is able to connect to k8s services (including DNS)
How to reproduce it (as minimally and precisely as possible):

Start a cluster
Install cilium with eBPF
start VM
nslookup google.com from VM (this shows that DNS - a service in k8s - is not working)

Additional context:
Nil
Environment:

KubeVirt version (use virtctl version):
Client Version: version.Info{GitVersion:"v1.0.0", GitCommit:"579bb66545630d93b29d0399219aaa51c3f0a00b", GitTreeState:"clean", BuildDate:"2023-07-06T17:46:07Z", GoVersion:"go1.19.9", Compiler:"gc", Platform:"darwin/arm64"}
Server Version: version.Info{GitVersion:"v0.59.0", GitCommit:"78f5184d1794838c5fc5061f920273fb4e5283ed", GitTreeState:"clean", BuildDate:"2023-03-01T16:55:38Z", GoVersion:"go1.19.2", Compiler:"gc", Platform:"linux/amd64"}

Kubernetes version (use kubectl version): v1.25.12

VM or VMI specifications:
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: vm
spec:
  runStrategy: Always
  template:
    spec:
      domain:
        devices:
          disks:
            - cdrom:
                bus: sata
              name: cloudinitdisk
            - disk:
                bus: virtio
              name: os
        resources:
          requests:
            cpu: 4
            memory: 32Gi
          limits:
            cpu: 16
      terminationGracePeriodSeconds: 180
      volumes:
        - cloudInitNoCloud:
            secretRef:
              name: cloud-init-vm
          name: cloudinitdisk
        - name: os
          containerDisk:
            image: kubevirt/fedora-cloud-container-disk-demo:latest

apiVersion: v1
kind: Secret
metadata:
  name: cloud-init-vm
type: Opaque
stringData:
  userdata: |
    #cloud-config
    hostname: vm
    password: fedora
    ssh_pwauth: True
    chpasswd: { expire: False }
    disable_root: false

Cloud provider or hardware configuration: bare-metal (dual Intel(R) Xeon(R) Gold 5120 CPU @ 2.20GHz) with 10G networking

OS (e.g. from /etc/os-release):
NAME="Rocky Linux"
VERSION="8.8 (Green Obsidian)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Rocky Linux 8.8 (Green Obsidian)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:8:GA"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2029-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-8"
ROCKY_SUPPORT_PRODUCT_VERSION="8.8"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.8"

Kernel (e.g. uname -a): 4.18.0-477.21.1.el8_8.x86_64

Install tools: HCO operator

Others:

Click here to show logs from QEMU pod
{"component":"virt-launcher","level":"info","msg":"Collected all requested hook sidecar sockets","pos":"manager.go:86","timestamp":"2023-09-06T09:28:32.180809Z"}
{"component":"virt-launcher","level":"info","msg":"Sorted all collected sidecar sockets per hook point based on their priority and name: map[]","pos":"manager.go:89","timestamp":"2023-09-06T09:28:32.180863Z"}
{"component":"virt-launcher","level":"info","msg":"Connecting to libvirt daemon: qemu+unix:///session?socket=/var/run/libvirt/virtqemud-sock","pos":"libvirt.go:496","timestamp":"2023-09-06T09:28:32.181826Z"}
{"component":"virt-launcher","level":"info","msg":"Connecting to libvirt daemon failed: virError(Code=38, Domain=7, Message='Failed to connect socket to '/var/run/libvirt/virtqemud-sock': No such file or directory')","pos":"libvirt.go:504","timestamp":"2023-09-06T09:28:32.183060Z"}
{"component":"virt-launcher","level":"info","msg":"libvirt version: 9.0.0, package: 3.el9<EMAIL_ADDRESS>2023-02-01-12:58:56, )","subcomponent":"libvirt","thread":"45","timestamp":"2023-09-06T09:28:32.199000Z"}
{"component":"virt-launcher","level":"info","msg":"hostname: vm","subcomponent":"libvirt","thread":"45","timestamp":"2023-09-06T09:28:32.199000Z"}
{"component":"virt-launcher","level":"error","msg":"internal error: Unable to get session bus connection: Cannot spawn a message bus without a machine-id: Unable to load /var/lib/dbus/machine-id or /etc/machine-id: Failed to open file “/var/lib/dbus/machine-id”: No such file or directory","pos":"virGDBusGetSessionBus:126","subcomponent":"libvirt","thread":"45","timestamp":"2023-09-06T09:28:32.199000Z"}
{"component":"virt-launcher","level":"error","msg":"internal error: Unable to get system bus connection: Could not connect: No such file or directory","pos":"virGDBusGetSystemBus:99","subcomponent":"libvirt","thread":"45","timestamp":"2023-09-06T09:28:32.199000Z"}
{"component":"virt-launcher","level":"info","msg":"Connected to libvirt daemon","pos":"libvirt.go:512","timestamp":"2023-09-06T09:28:32.684640Z"}
{"component":"virt-launcher","level":"info","msg":"Registered libvirt event notify callback","pos":"client.go:537","timestamp":"2023-09-06T09:28:32.687153Z"}
{"component":"virt-launcher","level":"info","msg":"Marked as ready","pos":"virt-launcher.go:75","timestamp":"2023-09-06T09:28:32.687319Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Executing PreStartHook on VMI pod environment","name":"vm","namespace":"vm","pos":"manager.go:518","timestamp":"2023-09-06T09:28:36.104148Z","uid":"38b33d91-d1c7-4189-9405-b679c9954430"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Starting PreCloudInitIso hook","name":"vm","namespace":"vm","pos":"manager.go:539","timestamp":"2023-09-06T09:28:36.104443Z","uid":"38b33d91-d1c7-4189-9405-b679c9954430"}
{"component":"virt-launcher","level":"info","msg":"Found nameservers in /etc/resolv.conf: \ufffd\u0014\u0000\n","pos":"network.go:298","timestamp":"2023-09-06T09:28:36.105420Z"}
{"component":"virt-launcher","level":"info","msg":"Found search domains in /etc/resolv.conf: vm.svc.cluster.local svc.cluster.local cluster.local system.nodes.preferred.ai storage.nodes.preferred.ai nodes.preferred.ai","pos":"network.go:299","timestamp":"2023-09-06T09:28:36.105446Z"}
{"component":"virt-launcher","level":"info","msg":"Starting SingleClientDHCPServer","pos":"server.go:65","timestamp":"2023-09-06T09:28:36.105511Z"}
{"component":"virt-launcher","level":"info","msg":"Driver cache mode for /var/run/kubevirt-ephemeral-disks/cloud-init-data/vm/vm/noCloud.iso set to none","pos":"converter.go:448","timestamp":"2023-09-06T09:28:36.148250Z"}
{"component":"virt-launcher","level":"info","msg":"Driver cache mode for /var/run/kubevirt-ephemeral-disks/disk-data/os/disk.qcow2 set to none","pos":"converter.go:448","timestamp":"2023-09-06T09:28:36.152773Z"}
{"component":"virt-launcher","level":"error","msg":"No disk capacity","pos":"manager.go:671","timestamp":"2023-09-06T09:28:36.163646Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Domain XML generated. Base64 dump PGRvbWFpbiB0eXBlPSJrdm0iIHhtbG5zOnFlbXU9Imh0dHA6Ly9saWJ2aXJ0Lm9yZy9zY2hlbWFzL2RvbWFpbi9xZW11LzEuMCI+Cgk8bmFtZT52bV92bTwvbmFtZT4KCTxtZW1vcnkgdW5pdD0iYiI+MzQzNTk3MzgzNjg8L21lbW9yeT4KCTxvcz4KCQk8dHlwZSBhcmNoPSJ4ODZfNjQiIG1hY2hpbmU9InEzNSI+aHZtPC90eXBlPgoJCTxzbWJpb3MgbW9kZT0ic3lzaW5mbyI+PC9zbWJpb3M+Cgk8L29zPgoJPHN5c2luZm8gdHlwZT0ic21iaW9zIj4KCQk8c3lzdGVtPgoJCQk8ZW50cnkgbmFtZT0idXVpZCI+ZDYzM2E2MjItMjMzNS01NjA2LTkzYWUtZDQzMmI3YzdmMmQyPC9lbnRyeT4KCQkJPGVudHJ5IG5hbWU9Im1hbnVmYWN0dXJlciI+S3ViZVZpcnQ8L2VudHJ5PgoJCQk8ZW50cnkgbmFtZT0iZmFtaWx5Ij5LdWJlVmlydDwvZW50cnk+CgkJCTxlbnRyeSBuYW1lPSJwcm9kdWN0Ij5Ob25lPC9lbnRyeT4KCQkJPGVudHJ5IG5hbWU9InNrdSI+PC9lbnRyeT4KCQkJPGVudHJ5IG5hbWU9InZlcnNpb24iPjwvZW50cnk+CgkJPC9zeXN0ZW0+CgkJPGJpb3M+PC9iaW9zPgoJCTxiYXNlQm9hcmQ+PC9iYXNlQm9hcmQ+CgkJPGNoYXNzaXM+PC9jaGFzc2lzPgoJPC9zeXNpbmZvPgoJPGRldmljZXM+CgkJPGludGVyZmFjZSB0eXBlPSJldGhlcm5ldCI+CgkJCTxzb3VyY2U+PC9zb3VyY2U+CgkJCTx0YXJnZXQgZGV2PSJ0YXAwIiBtYW5hZ2VkPSJubyI+PC90YXJnZXQ+CgkJCTxtb2RlbCB0eXBlPSJ2aXJ0aW8tbm9uLXRyYW5zaXRpb25hbCI+PC9tb2RlbD4KCQkJPG10dSBzaXplPSIxNTAwIj48L210dT4KCQkJPGFsaWFzIG5hbWU9InVhLWRlZmF1bHQiPjwvYWxpYXM+CgkJCTxyb20gZW5hYmxlZD0ibm8iPjwvcm9tPgoJCTwvaW50ZXJmYWNlPgoJCTxjaGFubmVsIHR5cGU9InVuaXgiPgoJCQk8dGFyZ2V0IG5hbWU9Im9yZy5xZW11Lmd1ZXN0X2FnZW50LjAiIHR5cGU9InZpcnRpbyI+PC90YXJnZXQ+CgkJPC9jaGFubmVsPgoJCTxjb250cm9sbGVyIHR5cGU9InVzYiIgaW5kZXg9IjAiIG1vZGVsPSJub25lIj48L2NvbnRyb2xsZXI+CgkJPGNvbnRyb2xsZXIgdHlwZT0ic2NzaSIgaW5kZXg9IjAiIG1vZGVsPSJ2aXJ0aW8tbm9uLXRyYW5zaXRpb25hbCI+PC9jb250cm9sbGVyPgoJCTxjb250cm9sbGVyIHR5cGU9InZpcnRpby1zZXJpYWwiIGluZGV4PSIwIiBtb2RlbD0idmlydGlvLW5vbi10cmFuc2l0aW9uYWwiPjwvY29udHJvbGxlcj4KCQk8dmlkZW8+CgkJCTxtb2RlbCB0eXBlPSJ2Z2EiIGhlYWRzPSIxIiB2cmFtPSIxNjM4NCI+PC9tb2RlbD4KCQk8L3ZpZGVvPgoJCTxncmFwaGljcyB0eXBlPSJ2bmMiPgoJCQk8bGlzdGVuIHR5cGU9InNvY2tldCIgc29ja2V0PSIvdmFyL3J1bi9rdWJldmlydC1wcml2YXRlLzM4YjMzZDkxLWQxYzctNDE4OS05NDA1LWI2NzljOTk1NDQzMC92aXJ0LXZuYyI+PC9saXN0ZW4+CgkJPC9ncmFwaGljcz4KCQk8bWVtYmFsbG9vbiBtb2RlbD0idmlydGlvLW5vbi10cmFuc2l0aW9uYWwiPgoJCQk8c3RhdHMgcGVyaW9kPSIxMCI+PC9zdGF0cz4KCQk8L21lbWJhbGxvb24+CgkJPGRpc2sgZGV2aWNlPSJjZHJvbSIgdHlwZT0iZmlsZSI+CgkJCTxzb3VyY2UgZmlsZT0iL3Zhci9ydW4va3ViZXZpcnQtZXBoZW1lcmFsLWRpc2tzL2Nsb3VkLWluaXQtZGF0YS92bS92bS9ub0Nsb3VkLmlzbyI+PC9zb3VyY2U+CgkJCTx0YXJnZXQgYnVzPSJzYXRhIiBkZXY9InNkYSIgdHJheT0iY2xvc2VkIj48L3RhcmdldD4KCQkJPGRyaXZlciBjYWNoZT0ibm9uZSIgZXJyb3JfcG9saWN5PSJzdG9wIiBuYW1lPSJxZW11IiB0eXBlPSJyYXciPjwvZHJpdmVyPgoJCQk8cmVhZG9ubHk+PC9yZWFkb25seT4KCQkJPGFsaWFzIG5hbWU9InVhLWNsb3VkaW5pdGRpc2siPjwvYWxpYXM+CgkJPC9kaXNrPgoJCTxkaXNrIGRldmljZT0iZGlzayIgdHlwZT0iZmlsZSIgbW9kZWw9InZpcnRpby1ub24tdHJhbnNpdGlvbmFsIj4KCQkJPHNvdXJjZSBmaWxlPSIvdmFyL3J1bi9rdWJldmlydC1lcGhlbWVyYWwtZGlza3MvZGlzay1kYXRhL29zL2Rpc2sucWNvdzIiPjwvc291cmNlPgoJCQk8dGFyZ2V0IGJ1cz0idmlydGlvIiBkZXY9InZkYSI+PC90YXJnZXQ+CgkJCTxkcml2ZXIgY2FjaGU9Im5vbmUiIGVycm9yX3BvbGljeT0ic3RvcCIgbmFtZT0icWVtdSIgdHlwZT0icWNvdzIiIGRpc2NhcmQ9InVubWFwIj48L2RyaXZlcj4KCQkJPGFsaWFzIG5hbWU9InVhLW9zIj48L2FsaWFzPgoJCQk8YmFja2luZ1N0b3JlIHR5cGU9ImZpbGUiPgoJCQkJPGZvcm1hdCB0eXBlPSJxY293MiI+PC9mb3JtYXQ+CgkJCQk8c291cmNlIGZpbGU9Ii92YXIvcnVuL2t1YmV2aXJ0L2NvbnRhaW5lci1kaXNrcy9kaXNrXzEuaW1nIj48L3NvdXJjZT4KCQkJPC9iYWNraW5nU3RvcmU+CgkJCTxleHBhbmREaXNrc0VuYWJsZWQ+dHJ1ZTwvZXhwYW5kRGlza3NFbmFibGVkPgoJCTwvZGlzaz4KCQk8c2VyaWFsIHR5cGU9InVuaXgiPgoJCQk8dGFyZ2V0IHBvcnQ9IjAiPjwvdGFyZ2V0PgoJCQk8c291cmNlIG1vZGU9ImJpbmQiIHBhdGg9Ii92YXIvcnVuL2t1YmV2aXJ0LXByaXZhdGUvMzhiMzNkOTEtZDFjNy00MTg5LTk0MDUtYjY3OWM5OTU0NDMwL3ZpcnQtc2VyaWFsMCI+PC9zb3VyY2U+CgkJPC9zZXJpYWw+CgkJPGNvbnNvbGUgdHlwZT0icHR5Ij4KCQkJPHRhcmdldCB0eXBlPSJzZXJpYWwiIHBvcnQ9IjAiPjwvdGFyZ2V0PgoJCTwvY29uc29sZT4KCTwvZGV2aWNlcz4KCTxtZXRhZGF0YT4KCQk8a3ViZXZpcnQgeG1sbnM9Imh0dHA6Ly9rdWJldmlydC5pbyI+CgkJCTx1aWQ+PC91aWQ+CgkJPC9rdWJldmlydD4KCTwvbWV0YWRhdGE+Cgk8ZmVhdHVyZXM+CgkJPGFjcGk+PC9hY3BpPgoJPC9mZWF0dXJlcz4KCTxjcHUgbW9kZT0iaG9zdC1tb2RlbCI+CgkJPHRvcG9sb2d5IHNvY2tldHM9IjE2IiBjb3Jlcz0iMSIgdGhyZWFkcz0iMSI+PC90b3BvbG9neT4KCTwvY3B1PgoJPHZjcHUgcGxhY2VtZW50PSJzdGF0aWMiPjE2PC92Y3B1PgoJPGlvdGhyZWFkcz4xPC9pb3RocmVhZHM+CjwvZG9tYWluPg==","name":"vm","namespace":"vm","pos":"libvirt_helper.go:133","timestamp":"2023-09-06T09:28:36.164844Z","uid":"38b33d91-d1c7-4189-9405-b679c9954430"}
{"component":"virt-launcher-monitor","level":"info","msg":"Reaped pid 66 with status 0","pos":"virt-launcher-monitor.go:124","timestamp":"2023-09-06T09:28:36.219622Z"}
{"component":"virt-launcher-monitor","level":"info","msg":"Reaped pid 68 with status 0","pos":"virt-launcher-monitor.go:124","timestamp":"2023-09-06T09:28:36.380068Z"}
{"component":"virt-launcher-monitor","level":"info","msg":"Reaped pid 74 with status 0","pos":"virt-launcher-monitor.go:124","timestamp":"2023-09-06T09:28:36.599407Z"}
{"component":"virt-launcher-monitor","level":"info","msg":"Reaped pid 76 with status 0","pos":"virt-launcher-monitor.go:124","timestamp":"2023-09-06T09:28:36.632420Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Domain defined.","name":"vm","namespace":"vm","pos":"manager.go:869","timestamp":"2023-09-06T09:28:36.937440Z","uid":"38b33d91-d1c7-4189-9405-b679c9954430"}
{"component":"virt-launcher","level":"info","msg":"DomainLifecycle event 0 with reason 0 received","pos":"client.go:463","timestamp":"2023-09-06T09:28:36.937631Z"}
{"component":"virt-launcher","level":"info","msg":"kubevirt domain status: Shutoff(5):Unknown(0)","pos":"client.go:295","timestamp":"2023-09-06T09:28:36.939109Z"}
{"component":"virt-launcher","level":"info","msg":"Successfully connected to domain notify socket at /var/run/kubevirt/domain-notify-pipe.sock","pos":"client.go:170","timestamp":"2023-09-06T09:28:36.942441Z"}
{"component":"virt-launcher","level":"info","msg":"Domain name event: vm_vm","pos":"client.go:422","timestamp":"2023-09-06T09:28:36.944697Z"}
{"component":"virt-launcher","level":"info","msg":"Monitoring loop: rate 1s start timeout 4m16s","pos":"monitor.go:181","timestamp":"2023-09-06T09:28:36.944840Z"}
{"component":"virt-launcher","level":"info","msg":"generated nocloud iso file /var/run/kubevirt-ephemeral-disks/cloud-init-data/vm/vm/noCloud.iso","pos":"cloud-init.go:675","timestamp":"2023-09-06T09:28:37.050122Z"}
{"component":"virt-launcher","level":"info","msg":"GuestAgentLifecycle event state 2 with reason 1 received","pos":"client.go:520","timestamp":"2023-09-06T09:28:37.206710Z"}
{"component":"virt-launcher","level":"info","msg":"kubevirt domain status: Paused(3):StartingUp(11)","pos":"client.go:295","timestamp":"2023-09-06T09:28:37.208161Z"}
{"component":"virt-launcher","level":"info","msg":"Domain name event: vm_vm","pos":"client.go:422","timestamp":"2023-09-06T09:28:37.209459Z"}
{"component":"virt-launcher","level":"info","msg":"DomainLifecycle event 4 with reason 0 received","pos":"client.go:463","timestamp":"2023-09-06T09:28:37.692988Z"}
{"component":"virt-launcher","level":"info","msg":"DomainLifecycle event 2 with reason 0 received","pos":"client.go:463","timestamp":"2023-09-06T09:28:37.702325Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Domain started.","name":"vm","namespace":"vm","pos":"manager.go:897","timestamp":"2023-09-06T09:28:37.713098Z","uid":"38b33d91-d1c7-4189-9405-b679c9954430"}
{"component":"virt-launcher","level":"info","msg":"kubevirt domain status: Running(1):Unknown(1)","pos":"client.go:295","timestamp":"2023-09-06T09:28:37.714389Z"}
{"component":"virt-launcher","level":"info","msg":"Domain name event: vm_vm","pos":"client.go:422","timestamp":"2023-09-06T09:28:37.715435Z"}
{"component":"virt-launcher","level":"info","msg":"kubevirt domain status: Running(1):Unknown(1)","pos":"client.go:295","timestamp":"2023-09-06T09:28:37.716711Z"}
{"component":"virt-launcher","level":"info","msg":"Domain name event: vm_vm","pos":"client.go:422","timestamp":"2023-09-06T09:28:37.717421Z"}
{"component":"virt-launcher","level":"error","msg":"No disk capacity","pos":"manager.go:671","timestamp":"2023-09-06T09:28:37.718029Z"}
{"component":"virt-launcher","kind":"","level":"info","msg":"Synced vmi","name":"vm","namespace":"vm","pos":"server.go:191","timestamp":"2023-09-06T09:28:37.718076Z","uid":"38b33d91-d1c7-4189-9405-b679c9954430"}

apiVersion: v1
kind: Pod
metadata:
  annotations:
    k8s.v1.cni.cncf.io/network-status: |-
      [{
          "name": "cilium",
          "interface": "eth0",
          "ips": [
              "<IP_ADDRESS>"
          ],
          "mac": "1e:e8:6c:ce:1a:b4",
          "default": true,
          "dns": {}
      }]
    kubectl.kubernetes.io/default-container: compute
    kubevirt.io/domain: vm
    kubevirt.io/migrationTransportUnix: 'true'
    post.hook.backup.velero.io/command: >-
      ["/usr/bin/virt-freezer", "--unfreeze", "--name", "vm", "--namespace",
      "vm"]
    post.hook.backup.velero.io/container: compute
    pre.hook.backup.velero.io/command: '["/usr/bin/virt-freezer", "--freeze", "--name", "vm", "--namespace", "vm"]'
    pre.hook.backup.velero.io/container: compute
    traffic.sidecar.istio.io/kubevirtInterfaces: k6t-eth0
  creationTimestamp: '2023-09-06T09:28:27Z'
  generateName: virt-launcher-vm-
  labels:
    kubevirt.io: virt-launcher
    kubevirt.io/created-by: 38b33d91-d1c7-4189-9405-b679c9954430
    vm.kubevirt.io/name: vm
  managedFields:
    - apiVersion: v1
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:annotations:
            .: {}
            f:kubectl.kubernetes.io/default-container: {}
            f:kubevirt.io/domain: {}
            f:kubevirt.io/migrationTransportUnix: {}
            f:post.hook.backup.velero.io/command: {}
            f:post.hook.backup.velero.io/container: {}
            f:pre.hook.backup.velero.io/command: {}
            f:pre.hook.backup.velero.io/container: {}
            f:traffic.sidecar.istio.io/kubevirtInterfaces: {}
          f:generateName: {}
          f:labels:
            .: {}
            f:kubevirt.io: {}
            f:kubevirt.io/created-by: {}
            f:vm.kubevirt.io/name: {}
          f:ownerReferences:
            .: {}
            k:{"uid":"38b33d91-d1c7-4189-9405-b679c9954430"}: {}
        f:spec:
          f:affinity:
            .: {}
            f:nodeAffinity:
              .: {}
              f:requiredDuringSchedulingIgnoredDuringExecution: {}
          f:automountServiceAccountToken: {}
          f:containers:
            k:{"name":"compute"}:
              .: {}
              f:command: {}
              f:env:
                .: {}
                k:{"name":"POD_NAME"}:
                  .: {}
                  f:name: {}
                  f:valueFrom:
                    .: {}
                    f:fieldRef: {}
                k:{"name":"XDG_CACHE_HOME"}:
                  .: {}
                  f:name: {}
                  f:value: {}
                k:{"name":"XDG_CONFIG_HOME"}:
                  .: {}
                  f:name: {}
                  f:value: {}
                k:{"name":"XDG_RUNTIME_DIR"}:
                  .: {}
                  f:name: {}
                  f:value: {}
              f:image: {}
              f:imagePullPolicy: {}
              f:name: {}
              f:resources:
                .: {}
                f:limits:
                  .: {}
                  f:cpu: {}
                  f:devices.kubevirt.io/kvm: {}
                  f:devices.kubevirt.io/tun: {}
                  f:devices.kubevirt.io/vhost-net: {}
                f:requests:
                  .: {}
                  f:cpu: {}
                  f:devices.kubevirt.io/kvm: {}
                  f:devices.kubevirt.io/tun: {}
                  f:devices.kubevirt.io/vhost-net: {}
                  f:ephemeral-storage: {}
                  f:memory: {}
              f:securityContext:
                .: {}
                f:allowPrivilegeEscalation: {}
                f:capabilities:
                  .: {}
                  f:add: {}
                  f:drop: {}
                f:privileged: {}
                f:runAsGroup: {}
                f:runAsNonRoot: {}
                f:runAsUser: {}
              f:terminationMessagePath: {}
              f:terminationMessagePolicy: {}
              f:volumeMounts:
                .: {}
                k:{"mountPath":"/var/run/kubevirt"}:
                  .: {}
                  f:mountPath: {}
                  f:name: {}
                k:{"mountPath":"/var/run/kubevirt-ephemeral-disks"}:
                  .: {}
                  f:mountPath: {}
                  f:name: {}
                k:{"mountPath":"/var/run/kubevirt-private"}:
                  .: {}
                  f:mountPath: {}
                  f:name: {}
                k:{"mountPath":"/var/run/kubevirt-private/secret/cloudinitdisk/userData"}:
                  .: {}
                  f:mountPath: {}
                  f:name: {}
                  f:readOnly: {}
                  f:subPath: {}
                k:{"mountPath":"/var/run/kubevirt-private/secret/cloudinitdisk/userdata"}:
                  .: {}
                  f:mountPath: {}
                  f:name: {}
                  f:readOnly: {}
                  f:subPath: {}
                k:{"mountPath":"/var/run/kubevirt/container-disks"}:
                  .: {}
                  f:mountPath: {}
                  f:mountPropagation: {}
                  f:name: {}
                k:{"mountPath":"/var/run/kubevirt/hotplug-disks"}:
                  .: {}
                  f:mountPath: {}
                  f:mountPropagation: {}
                  f:name: {}
                k:{"mountPath":"/var/run/kubevirt/sockets"}:
                  .: {}
                  f:mountPath: {}
                  f:name: {}
                k:{"mountPath":"/var/run/libvirt"}:
                  .: {}
                  f:mountPath: {}
                  f:name: {}
            k:{"name":"volumeos"}:
              .: {}
              f:args: {}
              f:command: {}
              f:image: {}
              f:imagePullPolicy: {}
              f:name: {}
              f:resources:
                .: {}
                f:limits:
                  .: {}
                  f:cpu: {}
                  f:memory: {}
                f:requests:
                  .: {}
                  f:cpu: {}
                  f:ephemeral-storage: {}
                  f:memory: {}
              f:securityContext:
                .: {}
                f:allowPrivilegeEscalation: {}
                f:capabilities:
                  .: {}
                  f:drop: {}
                f:runAsNonRoot: {}
                f:runAsUser: {}
              f:terminationMessagePath: {}
              f:terminationMessagePolicy: {}
              f:volumeMounts:
                .: {}
                k:{"mountPath":"/usr/bin"}:
                  .: {}
                  f:mountPath: {}
                  f:name: {}
                k:{"mountPath":"/var/run/kubevirt-ephemeral-disks/container-disk-data/38b33d91-d1c7-4189-9405-b679c9954430"}:
                  .: {}
                  f:mountPath: {}
                  f:name: {}
          f:dnsPolicy: {}
          f:enableServiceLinks: {}
          f:hostname: {}
          f:initContainers:
            .: {}
            k:{"name":"container-disk-binary"}:
              .: {}
              f:command: {}
              f:env:
                .: {}
                k:{"name":"XDG_CACHE_HOME"}:
                  .: {}
                  f:name: {}
                  f:value: {}
                k:{"name":"XDG_CONFIG_HOME"}:
                  .: {}
                  f:name: {}
                  f:value: {}
                k:{"name":"XDG_RUNTIME_DIR"}:
                  .: {}
                  f:name: {}
                  f:value: {}
              f:image: {}
              f:imagePullPolicy: {}
              f:name: {}
              f:resources:
                .: {}
                f:limits:
                  .: {}
                  f:cpu: {}
                  f:memory: {}
                f:requests:
                  .: {}
                  f:cpu: {}
                  f:memory: {}
              f:securityContext:
                .: {}
                f:allowPrivilegeEscalation: {}
                f:capabilities:
                  .: {}
                  f:drop: {}
                f:privileged: {}
                f:runAsGroup: {}
                f:runAsNonRoot: {}
                f:runAsUser: {}
              f:terminationMessagePath: {}
              f:terminationMessagePolicy: {}
              f:volumeMounts:
                .: {}
                k:{"mountPath":"/init/usr/bin"}:
                  .: {}
                  f:mountPath: {}
                  f:name: {}
            k:{"name":"volumeos-init"}:
              .: {}
              f:args: {}
              f:command: {}
              f:image: {}
              f:imagePullPolicy: {}
              f:name: {}
              f:resources:
                .: {}
                f:limits:
                  .: {}
                  f:cpu: {}
                  f:memory: {}
                f:requests:
                  .: {}
                  f:cpu: {}
                  f:ephemeral-storage: {}
                  f:memory: {}
              f:securityContext:
                .: {}
                f:allowPrivilegeEscalation: {}
                f:capabilities:
                  .: {}
                  f:drop: {}
                f:runAsNonRoot: {}
                f:runAsUser: {}
              f:terminationMessagePath: {}
              f:terminationMessagePolicy: {}
              f:volumeMounts:
                .: {}
                k:{"mountPath":"/usr/bin"}:
                  .: {}
                  f:mountPath: {}
                  f:name: {}
                k:{"mountPath":"/var/run/kubevirt-ephemeral-disks/container-disk-data/38b33d91-d1c7-4189-9405-b679c9954430"}:
                  .: {}
                  f:mountPath: {}
                  f:name: {}
          f:nodeSelector: {}
          f:readinessGates: {}
          f:restartPolicy: {}
          f:schedulerName: {}
          f:securityContext:
            .: {}
            f:runAsGroup: {}
            f:runAsNonRoot: {}
            f:runAsUser: {}
            f:seccompProfile:
              .: {}
              f:localhostProfile: {}
              f:type: {}
          f:terminationGracePeriodSeconds: {}
          f:volumes:
            .: {}
            k:{"name":"cloudinitdisk-udata"}:
              .: {}
              f:name: {}
              f:secret:
                .: {}
                f:defaultMode: {}
                f:secretName: {}
            k:{"name":"container-disks"}:
              .: {}
              f:emptyDir: {}
              f:name: {}
            k:{"name":"ephemeral-disks"}:
              .: {}
              f:emptyDir: {}
              f:name: {}
            k:{"name":"hotplug-disks"}:
              .: {}
              f:emptyDir: {}
              f:name: {}
            k:{"name":"libvirt-runtime"}:
              .: {}
              f:emptyDir: {}
              f:name: {}
            k:{"name":"private"}:
              .: {}
              f:emptyDir: {}
              f:name: {}
            k:{"name":"public"}:
              .: {}
              f:emptyDir: {}
              f:name: {}
            k:{"name":"sockets"}:
              .: {}
              f:emptyDir: {}
              f:name: {}
            k:{"name":"virt-bin-share-dir"}:
              .: {}
              f:emptyDir: {}
              f:name: {}
      manager: Go-http-client
      operation: Update
      time: '2023-09-06T09:28:27Z'
    - apiVersion: v1
      fieldsType: FieldsV1
      fieldsV1:
        f:status:
          f:conditions:
            k:{"type":"kubevirt.io/virtual-machine-unpaused"}:
              .: {}
              f:lastProbeTime: {}
              f:lastTransitionTime: {}
              f:message: {}
              f:reason: {}
              f:status: {}
              f:type: {}
      manager: Go-http-client
      operation: Update
      subresource: status
      time: '2023-09-06T09:28:27Z'
    - apiVersion: v1
      fieldsType: FieldsV1
      fieldsV1:
        f:metadata:
          f:annotations:
            f:k8s.v1.cni.cncf.io/network-status: {}
      manager: multus-daemon
      operation: Update
      subresource: status
      time: '2023-09-06T09:28:27Z'
    - apiVersion: v1
      fieldsType: FieldsV1
      fieldsV1:
        f:status:
          f:conditions:
            k:{"type":"ContainersReady"}:
              .: {}
              f:lastProbeTime: {}
              f:lastTransitionTime: {}
              f:status: {}
              f:type: {}
            k:{"type":"Initialized"}:
              .: {}
              f:lastProbeTime: {}
              f:lastTransitionTime: {}
              f:status: {}
              f:type: {}
            k:{"type":"Ready"}:
              .: {}
              f:lastProbeTime: {}
              f:lastTransitionTime: {}
              f:status: {}
              f:type: {}
          f:containerStatuses: {}
          f:hostIP: {}
          f:initContainerStatuses: {}
          f:phase: {}
          f:podIP: {}
          f:podIPs:
            .: {}
            k:{"ip":"<IP_ADDRESS>"}:
              .: {}
              f:ip: {}
          f:startTime: {}
      manager: kubelet
      operation: Update
      subresource: status
      time: '2023-09-06T09:28:35Z'
  name: virt-launcher-vm-bwzsp
  namespace: vm
  ownerReferences:
    - apiVersion: kubevirt.io/v1
      blockOwnerDeletion: true
      controller: true
      kind: VirtualMachineInstance
      name: vm
      uid: 38b33d91-d1c7-4189-9405-b679c9954430
  resourceVersion: '1095282326'
  uid: 38783e4d-e0b9-45c8-aa4b-c62ec4166ba4
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: node-labeller.kubevirt.io/obsolete-host-model
                operator: DoesNotExist
  automountServiceAccountToken: false
  containers:
    - command:
        - /usr/bin/virt-launcher-monitor
        - '--qemu-timeout'
        - 256s
        - '--name'
        - vm
        - '--uid'
        - 38b33d91-d1c7-4189-9405-b679c9954430
        - '--namespace'
        - vm
        - '--kubevirt-share-dir'
        - /var/run/kubevirt
        - '--ephemeral-disk-dir'
        - /var/run/kubevirt-ephemeral-disks
        - '--container-disk-dir'
        - /var/run/kubevirt/container-disks
        - '--grace-period-seconds'
        - '195'
        - '--hook-sidecars'
        - '0'
        - '--ovmf-path'
        - /usr/share/OVMF
        - '--run-as-nonroot'
      env:
        - name: XDG_CACHE_HOME
          value: /var/run/kubevirt-private
        - name: XDG_CONFIG_HOME
          value: /var/run/kubevirt-private
        - name: XDG_RUNTIME_DIR
          value: /var/run
        - name: POD_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.name
      image: >-
        quay.io/kubevirt/virt-launcher@sha256:20a72f7f5349f1f4035863b491b9a857c7dbbe5c7d8368bb6d7384f4b279c57c
      imagePullPolicy: IfNotPresent
      name: compute
      resources:
        limits:
          cpu: '16'
          devices.kubevirt.io/kvm: '1'
          devices.kubevirt.io/tun: '1'
          devices.kubevirt.io/vhost-net: '1'
        requests:
          cpu: '4'
          devices.kubevirt.io/kvm: '1'
          devices.kubevirt.io/tun: '1'
          devices.kubevirt.io/vhost-net: '1'
          ephemeral-storage: 50M
          memory: '34806431745'
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          add:
            - NET_BIND_SERVICE
          drop:
            - ALL
        privileged: false
        runAsGroup: 107
        runAsNonRoot: true
        runAsUser: 107
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      volumeMounts:
        - mountPath: /var/run/kubevirt-private
          name: private
        - mountPath: /var/run/kubevirt
          name: public
        - mountPath: /var/run/kubevirt-ephemeral-disks
          name: ephemeral-disks
        - mountPath: /var/run/kubevirt/container-disks
          mountPropagation: HostToContainer
          name: container-disks
        - mountPath: /var/run/libvirt
          name: libvirt-runtime
        - mountPath: /var/run/kubevirt/sockets
          name: sockets
        - mountPath: /var/run/kubevirt-private/secret/cloudinitdisk/userdata
          name: cloudinitdisk-udata
          readOnly: true
          subPath: userdata
        - mountPath: /var/run/kubevirt-private/secret/cloudinitdisk/userData
          name: cloudinitdisk-udata
          readOnly: true
          subPath: userData
        - mountPath: /var/run/kubevirt/hotplug-disks
          mountPropagation: HostToContainer
          name: hotplug-disks
    - args:
        - '--copy-path'
        - >-
          /var/run/kubevirt-ephemeral-disks/container-disk-data/38b33d91-d1c7-4189-9405-b679c9954430/disk_1
      command:
        - /usr/bin/container-disk
      image: kubevirt/fedora-cloud-container-disk-demo:latest
      imagePullPolicy: Always
      name: volumeos
      resources:
        limits:
          cpu: 100m
          memory: 40M
        requests:
          cpu: 10m
          ephemeral-storage: 50M
          memory: 1M
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        runAsNonRoot: true
        runAsUser: 107
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      volumeMounts:
        - mountPath: >-
            /var/run/kubevirt-ephemeral-disks/container-disk-data/38b33d91-d1c7-4189-9405-b679c9954430
          name: container-disks
        - mountPath: /usr/bin
          name: virt-bin-share-dir
  dnsPolicy: ClusterFirst
  enableServiceLinks: false
  hostname: vm
  initContainers:
    - command:
        - /usr/bin/cp
        - /usr/bin/container-disk
        - /init/usr/bin/container-disk
      env:
        - name: XDG_CACHE_HOME
          value: /var/run/kubevirt-private
        - name: XDG_CONFIG_HOME
          value: /var/run/kubevirt-private
        - name: XDG_RUNTIME_DIR
          value: /var/run
      image: >-
        quay.io/kubevirt/virt-launcher@sha256:20a72f7f5349f1f4035863b491b9a857c7dbbe5c7d8368bb6d7384f4b279c57c
      imagePullPolicy: IfNotPresent
      name: container-disk-binary
      resources:
        limits:
          cpu: 100m
          memory: 40M
        requests:
          cpu: 10m
          memory: 1M
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        privileged: false
        runAsGroup: 107
        runAsNonRoot: true
        runAsUser: 107
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      volumeMounts:
        - mountPath: /init/usr/bin
          name: virt-bin-share-dir
    - args:
        - '--no-op'
      command:
        - /usr/bin/container-disk
      image: kubevirt/fedora-cloud-container-disk-demo:latest
      imagePullPolicy: Always
      name: volumeos-init
      resources:
        limits:
          cpu: 100m
          memory: 40M
        requests:
          cpu: 10m
          ephemeral-storage: 50M
          memory: 1M
      securityContext:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
        runAsNonRoot: true
        runAsUser: 107
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      volumeMounts:
        - mountPath: >-
            /var/run/kubevirt-ephemeral-disks/container-disk-data/38b33d91-d1c7-4189-9405-b679c9954430
          name: container-disks
        - mountPath: /usr/bin
          name: virt-bin-share-dir
  nodeName: xxx
  nodeSelector:
    kubevirt.io/schedulable: 'true'
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  readinessGates:
    - conditionType: kubevirt.io/virtual-machine-unpaused
  restartPolicy: Never
  schedulerName: default-scheduler
  securityContext:
    runAsGroup: 107
    runAsNonRoot: true
    runAsUser: 107
    seccompProfile:
      localhostProfile: kubevirt/kubevirt.json
      type: Localhost
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 210
  tolerations:
    - effect: NoExecute
      key: node.kubernetes.io/not-ready
      operator: Exists
      tolerationSeconds: 300
    - effect: NoExecute
      key: node.kubernetes.io/unreachable
      operator: Exists
      tolerationSeconds: 300
  volumes:
    - emptyDir: {}
      name: private
    - emptyDir: {}
      name: public
    - emptyDir: {}
      name: sockets
    - emptyDir: {}
      name: virt-bin-share-dir
    - emptyDir: {}
      name: libvirt-runtime
    - emptyDir: {}
      name: ephemeral-disks
    - emptyDir: {}
      name: container-disks
    - name: cloudinitdisk-udata
      secret:
        defaultMode: 420
        secretName: cloud-init-vm
    - emptyDir: {}
      name: hotplug-disks
status:
  conditions:
    - lastProbeTime: '2023-09-06T09:28:27Z'
      lastTransitionTime: '2023-09-06T09:28:27Z'
      message: the virtual machine is not paused
      reason: NotPaused
      status: 'True'
      type: kubevirt.io/virtual-machine-unpaused
    - lastProbeTime: null
      lastTransitionTime: '2023-09-06T09:28:31Z'
      status: 'True'
      type: Initialized
    - lastProbeTime: null
      lastTransitionTime: '2023-09-06T09:28:35Z'
      status: 'True'
      type: Ready
    - lastProbeTime: null
      lastTransitionTime: '2023-09-06T09:28:35Z'
      status: 'True'
      type: ContainersReady
    - lastProbeTime: null
      lastTransitionTime: '2023-09-06T09:28:27Z'
      status: 'True'
      type: PodScheduled
  containerStatuses:
    - containerID: >-
        containerd://76458ef82a582d0cadb207b51438ce5249e94e365b436e6bc427669e24bca793
      image: quay.io/kubevirt/virt-launcher:v0.59.0
      imageID: >-
        quay.io/kubevirt/virt-launcher@sha256:20a72f7f5349f1f4035863b491b9a857c7dbbe5c7d8368bb6d7384f4b279c57c
      lastState: {}
      name: compute
      ready: true
      restartCount: 0
      started: true
      state:
        running:
          startedAt: '2023-09-06T09:28:32Z'
    - containerID: >-
        containerd://36e4511a9be0d0792e3bab9bdf25b99dc8dd804ce55c2694b8c7db0eb47492cc
      image: docker.io/kubevirt/fedora-cloud-container-disk-demo:latest
      imageID: >-
        docker.io/kubevirt/fedora-cloud-container-disk-demo@sha256:4a0c3f9526551d0294079f1b0171a071a57fe0bf60a2e8529bf4102ee63a67cd
      lastState: {}
      name: volumeos
      ready: true
      restartCount: 0
      started: true
      state:
        running:
          startedAt: '2023-09-06T09:28:34Z'
  hostIP: 192.168.xxx.xxx
  initContainerStatuses:
    - containerID: >-
        containerd://c7b62046e88e640639e6b16dbb9573c00f5a819b0ba9153b53a8573979247dee
      image: quay.io/kubevirt/virt-launcher:v0.59.0
      imageID: >-
        quay.io/kubevirt/virt-launcher@sha256:20a72f7f5349f1f4035863b491b9a857c7dbbe5c7d8368bb6d7384f4b279c57c
      lastState: {}
      name: container-disk-binary
      ready: true
      restartCount: 0
      state:
        terminated:
          containerID: >-
            containerd://c7b62046e88e640639e6b16dbb9573c00f5a819b0ba9153b53a8573979247dee
          exitCode: 0
          finishedAt: '2023-09-06T09:28:28Z'
          reason: Completed
          startedAt: '2023-09-06T09:28:28Z'
    - containerID: >-
        containerd://f5728f88150dc6ef271e1bdf29c7d3b055d40e3475ffde68aab717b07583178b
      image: docker.io/kubevirt/fedora-cloud-container-disk-demo:latest
      imageID: >-
        docker.io/kubevirt/fedora-cloud-container-disk-demo@sha256:4a0c3f9526551d0294079f1b0171a071a57fe0bf60a2e8529bf4102ee63a67cd
      lastState: {}
      name: volumeos-init
      ready: true
      restartCount: 0
      state:
        terminated:
          containerID: >-
            containerd://f5728f88150dc6ef271e1bdf29c7d3b055d40e3475ffde68aab717b07583178b
          exitCode: 0
          finishedAt: '2023-09-06T09:28:31Z'
          reason: Completed
          startedAt: '2023-09-06T09:28:31Z'
  phase: Running
  podIP: <IP_ADDRESS>
  podIPs:
    - ip: <IP_ADDRESS>
  qosClass: Burstable
  startTime: '2023-09-06T09:28:27Z'

for anyone finding this issue looking for the helm option. it's socketLB.hostNamespaceOnly now:
https://github.com/cilium/cilium/blob/main/install/kubernetes/cilium/values.yaml#L948C5-L948C22


Missing Robot Cabin

Location: Deserted Robotics Lab. If you enter the location from the landing place side, on the left side of the entrance to the robotics lab, there is usually a Robot, with a terminal you can unlock. The cabin this Robot is supposed to be in is missing. I can't say if this is random, but it happened the last three times I visited such a place.

Game Version
<IP_ADDRESS>
Language
English (EN)
New Game
Yes
Reproduction Steps
Go to any "Deserted Robotics Lab" location. Find the landing place, go down the stairs to the lab entrance, and the Robot should be left side of the door.

I forgot to add Shattered Space as DLC condition.

I've seen a few locations where Robots are missing their capsule but I've yet to look at how to edit the proc-gen locations.

I assume they sit in preset "mini"-cells, which will just be attached to the proc generation of the location. They are likely the same as we had in Fallout 4. Just can't remember the correct terminology right now. Mesh Groups? Reference Groups? I can't remember. But I guess you know what I mean.

I guess this one has been fixed by either you guys, or by the latest patch. Two time the location, the robot cabin was properly in place. As additional "layer" of difficulty they've added foliage and raised the water level. So my guess is this location was supposed to stand partially under water, but they forgot to correctly set up the water level etc. Looks pretty decent from what I was used to before.

I just want to let you know that this seems fixed for that specific location. But I ran into another invisible Robot holder just yesterday. Unfortunately my slow brain didn't react quick enough to note the ID. I remember I was doing a Ryujin mission, and it brought me to the Carinae System, where I stumbled across the quest "Juno's Gambit". It's the quest with the "AI" ship, and the planet the ship is orbiting has an "Asteroid Mining Outpost" or so, which held the broken Robot case. I provide ID data once I stumble across it again, but that may take a while, because I rarely visit one and the same place again in this game.


Flux Standard Action

I whipped together this minimal standard for Flux actions. Quoting from the README:

It's much easier to work with Flux actions if we can make certain assumptions about their shape. For example, essentially all Flux actions have an identifier field, such as type, actionType, or actionId. Many Flux implementations also include a way for actions to indicate success or failure, especially as the result of a data-fetching operation. Defining a minimal, common standard for these patterns enables the creation of useful tools and abstractions.

I came up with these initial specs based on my experience with Flummox, which internally uses a similar pattern for action handling. The key difference is that with Flummox, the implementation was baked into the core, whereas Redux allows us to take a much more modular, flexible approach.
I absolutely don't think this should be part of the Redux core, but it'd be nice to encourage middleware/extension users support this standard (or something like it) so that they're all interoperable.
To see an example of how FAS is useful, see this section of redux-promise.
Thoughts? Would love to receive feedback.
EDIT: Forgot to mention that I created some tools for creating and handling FSA actions in Redux. Look at handleActions() in particular for an example of how to create a reducer that handle multiple actions https://github.com/acdlite/redux-fsa#handleactionsreducermap-defaultstate.

I like the idea. So basically like a "json-schema", only for actions, right?

Interface instead of assumptions?
The overall idea is great, but there are lots of options how to achieve it. One of possibilities is to define an "interface" (a set of functions that user can provide) which would give users full control.
I have no specific suggestions yet, because for making them it would be better to examine several popular action "schemas" first.
For example, current FSA version would require a change to popular pattern of "SOME_ACTION_REQUESTED", "SOME_ACTION_SUCCESS", "SOME_ACTION_ERROR", where status is part of action's name, and the first of these actions may be handled in a reducer and impact state.
Drawback of using isSuccess/isError, is that each reducer would need to check for both, leading to lots of code duplication.

@emmenko Pretty much, except much more limited in scope.
@clearjs

The overall idea is great, but there are lots of options how to achieve it.

This is the point of defining a standard, right? To agree on some basic conventions so we can build tools around it.

For example, current FSA version would require a change to popular pattern of "SOME_ACTION_REQUESTED", "SOME_ACTION_SUCCESS", "SOME_ACTION_ERROR", where status is part of action's name, and the first of these actions may be handled in a reducer and impact state.

Yes, this is a popular pattern today, but it can easily be expressed using FSA's status field, which has the advantage of not 1) not requiring multiple action types, and 2) explicitly indicating the success or failure of an action, without needing to parse the action type.

Drawback of using isSuccess / isError, is that many reducers would need to check for both, leading to lots of code duplication.

You wouldn't have to use isSuccess / isError. The code for both is very simple. It's mostly just there as a reference implementation.

Take a look at the source of redux-promise as an example: https://github.com/acdlite/redux-promise/blob/master/src/index.js#L15-L20

This is the point of defining a standard, right?

Exactly. My point is that it might (but might not) be better to give users control and middleware some "interface".

You wouldn't have to use isSuccess / isError.

What I meant was that for "SOME_ACTION_SUCCESS" there might be a separate reducer from the other two. No need for a check at all.
Another point was that not all

You can still have separate reducers. The reducer just needs to check the status. See redux-fsa's handleAction() function, which does exactly this.

What I suggest is to discuss a few popular alternative action schemas somewhere, then think about best way to standardise.

You can still have separate reducers. The reducer just needs to check the status.
Adding some boilerplate.

See redux-fsa's handleAction() function, which does exactly this.

This looks very nice to me.

@clearjs Sure, of course, this standard isn't set in stone by any means. This initial version is based on my specific experiences with Flummox, but I'm totally open to changing and evolving it. The most important thing is that it's something the community can agree upon.

How to organise this discussion best? Maybe create one issue in the FSA repo per a schema that somebody uses in real life?

Another thing to note is that a middleware like redux-promise simply doesn't work with the ACTION_SUCCESS, ACTION_ERROR pattern without appending strings to the type. And then on the other side, the reducer has to do a action.type.endsWith('_SUCCESS') check, which is pretty gross IMO. It's better to have separate fields for type and status rather than overload them in a single field.
@clearjs Yeah, for in depth discussion of this it's probably best to open issues in the FSA repo.

@gaearon I know you're busy this week but I'd love to hear your thoughts, as well!

And then on the other side, the reducer has to do a action.type.endsWith('_SUCCESS') check, which is pretty gross IMO.

Not if reducer only handles SOME_ACTION_SUCCESS. Just a remark, you've already convinced me.

@acdlite, when you said:

Unlike Flummox, it will not perform a dispatch at the beginning of the operation, only at the end. Use Redux's built-in thunkMiddleware in combination with redux-promise to perform optimistic updates.

Could you briefly state how that would be structured?  I'm having a little bit of a hard time understanding how the order of middlewares would affect a thunk-dispatching-a-promise verses a promise-returning-a-thunk.  Also if I'm programming with promises having to fall back to a hand-written thunk rather than just using the ES7 async functionality wouldn't be my first choice.
But like I said I'm not completely clear on what's going on here, so it may make perfect sense.

(Also, is it legal to dispatch multiple times from a thunk-handled action?  Glancing at the code I'd say yes, but...)

@bdowning Yes, it is legal :)
The reason for not dispatching at the beginning is because usually when doing optimistic updates, you need to dispatch certain information like an id or a timestamp. Since there's no obvious pattern for how to do this, for now I'm suggesting that redux-promise users just use the thunk middleware for now.
Basic example:
// Relies on both thunk and promise middleware
createAction('FETCH_SOMETHING', id => {
  // Thunk will be handled by thunk middleware
  return dispatch => {
    // Trigger optimistic update
    dispatch({ type: 'FETCH_SOMETHING_BEGIN', body: { id } });

    // Promise will be handled by promise middleware
    return api.fetch(id);
  }
});

We're considering adding another status type besides error and success (perhaps pending?) though I'm not sure about this yet. https://github.com/acdlite/flux-standard-action/issues/1#issuecomment-118109907

@acdlite And just to check, for your example to work is there a specific ordering of thunk and promise middleware that has to be installed, or would any order work?
-bcd

I'll take a look soon. Too tired :-)

The main problem with this standardization process is I think that this kind of "actions" should fire automatically and this question shouldn't be exists at all. Also I found that other aspects Flux architecture itself is unnecessary overcomplicated in general.
I've started an alternative to Flux arch that's follows the same unidirectional approach but it differs in focus on the consistency of the state at any point of time. You could check it out here https://github.com/AlexeyFrolov/slt . It's on the early point of development, and it lack of examples and community, but it's well tested and I'm already using it in production in my projects.

@acdlite I really like this FSA idea :+1: in fact I use this { type: String, payload: Object } signature myself.
But I'm not sure about the status string (even if it allows these helpers here). It seems like added complexity, you're now handling 2 values, one constant and a plain string which could be error prone.
I mean, this
switch (action.type) {
  case FETCH_DATA:
  // ..
    break

  case FETCH_DATA_SUCCESS:
  // ..
    break

  case FETCH_DATA_ERROR:
  // ..
    break
}

is much more simpler than this
switch (action.type) {
  case FETCH_DATA:
  if (action.status === 'success') {
    // ..
  } else if (action.status === 'error') {
    // ..
  } else {
    // ..
  }
     break
}

Don't you think? That's my 2c

@acstll There is an interesting discussion on this topic here: https://github.com/acdlite/flux-standard-action/issues/1

@acstll The reason for a status field is so we can do this:
handleAction('FETCH_DATA', {
  success(state, action) {...}
  error(state, action) {...}
});

https://github.com/acdlite/redux-fsa#handleactiontype-reducer--reducermap

I'm closing, as it's not a Redux issue, and it has been dormant for a while.
FSA is mentioned in the new docs.


Update carbon-commons version

$subject

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/2139404755

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/2139404755
Status: failure

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/2142963752

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/2142963752
Status: cancelled


check hash validity of backward relay cells

We should be checking the validity of backward relay cell content with the appropriate backward digest and updating it accordingly.
Currently we're just ignoring this completely.
This should be added along with a fix for #70

This has been fixed since #76 merge


Plotting Functions have stale dependencies

Hi all,
Thank you for publishing the code I saw the paper and was quite interested in implementing and testing this method myself.
Unfortunately I think something is not right with the automatic installation of the sklearn package when trying to install
pip install git+https://github.com/fortuinlab/LA-NAM.git
More specifically, when i create a new environment and install the package I can run the la-nam. However when trying to call this line
from laplace_skorch.inspection import subnetwork_outputs_for_X, subnetwork_covar_for_X
I get the following error:

Traceback (most recent call last):
File "nam_iris.py", line 52, in
from laplace_skorch.inspection import subnetwork_outputs_for_X, subnetwork_covar_for_X
File "/C:/Users/ifft/miniforge3/envs/newenv/lib/python3.11/site-packages/laplace_skorch/inspection.py", line 13, in
from sklearn.utils import _get_column_indices, _safe_indexing, check_matplotlib_support
ImportError: cannot import name '_get_column_indices' from 'sklearn.utils' (/C:/Users/ifft/miniforge3/envs/newenv/lib/python3.11/site-packages/sklearn/utils/init.py)

I've looked up when this function was actively used and it seems that it was used in sklearn < 1.5
When i then want to downgrade it it doesnt work as other dependencies aren't compatible with a lower version of sklearn.
What would you suggest as a workaround for leveraging the plotting functions?

#downgrading scikit-learn to 1.4 resolved the issue

Ah yes, seems that this private API was split up into submodules in scikit-learn >= 1.5.0. I pushed a fix and added a dependency on that version or above.
Thanks for testing our project! Let me know if this fixes the fresh install for you. (If not I'll re-open.)


Can influxDB use multiple SSD

AS we have 12 SSD, but one ssd only 400G, so I'm confused whether influxDB can use multiple SSD?

@ziflyingyo the WAL and data can be configured to write to different directories but data can't be configured for multiple locations. Please post usage questions to the InfluxData community site. GitHub issues are for bugs and feature requests.


Send message to M365 group - Permissions needed. Ask your IT admin to enable this option for you.

Hi everybody,
It is not possible for me to send messages to the M365 group. Which setting do I have to change in the admin center so that this is possible?

Hi,
Check the steps of grant permissions to the app: Add permissions to your app

hi, i have the same issue, but the permissions are ok

Same issue with a new deployment. I provided the author app the required permissions on MS Graph. I can send messages through the app to channels, to everyone, and also to members of a MS Team. However it fails for M365 Groups only with the message described above.
Any tip where we can look for troubleshooting ?

Hi, I have the same issue. I already checked the API permissions for the authors app (please see next figure) but I'm still unable to send messages to M365 Groups. Any idea is welcome, thanks!

I found a solution: in the "Microsoft Teams admin center" go to "Teams apps"->"Manage Apps" and select the Company Communicator author app.; after clicking the author app you can go to the Permissions section and click "Review permissions and consent". This action will grant consent to the author app to read the groups info.
I successfully tested this process in in two different tenants!

Hello @etepetepe2022,
If all the permission are granted by admin from portal for the authors apps then you should definitely try what @faranzazu is suggesting.
Thank you for the solution @faranzazu.
OR
Maybe you can try doing this by URL consent.
Mention at Deployment Guide's Step 4.4.

Prepare link - https://login.microsoftonline.com/common/adminconsent?client_id=%appId%. Replace the %appId% with the Application (client) ID of Microsoft Teams author bot app (from above).

Let us know if the issue still persists for you.
Thanks.


Feature Request: Flags/Filter to auto-select collections

It would be more convenient to have flags + filters for auto-selecting collections and skipping the blocking dialog. This would in essence make the CLI-call a fire-and-forget execution where you don't have to wait for a dialog to come up and manually select the collections.
Some examples:

Skip Single-Collection choice: https://www.crunchyroll.com/alice-zoroku
This series has only one collection available in US (the RU collection is not available there) in this case the whole dialog could be skipped as there is only one item to be selected anyway.
Same goes for all series which have only one collection.

Skip Multi-Collection choice without filter: https://www.crunchyroll.com/food-wars-shokugeki-no-soma
This series has three different seasons available and if I want to simply download all of them the selection could also be skipped.

Skip Multi-Collection choice with filter: https://www.crunchyroll.com/the-ancient-magus-bride
Here are many dubs available which I personally would filter out with general filters to sort out everything containing "Dub)" or "(RU)". This way only the ones are auto-selected not containing these expressions and an auto-skip/select would be possible.

Hey there.
In 1.3.0 I added a couple options to address this, as I was planning on adding something like this for a while.
--ignore-dubs will now attempt to ignore any dubs
--episodes will allow you to select episode ranges
--download-all will download all collections
The best part is, all of these can be used at the same time... For example:
crunchyroll-dl -i https://www.crunchyroll.com/fullmetal-alchemist-brotherhood --download-all --ignore-dubs --episodes 1-12,15-20

Would ignore the dubbed version of the show, choose the subbed season, and download episodes 1-12 and 15-20.
I also tried to add a lot of feedback if something goes wrong.
Hope this helps!

Thank you and great work with this. I only have one minor issue with the "--episodes" parameter: If you only select one single episode it'll just drop out with an unhandle promise rejection. I'm aware that you can download single episodes with providing the direct link to it but without any proxy or session cookie magic in the browser you'll not be able to get that direct link for (out of your) region specific content. So at least for me it would be more convenient to be able to also select single episodes with the "--episodes" parameter.

@Noctunus
Hmm, I see your point. I have fixed that bug in 1.3.1, and to hopefully help, I pushed a feature that I had in my private version - --list. It will list all the collections and episodes as a tree in your console.

Oh, you did a excellent job there.

@simplymemes the new list param is awesome - thanks for that.
The --ignore-dubs parameter is working most of the time but with series like https://www.crunchyroll.com/puella-magi-madoka-magica it'll also select the dubbed version as it's not following the "(LNG Dub)" naming but simply "(Dubbed)". Maybe you could extend the regex to also include the optional "bed" at the end?

Found another "minor" bug with the series: https://www.crunchyroll.com/squid-girl
The first collection contains some files with no episode number:

└─ Squid Girl
   ├─ Squid Girl Season 1
   │  ├─ #(none) Squid Girl Preview #1
   │  ├─ #(none) Interview with Squid Girl (Hisako Kanemoto)
   │  ├─ #(none) Hat Making
   │  ├─ #(none) Squid Girl Preview #2
   │  ├─ #1 Who's up for a squid-vasion? / Hold on a squid, aren't you a compatriot? / Aren't I just the squiddiest?
   │  ├─ #2 Wait a squid, aren't you on my side? / Up for a squid-celebration? / Wanna play with this squid?
[...]

Without providing the episode (-e)  parameter it'll drop out with:

i Beginning to download "Squid Girl Season 1"
i Downloading episode (not set), "Squid Girl Preview #1", of "Squid Girl Season 1"
i Attempting to fetch episode...
! You may not have access to watch this episode
(node:4333) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'url' of undefined
    at getEpisode (/usr/local/lib/node_modules/crunchyroll-dl/index.js:240:33)
    at < anonymous >
    at process._tickCallback (internal/process/next_tick.js:188:7)
(node:4333) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:4333) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

By simply selecting the episodes with -e 1-12 this error is avoided as the episodes are filtered out.

@Noctunus I quickly pushed 1.3.3 to address these two problems :)

Thank you very much.

@simplymemes
I'll close this ticket now as the suggested feature is implemented and tested so far. If anything else comes up I'll open a new ticket.
Thanks a lot!


feat: include hash on success page

What does this PR do and why?
Provide a description of what this PR does. Link to any relevant GitHub issues, Notion tasks or Discord discussions.
Screenshots or screen recordings
If applicable, provide screenshots or screen recordings to demonstrate the changes.
Acceptance checklist

[ ] I have evaluated the Approval Guidelines for this PR.
[ ] (if relevant) I have tested this PR in all supported browsers.
[ ] (if relevant) I have tested this PR in dark mode and light mode (if applicable).

Current dependencies on/for this PR:

main

PR #3708

PR #3709

PR #3710

PR #3711   👈

This comment was auto-generated by Graphite.

@wraeth-eth started a stack merge that includes this pull request via Graphite.

Graphite rebased this pull request as part of a merge.


fluentd conf

In the logs-fluentd ConfigMap, the 01-sources.conf value has the entry as below
<...>
      kafka_configs {
        "bootstrap.servers": "brokers  logs-kafka-0:9092",
        "group.id": "fluentd"
      }
<...>

When I use this, I get an error from fluentd on startup per below

ERROR -- : rdkafka: [thrd:brokers logs-kafka-0:9092/bootstrap]: brokers logs-kafka-0:9092/bootstrap: Failed to resolve 'brokers logs-kafka-0:9092': Name or service not known (after 0ms in state CONNECT)

When I change the config per below, it works.
<...>
      kafka_configs {
        "bootstrap.servers": "logs-kafka-0:9092",
        "group.id": "fluentd"
      }
<...>

Do you know why this would be?
I can see that it mirrors the config per the fluentd rdkafka_group config so I'm not sure what's happening.
P.S. Thanks for the great work, it's a massive headstart and great solution.

Thank, the proposal is released in chart version 2.4.1


Enable CodeQL scanning

This PR will enable a github action triggering codeQL checks in this repository

👋🏻  Hey folks, glad to see you're using code scanning! A couple of comments I wanted to share:

We include the cron trigger to ensure that there's always at least one analysis per week. While that's redundant while there's active development going on, it may be the only analysis which happens if active development ceases. Since the threat landscape is constantly changing, this ensures you learn about new threats in either case.
For the push event, we recommend that you run on all branches so that you can learn about newly introduced security issues in your pull requests. Running only on master means that the vulnerabilities can be introduced to your mainline before we detect them.

In any case, thanks for testing this out and please feel free to shout if you have any concerns!


adding attribute 'assignee' & adding 'resolved' in attr_reader for faults api

@ajish Thanks for submitting some changes. I've taken a look and noticed some issues that you'll need to address. Give me a shout when you want me to take another look :+1:

sure, I will try and get this done in the next 24 hours.
On Tue, Jul 7, 2015 at 3:21 AM, Murray Summers<EMAIL_ADDRESS>wrote:

@ajish https://github.com/ajish Thanks for submitting some changes.
I've taken a look and noticed some issues that you'll need to address. Give
me a shout when you want me to take another look [image: :+1:]
—
Reply to this email directly or view it on GitHub
https://github.com/murraysum/honeybadger-api/pull/5#issuecomment-119007376
.

--
Ajish Balakrishnan
+91-8197068965

in.linkedin.com/pub/ajish-balakrishnan/1a/214/ba7/

@ajish Hey, I haven't heard from you in a while and this fell off my radar.
In the latest v2.0.0 release I have now included assignee attribute for faults.
I didn't realise at the time but you can tell if a fault is resolved using the resolved? method which I think is clearer that an attr_reader of resolved.
I am going to close this pull request as I think all the behaviour you need is now present. Please let me know if it isn't. 👍


ALSA lib  error

while I run the traing code
I found the ALSA error:

ALSA lib conf.c:5180:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
ALSA lib conf.c:5703:(snd_config_expand) Evaluate error: No such file or directory
why this will use ALSA and how can i fix it

i'm running the training bash script using the debug dataset
python hulc/training.py +trainer.gpus=-1 +datamodule.root_data_dir=/data/calvin/debug_dataset   datamodule/datasets=vision_lang_shm
after validation the error comes out

ps when i use the ABC_D dataset it collapse when load the data

It could be a problem with the GPU renderer when you run the rollouts. Can you try turning off rollouts and see if it still crashes? You have to add ~callbacks/rollout and ~callbacks/rollout_lh to the command line arguments. Which GPU do you have in your machine?
For the bigger dataset, you might not have enough shared memory, so try using the normal dataloader by setting datamodule/datasets=vision_lang.

when adding ~callbacks/rollout and ~callbacks/rollout_lh,it shows that: I have 4 A100 with 40G . and 5 EGL devices , with ID=4 can be used

when adding ~callbacks/rollout and ~callbacks/rollout_lh,it shows that:

I have 4 A100 with 40G . and 5 EGL devices , with ID=4 can be used .so I set   EGL_DEVICE_ID=4 to run the code or it will crash

ah sorry, my bad, then try only using `~callbacks/rollout_lh~.
Is your Nvidia driver correctly installed? In the log you previously sent it mentions Mesa, which shouldn't be used if you have an Nvidia GPU with the correct driver.

how can i not use Mesa? Here is my GPU :

I tried using the normal dataloader by setting datamodule/datasets=vision_lang. it can load the data ,but after validation of epoch 0, it crashes again :
`[Rank 3] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=63281, OpType=ALLREDUCE, NumelIn=1, NumelOut=1, Timeout(ms)=1800000) ran for 1800149 milliseconds before timing out.
[rank3]:[E ProcessGroupNCCL.cpp:537] Some NCCL operations have failed or timed out. Due to the asynchronous nature of CUDA kernels, subsequent GPU operations might run on corrupted/incomplete data.
[rank3]:[E ProcessGroupNCCL.cpp:543] To avoid data inconsistency, we are taking the entire process down.
[rank3]:[E ProcessGroupNCCL.cpp:1182] [Rank 3] NCCL watchdog thread terminated with exception: [Rank 3] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=63281, OpType=ALLREDUCE, NumelIn=1, NumelOut=1, Timeout(ms)=1800000) ran for 1800149 milliseconds before timing out.
Exception raised from checkTimeout at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:525 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x57 (0x7fe1fdae0d87 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libc10.so)
frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x1e6 (0x7fe1fec886e6 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #2: c10d::ProcessGroupNCCL::workCleanupLoop() + 0x19d (0x7fe1fec8bc3d in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #3: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x119 (0x7fe1fec8c839 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #4:  + 0xd3e95 (0x7fe2489a9e95 in /data/mamba/envs/robodiff/bin/../lib/libstdc++.so.6)
frame #5:  + 0x8609 (0x7fe24a003609 in /lib/x86_64-linux-gnu/libpthread.so.0)
frame #6: clone + 0x43 (0x7fe249dc2133 in /lib/x86_64-linux-gnu/libc.so.6)
terminate called after throwing an instance of 'c10::DistBackendError'
what():  [Rank 3] NCCL watchdog thread terminated with exception: [Rank 3] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=63281, OpType=ALLREDUCE, NumelIn=1, NumelOut=1, Timeout(ms)=1800000) ran for 1800149 milliseconds before timing out.
Exception raised from checkTimeout at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:525 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x57 (0x7fe1fdae0d87 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libc10.so)
frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x1e6 (0x7fe1fec886e6 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #2: c10d::ProcessGroupNCCL::workCleanupLoop() + 0x19d (0x7fe1fec8bc3d in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #3: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x119 (0x7fe1fec8c839 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #4:  + 0xd3e95 (0x7fe2489a9e95 in /data/mamba/envs/robodiff/bin/../lib/libstdc++.so.6)
frame #5:  + 0x8609 (0x7fe24a003609 in /lib/x86_64-linux-gnu/libpthread.so.0)
frame #6: clone + 0x43 (0x7fe249dc2133 in /lib/x86_64-linux-gnu/libc.so.6)
Exception raised from ncclCommWatchdog at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:1186 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x57 (0x7fe1fdae0d87 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libc10.so)
frame #1:  + 0xdf6b11 (0x7fe1fe9e2b11 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #2:  + 0xd3e95 (0x7fe2489a9e95 in /data/mamba/envs/robodiff/bin/../lib/libstdc++.so.6)
frame #3:  + 0x8609 (0x7fe24a003609 in /lib/x86_64-linux-gnu/libpthread.so.0)
frame #4: clone + 0x43 (0x7fe249dc2133 in /lib/x86_64-linux-gnu/libc.so.6)
[rank1]:[E ProcessGroupNCCL.cpp:523] [Rank 1] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=63281, OpType=ALLREDUCE, NumelIn=1, NumelOut=1, Timeout(ms)=1800000) ran for 1800818 milliseconds before timing out.
[rank1]:[E ProcessGroupNCCL.cpp:537] Some NCCL operations have failed or timed out. Due to the asynchronous nature of CUDA kernels, subsequent GPU operations might run on corrupted/incomplete data.
[rank1]:[E ProcessGroupNCCL.cpp:543] To avoid data inconsistency, we are taking the entire process down.
[rank1]:[E ProcessGroupNCCL.cpp:1182] [Rank 1] NCCL watchdog thread terminated with exception: [Rank 1] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=63281, OpType=ALLREDUCE, NumelIn=1, NumelOut=1, Timeout(ms)=1800000) ran for 1800818 milliseconds before timing out.
Exception raised from checkTimeout at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:525 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x57 (0x7fd106797d87 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libc10.so)
frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x1e6 (0x7fd10793f6e6 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #2: c10d::ProcessGroupNCCL::workCleanupLoop() + 0x19d (0x7fd107942c3d in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #3: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x119 (0x7fd107943839 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #4:  + 0xd3e95 (0x7fd151660e95 in /data/mamba/envs/robodiff/bin/../lib/libstdc++.so.6)
frame #5:  + 0x8609 (0x7fd152cba609 in /lib/x86_64-linux-gnu/libpthread.so.0)
frame #6: clone + 0x43 (0x7fd152a79133 in /lib/x86_64-linux-gnu/libc.so.6)
terminate called after throwing an instance of 'c10::DistBackendError'
what():  [Rank 1] NCCL watchdog thread terminated with exception: [Rank 1] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=63281, OpType=ALLREDUCE, NumelIn=1, NumelOut=1, Timeout(ms)=1800000) ran for 1800818 milliseconds before timing out.
Exception raised from checkTimeout at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:525 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x57 (0x7fd106797d87 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libc10.so)
frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x1e6 (0x7fd10793f6e6 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #2: c10d::ProcessGroupNCCL::workCleanupLoop() + 0x19d (0x7fd107942c3d in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #3: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x119 (0x7fd107943839 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #4:  + 0xd3e95 (0x7fd151660e95 in /data/mamba/envs/robodiff/bin/../lib/libstdc++.so.6)
frame #5:  + 0x8609 (0x7fd152cba609 in /lib/x86_64-linux-gnu/libpthread.so.0)
frame #6: clone + 0x43 (0x7fd152a79133 in /lib/x86_64-linux-gnu/libc.so.6)
Exception raised from ncclCommWatchdog at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:1186 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x57 (0x7fd106797d87 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libc10.so)
frame #1:  + 0xdf6b11 (0x7fd107699b11 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #2:  + 0xd3e95 (0x7fd151660e95 in /data/mamba/envs/robodiff/bin/../lib/libstdc++.so.6)
frame #3:  + 0x8609 (0x7fd152cba609 in /lib/x86_64-linux-gnu/libpthread.so.0)
frame #4: clone + 0x43 (0x7fd152a79133 in /lib/x86_64-linux-gnu/libc.so.6)
[rank2]:[E ProcessGroupNCCL.cpp:523] [Rank 2] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=63281, OpType=ALLREDUCE, NumelIn=1, NumelOut=1, Timeout(ms)=1800000) ran for 1800919 milliseconds before timing out.
[rank2]:[E ProcessGroupNCCL.cpp:537] Some NCCL operations have failed or timed out. Due to the asynchronous nature of CUDA kernels, subsequent GPU operations might run on corrupted/incomplete data.
[rank2]:[E ProcessGroupNCCL.cpp:543] To avoid data inconsistency, we are taking the entire process down.
[rank2]:[E ProcessGroupNCCL.cpp:1182] [Rank 2] NCCL watchdog thread terminated with exception: [Rank 2] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=63281, OpType=ALLREDUCE, NumelIn=1, NumelOut=1, Timeout(ms)=1800000) ran for 1800919 milliseconds before timing out.
Exception raised from checkTimeout at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:525 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x57 (0x7f2aa3076d87 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libc10.so)
frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x1e6 (0x7f2aa421e6e6 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #2: c10d::ProcessGroupNCCL::workCleanupLoop() + 0x19d (0x7f2aa4221c3d in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #3: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x119 (0x7f2aa4222839 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #4:  + 0xd3e95 (0x7f2aedf3fe95 in /data/mamba/envs/robodiff/bin/../lib/libstdc++.so.6)
frame #5:  + 0x8609 (0x7f2aef599609 in /lib/x86_64-linux-gnu/libpthread.so.0)
frame #6: clone + 0x43 (0x7f2aef358133 in /lib/x86_64-linux-gnu/libc.so.6)
terminate called after throwing an instance of 'c10::DistBackendError'
what():  [Rank 2] NCCL watchdog thread terminated with exception: [Rank 2] Watchdog caught collective operation timeout: WorkNCCL(SeqNum=63281, OpType=ALLREDUCE, NumelIn=1, NumelOut=1, Timeout(ms)=1800000) ran for 1800919 milliseconds before timing out.
Exception raised from checkTimeout at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:525 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x57 (0x7f2aa3076d87 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libc10.so)
frame #1: c10d::ProcessGroupNCCL::WorkNCCL::checkTimeout(std::optional<std::chrono::duration<long, std::ratio<1l, 1000l> > >) + 0x1e6 (0x7f2aa421e6e6 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #2: c10d::ProcessGroupNCCL::workCleanupLoop() + 0x19d (0x7f2aa4221c3d in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #3: c10d::ProcessGroupNCCL::ncclCommWatchdog() + 0x119 (0x7f2aa4222839 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #4:  + 0xd3e95 (0x7f2aedf3fe95 in /data/mamba/envs/robodiff/bin/../lib/libstdc++.so.6)
frame #5:  + 0x8609 (0x7f2aef599609 in /lib/x86_64-linux-gnu/libpthread.so.0)
frame #6: clone + 0x43 (0x7f2aef358133 in /lib/x86_64-linux-gnu/libc.so.6)
Exception raised from ncclCommWatchdog at ../torch/csrc/distributed/c10d/ProcessGroupNCCL.cpp:1186 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::string) + 0x57 (0x7f2aa3076d87 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libc10.so)
frame #1:  + 0xdf6b11 (0x7f2aa3f78b11 in /data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/lib/libtorch_cuda.so)
frame #2:  + 0xd3e95 (0x7f2aedf3fe95 in /data/mamba/envs/robodiff/bin/../lib/libstdc++.so.6)
frame #3:  + 0x8609 (0x7f2aef599609 in /lib/x86_64-linux-gnu/libpthread.so.0)
frame #4: clone + 0x43 (0x7f2aef358133 in /lib/x86_64-linux-gnu/libc.so.6)
Error executing job with overrides: ['+trainer.gpus=-1', 'datamodule.root_data_dir=/data/calvin/task_ABC_D', 'datamodule/datasets=vision_lang', '+datamodule.num_workers=1']
Traceback (most recent call last):
File "/pfs-data/code/hulc/hulc/training.py", line 76, in train
trainer.fit(model, datamodule=datamodule, ckpt_path=chk)  # type: ignore
File "/data/mamba/envs/robodiff/lib/python3.9/site-packages/pytorch_lightning/trainer/trainer.py", line 603, in fit
call._call_and_handle_interrupt(
File "/data/mamba/envs/robodiff/lib/python3.9/site-packages/pytorch_lightning/trainer/call.py", line 36, in _call_and_handle_interrupt
return trainer.strategy.launcher.launch(trainer_fn, *args, trainer=trainer, **kwargs)
File "/data/mamba/envs/robodiff/lib/python3.9/site-packages/pytorch_lightning/strategies/launchers/multiprocessing.py", line 113, in launch
mp.start_processes(
File "/data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/multiprocessing/spawn.py", line 197, in start_processes
while not context.join():
File "/data/mamba/envs/robodiff/lib/python3.9/site-packages/torch/multiprocessing/spawn.py", line 140, in join
raise ProcessExitedException(
torch.multiprocessing.spawn.ProcessExitedException: process 3 terminated with signal SIGABRT`
I wonder if this is related to the used of Mesa

I just realized there is a mistake in the README file, when pytorch-lightning upgraded to a newer version, they renamed the trainer.gpus argument to trainer.devices. This is already reflected in the code, but not in the documentation. Can you try running it on a single GPU without rollouts and without the shared memory dataloader?
python hulc/training.py trainer.devices=1 datamodule.root_data_dir=/data/calvin/debug_dataset datamodule/datasets=vision_lang ~callbacks/rollout_lh

If this works, then try the multiprocessing version by setting trainer.devices=-1

I also run the evaluate code withe pretrainde models
 python hulc/evaluation/evaluate_policy_ori.py --dataset_path /data/calvin/task_ABC_D  --train_folder ./checkpoints/HULC_ABC_D
How to get the video as output .i can't find some related params

I suggest you increase the batch size, we used 8 NVIDIA RTX 2080 ti with only 12 GB of memory per GPU, so if you have A100, you can easily increase the batch size. Since you use 4 GPUs in your setup, you could start by using batch size 64 if you want to have the same effective batch size as we had in our experiments, but feel free to experiment with increasing it more. Also, you can try to use more dataloading workers by setting datamodule.datasets.vision_dataset.num_workers=4 and  datamodule.datasets.lang_dataset.num_workers=4. Using the shared memory dataloader further speeds up training, but you need enough shared memory on your machine.
We trained our models for 30 epochs on 8 GPUs which took around 1 week (depending on the dataset).

I also run the evaluate code withe pretrainde models  python hulc/evaluation/evaluate_policy_ori.py --dataset_path /data/calvin/task_ABC_D --train_folder ./checkpoints/HULC_ABC_D How to get the video as output .i can't find some related params

Set the flag --debug

Thanks for your suggestion , I can run the code normally with num_workers=4 and batch_size =64 (although limited by the memory the speed is still slow)
After running one epoch I found nothing output , where the trained model saved ,and the save interval ,which params related to this .( I'm not familiar with the use of hydra )
Again thanks for your answering

By default, it saves the model every epoch. If you didn't set the log_dir command line argument, then it creates a folder  runs in the hulc directory, where all the runs are saved.

I got it
thanks for answering!

in order to make the rollouts work, did you have a look at this issue ?


lets try to default the instance name to some value by default which the user can then change if they wish

lets try to default the instance name to some value by default which the user can then change if they wish

[merge]

add to whitelist