I am seeing very inconsistent launch times with kata-qemu-virtiofs from kata-deploy 1.11

Description of problem
On multiple systems across different OS's I am seeing boot times that vary from 1s to 35s when using kata-qemu-virtiofs. I have confirmed this behavior on 3 different Clear Linux install versions and one Fedora 31 system. However, on an Ubuntu 18.04 system I am not seeing the behavior.
Here  is how I install kata on the systems.
docker run -v /opt/kata:/opt/kata -v /var/run/dbus:/var/run/dbus -v /run/systemd:/run/systemd -v /etc/docker:/etc/docker -it katadocker/kata-deploy:1.11.0 kata-deploy-docker install

I did not modify any of the files in /opt/kata
The command I ran is
time docker run --runtime=kata-qemu-virtiofs busybox date

Clear Linux systems
Docker is 19.03.6
Fedora system
Docker is 19.03.8
Ubuntu system
Docker is 19.03.6
Expected result
I would expect that the total time to launch and stop the container to do a simple command would be consistently between 1s and 2s.
Actual result
On the Clear Linux and Fedora 31 systems I see the launch to shutdown time vary between 1s to as high as 35s on some systems.   The Ubuntu system I tested has no issue. Below is a sample run on the Fedora 31 system.
eadams@fedorakata~ $ time docker run  --runtime=kata-qemu-virtiofs busybox date
Mon May 18 20:24:14 UTC 2020

real    0m1.705s
user    0m0.037s
sys     0m0.026s
eadams@fedorakata~ $ time docker run  --runtime=kata-qemu-virtiofs busybox date
Mon May 18 20:24:39 UTC 2020

real    0m18.290s
user    0m0.057s
sys     0m0.043s
eadams@fedorakata~ $ time docker run  --runtime=kata-qemu-virtiofs busybox date
Mon May 18 20:25:14 UTC 2020

real    0m33.927s
user    0m0.028s
sys     0m0.029s
eadams@fedorakata~ $ time docker run  --runtime=kata-qemu-virtiofs busybox date
Mon May 18 20:25:36 UTC 2020

real    0m18.598s
user    0m0.027s
sys     0m0.029s
eadams@fedorakata~ $ time docker run  --runtime=kata-qemu-virtiofs busybox date
Mon May 18 20:25:59 UTC 2020

real    0m18.801s
user    0m0.044s
sys     0m0.029s
eadams@fedorakata~ $ time docker run  --runtime=kata-qemu-virtiofs busybox date
Mon May 18 20:26:30 UTC 2020

real    0m29.999s
user    0m0.026s
sys     0m0.030s
eadams@fedorakata~ $ time docker run  --runtime=kata-qemu-virtiofs busybox date
Mon May 18 20:27:05 UTC 2020

real    0m33.278s
user    0m0.035s
sys     0m0.051s
eadams@fedorakata~ $ time docker run  --runtime=kata-qemu-virtiofs busybox date
Mon May 18 20:27:28 UTC 2020

real    0m5.649s
user    0m0.033s
sys     0m0.031s
eadams@fedorakata~ $ time docker run  --runtime=kata-qemu-virtiofs busybox date
Mon May 18 20:28:05 UTC 2020

real    0m34.758s
user    0m0.029s
sys     0m0.027s

Update: I just noticed that if I wait a minute or so between launches then the launch time is much more consistent at around 1.6s.

@eadamsintel 18s does seem an extraordinarily long time :-)
I know you've been running the report generator recently - could you use that with the grabdata.sh -t to get the timing test data for your setup, and grab the graphs out of the pdf (they are also placed in the output folder beside the pdf btw). Then we can see what sort of variance and noise there is across a run of 100.
Traditionally the only time I normally see such delays and noise is when the tests are run on a desktop system where lots of other stuff is going on in the background. What sort of systems are these? Is there much else happening on them - what does top tell you for instance.
/cc @devimc for thoughts around the qemu virtiofs side of things. And then maybe we can pull in some of the virtiofs folks if needed...

the pdf report would be really helpful here, this way we could figure out where is the instability (host or guest?)

Here is the report run on my Fedora system.  The boot times are really high and inconsistent which matches my manual testing above.
metrics_report.pdf

Here is the relevant picture.

Wow, that is terrible :-/ - to confirm then:

yes, it looks like your boot time are fairly uniformly up at ~24s on average, with just a few down in the 10s range. Normally we'd be looking at 1-2s I would say, max.
And the breakdown says the time appears to be in getting to the workload. So, not getting the VM up or into and through the kernel - but between the start of userspace and entering the container workload by the looks of it.

Oh that's a weird variation isn't it; I prefer the 1.705s first result!
Can we get a dmesg from inside the container? We could turn on some of virtiofsd's logigng/debug/syslog if that would help - (-o log_level=debug  --syslog ) but those are themselves expensive.

Sure thing.  I launched another container first, closed it, and then launched this one which took 20+ seconds or so.  Here is the dmesg.
eadams@fedorakata~ $ docker run -it --runtime=kata-qemu-virtiofs busybox
/ # dmesg
[    0.000000] Linux version 5.6.0 (runner@fv-az28) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)) #1 SMP Fri May 8 18:22:12 UTC 2020
[    0.000000] Command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro ro rootfstype=ext4 quiet systemd.show_status=false panic=1 nr_cpus=8 agent.use_vsock=false systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket scsi_mod.scan=none
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[    0.000000] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
[    0.000000] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
[    0.000000] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format.
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007ffdefff] usable
[    0.000000] BIOS-e820: [mem 0x000000007ffdf000-0x000000007fffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.8 present.
[    0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[    0.000000] Hypervisor detected: KVM
[    0.000000] kvm-clock: Using msrs 4b564d01 and 4b564d00
[    0.000000] kvm-clock: cpu 0, msr 21f9001, primary cpu clock
[    0.000000] kvm-clock: using sched offset of 136928558 cycles
[    0.000003] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns:<PHONE_NUMBER>83 ns
[    0.000010] tsc: Detected 2591.972 MHz processor
[    0.000390] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000391] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000393] last_pfn = 0x7ffdf max_arch_pfn = 0x400000000
[    0.000412] MTRR default type: write-back
[    0.000413] MTRR fixed ranges enabled:
[    0.000413]   00000-9FFFF write-back
[    0.000414]   A0000-BFFFF uncachable
[    0.000414]   C0000-FFFFF write-protect
[    0.000415] MTRR variable ranges enabled:
[    0.000416]   0 base<PHONE_NUMBER> mask FF80000000 uncachable
[    0.000416]   1 disabled
[    0.000416]   2 disabled
[    0.000416]   3 disabled
[    0.000416]   4 disabled
[    0.000417]   5 disabled
[    0.000417]   6 disabled
[    0.000417]   7 disabled
[    0.000422] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT
[    0.006622] found SMP MP-table at [mem 0x000f5a40-0x000f5a4f]
[    0.006658] Using GB pages for direct mapping
[    0.006662] BRK [0x02401000, 0x02401fff] PGTABLE
[    0.006663] BRK [0x02402000, 0x02402fff] PGTABLE
[    0.006663] BRK [0x02403000, 0x02403fff] PGTABLE
[    0.006685] BRK [0x02404000, 0x02404fff] PGTABLE
[    0.006751] BRK [0x02405000, 0x02405fff] PGTABLE
[    0.006778] ACPI: Early table checksum verification disabled
[    0.006791] ACPI: RSDP 0x00000000000F5860 000014 (v00 BOCHS )
[    0.006797] ACPI: RSDT 0x000000007FFE1DC2 00003C (v01 BOCHS  BXPCRSDT 00000001 BXPC 00000001)
[    0.006801] ACPI: FACP 0x000000007FFE16A9 000074 (v01 BOCHS  BXPCFACP 00000001 BXPC 00000001)
[    0.006809] ACPI: DSDT 0x000000007FFDF040 002669 (v01 BOCHS  BXPCDSDT 00000001 BXPC 00000001)
[    0.006811] ACPI: FACS 0x000000007FFDF000 000040
[    0.006813] ACPI: APIC 0x000000007FFE171D 0000B0 (v01 BOCHS  BXPCAPIC 00000001 BXPC 00000001)
[    0.006815] ACPI: HPET 0x000000007FFE17CD 000038 (v01 BOCHS  BXPCHPET 00000001 BXPC 00000001)
[    0.006817] ACPI: SRAT 0x000000007FFE1805 000150 (v01 BOCHS  BXPCSRAT 00000001 BXPC 00000001)
[    0.006819] ACPI: SSDT 0x000000007FFE1955 00038D (v01 BOCHS  NVDIMM   00000001 BXPC 00000001)
[    0.006821] ACPI: NFIT 0x000000007FFE1CE2 0000E0 (v01 BOCHS  BXPCNFIT 00000001 BXPC 00000001)
[    0.006830] ACPI: Local APIC address 0xfee00000
[    0.006892] Zone ranges:
[    0.006895]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
[    0.006896]   DMA32    [mem 0x0000000001000000-0x000000007ffdefff]
[    0.006896]   Normal   empty
[    0.006897]   Device   empty
[    0.006897] Movable zone start for each node
[    0.006897] Early memory node ranges
[    0.006898]   node   0: [mem 0x0000000000001000-0x000000000009efff]
[    0.006900]   node   0: [mem 0x0000000000100000-0x000000007ffdefff]
[    0.006915] Zeroed struct page in unavailable ranges: 131 pages
[    0.006916] Initmem setup node 0 [mem 0x0000000000001000-0x000000007ffdefff]
[    0.006916] On node 0 totalpages: 524157
[    0.006919]   DMA zone: 64 pages used for memmap
[    0.006919]   DMA zone: 21 pages reserved
[    0.006920]   DMA zone: 3998 pages, LIFO batch:0
[    0.007058]   DMA32 zone: 8128 pages used for memmap
[    0.007058]   DMA32 zone: 520159 pages, LIFO batch:63
[    0.025035] ACPI: PM-Timer IO Port: 0x608
[    0.025037] ACPI: Local APIC address 0xfee00000
[    0.025045] ACPI: LAPIC_NMI (acpi_id[0xff] dfl dfl lint[0x1])
[    0.025081] IOAPIC[0]: apic_id 0, version 17, address 0xfec00000, GSI 0-23
[    0.025082] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.025084] ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
[    0.025084] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.025087] ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
[    0.025088] ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
[    0.025089] ACPI: IRQ0 used by override.
[    0.025089] ACPI: IRQ5 used by override.
[    0.025090] ACPI: IRQ9 used by override.
[    0.025090] ACPI: IRQ10 used by override.
[    0.025091] ACPI: IRQ11 used by override.
[    0.025092] Using ACPI (MADT) for SMP configuration information
[    0.025094] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.025105] smpboot: Allowing 8 CPUs, 7 hotplug CPUs
[    0.025113] KVM setup pv remote TLB flush
[    0.025121] [mem 0x80000000-0xfeffbfff] available for PCI devices
[    0.025122] Booting paravirtualized kernel on KVM
[    0.025124] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns:<PHONE_NUMBER>211568 ns
[    0.027843] setup_percpu: NR_CPUS:240 nr_cpumask_bits:240 nr_cpu_ids:8 nr_node_ids:1
[    0.028935] percpu: Embedded 42 pages/cpu s140120 r0 d31912 u262144
[    0.028940] pcpu-alloc: s140120 r0 d31912 u262144 alloc=1*2097152
[    0.028941] pcpu-alloc: [0] 0 1 2 3 4 5 6 7
[    0.028957] KVM setup async PF for cpu 0
[    0.028961] kvm-stealtime: cpu 0, msr 7dc17e40
[    0.028964] Built 1 zonelists, mobility grouping on.  Total pages: 515944
[    0.028965] Kernel command line: tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro ro rootfstype=ext4 quiet systemd.show_status=false panic=1 nr_cpus=8 agent.use_vsock=false systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket scsi_mod.scan=none
[    0.030185] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[    0.030690] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.030800] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.034302] Memory: 2038800K/2096628K available (10242K kernel code, 481K rwdata, 1344K rodata, 828K init, 2152K bss, 57828K reserved, 0K cma-reserved)
[    0.034353] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.034371] Kernel/User page tables isolation: enabled
[    0.034479] rcu: Hierarchical RCU implementation.
[    0.034480] rcu:     RCU restricting CPUs from NR_CPUS=240 to nr_cpu_ids=8.
[    0.034480]  All grace periods are expedited (rcu_expedited).
[    0.034482] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.034483] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8
[    0.034492] NR_IRQS: 15616, nr_irqs: 488, preallocated irqs: 16
[    0.034632] rcu:     Offload RCU callbacks from CPUs: (none).
[    0.034688] random: get_random_bytes called from start_kernel+0x292/0x44a with crng_init=0
[    0.034805] Console: colour *CGA 80x25
[    0.034813] ACPI: Core revision 20200110
[    0.034934] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns:<PHONE_NUMBER>7 ns
[    0.035015] APIC: Switch to symmetric I/O mode setup
[    0.035296] x2apic enabled
[    0.035530] Switched APIC routing to physical x2apic.
[    0.035531] KVM setup pv IPIs
[    0.036600] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.036623] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x255c9c8e84c, max_idle_ns:<PHONE_NUMBER>12 ns
[    0.036624] Calibrating delay loop (skipped) preset value.. 5183.94 BogoMIPS (lpj=10367888)
[    0.036625] pid_max: default: 32768 minimum: 301
[    0.036641] LSM: Security Framework initializing
[    0.036668] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
[    0.036685] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
[    0.037008] x86/cpu: User Mode Instruction Prevention (UMIP) activated
[    0.037013] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
[    0.037014] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
[    0.037016] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[    0.037018] Spectre V2 : Mitigation: Full generic retpoline
[    0.037018] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
[    0.037018] Spectre V2 : Enabling Restricted Speculation for firmware calls
[    0.037020] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
[    0.037022] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl and seccomp
[    0.037023] TAA: Mitigation: Clear CPU buffers
[    0.037023] MDS: Mitigation: Clear CPU buffers
[    0.037197] Freeing SMP alternatives memory: 28K
[    0.037422] TSC deadline timer enabled
[    0.037433] smpboot: CPU0: Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz (family: 0x6, model: 0x5e, stepping: 0x3)
[    0.037533] Performance Events: Skylake events, Intel PMU driver.
[    0.037555] ... version:                2
[    0.037555] ... bit width:              48
[    0.037556] ... generic registers:      4
[    0.037556] ... value mask:             0000ffffffffffff
[    0.037556] ... max period:             000000007fffffff
[    0.037557] ... fixed-purpose events:   3
[    0.037557] ... event mask:<PHONE_NUMBER>00000f
[    0.037604] rcu: Hierarchical SRCU implementation.
[    0.037774] smp: Bringing up secondary CPUs ...
[    0.037774] smp: Brought up 1 node, 1 CPU
[    0.037775] smpboot: Max logical packages: 8
[    0.037775] smpboot: Total of 1 processors activated (5183.94 BogoMIPS)
[    0.037926] devtmpfs: initialized
[    0.037957] x86/mm: Memory block size: 128MB
[    0.038217] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns:<PHONE_NUMBER>100000 ns
[    0.038219] futex hash table entries: 2048 (order: 5, 131072 bytes, linear)
[    0.038354] thermal_sys: Registered thermal governor 'step_wise'
[    0.038436] NET: Registered protocol family 16
[    0.038546] cpuidle: using governor menu
[    0.038606] ACPI: bus type PCI registered
[    0.038608] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.038624] PCI: Using configuration type 1 for base access
[    0.039175] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.039324] ACPI: Added _OSI(Module Device)
[    0.039324] ACPI: Added _OSI(Processor Device)
[    0.039325] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.039325] ACPI: Added _OSI(Processor Aggregator Device)
[    0.039326] ACPI: Added _OSI(Linux-Dell-Video)
[    0.039326] ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
[    0.039327] ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)
[    0.040055] ACPI: 2 ACPI AML tables successfully acquired and loaded
[    0.040623] ACPI: Interpreter enabled
[    0.040623] ACPI: (supports S0 S5)
[    0.040623] ACPI: Using IOAPIC for interrupt routing
[    0.040623] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.040623] ACPI: Enabled 4 GPEs in block 00 to 0F
[    0.043794] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.043796] acpi PNP0A03:00: _OSC: OS supports [ASPM ClockPM Segments MSI HPX-Type3]
[    0.043978] acpiphp: Slot [3] registered
[    0.043988] acpiphp: Slot [4] registered
[    0.043997] acpiphp: Slot [5] registered
[    0.044006] acpiphp: Slot [6] registered
[    0.044015] acpiphp: Slot [7] registered
[    0.044024] acpiphp: Slot [8] registered
[    0.044037] acpiphp: Slot [9] registered
[    0.044046] acpiphp: Slot [10] registered
[    0.044055] acpiphp: Slot [11] registered
[    0.044064] acpiphp: Slot [12] registered
[    0.044073] acpiphp: Slot [13] registered
[    0.044082] acpiphp: Slot [14] registered
[    0.044094] acpiphp: Slot [15] registered
[    0.044103] acpiphp: Slot [16] registered
[    0.044112] acpiphp: Slot [17] registered
[    0.044121] acpiphp: Slot [18] registered
[    0.044130] acpiphp: Slot [19] registered
[    0.044139] acpiphp: Slot [20] registered
[    0.044148] acpiphp: Slot [21] registered
[    0.044160] acpiphp: Slot [22] registered
[    0.044169] acpiphp: Slot [23] registered
[    0.044181] acpiphp: Slot [24] registered
[    0.044190] acpiphp: Slot [25] registered
[    0.044199] acpiphp: Slot [26] registered
[    0.044208] acpiphp: Slot [27] registered
[    0.044219] acpiphp: Slot [28] registered
[    0.044229] acpiphp: Slot [29] registered
[    0.044238] acpiphp: Slot [30] registered
[    0.044246] acpiphp: Slot [31] registered
[    0.044253] PCI host bridge to bus 0000:00
[    0.044254] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
[    0.044255] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
[    0.044256] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[    0.044256] pci_bus 0000:00: root bus resource [mem 0x80000000-0xfebfffff window]
[    0.044257] pci_bus 0000:00: root bus resource [mem 0x740000000-0x7bfffffff window]
[    0.044258] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.044278] pci 0000:00:00.0: [8086:1237] type 00 class 0x060000
[    0.044530] pci 0000:00:01.0: [8086:7000] type 00 class 0x060100
[    0.044851] pci 0000:00:01.1: [8086:7010] type 00 class 0x010180
[    0.047268] pci 0000:00:01.1: reg 0x20: [io  0xd0e0-0xd0ef]
[    0.048317] pci 0000:00:01.1: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
[    0.048318] pci 0000:00:01.1: legacy IDE quirk: reg 0x14: [io  0x03f6]
[    0.048319] pci 0000:00:01.1: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
[    0.048319] pci 0000:00:01.1: legacy IDE quirk: reg 0x1c: [io  0x0376]
[    0.048429] pci 0000:00:01.3: [8086:7113] type 00 class 0x068000
[    0.048681] pci 0000:00:01.3: quirk: [io  0x0600-0x063f] claimed by PIIX4 ACPI
[    0.048686] pci 0000:00:01.3: quirk: [io  0x0700-0x070f] claimed by PIIX4 SMB
[    0.048831] pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
[    0.050626] pci 0000:00:02.0: reg 0x10: [mem 0xfea00000-0xfea000ff 64bit]
[    0.052050] pci 0000:00:03.0: [1af4:1003] type 00 class 0x078000
[    0.053176] pci 0000:00:03.0: reg 0x10: [io  0xd000-0xd03f]
[    0.054236] pci 0000:00:03.0: reg 0x14: [mem 0xfea01000-0xfea01fff]
[    0.058238] pci 0000:00:03.0: reg 0x20: [mem 0xc0200000-0xc0203fff 64bit pref]
[    0.060988] pci 0000:00:04.0: [1af4:1004] type 00 class 0x010000
[    0.061977] pci 0000:00:04.0: reg 0x10: [io  0xd040-0xd07f]
[    0.062912] pci 0000:00:04.0: reg 0x14: [mem 0xfea02000-0xfea02fff]
[    0.065673] pci 0000:00:04.0: reg 0x20: [mem 0xc0204000-0xc0207fff 64bit pref]
[    0.066960] pci 0000:00:05.0: [1af4:1005] type 00 class 0x00ff00
[    0.067671] pci 0000:00:05.0: reg 0x10: [io  0xd0c0-0xd0df]
[    0.071673] pci 0000:00:05.0: reg 0x20: [mem 0xc0208000-0xc020bfff 64bit pref]
[    0.072651] pci 0000:00:06.0: [1af4:105a] type 00 class 0x018000
[    0.080343] pci 0000:00:06.0: reg 0x14: [mem 0xfea03000-0xfea03fff]
[    0.084281] pci 0000:00:06.0: reg 0x18: [mem 0x80000000-0xbfffffff 64bit pref]
[    0.087942] pci 0000:00:06.0: reg 0x20: [mem 0xc020c000-0xc020ffff 64bit pref]
[    0.092972] pci 0000:00:07.0: [1af4:1000] type 00 class 0x020000
[    0.094035] pci 0000:00:07.0: reg 0x10: [io  0xd080-0xd0bf]
[    0.095152] pci 0000:00:07.0: reg 0x14: [mem 0xfea04000-0xfea04fff]
[    0.097583] pci 0000:00:07.0: reg 0x20: [mem 0xc0210000-0xc0213fff 64bit pref]
[    0.099215] pci_bus 0000:01: extended config space not accessible
[    0.099449] acpiphp: Slot [0] registered
[    0.099464] acpiphp: Slot [1] registered
[    0.099475] acpiphp: Slot [2] registered
[    0.099486] acpiphp: Slot [3-2] registered
[    0.099501] acpiphp: Slot [4-2] registered
[    0.099513] acpiphp: Slot [5-2] registered
[    0.099525] acpiphp: Slot [6-2] registered
[    0.099536] acpiphp: Slot [7-2] registered
[    0.099548] acpiphp: Slot [8-2] registered
[    0.099559] acpiphp: Slot [9-2] registered
[    0.099572] acpiphp: Slot [10-2] registered
[    0.099586] acpiphp: Slot [11-2] registered
[    0.099599] acpiphp: Slot [12-2] registered
[    0.099610] acpiphp: Slot [13-2] registered
[    0.099622] acpiphp: Slot [14-2] registered
[    0.099633] acpiphp: Slot [15-2] registered
[    0.099646] acpiphp: Slot [16-2] registered
[    0.099660] acpiphp: Slot [17-2] registered
[    0.099672] acpiphp: Slot [18-2] registered
[    0.099687] acpiphp: Slot [19-2] registered
[    0.099699] acpiphp: Slot [20-2] registered
[    0.099711] acpiphp: Slot [21-2] registered
[    0.099723] acpiphp: Slot [22-2] registered
[    0.099738] acpiphp: Slot [23-2] registered
[    0.099751] acpiphp: Slot [24-2] registered
[    0.099762] acpiphp: Slot [25-2] registered
[    0.099774] acpiphp: Slot [26-2] registered
[    0.099785] acpiphp: Slot [27-2] registered
[    0.099796] acpiphp: Slot [28-2] registered
[    0.099807] acpiphp: Slot [29-2] registered
[    0.099822] acpiphp: Slot [30-2] registered
[    0.099834] acpiphp: Slot [31-2] registered
[    0.099970] pci 0000:00:02.0: PCI bridge to [bus 01]
[    0.099980] pci 0000:00:02.0:   bridge window [io  0xc000-0xcfff]
[    0.099988] pci 0000:00:02.0:   bridge window [mem 0xfe800000-0xfe9fffff]
[    0.100005] pci 0000:00:02.0:   bridge window [mem 0xc0000000-0xc01fffff 64bit pref]
[    0.100628] pci_bus 0000:00: on NUMA node 0
[    0.100902] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
[    0.100964] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[    0.101019] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[    0.101072] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
[    0.101104] ACPI: PCI Interrupt Link [LNKS] (IRQs *9)
[    0.101766] vgaarb: loaded
[    0.101922] SCSI subsystem initialized
[    0.101960] PCI: Using ACPI for IRQ routing
[    0.101963] PCI: pci_cache_line_size set to 64 bytes
[    0.102635] e820: reserve RAM buffer [mem 0x0009fc00-0x0009ffff]
[    0.102638] e820: reserve RAM buffer [mem 0x7ffdf000-0x7fffffff]
[    0.102887] clocksource: Switched to clocksource kvm-clock
[    0.103065] pnp: PnP ACPI init
[    0.103107] pnp 00:00: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.103121] pnp 00:01: Plug and Play ACPI device, IDs PNP0303 (active)
[    0.103130] pnp 00:02: Plug and Play ACPI device, IDs PNP0f13 (active)
[    0.103134] pnp 00:03: [dma 2]
[    0.103138] pnp 00:03: Plug and Play ACPI device, IDs PNP0700 (active)
[    0.103527] pnp: PnP ACPI: found 4 devices
[    0.106456] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns:<PHONE_NUMBER> ns
[    0.106461] pci 0000:00:02.0: PCI bridge to [bus 01]
[    0.106467] pci 0000:00:02.0:   bridge window [io  0xc000-0xcfff]
[    0.107016] pci 0000:00:02.0:   bridge window [mem 0xfe800000-0xfe9fffff]
[    0.107361] pci 0000:00:02.0:   bridge window [mem 0xc0000000-0xc01fffff 64bit pref]
[    0.108061] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
[    0.108062] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
[    0.108063] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
[    0.108064] pci_bus 0000:00: resource 7 [mem 0x80000000-0xfebfffff window]
[    0.108064] pci_bus 0000:00: resource 8 [mem 0x740000000-0x7bfffffff window]
[    0.108065] pci_bus 0000:01: resource 0 [io  0xc000-0xcfff]
[    0.108066] pci_bus 0000:01: resource 1 [mem 0xfe800000-0xfe9fffff]
[    0.108066] pci_bus 0000:01: resource 2 [mem 0xc0000000-0xc01fffff 64bit pref]
[    0.108135] NET: Registered protocol family 2
[    0.108286] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear)
[    0.108299] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear)
[    0.108370] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear)
[    0.108497] TCP: Hash tables configured (established 16384 bind 16384)
[    0.108589] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear)
[    0.108605] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear)
[    0.108662] NET: Registered protocol family 1
[    0.108681] pci 0000:00:01.0: PIIX3: Enabling Passive Release
[    0.108689] pci 0000:00:00.0: Limiting direct PCI/PCI transfers
[    0.108695] pci 0000:00:01.0: Activating ISA DMA hang workarounds
[    0.108739] PCI: CLS 0 bytes, default 64
[    0.108909] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x255c9c8e84c, max_idle_ns:<PHONE_NUMBER>12 ns
[    0.109114] workingset: timestamp_bits=46 max_order=19 bucket_order=0
[    0.110360] fuse: init (API version 7.31)
[    0.110424] SGI XFS with security attributes, no debug enabled
[    0.110685] 9p: Installing v9fs 9p2000 file system support
[    0.110742] NET: Registered protocol family 38
[    0.110747] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
[    0.110933] shpchp 0000:00:02.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0.S10_)
[    0.110936] shpchp 0000:00:02.0: Requesting control of SHPC hotplug via OSHP (\_SB_.PCI0)
[    0.110938] shpchp 0000:00:02.0: Cannot get control of SHPC hotplug
[    0.110942] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    0.110986] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
[    0.110987] ACPI: Power Button [PWRF]
[    0.125705] PCI Interrupt Link [LNKC] enabled at IRQ 11
[    0.139191] PCI Interrupt Link [LNKD] enabled at IRQ 10
[    0.153116] PCI Interrupt Link [LNKA] enabled at IRQ 10
[    0.166364] PCI Interrupt Link [LNKB] enabled at IRQ 11
[    0.167723] virtiofs virtio3: Cache len: 0x40000000 @ 0x80000000
[    0.176230] memmap_init_zone_device initialised 262144 pages in 8ms
[    0.192698] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.207432] printk: console [hvc0] enabled
[    0.208703] brd: module loaded
[    0.209518] loop: module loaded
[    0.210792] memmap_init_zone_device initialised 32768 pages in 0ms
[    0.210891]  pmem0: p1
[    0.210927] pmem0: detected capacity change from 0 to 132120576
[    0.211711] scsi host0: Virtio SCSI HBA
[    0.214094] intel_pstate: CPU model not supported
[    0.214442] xt_time: kernel timezone is -0000
[    0.214453] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
[    0.214460] random: fast init done
[    0.214522] IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
[    0.214627] IPVS: ipvs loaded.
[    0.214629] IPVS: [rr] scheduler registered.
[    0.214629] IPVS: [wrr] scheduler registered.
[    0.214630] IPVS: [lc] scheduler registered.
[    0.214630] IPVS: [wlc] scheduler registered.
[    0.214630] IPVS: [fo] scheduler registered.
[    0.214631] IPVS: [ovf] scheduler registered.
[    0.214633] IPVS: [lblc] scheduler registered.
[    0.214634] IPVS: [lblcr] scheduler registered.
[    0.214635] IPVS: [dh] scheduler registered.
[    0.214635] IPVS: [sh] scheduler registered.
[    0.214636] IPVS: [sed] scheduler registered.
[    0.214636] IPVS: [nq] scheduler registered.
[    0.214638] IPVS: ftp: loaded support on port[0] = 21
[    0.214638] IPVS: [sip] pe registered.
[    0.214794] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
[    0.214824] Initializing XFRM netlink socket
[    0.214908] NET: Registered protocol family 10
[    0.215051] random: crng init done
[    0.215238] Segment Routing with IPv6
[    0.215263] NET: Registered protocol family 17
[    0.215299] 9pnet: Installing 9P2000 support
[    0.215375] NET: Registered protocol family 40
[    0.215470] IPI shorthand broadcast: enabled
[    0.215472] sched_clock: Marking stable (210643512, 1986078)->(220773235, -8143645)
[    0.215799] EXT4-fs (pmem0p1): DAX enabled. Warning: EXPERIMENTAL, use at your own risk
[    0.215830] EXT4-fs (pmem0p1): INFO: recovery required on readonly filesystem
[    0.215831] EXT4-fs (pmem0p1): write access will be enabled during recovery
[    0.216340] EXT4-fs (pmem0p1): recovery complete
[    0.216353] EXT4-fs (pmem0p1): mounted filesystem with ordered data mode. Opts: dax,data=ordered,errors=remount-ro
[    0.216364] VFS: Mounted root (ext4 filesystem) readonly on device 259:1.
[    0.216381] devtmpfs: mounted
[    0.216566] Freeing unused kernel image (initmem) memory: 828K
[    0.220738] Write protecting the kernel read-only data: 14336k
[    0.221480] Freeing unused kernel image (text/rodata gap) memory: 2044K
[    0.221751] Freeing unused kernel image (rodata/data gap) memory: 704K
[    0.221759] Run /sbin/init as init process
[    0.221759]   with arguments:
[    0.221760]     /sbin/init
[    0.221760]   with environment:
[    0.221760]     HOME=/
[    0.221760]     TERM=linux
[    0.229886] systemd[1]: systemd 245 running in system mode. (+PAM +AUDIT -SELINUX +IMA -APPARMOR -SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 -IDN -PCRE2 default-hierarchy=hybrid)
[    0.229904] systemd[1]: Detected virtualization kvm.
[    0.229913] systemd[1]: Detected architecture x86-64.
[    0.230402] systemd[1]: No hostname configured.
[    0.230406] systemd[1]: Set hostname to <localhost>.
[    0.230442] systemd[1]: Initializing machine ID from random generator.
[    0.230461] systemd[1]: Installed transient /etc/machine-id file.
[    0.254027] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[    0.254169] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[    0.254181] systemd[1]: Reached target Local Encrypted Volumes.
[    0.254188] systemd[1]: Reached target Paths.
[    0.254193] systemd[1]: Reached target Slices.
[    0.254271] systemd[1]: Listening on Process Core Dump Socket.
[    0.254303] systemd[1]: Listening on initctl Compatibility Named Pipe.
[    0.254309] systemd[1]: Reached target Sockets.
[    0.254378] systemd[1]: Condition check resulted in Kernel Trace File System being skipped.
[    0.254395] systemd[1]: Condition check resulted in Create list of static device nodes for the current kernel being skipped.
[    0.254412] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped.
[    0.254504] systemd[1]: Condition check resulted in Load Kernel Modules being skipped.
[    0.255214] systemd[1]: Starting Remount Root and Kernel File Systems...
[    0.255662] systemd[1]: Starting Repartition Root Disk...
[    0.256181] systemd[1]: Starting Apply Kernel Variables...
[    0.257914] systemd[39]: systemd-sysctl.service: Failed to connect stdout to the journal socket, ignoring: No such file or directory
[    0.258092] systemd[38]: systemd-repart.service: Failed to connect stdout to the journal socket, ignoring: No such file or directory
[    0.263898] systemd[37]: systemd-remount-fs.service: Failed to connect stdout to the journal socket, ignoring: No such file or directory
[    0.268428] systemd-sysctl[39]: Couldn't write '16' to 'kernel/sysrq', ignoring: No such file or directory
[    0.268734] systemd-sysctl[39]: Not setting net/ipv4/conf/all/rp_filter (explicit setting exists).
[    0.268737] systemd-sysctl[39]: Not setting net/ipv4/conf/default/rp_filter (explicit setting exists).
[    0.268769] systemd-sysctl[39]: Not setting net/ipv4/conf/all/accept_source_route (explicit setting exists).
[    0.268771] systemd-sysctl[39]: Not setting net/ipv4/conf/default/accept_source_route (explicit setting exists).
[    0.268800] systemd-sysctl[39]: Not setting net/ipv4/conf/all/promote_secondaries (explicit setting exists).
[    0.268801] systemd-sysctl[39]: Not setting net/ipv4/conf/default/promote_secondaries (explicit setting exists).
[    0.269327] systemd[1]: Finished Apply Kernel Variables.
[    0.269964] systemd[1]: Finished Repartition Root Disk.
[    0.270697] systemd[1]: Finished Remount Root and Kernel File Systems.
[    0.270750] systemd[1]: Reached target Local File Systems (Pre).
[    0.270763] systemd[1]: Condition check resulted in Default Swap File (/var/swapfile) being skipped.
[    0.270768] systemd[1]: Reached target Swap.
[    0.271268] systemd[1]: Mounting Temporary Directory (/tmp)...
[    0.271289] systemd[1]: Condition check resulted in Flush Journal to Persistent Storage being skipped.
[    0.271884] systemd[40]: tmp.mount: Failed to connect stdout to the journal socket, ignoring: No such file or directory
[    0.273766] systemd[1]: Mounted Temporary Directory (/tmp).
[    0.273807] systemd[1]: Reached target Local File Systems.
[    0.273822] systemd[1]: Condition check resulted in Store a System Token in an EFI Variable being skipped.
[    0.273845] systemd[1]: Condition check resulted in Commit a transient machine-id on disk being skipped.
[    0.273854] systemd[1]: Reached target System Initialization.
[    0.273875] systemd[1]: Started Daily Cleanup of Temporary Directories.
[    0.273881] systemd[1]: Reached target Basic System.
[    0.273910] systemd[1]: Reached target Timers.
[    0.273964] systemd[1]: Condition check resulted in NTP client/server being skipped.
[    0.274417] systemd[1]: Started Kata Containers Agent.
[    0.274450] systemd[1]: Reached target Kata Containers Agent Target.
[    0.274479] systemd[1]: Startup finished in 225ms (kernel) + 47ms (userspace) = 272ms.
[    0.301338] fuse_dax_mem_range_init(): dax mapped 262144 pages. nr_ranges=512
[    0.311548] pci 0000:00:02.0: PCI bridge to [bus 01]
[    0.311557] pci 0000:00:02.0:   bridge window [io  0xc000-0xcfff]
[    0.312780] pci 0000:00:02.0:   bridge window [mem 0xfe800000-0xfe9fffff]
[    0.313513] pci 0000:00:02.0:   bridge window [mem 0xc0000000-0xc01fffff 64bit pref]
[    0.318203] kmem.limit_in_bytes is deprecated and will be removed. Please report your usecase to<EMAIL_ADDRESS>if you depend on this functionality.
[    0.334764] systemd[1]: run-libcontainer-e3ac3b553f37bb4575684be6e044ef1a648f63ccd42c42e1e8a29da55ff53460-e3ac3b553f37bb4575684be6e044ef1a648f63ccd42c42e1e8a29da55ff53460-runc.vdV74h.mount: Succeeded.
[    0.417539] process 'e3ac3b553f37bb4575684be6e044ef1a648f63ccd42c42e1e8a29da55ff53460/rootfs/bin/sh' started with executable stack
[    1.220839] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Well that's a nice peachy 1.22s - can't moan too much.
Since you're running systemd, how about running a    systemd-analyze blame    in the guest?

or - see if we can get the agent logs - afaict the time is between entering userland (the end of that dmesg above pretty much), and entering the container. Sadly, those are the only sequence points I could trivially extract in this timing test code we use... so then we'd have to look in the agent logs maybe for hints as to if the agent took a looong time to do its thing etc.

I've not used this tool before.  I tried a clearlinux container after I got the slow boot time, and below is what it showed.  I got a similar error with a 'centos/tools' container.  I am having issues running the boot metric test on Clear Linux as after either run 3, run 4, or in one case run 10 I keep getting a time/launch_times.sh: line 64: printf: 070696912: invalid octal number
root@7b3319e725bd/ # systemd-analyze
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to create bus connection: Host is down

Just for fun I opened up 4 terminal windows to my Fedora machine and loaded each with the time docker run  --runtime=kata-qemu-virtiofs busybox date and then as fast as I could executed each of those nearly simultaneously and probably took me just over a second to launch all four.
Window 1 - 1.712s
Window 2 - 39.5s
Window 3 - 1m22.71s
Window 4 - 52.368s

or maybe runtime log as well - we probably want all the kata logs, and then to use some of @jodh-intel 'magic' scripts to combine them into a timeline - let's see .... yep, 'use the log parser Luke'... :yoda:

The 'octal number' is very likely not the issue, or not directly the issue (it could be related). That is most likely due to something generating missing or unexpected data that the script and json generation then fails to parse/print into the results files. To diagnose that one you can run the script with a bash -x, capture that output, and then we can hopefully narrow down on what the corrupt data is and where it came from. Probably best to do that on a different Issue if you want to chase it on an issue.

I tried out the log parser but ran into issues. Maybe @jodh-intel  can tell me what I did wrong?  To get the logs I launched two containers back to back. The second container had a 27s launch time.
time docker run  --runtime=kata-qemu-virtiofs busybox date

This was done on my Fedora 31 system.  The ksm-throttler.log and vc-throttler.log were empty so I did not attach them.
$ /home/eadams/go/bin/kata-log-parser proxy.log runtime.log shim.log vc-throttler.log ksm-throttler.log
ERROR: kata-log-parser: failed to parse file "/home/eadams/logs/proxy.log", line 607: logfmt syntax error at pos 194 on line 607: invalid quoted value (keyvals: [{key:time value:2020-05-19T15:23:53.073955287-07:00} {key:level value:info}])

runtime.log
shim.log
proxy.log

FYI @eadamsintel - I re-created the hex issue on a Clear machine - the bash -x errant part looks like:
++ docker run --cap-add SYSLOG --rm --runtime=kata-qemu-virtiofs ubuntu sh -c 'date -u +%-s:%-N '
++ date -u +%-s:%-N
+ end_time=1589969739:078597421
++ sn_to_ns<PHONE_NUMBER>:465839665
++ printf %d%09d<PHONE_NUMBER> 465839665
+ start_time=1589969736465839665
++ sn_to_ns<PHONE_NUMBER>:078597421
++ printf %d%09d<PHONE_NUMBER> 078597421
../time/launch_times.sh: line 64: printf: 078597421: invalid octal number
+ end_time=1589969739000000007

I'll debug and report/fix... my suspicion is that leading '0' on the '078597421' is tripping it up. This is ringing bells...

and then ironically, if we look at the code fragment where that date command is executed, we see the comments:
# The date command format we use to ensure we capture the ns timings
# Note the no-0-padding - 0 padding the results breaks bc in some cases
DATECMD="date -u +%-s:%-N"

So, yes, we've run into this before. I'll see if I can work out why the original fix is apparently not working here...

It's feeling like an issue with date - unclear if that is Clear specific or not.
The '-' before the 'N' should prevent 0 leading padding. It seems to not be working in this case.
If I run date -u +%-s:%-N a number of times (you have a 1-in-10 chance of failing....), then on Clear, with date version 8.32 I get something like:
$ date -u +%-s:%-N
1589970417:600907074
$ date -u +%-s:%-N
1589970418:033015649
$ date -u +%-s:%-N
1589970418:464477298

Oops - 2nd entry has leading 0 padding on the ns part.
On Fedora with date version 8.31 I get:
$ date -u +%-s:%-N
1589970541:223687637
$ date -u +%-s:%-N
1589970541:623620365
$ date -u +%-s:%-N
1589970542:21584109
$ date -u +%-s:%-N
1589970542:456179206

where we see that 3rd run has less digits in the ns part - because the leading 0 was dropped....
Now, to figure out if this is a date issue or a Clear issue...
@eadamsintel - if you are desperate, we could write a tiny bit of shell hack to trim the leading 0's off I suspect as a workaround - shout if you need that.

Hmm, my best guess is maybe this change in the gnu coreutils lib that handles the formatted printing, and does mention both %N and - prefixes. It's a change from December 2019....
On the off chance, @eggert, I don't suppose this rings any immediate bells does it (that the command $ date -u +%-s:%-N on date version 8.32 seems to be returning leading padding 0's on the %-N part...), but not with date version 8.31, such as:
$ date -u +%-s:%-N
1589970418:033015649

@eadamsintel - OK, I have a small patch/workaround for you for the octal issue to get your running hopefully. The patch looks like:
diff --git a/metrics/time/launch_times.sh b/metrics/time/launch_times.sh
index 0ae550d..e85125e 100755
--- a/metrics/time/launch_times.sh
+++ b/metrics/time/launch_times.sh
@@ -61,7 +61,9 @@ check_entropy_level() {
 sn_to_ns() {
        # use shell magic to strip out the 's' and 'ns' fields and print
        # them as a 0-padded ns string...
-       printf "%d%09d" ${1%:*} ${1##*:}
+       ns=${1##*:}
+       ns=$( echo ${ns} | sed 's/^0*//' )
+       printf "%d%09d" ${1%:*} ${ns}
 }

 # convert 'nanoseconds' (since epoch) into a 'float' seconds

which basically changes the function in the launch_times.sh to:

# convert a 'seconds:nanoseconds' string into nanoseconds
sn_to_ns() {
        # use shell magic to strip out the 's' and 'ns' fields and print
        # them as a 0-padded ns string...
        ns=${1##*:}
        ns=$( echo ${ns} | sed 's/^0*//' )
        printf "%d%09d" ${1%:*} ${ns}
}

That was fun, as I was going to use a bash ##0* prefix strip fix, but found sometimes we get more than one 0 prefix!, and the bash globbing I could not be bothered battling to handle that, so went with a simple(ish) sed...
I ran that on my system for both straight kata-qemu and kata-qemu-virtiofs - results look like:

Now, just be aware that I suspect there is a kernel config setup thing going on with the virtiofs one, whereby it does not seem to capture the details about kernel time details. iirc, we parse the dmesg time stamps to get that - so I'm guessing either the time stamps or the whole dmesg are not enabled in that kernel config??. We get results like:
                        {
                "total": {
                        "Result": 1.573,
                        "Units" : "s"
                },
                "to-workload": {
                        "Result": 1.319,
                        "Units" : "s"
                },
                "in-kernel": {
                        "Result": 0.0,
                        "Units" : "s"
                },
                "to-kernel": {
                        "Result": 0.0,
                        "Units" : "s"
                },
                "to-quit": {
                        "Result": 0.254,
                        "Units" : "s"
                }
        },

I'm thinking the to-workload, total and quit times should be correct though still.
Back to the graph then... two obvious things are:

virtiofs is much noisier
virtiofs is slower (err, like twice as slow - 1.9s vs 0.88s).
the quit time for virtiofs looks much bigger as well (which is why the 'total' time has a bigger diff than the 'to workload' times). Most people are really concerned about 'to workload' afaik.

What I don't see are the 30s long times and hangs you see @eadamsintel . I ran on a reasonably meaty i7 NUC, for reference.

With that patch I was able to run the boot time test on  one of my Clear Linux systems.  It is a SkyLake SkullCanyon NUC with a core i7-6770HQ CPU. I am using Clear Linux 33080.
metrics_report.pdf

Here are the results from a Server with Clear Linux 32810 with a "Intel(R) Xeon(R) Gold 6238 CPU @ 2.10GHz"  I used kata-deploy to install kata and its artifacts. The results don't seem as bad. I gave it a shorter title so it wouldn't mess up the picture graph.
metrics_report.pdf

Still though if I launch containers by hand right after one finishes the launch time is 3x to 6x greater than if I let the system settle. This seems to match the lifecycle phase time.  The boot to workload is still relatively quick but the entire startup/shutdown is rather long.
eadams@otc-tme-wf-02~ $ time docker run --runtime=kata-qemu-virtiofs busybox date
Wed May 20 21:43:36 UTC 2020

real    0m1.168s
user    0m0.027s
sys     0m0.034s
eadams@otc-tme-wf-02~ $ time docker run --runtime=kata-qemu-virtiofs busybox date
^[[A
^C
real    0m3.537s
user    0m0.032s
sys     0m0.021s

eadams@otc-tme-wf-02~ $ time docker run --runtime=kata-qemu-virtiofs busybox date
Wed May 20 21:43:44 UTC 2020

real    0m1.174s
user    0m0.036s
sys     0m0.017s
eadams@otc-tme-wf-02~ $ time docker run --runtime=kata-qemu-virtiofs busybox date
Wed May 20 21:43:52 UTC 2020

real    0m5.742s
user    0m0.027s
sys     0m0.025s
eadams@otc-tme-wf-02~ $ time docker run --runtime=kata-qemu-virtiofs busybox date
Wed May 20 21:43:58 UTC 2020

real    0m5.994s
user    0m0.024s
sys     0m0.032s
eadams@otc-tme-wf-02~ $ time docker run --runtime=kata-qemu-virtiofs busybox date
Wed May 20 21:44:05 UTC 2020

real    0m6.203s
user    0m0.033s
sys     0m0.021s
eadams@otc-tme-wf-02~ $ time docker run --runtime=kata-qemu-virtiofs busybox date
Wed May 20 21:44:09 UTC 2020

real    0m3.460s
user    0m0.027s
sys     0m0.027s
eadams@otc-tme-wf-02~ $ time docker run --runtime=kata-qemu-virtiofs busybox date
Wed May 20 21:44:13 UTC 2020

real    0m3.950s
user    0m0.029s
sys     0m0.026s
eadams@otc-tme-wf-02~ $ time docker run --runtime=kata-qemu-virtiofs busybox date
Wed May 20 21:44:17 UTC 2020

real    0m3.498s
user    0m0.029s
sys     0m0.024s
eadams@otc-tme-wf-02~ $ #wait 15 seconds
eadams@otc-tme-wf-02~ $ time docker run --runtime=kata-qemu-virtiofs busybox date
Wed May 20 21:44:32 UTC 2020

real    0m1.157s
user    0m0.033s
sys     0m0.027s

Hmm, my best guess is maybe this change in the gnu coreutils lib that handles the formatted printing, and does mention both %N and - prefixes. It's a change from December 2019....

Upstream says that the change in behavior was intended:
https://lists.gnu.org/archive/html/bug-gnulib/2020-05/msg00208.html
... and updated coreutils documentation to reflect the change:
https://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=6d0107a3

@kdudka Thanks! Heh, on the surface that feels broken in my head (- do not pad still pads....). np, I'll PR my sed patch as that will work with both old and new style.

@eadamsintel It looks like the shutdown (delete) time is killing your 'total time' there. There are other niggles, as per my previous list though. The noise/variance is still pretty high to my eye for instance.
I think we'll have to get that log parser working to help diagnose where the time went.

I collected the logs on one of my Clear Linux systems that is having 25+ second launch times on subsequent container launches.  Unfortunately, I ran into issues trying the kata-log-parser   I wonder if this is same date issue you were having above? Perhaps @jodh-intel can chime in.
$ /home/kata/go/bin/kata-log-parser  proxy.log runtime.log shim.log vc-throttler.log ksm-throttler.log
ERROR: kata-log-parser: failed to parse file "/home/kata/temp/proxy.log", line 604: logfmt syntax error at pos 194 on line 604: invalid quoted value (keyvals: [{key:time value:2020-05-21T13:43:05.164580014-07:00} {key:level value:info}])

I ran the launch twice, and the second busybox launch was 28 seconds.  Here are the logs. The ksm-throttler.log and vc-throttler.log were both empty.
runtime.log
shim.log
proxy.log

@eadamsintel - looks like the log parser is choking on lines containing escaped backslashes. I've raised https://github.com/kata-containers/tests/issues/2570 but meantime, simply remove the double-backslash in entries like this:
/usr/lib/systemd/system/system-systemd\\x2dcryptsetup.slice

@jodh-intel I may have to wait for the patch. Besides that entry there were a ton of other entries like the following. Would your patch fix those as well?
...req=\"interface:<device:\\\"eth0\\\" name:\\\"eth0\\\" IPAddresses:<address:\\\"<IP_ADDRESS>\\\" mask:\\\"16\\\" > mtu:1500...


dart2js: should give compile time error on name clashes between type vars and members

Per latest spec (end of section 7, Classes)

fixed via the CFE


Reference to non-existing Q058860 Knowledge Base article

The following files reference non-existing Q058860 Knowledge Base article:
https://github.com/MicrosoftDocs/cpp-docs/blob/8fa8fdf0fbb4f57950f1e8f4f9b81b4d39ec7d7a/docs/data/oledb/cdynamicparameteraccessor-class.md
https://github.com/MicrosoftDocs/cpp-docs/blob/8fa8fdf0fbb4f57950f1e8f4f9b81b4d39ec7d7a/docs/data/oledb/using-dynamic-accessors.md

It's conceivable that the KB article number was a typo, but I could find no reference to it by title anywhere, either. However, it looks like the target may have been intended to be a description of one of the OLEDB samples that shipped in Visual Studio long ago. These are now on a GitHub repo, so I pointed the sample links there, instead. PR #170 should fix things when it goes live. Hope this helps.


⚠ Jenkins Plugins Artifactory has degraded performance

In cc90f8d, Jenkins Plugins Artifactory (https://get.jenkins.io/plugins/artifactory/) experienced degraded performance:

HTTP code: 200
Response time: 1298 ms

Resolved: Jenkins Plugins Artifactory performance has improved in 53413dd after 47 minutes.


Fix the logic grabbing the link from table in AllJobPage

This issue is related to #6419 .
Now AllJobPage doesn't have a "kill link" but I think fix the issue mentioned in #6419 just in case to avoid accidents in the future.
So, it's minor issue for now and I don't file this issue in JIRA.

Merged build triggered.

Merged build started.

Test build #33578 has started for   PR 6432 at commit cd1a503.

Test build #33578 has finished for   PR 6432 at commit cd1a503.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/33578/
Test FAILed.

retest this please.

Merged build triggered.

Merged build started.

Test build #33591 has started for   PR 6432 at commit cd1a503.

Test build #33591 has finished for   PR 6432 at commit cd1a503.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/33591/
Test PASSed.

Merged build finished. Test PASSed.

LGTM merging into master 1.4. By the way I'll add SPARK-7864 to the title when I merge this. It would be good to add it next time.

Oh, thanks for pointing it out.


Go binaries on release page?

Can be vmango go binaries included in assets on release page (https://github.com/subuk/vmango/releases) ?
Thanks

You can download binaries as deb/rpm packages, why do you want to have them on releases page?

And it's a bit complicated binary, because it requires libvirt shared library to be present on the system. You can't just download and run it.

I want to start experimenting with docker image..
see: https://github.com/kubevirt/libvirt
vmango would be a great as docker image

You can build it with rpm packages:
FROM centos:7
RUN yum install -y yum-plugin-copr && yum copr -y enable subuk/vmango && yum install -y vmango && yum clean all
CMD /usr/bin/vmango --config /etc/vmango.conf

Use yum copr -y enable subuk/vmango-devel for the latest master

I created draft image on dockerhub, see https://hub.docker.com/r/subuk/vmango


PowerBi quickfilter placement

It is left side, but its supposed to be right side

@MagnusGjosund Fix this while im away

hint: do it inline devtools with flex, and justifyContent


Text field valid state icon color

When a lx-text-field is focused the corresponding icon is highlighted in blue, similarly when the lx-text-field has an error state the icon is highlighted in red.
However when a lx-text-field has a valid state the icon is not highlighted in green.

Thanks for reporting the issue. We're going to work on it very soon!

Cheers @matmkian, much appreciated. Keep up the good work!

Hello, the issue is now fixed : https://github.com/lumapps/lumX/commit/4aa91dd31276193ba34aee2843a545e9253190e8 .
Thanks for reporting.


Current status of gleam/otp/actor

Playing more with Gleam I had to play with actors and how they will become typed, my biggest gripe with dialyzer and Erlang/Elixir. I assume the typing is tied to the Channel that's used to pass messages around, right?
If so: I read through the actor source and didn't find a way to get a channel to the actor after starting it with a spec as is done in the tests. Is this just rough state because of active development or did I miss a piece?
Also regarding this concept I was wondering how typing would fit into things like dynamic process registries.

Hi @timbuchwaldt ! I'm still in the process of upgrading actor after the move to channels, so it's not quite usable yet. The main problem (as you've worked out) is that the actor's channel is created but never shared, so it's not possible to send any messages to it.
I'm working on the compiler at the moment but I'll fix this soon (or you could have a go? 😁 )
The main thing I'm wondering is what should the start function return. Perhaps Result(tuple(Pid, state), FailureReason). This would break compatibility with Erlang's supervisors but we could include a function that converts it to {ok, Pid, State} | {error, Reason} which they do accept.

I can sure give it a try, yes! :)


[doc] Configuration::*_handler() doc doesn't specify what the usize argument to the callback is for

I guess it's a thread id, but it should be spelled out.

Ah, we have that specified in the docs on the StartHandler and ExitHandler type aliases, but after some refactoring these are no longer public.  Care to send pull request clarifying this?
To be a little more precise, it's the index of the thread in our own pool, not the OS thread id.

What can one do in the handler with that index?

You can use it for whatever bookkeeping you like, especially to associate the start and exit of a given thread.


Sheet in Legacy Rules

Switching to legacy rules leaves the sheet like this

+1

Any console errors? Module free replication?

Same problem here. Created new world for testing if something else made a hickup but it's true for me this way too.
No modules activated.
Console error which generates:

What browsers are you using?

Maybe I've found the problem. The variables are bugging in the legacy mode if the foundry language isn't in english. I redid all the standards steps:

I created a new world
I started without any modules
I changed to Legacy Rules

And the error persisted, but switching back to the default Foundry language made it go back to normal.

Specifically seems to a problem if you set it to a different language, use the legacy rules, and don't load any system translations.

Yes the language change fixed it. thx :)


Delete command should print out rules that were deleted on the backend

Description
Delete command should print out rules that were deleted on the backend

By the way, here is the reason we removed the preview (which is a better UX). It would require backend changes.


Added build and dependency instructions to README.

Signed-off-by: Roman Grigoriadi<EMAIL_ADDRESS>

Fixes #1298


Board Labels Limit crash

Hi Greg,
First of all, many thanks for your great work : it allows me to manage our entire team workflow on Trello, it is a life saviour for us.
I've a encountered some issues (our boards are quite large and the processing is heavy for now), and found workaround for most of them. But I'm quite stuck with the Labels on Board, with v2.4 : The default limit is 50. But, if I try to increase the board cards collection limit using the Limit extension method, it's returning a null collection, in any case.
        var lstBoardLabels = refBoard.Labels.Filter(100);

        // CRASH : lstBoardLabels is null.
        int nCount = lstBoardLabels.Count();

Any idea ?
Regards,
Roland TOMCZAK

Thanks for reporting this.  I'll try to work on this soon.

@rolsct here is the extension method that adds a filter to the label collection on a board.  As you can see, it can't return null.
Please run your test again and verify that your lstBoardLabels variable is null.  It could be that something inside Manatee.Trello is throwing the exception instead.  If you can, please post the stacktrace.

Sorry, I made a typo when writing my snippet :
It was not
var lstBoardLabels = refBoard.Labels.Filter(100);
but of course
var lstBoardLabels = refBoard.Labels.Limit(100);
I retried it again just right now, on a small board, same  crash from my side (Limit returns null).
Thanks,
Roland

That code is here.  Again, it returns a new collection.

Dear Gregs, yes I was still encountering the issue (and, looking as the code as you did, I didn't understand how it could happened :( ). So finally we called directly the REST API to get the full board data. Doing so, we bypass the limit, and we gained in perf to initialize our internal model. As a suggestion, it could be a good option for Manatee.Trello to read the entire content of a Board using the Board GET service, to initialize it and minimize the calls count.
Regards,
Roland

I've been able to reproduce this in v3.  It's probably an issue with all collections.  I'll publish an update soon.

Trello doesn't list the limit parameter in their docs.  I remember seeing it in the old docs (pre-Atlassian).  I'll ask about it.

Thank you Greg !

Trello reports that the limit is still working.  I'll have to research why I'm not seeing it.

So it works in some cases, but not in others.  For example /1/boards/{id}/cards?limit=1 only returns a single card, but /1/boards/{id}/lists?limit=1 ignores the parameter and returns all of the lists.

@rolsct please watch for v3.0.7.  Should be up soon.


Alignment Issue with Sign Up/Sign In Page Close Button

I've noticed a minor alignment problem on the sign-up and sign-in pages. The close button does not appear to be properly aligned. This could affect the overall user experience.
Screenshot:

I'd like to take on the task of addressing this alignment issue. Please assign it to me, and I'll work on resolving it.

It is already fixed !! Thanks @LakshanRukantha

I think it is not still responsive.
https://github.com/c4coderandcreator/Flavour-Fusion/assets/64830641/8c2b7b93-d6d6-4fa3-9ebe-856b4acbb472

Hey @LakshanRukantha  actually it is a bug, if the browser visibility is set to 100% the cross is at exact position i.e Top-Right. But if it is reduced to 80% or less it acts weird !! Good find , I will say !! Please fix it , also make it responsive and try to create PR with
UI-Improvement branch not with the main branch !!

@c4coderandcreator Got it. I'll take care of fixing it.


Pod IP was configured to Node's eth0 when Pods were created on a Node in parallel

Describe the bug
It happened to @alex-vmw's cluster that some short-life Pods didn't get their IPs and caused connectivity issue.
It was observed that the missing Pod IPs were configured to Node's eth0 somehow, and there were a number of error logs like:
E0707 01:05:30.751839       1 server.go:422] Failed to configure interfaces for container 596bd949477355f1199a5dfe06cb33b8c8cf219421b68c8606e0a09a68b786c0: failed to configure IP address for container 596bd949477355f1199a5dfe06cb33b8c8cf219421b68c8606e0a09a68b786c0: error switching to ns /host/proc/32618/ns/net: Error switching to ns /host/proc/32618/ns/net: invalid argument

E0707 00:55:34.973015       1 pod_configuration.go:242] Failed to advertise IP address for container efb3f9340201bc330e1f009b21d5801ca8fcddcf54e9ecc9f9db6cc32f13dfe9: /host/proc/3808/ns/net is not a valid network namespace: failed to Statfs "/host/proc/3808/ns/net": no such file or directory

E0707 01:45:46.128598       1 server.go:422] Failed to configure interfaces for container bd391dfba8a1e7423213b3088f20c2bcbfb42c36b11d7a6ec3fea353aab77606: failed to create veth devices for container bd391dfba8a1e7423213b3088f20c2bcbfb42c36b11d7a6ec3fea353aab77606: error switching to ns /proc/1/task/3667/ns/net: Error switching to ns /proc/1/task/3667/ns/net: bad file descriptor

And there were FD leaks after Pods created and deleted.
antrea-ag 32229 root   23u     sock                0,8      0t0 212567577 protocol: PACKET
antrea-ag 32229 root   27u     sock                0,8      0t0 212637082 protocol: PACKET
antrea-ag 32229 root   32u     sock                0,8      0t0 212616399 protocol: PACKET
antrea-ag 32229 root   35u     sock                0,8      0t0 212611716 protocol: PACKET
antrea-ag 32229 root   48u     sock                0,8      0t0 212637275 protocol: PACKET

The issue didn't happen when v0.5.1 was used.
To Reproduce
Running a loop that schedules a number of Pods to one Node in parallel, the IP misconfiguration may happen after 30~50 rounds. The FD leak can happen immediately.
for i in `seq 1 100`; do
  echo "round $i"
  kubectl apply -f pods.yaml
  sleep 15
  kubectl delete -f pods.yaml
  sleep 15
done

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: test
  name: test-1
spec:
  nodeName: <NODE NAME>
  containers:
  - command:
    - sleep
    - "1"
    image: busybox
    name: container
  dnsPolicy: ClusterFirst
  priority: 0
  restartPolicy: Never
---
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: test
  name: test-2
spec:
  nodeName: <NODE NAME>
  containers:
  - command:
    - sleep
    - "1"
    image: busybox
    name: container
  dnsPolicy: ClusterFirst
  priority: 0
  restartPolicy: Never
---
# Create 20 such Pods
...

Expected
None of above errors should not happen.
Versions:
Please provide the following information:

Antrea version (Docker image tag). 0.7.2

Root cause
GratuitousArpOverIface in "github.com/j-keck/arping" is not thread-safe as it uses global variables to keep socket and Sockaddr:
https://github.com/j-keck/arping/blob/1a9d8d0d4f43e32ed4df967f1b3fd67cee09f38c/arping_linux.go#L9-L10
When batch processing CNI ADD requests, race condition could happen and lead to FD leak and mismatch as the goroutine that sends gratuitous ARPs may close and release others' FDs by accident.
It didn't happen in v0.5.1 because sending gratuitous ARPs actually failed for most times with that version:

Prior to 0.7.0, it had a great chance that the container netns had been closed when it tried to send gratuitous ARPs because it's executed in a goroutine:
https://github.com/vmware-tanzu/antrea/blob/a5cf8233c0209df3cc24ac6f65d465376f82cf22/pkg/agent/cniserver/pod_configuration.go#L142-L143
In 0.7.0, it was wrong in another manner, see explanation and fix in https://github.com/vmware-tanzu/antrea/pull/796.

I wanted to thank @alex-vmw for all the help he provided in troubleshooting this issue and the time he spent on this.


Allow additional publish to a docker.io repository

(...) we will be discontinuing Autobuilds on the free tier starting from June 18, 2021.
https://www.docker.com/blog/changes-to-docker-hub-autobuilds/

[ ] push to https://hub.docker.com/r/macbre/push-to-ghcr
[ ] create access tokens via https://hub.docker.com/settings/security for pushes to docker.io


Bug with scheduler

Laravel Version: 5.6.15
PHP Version: 7.1.3
Database Driver & Version: MySQL 5.7

Description:
I set my config/app.php timezone to Europe/London and have set up the scheduler execute tasks at a specific time every day. However it seems that the scheduler didn't use the app's config timezone and defaulted to something else. I had to add the timezone method to each task to get it working - seems like a bug to me as the scheduler should default to the app config?

Scheduled events will be interrupted in UTC. So if you're timezone is Europe/London then your events will run an hour later than expected.
I personally prefer working in UTC and converting to different timezones (especially if you have an app used across the world)
This is probably your solution - https://laravel.com/docs/5.6/scheduling#timezones

@arjasco Yeah I realised that but shouldn't the scheduler be using the app's timezone by default? Right now it ignores the app/config set timezone.

@decadence, nope. Didn’t have any cache because I tried it on a new installation of the app as well.

Just tested for myself. app.timezone is being respected when changed, however @decadence makes very good point. If your config is cached it will need clearing and cached again via php artisan config:cache if an environment var / config has changed.

I think I figured it out. I’m the app/config file I had an accidental space
in it making it “ Europe/London” and I think that was invalid and therefore
became UTC.
Maybe make it strip whitespace or show an error but I assume that’s the
issue?
On 2 Apr 2018, at 15:43, Victor Isadov<EMAIL_ADDRESS>wrote:
@shivampaw https://github.com/shivampaw so make
Route::get("timezone", function(){   return config("app.timezone");});
and check if this returns correct value.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/laravel/framework/issues/23768#issuecomment-377944685,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALS1o5b0sHIhoTUlzEnMK9F_nddcq357ks5tkjkWgaJpZM4TCoyU
.


[Help] Can't get list item to animate using TransitionMotion

I am not quite familiar with this library yet so apologies if I've missed something obvious.  I've been desperately trying to get this to work for some time now without luck.
I need to animate list items on enter and leave in Staggered manner. I've got a Container component which renders  Item children. The Container reads from state (I'm using redux if that helps). The item data is stored in state. I update the state in componentWillReceiveProps. Now, I want to animate the list items when state has changed.
From the README, I figured TransitionMotion would be the best fit as it pertains to mounting an unmounting (The Container is being mounted once).
getStyles() {
    return this.state.items.map(item => ({
      key: item.id, style: {opacity: spring(1)}
    }))
  }
render() {
<TransitionMotion
   styles={this.getStyles()}>
          {
            interpolatedStyles => {
             return

                {
                  interpolatedStyles.map(config =>

                      Item

                  )
                }

            }
          }
</TransitionMotion>
}

I guess the issue is, I'm updating the state while the TransitionMotion is specifically for mounting/unmounting. If so, how do I achieve this? I've tried setting the getDefaultStyles and willEnter without any difference

I tried implementing a simple example with StaggeredMotion where todo-items have to be animated in the todo-list. Seems like the animation is not triggered on setState. Is there a way to trigger animation on state change?

maybe I'm misunderstanding your issue, but i may have a similar one. It seems like the set passed into TransitionMotion styles prop has to change in order to trigger an animation. I would have thought setState would be sufficient, since getStyles() is invoked on render, provided this.state.items is actually changing.

In this thread I explain how it works and gave an example. Basicaly you are not setting an starting point with willEnter.


Datetimes don't parse correctly

The implementation of FromSql for Timespec uses strptime with the following formats:
const SQLITE_DATETIME_FMT: &str = "%Y-%m-%dT%H:%M:%S.%fZ";
const SQLITE_DATETIME_FMT_LEGACY: &str = "%Y-%m-%d %H:%M:%S:%f %Z";
SQLite's docs (https://sqlite.org/lang_datefunc.html) specify either of those as correct for inserting datetimes into SQLite, but its output formats don't match, they are:

date(...)

strftime('%Y-%m-%d', ...)

time(...)

strftime('%H:%M:%S', ...)

datetime(...)

strftime('%Y-%m-%d %H:%M:%S', ...)

julianday(...)

strftime('%J', ...)

so when I try to convert the output of "SELECT DATETIME('now')" into a Timespec, I get an error because the output doesn't match format.

The original was ok.
I will check why this is not the case anymore.

https://github.com/jgallagher/rusqlite/pull/305

Fixed by 0.16.0 release.


ec_deployment: Test against legacy plans

Description
At this point, no testing has been performed against legacy deployments with legacy plans, some testing should be performed to ensure it works interchangeably with legacy and current plans.

This is a little bit large, when importing legacy that haven't been updated in a long time and have the default instance configuration ID, there's a few issues:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # ec_deployment.example_minimal must be replaced
-/+ resource "ec_deployment" "example_minimal" {
      + apm_secret_token       = (sensitive value)
        deployment_template_id = "default"
      + elasticsearch_password = (sensitive value)
      + elasticsearch_username = (known after apply)
      ~ id                     = "XXXXY" -> (known after apply)
      ~ name                   = "ear" -> "my_example_deployment"
      + region                 = "us-east-1" # forces replacement
      + version                = "7.9.2"

      ~ elasticsearch {
          ~ cloud_id       = "ear:dXMtZWFzdC0xLmF3cy5mb3VuZC5pbyQxOGZjOTZjNDkxYjNkNWUxMGUxNDc0NjM5MjdhNTM0OSRiOTgwZjllZjRhZjg0ZDc4ODUxZGRmNzlmNDM5YWQ4ZA==" -> (known after apply)
          ~ http_endpoint  = "http://XXXXY.us-east-1.aws.found.io:9200" -> (known after apply)
          ~ https_endpoint = "https://XXXXY.us-east-1.aws.found.io:9243" -> (known after apply)
          ~ ref_id         = "elasticsearch" -> "main-elasticsearch"
          ~ region         = "us-east-1" -> (known after apply)
          ~ resource_id    = "XXXXY" -> (known after apply)
          ~ version        = "2.4.5" -> (known after apply)

          + topology {
              + instance_configuration_id = (known after apply)
              + memory_per_node           = "2g"
              + node_count_per_zone       = (known after apply)
              + node_type_data            = (known after apply)
              + node_type_ingest          = (known after apply)
              + node_type_master          = (known after apply)
              + node_type_ml              = (known after apply)
              + zone_count                = 2
            }
        }

      ~ kibana {
          ~ elasticsearch_cluster_ref_id = "elasticsearch" -> "main-elasticsearch"
          ~ http_endpoint                = "http://YYYYX.us-east-1.aws.found.io:9200" -> (known after apply)
          ~ https_endpoint               = "https://YYYYX.us-east-1.aws.found.io:9243" -> (known after apply)
          ~ ref_id                       = "kibana" -> "main-kibana"
          ~ region                       = "us-east-1" -> (known after apply)
          ~ resource_id                  = "YYYYX" -> (known after apply)
          ~ version                      = "4.6.6" -> (known after apply)

          + topology {
              + instance_configuration_id = (known after apply)
              + memory_per_node           = (known after apply)
              + node_count_per_zone       = (known after apply)
              + zone_count                = (known after apply)

              + config {
                  + user_settings_json          = (known after apply)
                  + user_settings_override_json = (known after apply)
                  + user_settings_override_yaml = (known after apply)
                  + user_settings_yaml          = (known after apply)
                }
            }
        }

      - timeouts {}
    }

Plan: 1 to add, 0 to change, 1 to destroy.

This has been documented we can leave this open in case users complain


Workspace selection and more

This is a rather big pull request due to some refactoring and cleanup, I suggest reading it commit-by-commit.
The main feature is standardized workspace selection for all commands (#51), but another bug (#48) got fixed as a side-effect.

Closes #48
Closes #51


Uncaught exception in enqueueOperation

The calls to mconn.enqueueOperation in SpyMemcachedIntegration can throw IllegalStateException when the queue is full:
java.lang.IllegalStateException: Timed out waiting to add Cmd: 1 Opaque: 229348 Key: XXX Cas: 0 Exp:<PHONE_NUMBER> Flags: 0 Data Length: 0(max wait=10000ms)
        at net.spy.memcached.protocol.TCPMemcachedNodeImpl.addOp(TCPMemcachedNodeImpl.java:362)
        at net.spy.memcached.MemcachedConnection.addOperation(MemcachedConnection.java:1278)
        at net.spy.memcached.MemcachedConnection.addOperation(MemcachedConnection.java:1240)
        at net.spy.memcached.MemcachedConnection.enqueueOperation(MemcachedConnection.java:1196)
        at shade.memcached.internals.SpyMemcachedIntegration.realAsyncSet(SpyMemcachedIntegration.scala:235)
        at shade.memcached.MemcachedImpl.set(MemcachedImpl.scala:60)

This ends up breaking the implied contract of always returning a Future when calling set, etc.

Oh nice find. Maybe we can wrap those queue inserts in a try {} catch {}, maybe abstracted in another method, and on failure, fulfil the Promise with the exception.

My "random guy on the internet" two cents would be push the call to mconn.enqueueOperation down into prepareFuture where this error case can be handled in a central place. It looks like every call to prepareFuture(key, op) is preceded by a call to mcomm.enqueueOperation(key, op, ...).


[Txt2Img] CPU support + TorchScript and Intel® Extension for PyTorch* optimizations

Summary
Proposing following changes that enable CPU support for Stable Diffusion and add TorchScript and Intel® Extension for PyTorch*(IPEX) optimizations to improve the performance on Intel® CPU hardware.
The optimizations provide about 3x the performance comparing with currently implemented eager execution for Intel Xeon platform 3rd Generation(IceLake). These optimizations also enable BF-16 for Intel Xeon 4th Generation(Sapphire Rapids), which optimizes the throughput by another 3x.
Changes
The code mainly implements TorchScript+IPEX optimizations in scripts/txt2img.py, but also adds support for CPU in samplers and provide bfloat16 support. The provided configs disable gradient checkpointing and add support for bfloat16 if needed.

How much does this improve performance?

On AWS instance c6i.16xlarge (Intel(R) Xeon(R) Platinum 8375C) the performance looks as follows:

Batch size
Model name
Optimizations
Avg latency [in secs]
Boost in comparison with clean pytorch only CPU support

1
SD2-v (768px)
clean, no ipex, only CPU support added
385.007
N/A

1
SD2-v (768px)
ipex + torchscript with ipex envs
110.356
349%

4
SD2-v (768px)
clean, no ipex, only CPU support added
1496.812
N/A

4
SD2-v (768px)
ipex + torchscript with ipex envs
460.320
325%

1
SD2-base (512px)
clean, no ipex, only CPU support added
112.521
N/A

1
SD2-base (512px)
ipex + torchscript with ipex envs
37.998
296%

4
SD2-base (512px)
clean, no ipex, only CPU support added
412.438
N/A

4
SD2-base (512px)
ipex + torchscript with ipex envs
145.346
284%

BF-16 reduces the latency by another 3x with Intel 4th Gen Xeon Platform.

It might be useful to allow "xpu" as a possible device option so that Intel's new discrete GPU line works also. I think currently this would raise a ValueError. The discrete GPUs would like benefit from the Intel Extension optimizations given their XMX cores.

It might be useful to allow "xpu" as a possible device option so that Intel's new discrete GPU line works also. I think currently this would raise a ValueError. The discrete GPUs would like benefit from the Intel Extension optimizations given their XMX cores.

We haven't tested this pipeline on XPU yet, but it's a great suggestion. We'll consider testing it in the future.

Installing requirements for CodeFormer
Installing requirements for Web UI
Installing Deforum requirement: av
Installing Deforum requirement: pims
Installing Deforum requirement: imageio_ffmpeg

Launching Web UI with arguments: --share --xformers --enable-insecure-extension-access --gradio-queue
2023-02-11 20:33:38.960007: I tensorflow/core/platform/cpu_feature_guard.cc:193] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations:  AVX2 AVX512F FMA
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
2023-02-11 20:33:41.763634: W tensorflow/compiler/xla/stream_executor/platform/default/dso_loader.cc:64] Could not load dynamic library 'libnvinfer.so.7'; dlerror: libnvinfer.so.7: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/local/lib/python3.8/dist-packages/cv2/../../lib64:/usr/lib64-nvidia
2023-02-11 20:33:41.764023: W tensorflow/compiler/xla/stream_executor/platform/default/dso_loader.cc:64] Could not load dynamic library 'libnvinfer_plugin.so.7'; dlerror: libnvinfer_plugin.so.7: cannot open shared object file: No such file or directory; LD_LIBRARY_PATH: /usr/local/lib/python3.8/dist-packages/cv2/../../lib64:/usr/lib64-nvidia
2023-02-11 20:33:41.764049: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:38] TF-TRT Warning: Cannot dlopen some TensorRT libraries. If you would like to use Nvidia GPU with TensorRT, please make sure the missing libraries mentioned above are installed properly.
[AddNet] Updating model hashes...
0it [00:00, ?it/s]
[AddNet] Updating model hashes...
0it [00:00, ?it/s]


Problems changing the FrameRate of Picam v3 using picamera2()

Hello everyone,
I'm trying to capture images to do real-time object counting. Everything works except for a small thing, the ROI is illuminated by a lamp with a small refresh rate so when the camera takes a shot there is all that dark noise from the lamp. I'm trying to reduce the refresh rate of the camera so that i can take care of that problem but i can't seem to do it.
This is a sample of the code, please have in mind im trying to work it out so it may have some unnecessary lines:
from picamera2 import Picamera2
from libcamera import controls
import time
import os
Cam = Picamera2()
os.system("v4l2-ctl --set-ctrl wide_dynamic_range=1    -d /dev/v4l-subdev0")
Cam.still_configuration.size=(640, 480)
#camera_config = Cam.create_still_configuration({"size": (640, 480)})
Cam.configure()
Cam.set_controls({"FrameRate": 15})
Cam.set_controls({"AfMode": controls.AfModeEnum.Continuous})
Cam.start(show_preview = True)
size = Cam.capture_metadata()['ScalerCrop'][2:]
full_res = Cam.camera_properties['PixelArraySize']
size = [int(s * 1.5) for s in size]
offset = [(r - s) // 2 for r, s in zip(full_res, size)]
Cam.set_controls({"ScalerCrop": offset + size})
input('Enter para tirar fotos')
Cam.start_and_capture_files("Foto{0:03}.jpg", initial_delay = 3, capture_mode = "still", num_files = 20, delay = 2)
os.system("v4l2-ctl --set-ctrl wide_dynamic_range=0 -d /dev/v4l-subdev0")
Anyone with a solution for this? Thanks in advance

Thanks for the quick response,
I added a  input() line to check if the preview was indeed running at 15 and it is. Unfortunatly, i cant test the lighting right now but while we're at it, i want to save the image with a smaller resolution and the only way i got it don was by using Cam.still_configuration.size=(640, 480)
now even if i use it with the code you provided, it doesn't work anymore.
Thank you again for your help.

Hi, if you're still running my example, try changing
capture_config = cam.create_still_configuration(controls=capture_controls)

to
capture_main = {'size': (640, 480)}
capture_raw = {'size': (4608, 2592)}
capture_config = cam.create_still_configuration(capture_main, raw=capture_raw, controls=capture_controls)

(And if you want VGA resolution probably change (640, 360) to (640, 480) everywhere!!) This is still using the full sensor resolution (4608, 2592) for the capture so will give the absolute best quality, but for such a small output resolution you might find that the preview mode (2304, 1296) is plenty.
I forget to mention that I'd removed the v4l2-ctl --set-ctrl ... thing. I'd leave that off for now as it somewhat confuses things by changing the available sensor modes. I'd try to get the basic script working and then one can always experiment.

Amazing! I can now test which resolutions will work best for my implementation. I'll try to update on the dark noise issue, don't close the issue just yet. Thank you @davidplowman !

Hello @davidplowman,
It works! The dark noise is no longer there. One last thing, can i use the example in zoom.py to apply in this implementation?

Great! Sure, those examples are all there for folks to use. If it doesn't work in any way, please feel free to file a new issue. Remember that a (really!) small test case that I can run myself is always helpful!

Hello again!
I've been having problems with flickering and while searching the picam2 manual i found a control named 'AeFlickerPeriod'. I figure it is what I'm looking for but it does not work... I simply write somthing like
cam.set_controls({'AeFlickerPeriod': 10000})
and gives the output:
Traceback (most recent call last):
File "/home/Carlos/Fischer/821.X/Testes/TiraPic.py", line 20, in
cam.set_controls({'AeFlickerPeriod': 10000})
File "/usr/lib/python3/dist-packages/picamera2/picamera2.py", line 1093, in set_controls
self.controls.set_controls(controls)
File "/usr/lib/python3/dist-packages/picamera2/controls.py", line 58, in set_controls
self.setattr(k, v)
File "/usr/lib/python3/dist-packages/picamera2/controls.py", line 33, in setattr
raise RuntimeError(f"Control {name} is not advertised by libcamera")
RuntimeError: Control AeFlickerPeriod is not advertised by libcamera
Should i open a new issue?

It certainly should be available, and it seems OK for other folks here in the office. Could you confirm that all your software is up to date? Are you building anything for yourself? Thanks.

what software? If you mean the picamera2 library i certainlly did not update... I'm just trying to take some pictures and they get all this noise that i thought i handled earlier with reducing the frame rate...
Pls excuse my lack of knowledge on this matter

The normal procedure would be to do sudo apt update and sudo apt upgrade from time to time so that you pick up the latest version of libcamera, and a compatible version of Picamera2. The AeFlickerPeriod control was added, I think, many months ago.

That was the first thing i tried...
I don'tknow if i have libcamera correclty installed, should i start there?

sudo apt update and sudo apt upgrade would update everything, and you'd be guaranteed to have up to date camera software. What does apt list python3-picamera2 report currently?
(Usual warnings about doing a full system update... if there's anything that you absolutely cannot afford to lose, then back it up somewhere else first!)

Can you double-check that? The results I get all start with "python3-picamera2", not "python3-picamera". What version of the OS are you using (cat /etc/os-release) are you using?

Sorry I'm a noob, this is the output
python3-picamera2/oldstable,oldstable,now 0.3.12-2 all [installed]
and the os is:
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian

OK, a little bit of digging here suggests that the last version of libcamera that's available with Bullseye did not have those flicker controls (Bullseye has become the "legacy OS" since the release of Bookworm).
Are you able to switch over to a Bookworm image?

Yes, it is recommended to do a clean installation rather than try to upgrade the entire OS in place. I don't believe there are any issues using OpenCV with Picamera2, it works on Bookworm like it always has - I'm sure you're familiar with the examples folder here.

Hello again!
I switched to a bookworm image and tried to my script with
cam.set_controls({'AeFlickerPeriod': 10000})
cam.set_controls({'AeFlickerMode': libcamera.controls.AeFlickerModeEnum.Manual})
and nothing solved, no results with 'AeFlickerPeriod': 8333 either
tried to enable anti-flickering automatically with
cam.set_controls({'AeFlickerMode': libcamera.controls.AeFlickerModeEnum.Auto})
and it doesnt work as well, saying in the output
[0:08:46.194088246] [2272] ERROR IPARPI ipa_base.cpp:872 Flicker mode 2 is not supported
Is there something i can do except turning off the lights?

Yes, there's no auto-detection supported currently. However, your first attempt should work. Try it again and see what
cam.capture_metadata()['ExposureTime']

reports.

It reports 681 if i dont configre it. However i tried changing it so small values using cam.set_controls({'ExposureTime': 200}) to reduce flickering that way and it doesn't work too...

The trouble is that for flicker cancellation to work, you have to have to be using an exposure time that is an integer multiple of the lighting period. So it can't help if the exposure time is less than 10ms.
If that's reporting 681, then that's 681us which is really low. Is the scene really that bright? There's no way flicker avoidance can help you here. I also find that modern lighting often causes much worse flicker than old incandescent bulbs (and is not always 100/120Hz either).

I'm afraid i can't change the lights, is there something i can do?
Thanks for all the help!

Is it important that the exposure time is really short? If not (and this is a serious suggestion!) you could buy an ND filter to push up the exposure times.

It's not that i need small exposure times, i just want to eliminate the flickering :). I was trying to use exposure time to try and match the refresh rate of the lamps. Thank you for that insight!
I'll try and see if i can get info on those lamps.

The thing is that every pixel in the image "samples" the lighting for the exposure time. If all pixels were sampled at the same moment, then the entire image could be bright (the LEDs are "on"), or black (the LEDs are "off"). But because these are rolling shutter sensors, each pixel samples the light at a slightly later moment than the previous one, which gives you the banding effect.
LEDs are worse than incandescent bulbs because they go more quickly to "completely on" and more quickly to "completely off". The incandescent bulb takes a moment to heat up or cool down as the voltage changes, so there's some thermal inertia (there's probably a technical name for it) there.
The brightness as such doesn't change the flicker, but the exposure time does, because that determines how long you sample the light. If you can capture exactly one "lighting period", then every pixel gets the same amount of light. If you capture 1.5 lighting periods, you will still get flicker, but it will be less than, say, 0.5 lighting periods. Does this all make sense?
So lower power LEDs would help, doing effectively the same thing as putting an ND filter in front of the camera. But it only helps by causing longer exposures.

I'm getting close!!
I think i've clearly matched the frequency of the lights but there is a very slow black band that passes
through the whole image... have you heard of it?

That's exactly the kind of thing that lighting flicker causes. There's a period for which your light emits, well, no light, so the part of the image being exposed during that time ends up black. But because your frame period is not synced to the lighting, it ends up in a slightly different place in the image next time round. It ought to be possible to get the bands to be stationary if you can sync exactly, but you probably can't remove it completely without longer exposure times.


Rework validataclass defaults

Currently, default values in validataclass fields are implemented without using the field default mechanism of usual dataclasses.
The primary reason for this is an annoying inconvenience in Python's dataclasses: You must define all fields that don't have default values first, then all fields that have default values. Otherwise, the __init__ method cannot be generated automatically, since it uses positional arguments (and you can't have required positional arguments after optional ones).
Instead, it's the DataclassValidator's task to fill an input dictionary with defined default values before creating an instance of the dataclass.
This solution replaces the inconvenience of Python's dataclasses with a new (smaller, but still annoying) inconvenience, though: You cannot use the dataclass without the DataclassValidator that easily anymore, e.g. to create an instance manually, you need to specify all (even optional) fields explicitly. A workaround is the create_with_defaults() class method in the ValidataclassMixin, but it's not really a nice solution imho.
Since Python 3.10, dataclasses have a better solution though: The kw_only flag. When using this flag, the order of optional/required fields doesn't matter anymore (at least I think I have tested that...?).
It would be nice to use this flag instead of our own defaults implementation. Problem: Backwards compatibility! /o/
Let's check if we can find a solution that uses this flag with Python 3.10+ without breaking compatibility with older Python versions... Welp.

Implemented in #65.


binary for linux x86_64 does not work

From the release page for v1.0.1, I downloaded slogen_1.0.0_Linux_x86_64.tar.gz (strange that the version number is different!).  And I attempted to run it:
$ ./slogen --help
./slogen: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./slogen)
./slogen: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./slogen)
./slogen: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./slogen)
./slogen: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.35' not found (required by ./slogen)
./slogen: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./slogen)

I'm not sure what the problem is here, but the previous release works fine on my system (HP Elitebook G5 running Ubuntu 18.04.6
Here's the release from https://github.com/OpenSLO/slogen/releases/tag/v1.0-beta :
$ slogen --help

Generates terraform files from openslo compatible yaml configs.
Generated terraform files can be used to configure SLO monitors, scheduled views & dashboards in sumo.
One or more config or directory containing configs can be given as arg. Doesn't supports regex/wildcards as input.

Usage:
  slogen [paths to yaml config]... [flags]
  slogen [command]

Examples:
slogen service/search.yaml
slogen ~/team-a/slo/ ~/team-b/slo ~/core/slo/login.yaml
slogen ~/team-a/slo/ -o team-a/tf

Available Commands:
  completion  Generate the autocompletion script for the specified shell
  destroy     destroy the content generated from the slogen command, equivalent to 'terraform destroy'
  docs        generate markdown documents of this tool in the specified path
  help        Help about any command
  list        utility command to get additional info about your sumo resources e.g.
  new         create a sample config from given profile
  validate    A brief description of your command

Flags:
  -o, --out string                output directory where to create the terraform files (default "tf")
  -d, --dashboardFolder string    root dashboard folder where to organise the dashboards per service (default "slogen-tf-dashboards")
  -m, --monitorFolder string      root monitor folder where to organise the monitors per service (default "slogen-tf-monitors")
  -i, --ignoreErrors              whether to continue validation even after encountering errors
  -p, --plan                      show plan output after generating the terraform config
  -a, --apply                     apply the generated terraform config as well
  -c, --clean                     clean the old tf files for which openslo config were not found in the path args
      --asModule                  whether to generate the terraform config as a module
      --useViewHash               whether to use descriptive or hashed name for the scheduled views, hashed names ensure data for old view is not used when the query for it changes
      --onlyNative                whether to generate only the native slo resources
      --sloFolder string          root slo folder where to organise native slos by service (default "slogen")
      --sloMonitorFolder string   root monitor folder where to organise native slo monitors by service (default "slogen")
  -h, --help                      help for slogen

Use "slogen [command] --help" for more information about a command.

And here's my machine info:
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.6 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.6 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

$ uname -a
Linux SunilChop2019-Lunix 4.15.0-194-generic #205-Ubuntu SMP Fri Sep 16 19:49:27 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

hey @dayer4b thnx for reporting this.
looks like the graphviz library needs glibc version >= 2.29. graphviz is used to generate the dependency graph b/w SLO, alert rules and policies. it was added in v1.0.1.
Let me see if the glibc requirement can be embedded in the binary itself for compatibility with older linux systems. Give me a day or two to fix this.


256K Items mssing their models in 1.1.1-beta.1 for MC: 1.18.2

Using your latest Beta (1.1.1-beta.1) with MC 1.18.2, Fabric 0.14.9 Loader, Fabric 0.59.0
The 256K items, Cell Component, Storage Cell, Fluid Storage Cell and portable cells for same are missing their models.  REI also shows the checker image for the devices.


White Container Appears at the Bottom of the Screen on Flutter Master - google_maps_flutter 2.2.6

Issue Description:
After updating to google_maps_flutter version 2.2.6 and running the application on Flutter Master, a white container unexpectedly appears at the bottom of the screen when using the Google Maps widget. This container covers a portion of the map and disrupts the intended user interface.
Reproduction Steps:
To replicate the issue, follow these steps:
Update google_maps_flutter dependency to version 2.2.6 in the pubspec.yaml file.
Ensure you are running the latest Flutter Master branch.
Build and run the application on a device or emulator.
Expected Behavior:
The Google Maps widget should be displayed without any additional white containers at the bottom of the screen. The map should cover the entire visible area, and the user interface elements should not be obscured.
Actual Behavior:
Upon running the application, a white container appears at the bottom of the screen, covering a portion of the map. This container disrupts the user interface and reduces the visibility and usability of the map widget.

Hi @Alecia1997
In order to address the issue properly, please provide a completed and minimal reproducible code sample that doesn’t include 3rd party plugins or complex production code so that we may verify this. Also, please provide the output of flutter doctor -v as well.
Thank you!


[C] Basic libpq-based driver

The driver supports basic queries (int32 only) and toggling autocommit. It does not yet support bulk ingestion or prepared statements.
It hasn't been optimized for speed and the approach taken here will not be fast (it uses the per-row getters). In future PRs, we should set up some benchmarks and then see if DuckDB's approach makes more sense (use COPY). DuckDB also does multithreading (that might be hard for us). We may want to implement #61 first since then we will know whether it is safe to use COPY or not.

Rebased/updated. This now tries to use the COPY command, taking advantage of the changes in #69.
Things that need to happen next:

[ ] Build a type mapping table on startup
[ ] Handle null values, more types
[ ] Work out some of the error handling details that were left as TODOs (and probably do some refactoring)
[ ] Handle bulk ingestion
[ ] Handle prepared statements
[ ] Add tests for queries that don't return result sets
[ ] Start adding benchmarks to help guide the rest of the design

I'm going to punt on most of the other tasks for now (see #81) so I can get this packaged in #57 before continuing to implement things.