text:
[Usage]: How to start vLLM on a particular GPU?

Your current environment
Collecting environment information...
PyTorch version: 2.3.0+cu121
Is debug build: False
CUDA used to build PyTorch: 12.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.6 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
Clang version: Could not collect
CMake version: version 3.29.3
Libc version: glibc-2.31

Python version: 3.11.9 (main, Apr 19 2024, 16:48:06) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-5.15.0-1056-azure-x86_64-with-glibc2.31
Is CUDA available: True
CUDA runtime version: 11.8.89
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration:
GPU 0: NVIDIA A100 80GB PCIe
GPU 1: NVIDIA A100 80GB PCIe

Nvidia driver version: 545.23.08
cuDNN version: Probably one of the following:
/usr/local/cuda-11.8/targets/x86_64-linux/lib/libcudnn.so.8.7.0
/usr/local/cuda-11.8/targets/x86_64-linux/lib/libcudnn_adv_infer.so.8.7.0
/usr/local/cuda-11.8/targets/x86_64-linux/lib/libcudnn_adv_train.so.8.7.0
/usr/local/cuda-11.8/targets/x86_64-linux/lib/libcudnn_cnn_infer.so.8.7.0
/usr/local/cuda-11.8/targets/x86_64-linux/lib/libcudnn_cnn_train.so.8.7.0
/usr/local/cuda-11.8/targets/x86_64-linux/lib/libcudnn_ops_infer.so.8.7.0
/usr/local/cuda-11.8/targets/x86_64-linux/lib/libcudnn_ops_train.so.8.7.0
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture:                       x86_64
CPU op-mode(s):                     32-bit, 64-bit
Byte Order:                         Little Endian
Address sizes:                      48 bits physical, 48 bits virtual
CPU(s):                             48
On-line CPU(s) list:                0-47
Thread(s) per core:                 1
Core(s) per socket:                 48
Socket(s):                          1
NUMA node(s):                       2
Vendor ID:                          AuthenticAMD
CPU family:                         25
Model:                              1
Model name:                         AMD EPYC 7V13 64-Core Processor
Stepping:                           1
CPU MHz:                            2445.437
BogoMIPS:                           4890.87
Hypervisor vendor:                  Microsoft
Virtualization type:                full
L1d cache:                          1.5 MiB
L1i cache:                          1.5 MiB
L2 cache:                           24 MiB
L3 cache:                           192 MiB
NUMA node0 CPU(s):                  0-23
NUMA node1 CPU(s):                  24-47
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Not affected
Vulnerability Retbleed:             Not affected
Vulnerability Spec rstack overflow: Mitigation; safe RET, no microcode
Vulnerability Spec store bypass:    Vulnerable
Vulnerability Spectre v1:           Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:           Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Not affected
Flags:                              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core invpcid_single vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves clzero xsaveerptr rdpru arat umip vaes vpclmulqdq rdpid fsrm

Versions of relevant libraries:
[pip3] numpy==1.26.4
[pip3] nvidia-nccl-cu12==2.20.5
[pip3] torch==2.3.0
[pip3] triton==2.3.0
[pip3] vllm_nccl_cu12==2.18.1.0.4.0
[conda] numpy                     1.26.4                   pypi_0    pypi
[conda] nvidia-nccl-cu12          2.20.5                   pypi_0    pypi
[conda] torch                     2.3.0                    pypi_0    pypi
[conda] triton                    2.3.0                    pypi_0    pypi
[conda] vllm-nccl-cu12            2.18.1.0.4.0             pypi_0    pypiROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: 0.4.2
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
GPU Topology:
GPU0    GPU1    NIC0    CPU Affinity    NUMA Affinity   GPU NUMA ID
GPU0     X      NV12    SYS     0-23    0               N/A
GPU1    NV12     X      SYS     24-47   1               N/A
NIC0    SYS     SYS      X

Legend:

  X    = Self
  SYS  = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI)
  NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node
  PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
  PXB  = Connection traversing multiple PCIe bridges (without traversing the PCIe Host Bridge)
  PIX  = Connection traversing at most a single PCIe bridge
  NV#  = Connection traversing a bonded set of # NVLinks

NIC Legend:

  NIC0: mlx5_0

How would you like to use vllm
I have two GPUs in my VM... I am already using vLLM on one of the GPUs and the other one is vacant.
How can I start a second vLLM instance on the second GPU of mine?
I tried:
--device cuda    |    --device auto    |    --device cuda:1

but they don't seem to work as I was expecting...
Could you please tell me what am I missing here?
Regards!

You can use CUDA_VISIBLE_DEVICES environment variable when running the command.

I changed CUDA_VISIBLE_DEVICES, and when I delete CUDA_VISIBLE_DEVICES to load another model. I got an error: CUDA error: invalid device ordinal.

I changed CUDA_VISIBLE_DEVICES, and when I delete CUDA_VISIBLE_DEVICES to load another model. I got an error: CUDA error: invalid device ordinal.

Can you show the commands (including a rnv variables) which you used to run vLLM?

我更改了CUDA_VISIBLE_DEVICES，当我删除CUDA_VISIBLE_DEVICES以加载另一个模型时。我收到错误：CUDA 错误：设备序号无效。

您能展示用于运行 vLLM 的命令（包括 env 变量）吗？

I use an script to select GPU of most memory. So I have to del CUDA_VISIBLE_DEVICES env variable after I load a model, and then to load another model. However, When I move new model to the device I select. I got the error.
Actually, I think this bug is not caused by vllm. Even I don't use vllm, when I set CUDA_VISIBLE_DEVICES and then unset CUDA_VISIBLE_DEVICES to load another model, I will got an error. I don't think set CUDA_VISIBLE_DEVICES  is a good way to set GPU.

我更改了CUDA_VISIBLE_DEVICES，当我删除CUDA_VISIBLE_DEVICES以加载另一个模型时。我收到错误：CUDA 错误：设备序号无效。

您能展示用于运行 vLLM 的命令（包括 env 变量）吗？

It appears that if you set the CUDA_VISIBLE_DEVICES environment variable, for example, os.environ["CUDA_VISIBLE_DEVICES"] = "2,3", then in your code, the device indices will start from 0. That is, cuda:0 corresponds to the actual cuda:2, and cuda:1 corresponds to the actual cuda:3

我更改了CUDA_VISIBLE_DEVICES，当我删除CUDA_VISIBLE_DEVICES以加载另一个模型时。我收到错误：CUDA 错误：设备序号无效。

您能展示用于运行 vLLM 的命令（包括 env 变量）吗？

如果您设置了CUDA_VISIBLE_DEVICES环境变量，例如 os.environ[“CUDA_VISIBLE_DEVICES”] = “2,3”，那么在您的代码中，设备索引将从 0 开始。也就是说，cuda：0 对应于实际的 cuda：2，而 cuda：1 对应于实际的 cuda：3

通常，我在命令行中而不是在 Python 中设置环境变量，例如：
CUDA_VISIBLE_DEVICES=0,1 python -m <command>

这是因为在导入 PyTorch 之前需要更新环境变量才能使其正确生效，这很难依赖。

I have several model and gpu. So I have to set CUDA_VISIBLE_DEVICES several times, and get error. Set CUDA_VISIBLE_DEVICES is not a good way. I think when people have several model and gpu, they need a device paramter.

I have decided not to use vllm. Vllm has a DeviceConfig configuration, but the kv-cache does not use it and always uses cuda:0. This is too messy.


text:
Fix issue in UDP/SCTP Service flow in Antrea Proxy

Set IP protocol number according to the Service protocol type in "learn" flow.
Add integration test cases to ensure the flow is realized as expected.

Fixes #1395

Codecov Report

Merging #1398 into master will decrease coverage by 16.77%.
The diff coverage is 90.90%.

@@             Coverage Diff             @@
##           master    #1398       +/-   ##
===========================================
- Coverage   64.35%   47.57%   -16.78%
===========================================
  Files         159       74       -85
  Lines       12685     5597     -7088
===========================================
- Hits         8163     2663     -5500
+ Misses       3665     2650     -1015
+ Partials      857      284      -573

Flag
Coverage Δ

#integration-tests
47.57% <90.90%> (+2.74%)
:arrow_up:

#kind-e2e-tests
?

#unit-tests
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/ovs/openflow/ofctrl_action.go
88.29% <90.90%> (-1.56%)
:arrow_down:

pkg/agent/proxy/service.go
0.00% <0.00%> (-100.00%)
:arrow_down:

pkg/ovs/ovsconfig/default.go
0.00% <0.00%> (-100.00%)
:arrow_down:

pkg/agent/proxy/types/groupcounter.go
0.00% <0.00%> (-95.00%)
:arrow_down:

pkg/agent/proxy/endpoints.go
0.00% <0.00%> (-88.58%)
:arrow_down:

pkg/agent/querier/querier.go
0.00% <0.00%> (-87.50%)
:arrow_down:

pkg/apis/controlplane/register.go
0.00% <0.00%> (-85.72%)
:arrow_down:

pkg/agent/proxy/types/types.go
0.00% <0.00%> (-84.62%)
:arrow_down:

pkg/agent/flowexporter/connections/conntrack.go
0.00% <0.00%> (-84.22%)
:arrow_down:

pkg/agent/types/networkpolicy.go
5.88% <0.00%> (-82.36%)
:arrow_down:

... and 125 more

/test-all

/test-e2e

/test-conformance
/test-networkpolicy

/test-all

source: gharchive/pull-request

authors: codecov-io lzhecheng wenyingd

repo: vmware-tanzu/antrea

license_type: permissive

license_source: github-api


text:
Change flow export interval mechanism in Flow Exporter

We have one flow export interval for all flows at Antrea Agent; this
leads to one burst of flow records at flow collector. Instead we could
have granular flow export intervals for individual flows by using active
flow export timeout and inactive flow export time out.
As part of this change, the flow export frequency config parameter is removed.
Fixes #1637
Remaining part is adding tests.

Codecov Report

Merging #1714 (e35692e) into master (9d3d10b) will decrease coverage by 10.88%.
The diff coverage is 51.82%.

@@             Coverage Diff             @@
##           master    #1714       +/-   ##
===========================================
- Coverage   63.31%   52.43%   -10.89%
===========================================
  Files         170      184       +14
  Lines       14250    15799     +1549
===========================================
- Hits         9023     8284      -739
- Misses       4292     6593     +2301
+ Partials      935      922       -13

Flag
Coverage Δ

kind-e2e-tests
37.12% <38.48%> (-18.27%)
:arrow_down:

unit-tests
40.31% <35.52%> (-0.96%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

cmd/antrea-agent/agent.go
0.00% <0.00%> (ø)

.../agent/apiserver/handlers/networkpolicy/handler.go
58.33% <ø> (ø)

...gent/controller/noderoute/node_route_controller.go
45.83% <0.00%> (-0.64%)
:arrow_down:

pkg/agent/proxy/proxier_linux.go
0.00% <0.00%> (-25.00%)
:arrow_down:

pkg/agent/proxy/types/groupcounter.go
0.00% <0.00%> (-95.00%)
:arrow_down:

pkg/agent/proxy/types/types.go
0.00% <0.00%> (-84.62%)
:arrow_down:

pkg/agent/stats/collector.go
97.72% <ø> (ø)

pkg/agent/types/networkpolicy.go
37.50% <ø> (-45.84%)
:arrow_down:

pkg/antctl/antctl.go
100.00% <ø> (ø)

pkg/antctl/command_definition.go
54.65% <ø> (+14.24%)
:arrow_up:

... and 136 more

Codecov Report

Merging #1714 (e35692e) into master (9d3d10b) will decrease coverage by 10.88%.
The diff coverage is 51.82%.

@@             Coverage Diff             @@
##           master    #1714       +/-   ##
===========================================
- Coverage   63.31%   52.43%   -10.89%
===========================================
  Files         170      184       +14
  Lines       14250    15799     +1549
===========================================
- Hits         9023     8284      -739
- Misses       4292     6593     +2301
+ Partials      935      922       -13

Flag
Coverage Δ

kind-e2e-tests
37.12% <38.48%> (-18.27%)
:arrow_down:

unit-tests
40.31% <35.52%> (-0.96%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

cmd/antrea-agent/agent.go
0.00% <0.00%> (ø)

.../agent/apiserver/handlers/networkpolicy/handler.go
58.33% <ø> (ø)

...gent/controller/noderoute/node_route_controller.go
45.83% <0.00%> (-0.64%)
:arrow_down:

pkg/agent/proxy/proxier_linux.go
0.00% <0.00%> (-25.00%)
:arrow_down:

pkg/agent/proxy/types/groupcounter.go
0.00% <0.00%> (-95.00%)
:arrow_down:

pkg/agent/proxy/types/types.go
0.00% <0.00%> (-84.62%)
:arrow_down:

pkg/agent/stats/collector.go
97.72% <ø> (ø)

pkg/agent/types/networkpolicy.go
37.50% <ø> (-45.84%)
:arrow_down:

pkg/antctl/antctl.go
100.00% <ø> (ø)

pkg/antctl/command_definition.go
54.65% <ø> (+14.24%)
:arrow_up:

... and 136 more

This is what I get from RFC 5102:
5.11.1.  flowActiveTimeout

   Description:
      The number of seconds after which an active Flow is timed out
      anyway, even if there is still a continuous flow of packets.
   Abstract Data Type: unsigned16
   ElementId: 36
   Status: current
   Units: seconds

5.11.2.  flowIdleTimeout

   Description:
      A Flow is considered to be timed out if no packets belonging to
      the Flow have been observed for the number of seconds specified by
      this field.
   Abstract Data Type: unsigned16
   ElementId: 37
   Status: current
   Units: seconds

5.11.3.  flowEndReason

   Description:
      The reason for Flow termination.  The range of values includes the
      following:

      0x01: idle timeout
            The Flow was terminated because it was considered to be
            idle.

      0x02: active timeout
            The Flow was terminated for reporting purposes while it was
            still active, for example, after the maximum lifetime of
            unreported Flows was reached.

      0x03: end of Flow detected
            The Flow was terminated because the Metering Process
            detected signals indicating the end of the Flow, for
            example, the TCP FIN flag.

It seems that in this PR you ignore case 0x01: idle timeout altogether. However, I believe that when we talk about "inactive_timeout", this is the case that actually matters the most. Actually I feel we have 2 solutions:

use "inactive_timeout" for both 0x01: idle timeout and 0x03: end of Flow detected
use "inactive_timeout" for 0x01: idle timeout only (in which case I suggest renaming it to "idle_timeout") and export a flow record immediately when a connection is actually terminated

My preference would definitely be the second solution. I feel like it's more consistent with RFC 6645 and RFC 5470.

Thanks for the comments, Antonin.
Yes, 0x01: idle timeout is being ignored. As we are relying on conntrack to timeout the flow in the conntrack table with DYING flag (both UDP and TCP) to treat the flow as inactive, I thought we can consider the conntrack timeout as the detection signal to consider it as 0x03: end of Flow detected.
My read for 0x01: idle timeout is that for example if flow records packet data and throughput data do not change for a given time period, we could timeout the flow and send the 0x01: idle timeout as the reason.
I consider the flows, where there is only TCP-SYN (CONFIRMED) orTCP-SYN+TCP-SYN-ACK(SEEN_REPLY), as inactive flows and trigger the inactive_timeout and reason asflow end detected. It can definitely be argued that they fall in the bucket of 0x01: idle timeout`.

use "inactive_timeout" for both 0x01: idle timeout and 0x03: end of Flow detected

Maybe we could use both depending on whether the status is DYING or TCP-SYN (CONFIRMED)/ TCP-SYN+TCP-SYN-ACK(SEEN_REPLY)
What do you think?

This is what I get from RFC 5102:
5.11.1.  flowActiveTimeout

   Description:
      The number of seconds after which an active Flow is timed out
      anyway, even if there is still a continuous flow of packets.
   Abstract Data Type: unsigned16
   ElementId: 36
   Status: current
   Units: seconds

5.11.2.  flowIdleTimeout

   Description:
      A Flow is considered to be timed out if no packets belonging to
      the Flow have been observed for the number of seconds specified by
      this field.
   Abstract Data Type: unsigned16
   ElementId: 37
   Status: current
   Units: seconds

5.11.3.  flowEndReason

   Description:
      The reason for Flow termination.  The range of values includes the
      following:

      0x01: idle timeout
            The Flow was terminated because it was considered to be
            idle.

      0x02: active timeout
            The Flow was terminated for reporting purposes while it was
            still active, for example, after the maximum lifetime of
            unreported Flows was reached.

      0x03: end of Flow detected
            The Flow was terminated because the Metering Process
            detected signals indicating the end of the Flow, for
            example, the TCP FIN flag.

It seems that in this PR you ignore case 0x01: idle timeout altogether. However, I believe that when we talk about "inactive_timeout", this is the case that actually matters the most. Actually I feel we have 2 solutions:

use "inactive_timeout" for both 0x01: idle timeout and 0x03: end of Flow detected
use "inactive_timeout" for 0x01: idle timeout only (in which case I suggest renaming it to "idle_timeout") and export a flow record immediately when a connection is actually terminated

My preference would definitely be the second solution. I feel like it's more consistent with RFC 6645 and RFC 5470.

Thanks for the comments, Antonin.
Yes, 0x01: idle timeout is being ignored. As we are relying on conntrack to timeout the flow in the conntrack table with DYING flag (both UDP and TCP) to treat the flow as inactive, I thought we can consider the conntrack timeout as the detection signal to consider it as 0x03: end of Flow detected.
My read for 0x01: idle timeout is that for example if flow records packet data and throughput data do not change for a given time period, we could timeout the flow and send the 0x01: idle timeout as the reason.
I consider the flows, where there is only TCP-SYN (CONFIRMED) orTCP-SYN+TCP-SYN-ACK(SEEN_REPLY), as inactive flows and trigger the inactive_timeout and reason asflow end detected. It can definitely be argued that they fall in the bucket of 0x01: idle timeout`.

use "inactive_timeout" for both 0x01: idle timeout and 0x03: end of Flow detected

Maybe we could use both depending on whether the status is DYING or TCP-SYN (CONFIRMED)/ TCP-SYN+TCP-SYN-ACK(SEEN_REPLY)
What do you think?

My read for 0x01: idle timeout is that for example if flow records packet data and throughput data do not change for a given time period, we could timeout the flow and send the 0x01: idle timeout as the reason.

That's the idea

I consider the flows, where there is only TCP-SYN (CONFIRMED) or TCP-SYN+TCP-SYN-ACK(SEEN_REPLY), as inactive flows and trigger the inactive_timeout and reason as flow end detected. It can definitely be argued that they fall in the bucket of 0x01: idle timeout.

I don't see how this is compatible with the above. If you have a SEEN_REPLY connection (for me this is basically an "established" connection, but am I wrong), I think the following logic should apply while it is in that state:

if packet counts don't change for a 15s window, send a record with "idle timeout" end flow reason
otherwise, after 60s, always send a record with "active timeout" end flow reason

I would say the same goes for a CONFIRMED connection.

DYING

I don't think this is a good signal for "end of Flow detected" (0x03). The RFC text above explicitly lists TCP FIN as a possible signal. Between TCP FIN and the connection going to DYING state, there will be 120s (TIME_WAIT state).
As you see I have carefully avoided the terminology "inactive timeout". Either it means "idle timeout", in which case we should use "idle timeout" as it is not as ambiguous. Or it means something else, but in that case I am not sure what exactly or what should be implemented.

My read for 0x01: idle timeout is that for example if flow records packet data and throughput data do not change for a given time period, we could timeout the flow and send the 0x01: idle timeout as the reason.

That's the idea

I consider the flows, where there is only TCP-SYN (CONFIRMED) or TCP-SYN+TCP-SYN-ACK(SEEN_REPLY), as inactive flows and trigger the inactive_timeout and reason as flow end detected. It can definitely be argued that they fall in the bucket of 0x01: idle timeout.

I don't see how this is compatible with the above. If you have a SEEN_REPLY connection (for me this is basically an "established" connection, but am I wrong), I think the following logic should apply while it is in that state:

if packet counts don't change for a 15s window, send a record with "idle timeout" end flow reason
otherwise, after 60s, always send a record with "active timeout" end flow reason

I would say the same goes for a CONFIRMED connection.

DYING

I don't think this is a good signal for "end of Flow detected" (0x03). The RFC text above explicitly lists TCP FIN as a possible signal. Between TCP FIN and the connection going to DYING state, there will be 120s (TIME_WAIT state).
As you see I have carefully avoided the terminology "inactive timeout". Either it means "idle timeout", in which case we should use "idle timeout" as it is not as ambiguous. Or it means something else, but in that case I am not sure what exactly or what should be implemented.

I don't think this is a good signal for "end of Flow detected" (0x03). The RFC text above explicitly lists TCP FIN as a possible signal. Between TCP FIN and the connection going to DYING state, there will be 120s (TIME_WAIT state).

Yes, you are right about status flag DYING which is only set when conntrack entry is deleted--made sure from Linux conntrack code. Agreed that FIN_WAIT state cannot be captured with DYING.

I consider the flows, where there is only TCP-SYN (CONFIRMED) or TCP-SYN+TCP-SYN-ACK(SEEN_REPLY), as inactive flows and trigger the inactive_timeout and reason as flow end detected. It can definitely be argued that they fall in the bucket of 0x01: idle timeout.

I don't see how this is compatible with the above. If you have a SEEN_REPLY connection (for me this is basically an "established" connection, but am I wrong), I think the following logic should apply while it is in that state:

I was considering following status flags: (SEEN_REPLY & !ASSURED) and (CONFIRMED & !ASSURED). Yes, SEEN_REPLY status flag can be there for connection with the "established" state as well. I think we should use TCP states: SYN_SENT and SYN_RECV rather than status flags.

if packet counts don't change for a 15s window, send a record with "idle timeout" end flow reason
otherwise, after 60s, always send a record with "active timeout" end flow reason

I would say the same goes for a CONFIRMED connection.

Agree with the approach to have only "idle_timeout" and "active_timeout" following RFC 5470 and RFC 6645.
However, I have a question for long-standing connections in the ESTABLISHED state (the default time out for this state is 5days). If there are no packets for 15s and we timeout the connection to export the flow records, then I am thinking of the following approach following this example.  When this situation happens, we will delete the connection from the flow record map after expiring the flow with "idle_timeout". We will retain the same connection in the connection map but create the flow record again. Any comments on this policy?

I don't think this is a good signal for "end of Flow detected" (0x03). The RFC text above explicitly lists TCP FIN as a possible signal. Between TCP FIN and the connection going to DYING state, there will be 120s (TIME_WAIT state).

Yes, you are right about status flag DYING which is only set when conntrack entry is deleted--made sure from Linux conntrack code. Agreed that FIN_WAIT state cannot be captured with DYING.

I consider the flows, where there is only TCP-SYN (CONFIRMED) or TCP-SYN+TCP-SYN-ACK(SEEN_REPLY), as inactive flows and trigger the inactive_timeout and reason as flow end detected. It can definitely be argued that they fall in the bucket of 0x01: idle timeout.

I don't see how this is compatible with the above. If you have a SEEN_REPLY connection (for me this is basically an "established" connection, but am I wrong), I think the following logic should apply while it is in that state:

I was considering following status flags: (SEEN_REPLY & !ASSURED) and (CONFIRMED & !ASSURED). Yes, SEEN_REPLY status flag can be there for connection with the "established" state as well. I think we should use TCP states: SYN_SENT and SYN_RECV rather than status flags.

if packet counts don't change for a 15s window, send a record with "idle timeout" end flow reason
otherwise, after 60s, always send a record with "active timeout" end flow reason

I would say the same goes for a CONFIRMED connection.

Agree with the approach to have only "idle_timeout" and "active_timeout" following RFC 5470 and RFC 6645.
However, I have a question for long-standing connections in the ESTABLISHED state (the default time out for this state is 5days). If there are no packets for 15s and we timeout the connection to export the flow records, then I am thinking of the following approach following this example.  When this situation happens, we will delete the connection from the flow record map after expiring the flow with "idle_timeout". We will retain the same connection in the connection map but create the flow record again. Any comments on this policy?

However, I have a question for long-standing connections in the ESTABLISHED state (the default time out for this state is 5days). If there are no packets for 15s and we timeout the connection to export the flow records, then I am thinking of the following approach following this example. When this situation happens, we will delete the connection from the flow record map after expiring the flow with "idle_timeout". We will retain the same connection in the connection map but create the flow record again. Any comments on this policy?

I think this approach kind of makes sense to me. So in case of idle_timeout, we essentially clear the cache (flow record map), which means that if activity resumes for this flow, we will use a new flowStart timestamp and reset counters? That would at least be consistent with network devices which do sampling... Do you think it will work well with external flow collectors?
BTW, what made you decide to use 2 separate maps (one for the connection store and one for the flow records) instead of a single one? After all the maps are indexed by the same key. Maybe the commit message / PR description should have a clear description of the purpose of each one.

I don't think you have included any changes with regard to leveraging TCP FIN to terminate flow records (end of Flow detected case) and filtering out connections in the TIME_WAIT state?

Yes, I did not add the scenario with the state corresponding to the TCP FIN flag and the flow reason end of flow detected.
TIME_WAIT state filtering was also not done. Will take it up in a future PR.

I think this approach kind of makes sense to me. So in case of idle_timeout, we essentially clear the cache (flow record map), which means that if activity resumes for this flow, we will use a new flowStart timestamp and reset counters? That would at least be consistent with network devices which do sampling... Do you think it will work well with external flow collectors?
BTW, what made you decide to use 2 separate maps (one for the connection store and one for the flow records) instead of a single one? After all the maps are indexed by the same key. Maybe the commit message / PR description should have a clear description of the purpose of each one.

I went with separate maps to reduce contention when doing polling and exporting. With the current export timeout implementation, where Export function is called every second, separate data structures become more important. Will add their description and purpose in PR and commit message.

/test-all

/test-all

do you think we can change the FlowRecord struct so that the embedded Connection object is a value and not a pointer?
So this:
type FlowRecord struct {
	Conn               Connection
...
}

Instead of that:
type FlowRecord struct {
	Conn               *Connection
...
}

I want to make it obvious that the Connection stored in the FlowRecord is a copy of what's stored in the ConnectionStore. It will remove that ambiguity and there is no downside IMO. It makes it more obvious that the separation of connections & flows help reduce contention.

Thanks for the comment Antonin.
Yes, agreed that there will be no downside in moving to because we take in the Connection object as the argument in the callback function signature:
type ConnectionMapCallBack func(key ConnectionKey, conn Connection) error
There is scope for improvement by changing the signature to take the pointer of the Connection object. For now, I will change from the pointer to embed the Connection struct directly in FlowRecord. As part of performance improvements with the perf unit test, we can take that up. Hope that's ok.

I think that from a design perspective, it is a bit surprising that the FlowExporter is in charge of deleting connections from the ConnectionStore. I understand why: we need to make sure the connection information is preserved until the last record can be sent. But maybe it is worth a comment.

Added the comment.

/test-all

/test-all

There is scope for improvement by changing the signature to take the pointer of the Connection object.

I think it is better to keep it as "pass-by-value" for now. It makes it clear that the function intends to make a copy and makes the code more readable IMO. Even if there may be a small performance penalty. Did you ever get a chance to benchmark the exporter code?

There is scope for improvement by changing the signature to take the pointer of the Connection object.

I think it is better to keep it as "pass-by-value" for now. It makes it clear that the function intends to make a copy and makes the code more readable IMO. Even if there may be a small performance penalty. Did you ever get a chance to benchmark the exporter code?

Yes sometime back in last year. At that time memory consumption of antrea agent is increased by 10MB when we moved from 300 to 1K flows in Antrea connection store. Agree that the code now warrants a performance unit test using conntrack dumper interface.

/test-all

/test-all

LGTM, looking forward to a follow-up PR with support for TIME_WAIT state transitions & the "end of Flow detected" end-of-flow reason (0x03).

Thanks for the review. Yes, that flowEndReason will be added in a follow up PR.

authors: antoninbas codecov-io srikartati


text:
🐦 Please tweet about v0.26.0

So I can RT it for https://github.com/adriens/chocolatey-vendir/issues/16 🙏

Sorry @adriens I was OOO since Thursday. Thanks!

No worries @microwavables 💟

source: gharchive/issue

authors: adriens microwavables

repo: vmware-tanzu/carvel-vendir


text:
Tanzu CLI update from 10.1 to 11 failed with - Error: could not read artifact "artifacts/pinniped-auth/v0.11.4/tanzu-pinniped-auth-linux_amd64": storage: object doesn't exist

Bug Report
Tanzu cli update from commandline not working at this moment and failed with
Error: could not read artifact "artifacts/pinniped-auth/v0.11.4/tanzu-pinniped-auth-linux_amd64": storage: object doesn't exist
Steps to Reproduce the Bug

user@k8s-mgmt:~$ tanzu version
version: v0.10.1
buildDate: 2022-02-14
sha: 401d55b

user@k8s-mgmt:~$ tanzu update
the following updates will take place:
core v0.10.1 → v0.11.4
package v0.10.1 → {v0.11.4 %!s(*cli.GCPBucketRepository=&{tce-tanzu-cli-framework artifacts core 0x13d53a0})}
pinniped-auth v0.10.1 → {v0.11.4 %!s(*cli.GCPBucketRepository=&{tce-tanzu-cli-framework artifacts core 0x13d53a0})}
secret v0.10.1 → {v0.11.4 %!s(*cli.GCPBucketRepository=&{tce-tanzu-cli-framework artifacts core 0x13d53a0})}
cluster v0.10.1 → {v0.11.4 %!s(*cli.GCPBucketRepository=&{tce-tanzu-cli-framework artifacts core 0x13d53a0})}
kubernetes-release v0.10.1 → {v0.11.4 %!s(*cli.GCPBucketRepository=&{tce-tanzu-cli-framework artifacts core 0x13d53a0})}
login v0.10.1 → {v0.11.4 %!s(*cli.GCPBucketRepository=&{tce-tanzu-cli-framework artifacts core 0x13d53a0})}
management-cluster v0.10.1 → {v0.11.4 %!s(*cli.GCPBucketRepository=&{tce-tanzu-cli-framework artifacts core 0x13d53a0})}
would you like to continue? [y/n] y

Environment Details

Build version (tanzu version): version: v0.10.1, buildDate: 2022-02-14, sha: 401d55b
Deployment (Managed/Unmanaged cluster): Managed
Infrastructure Provider (Docker/AWS/Azure/vSphere): vSphere
Operating System (client): Ubuntu 20.04.4 LTS, x86_64

i get the same error but with a different plugin
? would you like to continue? [y/n] y
Error: could not read artifact "artifacts/conformance/v0.11.0/tanzu-conformance-linux_amd64": storage: object doesn't exist

✖  could not read artifact "artifacts/conformance/v0.11.0/tanzu-conformance-linux_amd64": storage: object doesn't exist

repo: vmware-tanzu/community-edition


text:
site css: images on resource page should fit the grid

Images on the resources page should resize to fit the grid, much like embedded youtube videos.
Reviewed this older PR to see that we do commit the built CSS files.

Rebasing.

repo: vmware-tanzu/pinniped


text:
Update Craft Library symbols

[X] bug
[ ] feature request
[ ] enhancement

Expected behavior

[ ] Sync symbols with correct resizing attributes
[ ] update Design Resources section with new version number and download

Actual behavior

Some symbols have broken resizing attributes
InVision Craft Library plugin recently fixed (v1.0.38) the bug where this happened
confirmed bug has been fixed

Environment details

Clarity Craft Library version: 0.9.9

Updated and tested

repo: vmware/clarity

license: MIT


text:
Webpack hangs when ClairtyModule imported on project created with angular-cli

Select one ...  (check one with "x")
[x] bug - More of a question/request for guidance
[ ] feature request
[ ] enhancement

Expected behavior
angular-cli app, added Clarity, Webpack should complete and bundle should be valid(?)
Time: 1734ms
chunk    {0} main.bundle.js, main.bundle.map (main) 4.64 kB {3} [initial]
chunk    {1} styles.bundle.js, styles.bundle.map (styles) 730 kB {4} [initial]
chunk    {2} scripts.bundle.js, scripts.bundle.map (scripts) 55.8 kB {4} [initial]
chunk    {3} vendor.bundle.js, vendor.bundle.map (vendor) 2.22 MB [initial]
chunk    {4} inline.bundle.js, inline.bundle.map (inline) 0 bytes [entry]
webpack: bundle is now VALID.
Actual behavior
I'm new to web development so apologies in advance as I don't fully understand all the technologies at play here (e.g. webpack).  After following the instructions for adding Clarity to an app created with angular-cli, webpack seems to hang when building modules.
21% building modules 96/96 modules 0 active
When actually trying to connect to the new site when webpack is in this state, I receive this on the console:
webpack: wait until bundle finished: /
If I do not include ClarityModule, webpack completes and I get the nice little 'app works!' message generated by the angular-cli project:
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { FormsModule } from '@angular/forms';
import { HttpModule } from '@angular/http';
import { ClarityModule } from 'clarity-angular';
import { AppComponent } from './app.component';
...
imports: [
BrowserModule,
FormsModule,
HttpModule,
],
But with ClarityModule:
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { FormsModule } from '@angular/forms';
import { HttpModule } from '@angular/http';
import { ClarityModule } from 'clarity-angular';
import { AppComponent } from './app.component';
...
imports: [
BrowserModule,
ClarityModule,
FormsModule,
HttpModule,
],
Webpack hangs.
This is on a brand new project created with the angular-cli (e.g. ng new myproject).
Reproduction of behavior
Create new project with angular-cli
ng new myproj
Follow instructions for adding clarity, add css and js to the angular-cli.json file under styles and scripts sections.
npm start to confirm that you receive the "app works!" message from your browser
Import module in app.modules.ts
npm start seems to hang at webpack preparation.
Environment details
$ ng --version
angular-cli: 1.0.0-beta.22-1
node: 6.2.1
os: linux x64
14   "dependencies": {
15     "@angular/common": "2.2.3",
16     "@angular/compiler": "2.2.3",
17     "@angular/core": "2.2.3",
18     "@angular/forms": "2.2.3",
19     "@angular/http": "2.2.3",
20     "@angular/platform-browser": "2.2.3",
21     "@angular/platform-browser-dynamic": "2.2.3",
22     "@angular/router": "3.2.3",
23     "@webcomponents/custom-elements": "^1.0.0-alpha.3",
24     "clarity-angular": "^0.7.3",
25     "clarity-icons": "^0.7.3",
26     "clarity-ui": "^0.7.3",
27     "core-js": "^2.4.1",
28     "mutationobserver-shim": "^0.3.2",
29     "rxjs": "5.0.0-beta.12",
30     "sass-loader": "^4.0.2",
31     "ts-helpers": "^1.1.1",
32     "zone.js": "^0.6.23"

Angular version: 2.0.X

Clarity version:

OS and version:
Ubuntu 16.04

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
N/A

@RainTomassi people are experiencing the errors with the latest angular-cli 3426 too. We are currently investigating the possible solutions for this issue and get back to you soon.

Thank you for the update.  Appreciate the quick response and apologies, I didn't see the other ticket :-)

I can confirm the following: if you remove the clarity dependency as a module and do "ng serve" and then update that file by adding that dependency and let webpack do the build job, it works!
So it must be something that the beginning that makes the compiler not finding ClarityModule. Maybe some include PATH's?

angular-cli@1.0.0-beta.22 is still experimental and forces AOT compilation. See https://github.com/angular/angular-cli/issues/3354 and https://github.com/angular/angular-cli/issues/3368 on the angular-cli project.
It's a pretty heated topic right now, but all we can do on our side is become AOT-compliant as soon as possible. So I'm closing this as a duplicate of #62.

authors: RainTomassi Shijir dragosrusu youdz


text:
fix: hide card doc from website sidebar nav

Signed-off-by: stsogoo stsogoo@vmware.com
PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)
[ ] If applicable, have a visual design approval

PR Type
What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] clarity.design website / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

Issue Number: N/A
What is the new behavior?
Does this PR introduce a breaking change?

[ ] Yes
[ ] No

Other information

Preview: https://60c3becc62e97e0a9f9e8497--vmware-clarity.netlify.app/

I was thinking to make a tool next week to look for @beta tags and discard the component docs for components in beta. What do you think?

authors: Shijir bbogdanov


text:
CLN/ENH: Decouple Segments from Sound

I think we want to decouple Segments from Sound so that a Segments instance does not have an attribute that is a Sound instance.
Instead we should just associate a sample rate with segments and remove need for Sound
This will also mean that we remove the Segment class. We just use a Segments instance with Sound.segment, to get back a new list of Sounds.

Some nuance to this:
I think I have found corner cases that reveal another bug in the original ava segmentation algorithm.
I only found this because of the pre-condition for Segments where we require that the offset of the last segment not be greater than the length of the Sound in samples.
So we probably want to keep that condition, to rule out that class of errors that could occur if we're not checking.

[ ] To do so without requiring that the Sound be around, we can solve the same way we're keeping the start_times / stop_times, etc.: add an attribute n_samples that we get from the sound, just like we get samplerate so we can convert from sample number to time. Then we will save n_samples in the json file representing the segments, just like we will save the samplerate. I need to think more about the name of the attribute but I think this solution generally will work.

repo: vocalpy/vocalpy


text:
test rerun

Please add a meaningful description for your change here

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

Run Go Samza ValidatesRunner

repo: volatilemolotov/beam


text:
[Question] Is it possible to calculate IV if the option price is given?

Is it possible to calculate implied volatility if the option price is given?

I wrote a routine to do this.
Basically, you run the model and change the IV until you reach your desired price. 1) You need an IV value to begin from. 2) There are limits to the equation. So as your IV values get very large or very small the price of the option becomes asymptotic and creates a pseudo infinite loop.  But I find it to be a valuable tool because the only thing you can lean on is the bid/ask price. Everything else is theoretical and therefore relative to your model.

license: mit

license_source: bigquery


text:
WIP add data_source_volterra_service_policy

ref: https://github.com/volterraedge/terraform-provider-volterra/issues/95

I have this working locally I just need the test to pass:
$ terraform apply

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  + create
 <= read (data resources)

Terraform will perform the following actions:

  # data.volterra_service_policy.foobar will be read during apply
  # (config refers to values not yet known)
 <= data "volterra_service_policy" "foobar"  {
      + id        = (known after apply)
      + name      = "foobar"
      + namespace = "shared"
    }

  # volterra_service_policy.foobar will be created
  + resource "volterra_service_policy" "foobar" {
      + algo               = "FIRST_MATCH"
      + allow_all_requests = true
      + any_server         = true
      + id                 = (known after apply)
      + name               = "foobar"
      + namespace          = "shared"
    }

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

Changes to Outputs:
  + test = {
      + id        = (known after apply)
      + name      = "foobar"
      + namespace = "shared"
    }

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

volterra_service_policy.foobar: Creating...
volterra_service_policy.foobar: Creation complete after 1s [id=35ede2bf-6c9f-4920-bceb-63570a964012]
data.volterra_service_policy.foobar: Reading...
data.volterra_service_policy.foobar: Read complete after 0s [id=35ede2bf-6c9f-4920-bceb-63570a964012]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Outputs:

test = {
  "id" = "35ede2bf-6c9f-4920-bceb-63570a964012"
  "name" = "foobar"
  "namespace" = "shared"
}

I have this working and the tests are creating the service policy test resource, then successfully using the data resouce.  But I have no idea why it is saying the plan is not empty and then failing.
https://github.com/volterraedge/terraform-provider-volterra/pull/98/checks#step:6:199
Error:     testing.go:654: Step 0 error: After applying this step and refreshing, the plan was not empty:

        DIFF:

        UPDATE: data.volterra_service_policy.aikuqbdhiz
          id:        "" => "<computed>"
          name:      "" => "aikuqbdhiz"
          namespace: "" => "shared"

        STATE:

        volterra_service_policy.aikuqbdhiz:
          ID = 293dc667-86e0-459c-9394-cb8442e51e37
          provider = provider.volterra
          algo = FIRST_MATCH
          allow_all_requests = true
          any_server = true
          deny_all_requests = false
          description =
          disable = false
          name = aikuqbdhiz
          namespace = shared
rest RPC: ves.io.schema.service_policy.API.Delete , Status: OK        , The 'service_policy' 'aikuqbdhiz' in namespace 'shared' was successfully deleted.

Alex, Can you please update this PR.

@sanabby this MR can be closed out as we merged in the main change and this was another option that added a few tests.


text:
Correction/addition regarding userconfig.txt

According to this list some boot options do not work when placed in an file referenced by the include option in /boot/config.txt. They are processed at an (too) early stage of the boot process when the included file does not get parsed.

Thanks!

authors: gvolt volumio

repo: volumio/docs


text:
Access denied due to invalid VCC-API-KEY

I've created app under developer account and copied VCC API key - Primary but there's still an error
{     "status": 401,     "error": {         "message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application."     } }
The app isn't publish since it was made for testing purposes but the API does not want to accept the VCC API, any ideas?

Hi @grzegorztomasiak. Thanks for raising an issue :raised_hands:
To better help you, we require some more information.
How are you running the request? Are you trying to run our samples in this repo?
Have you verified that the VCC_API_KEY is correctly added to the .env file?
If you still have issues, please try to execute a simple curl command following the instructions here:
https://developer.volvocars.com/apis/docs/getting-started/

Hi @adamgronberg, I have the exact same issue when trying out the connected-vehicle-fetch-sample.
This also happens when I try to execute the request in curl/python.
Could this be because my application is not published?
Status: Only for testing

I'm having same issue. Have tried creating multiple 'apps' and regenerating the keys etc.

Same for me. Happens even in the sandbox>

Same here... tried multiple applications and regenerated multiple times

Hi all, thanks for the added context.
It looks like the issues are related to the API, and not related to the sample code in this repository.
I've escalated this internally. You can also contact developer.portal@volvocars.com for more direct help.
I will leave this issue open until we've fully investigated the reason for the errors.

Same error here. I've never managed to get it to work at all in either command line curl or a programming environment, e.g. these node packages. I've tried regenerating my VCC API keys but makes no difference, same 401 error. Looks like something is borked in the API system/auth itself.
If helpful, here is my -vvvv curl output.
`
curl -vvvv 'https://api.volvocars.com/connected-vehicle/v2/vehicles'
| => -H 'accept: "application/json"'
| => -H 'authorization: Bearer my-bearer-token'
| => -H 'vcc-api-key: my-vcc-api-key'

Trying 52.19.178.68:443...
Connected to api.volvocars.com (52.19.178.68) port 443
ALPN: curl offers h2,http/1.1
(304) (OUT), TLS handshake, Client hello (1):
CAfile: /etc/ssl/cert.pem
CApath: none
(304) (IN), TLS handshake, Server hello (2):
(304) (IN), TLS handshake, Unknown (8):
(304) (IN), TLS handshake, Certificate (11):
(304) (IN), TLS handshake, CERT verify (15):
(304) (IN), TLS handshake, Finished (20):
(304) (OUT), TLS handshake, Finished (20):
SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
ALPN: server accepted h2
Server certificate:
subject: C=SE; L=Gothenburg; O=Volvo Car Corporation; CN=api.volvocars.com
start date: Feb 15 00:00:00 2023 GMT
expire date: Mar  6 23:59:59 2024 GMT
subjectAltName: host "api.volvocars.com" matched cert's "api.volvocars.com"
issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
SSL certificate verify ok.
using HTTP/2
[HTTP/2] [1] OPENED stream for https://api.volvocars.com/connected-vehicle/v2/vehicles
[HTTP/2] [1] [:method: GET]
[HTTP/2] [1] [:scheme: https]
[HTTP/2] [1] [:authority: api.volvocars.com]
[HTTP/2] [1] [:path: /connected-vehicle/v2/vehicles]
[HTTP/2] [1] [user-agent: curl/8.4.0]
[HTTP/2] [1] [accept: "application/json"]
[HTTP/2] [1] [authorization: Bearer my-bearer-token]
[HTTP/2] [1] [vcc-api-key: my-vcc-api-key]

GET /connected-vehicle/v2/vehicles HTTP/2
Host: api.volvocars.com
User-Agent: curl/8.4.0
accept: "application/json"
authorization: Bearer my-bearer-token
vcc-api-key: my-vcc-api-key

< HTTP/2 401
< content-length: 270
< content-type: application/json
< date: Sun, 28 Jan 2024 19:40:15 GMT
< server: vcc
< access-control-allow-origin: https://developer.volvocars.com
< request-context: appId=cid-v1:d08a6ac1-4942-4ce7-a466-f3dd07fd71d1
<
{
"status": 401,
"error": {
"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application."
}

Connection #0 to host api.volvocars.com left intact
}
`

Have also tried accessing this via VolvoMQTT Home Assistant integration but same error message of:
`Feb 01 22:43:16 volvo2mqtt [106] - INFO: Starting volvo2mqtt version v1.8.27
Feb 01 22:43:17 volvo2mqtt [106] - WARNING: VCCAPIKEY  isn't working! Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application.
Feb 01 22:43:17 volvo2mqtt [106] - WARNING: No working VCCAPIKEY found, waiting 10 minutes. Then trying again!`
Any idea when this will be addressed?

Have also tried accessing this via VolvoMQTT Home Assistant integration but same error message of:
`Feb 01 22:43:16 volvo2mqtt [106] - INFO: Starting volvo2mqtt version v1.8.27
Feb 01 22:43:17 volvo2mqtt [106] - WARNING: VCCAPIKEY isn't working! Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application.
Feb 01 22:43:17 volvo2mqtt [106] - WARNING: No working VCCAPIKEY found, waiting 10 minutes. Then trying again!`
Any idea when this will be addressed?

Did you try the portal? https://developer.volvocars.com/apis/connected-vehicle/v2/specification/#openapi
I noticed this week that it is working a little bit better. It still comes up some times with an 401, but pressing the execute button again and then it works.
It works 3 out of 5 times for the first try.

Thanks @Michel-NL , I did try via the portal too but I have a very low success rate on good responses. Actually, I don't think I've had a valid response from the portal, only ones from MQTT via Home Assistant. To be frank, I don't have time to keep pressing a button to get a valid response, Volvo really need to get the stability of the API corrected!
For info, here's the tail of the HA log file so far - just full of auth errors!
Feb 02 12:40:33 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:40:33 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:40:33 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:40:33 volvo2mqtt [106] - INFO: Mqtt update done. Next run in 300 seconds.  Feb 02 12:45:33 volvo2mqtt [106] - INFO: Sending mqtt update...  Feb 02 12:45:33 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:45:33 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:45:33 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:45:33 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:45:33 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:45:33 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:45:33 volvo2mqtt [106] - INFO: Mqtt update done. Next run in 300 seconds.  Feb 02 12:50:33 volvo2mqtt [106] - INFO: Sending mqtt update...  Feb 02 12:50:34 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:50:34 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:50:34 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:50:34 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:50:34 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:50:34 volvo2mqtt [106] - ERROR: API Call failed. Status Code: 401. Error: {"status": 401, "error": {"message": "Access denied due to invalid VCC-API-KEY. Make sure to provide a valid key for an active application." } }  Feb 02 12:50:34 volvo2mqtt [106] - INFO: Mqtt update done. Next run in 300 seconds.

Hello everyone, and thank you for your continued error reports. I've forwarded all your comments to the support team.
However, since the errors you are encountering are not related to the code in this repository, we've determined that we will have to close this issue.
For further assistance and error reporting, please continue to reach out to the Volvo Cars' Developer Portal support at developer.portal@volvocars.com. They are better equipped to assist with your issues.

authors: DuncanSmith Isshin Michel-NL REELcoder adamgronberg grzegorztomasiak markhaines thiemo-seys

repo: volvo-cars/developer-portal-api-samples


text:
Створи index.html і встав в нього наведений нижче фрагмент:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>Résumé</title>
  </head>
  <body>
    ― Hello World! 😉
  </body>
</html>

Added index.html template

repo: vovabatsyk/homepage


text:
Adding parameters to puppet-amanda/manifests/params.pp file for Redhat OSfamily.

Added $shell, $xinetd_unsupported and $generic_package paramters to Redhat OSfamily.

Pull Request (PR) description

This Pull Request (PR) fixes the following issues

This is to support strict_variables.

thanks for the PR!

authors: bastelfreak cliff-svt datarame

repo: voxpupuli/puppet-amanda


text:
Add replacement ldapquery::search function

Sourcing ldap server configuration options from puppet.conf was conflating their original purpose, and a future release of Puppet may even remove these options.
It's still desirable to be able to set defaults for the function from a file, but a dedicated yaml file is far more flexible than an ini file.
In this commit, a new ldapquery::search function is added with a new implementation. The old version is kept, but marked as DEPRECATED.

Hi,
Was looking at starting to use this module - thanks.
Any chance of finishing this off , have written against this branch and its working well.
The idea of creating a new function ldapquery::search and deprecating the current ldapquery::query one makes
sense to me?
Am using it like:
 $_filter = "(&(objectClass=group)(|${_egroups.map | $_eg | { "(CN=${_eg})" }.join()}))"

 $_results = ldapquery::query(
   'OU=e-groups,OU=Workgroups,DC=example,DC=ch',
   $_filter,
   ['member'],
   {
     'hosts' => [
       ['ldap.example.ch', 389],
       ['ldap-critical.example.ch', 389],
     ],
     'scope'   => 'sub'
   },
 )

which is fine I'd say.
If the connection parameters  came from a file f we certainly have more than one ldap server so that location path needs to be a configuration. I would just leave loading from a yaml or hiera as exercise for the reader.

Any chance of finishing this off , have written against this branch and its working well.

@traylenator I've just got around to picking this up again. Decided the best approach is probably just a new function instead of messing around with multiple dispatches etc.  Just doing a bit more testing locally, then I'll take this off draft.

Thanks - had it mind to look at.

authors: alexjfisher traylenator

repo: voxpupuli/puppet-ldapquery


text:
Remove CentOS 5 support

just tried to run the acceptance test for centos5.

selinux::module fails (could not find /usr/share/selinux/devel/Makefile)
selinux::permissive fails (semanage permissive doesn't exist at all)

CentOS 5 will be out of support on 2015-03 so I don't think its worth to invest time.
my proposed solution is to just remove Centos 5 support from metadata.json.

legacy fedora releases should be removed too (Fedora 19-23) from metadata.json

Fedora versions strings probably shouldn't be in the metadata.json

Fedora versions strings probably shouldn't be in the metadata.json

Why? What are yor arguments to remove it?
We do run tests against specific versions of fedora not against unspecified ones.
As a user i'd like to see specific distro versions.
What would happen to rspec puppet facts/facterdb tests which reads metadata json distro and version?

I think we should list what we are running beaker acceptance tests for.

I think it makes sense to support at least:

CentOS/RHEL 6 (latest minor release, and the others best-effort only) and 7.3, and additionally RHEL 7.2 (CentOS doesn't usually support point releases after the next one is released AFAIK, but RHEL does, and not everyone will have updated to 7.3)
Fedora 24 and 25

I'm not sure if there are boxes available for testing against RHEL, but CentOS probably is close enough.

authors: juniorsysadmin oranenj vinzent

repo: voxpupuli/puppet-selinux


text:
release 3.0.1-rc0

Affected Puppet, Ruby, OS and module versions/distributions

Puppet:
Ruby:
Distribution:
Module version:

How to reproduce (e.g Puppet code you use)
I'm currently unable to update to the most recent version of puppetlabs-registry because of dependency conflicts introduced by this module. These dependencies are updated in the latest RC version of this module, but it hasn't been released to the Forge yet.
What are you seeing
What behaviour did you expect instead
Output log
Any additional information you'd like to impart

Hi,
based on a discussion in https://groups.io/g/voxpupuli/message/449 we decided to archive this repository. I'm going to close all issues and PRs. If you're interested in maintaining the module, please respond to our mailinglist.


text:
06 auto var target

$@ 書いた

依存、 $@、$^ で三部作に。


text:
feat: support extraction of MJPEG video frames

This commit adds support for extracting MJPEG files out of
.vraw-files.
The generated files are playable in ffplay, but not VLC. This might
be because MJPEG is not a standardized format and therefore not
documented where it is easily found.
To do something interesting with the extracting MJPEG files it needs
to be converted with for instance ffmpeg.

Hello Voysys! We needed to extract some MJPEG video data from our cameras (which stream in MJPEG), so I thought I'd add some support in vraw_convert. I've added a start here and am happy to change it according to your requests, or just hand it over to you directly if you want to take it and adapt it.
One thing that I looked into, but did not invest enough time in, is to convert the MJPEG video data using ffmpeg crates and then generate some standard-conforming MP4 file. The crates I found seemed to assume a lot of domain knowledge about ffmpeg libraries, which I do not have.


text:
resampling code

Excellent work - if i wanted to change the resampling techniques from NN to interpolation, please advise where is this part of the code? Also, have you trained on the PanNuke dataset? If so are any changes are needed? Thank-you.

Thank you! I assume that you are referring to upsampling here. You can alternatively upsample with interpolation by using:
tf.image.resize_images(
    images,
    size,
    method=ResizeMethod.BILINEAR,
    align_corners=False
)

Here, you can also use method=ResizeMethod.BICUBIC.
Yes, we did train on the PanNuke dataset. For this we changes the input size to 256x256, in line with the size of the pre-extracted patches. If you are simply reporting a model on the PanNuke dataset (patches of size 256x256), then you can use same padding in the decoder and similarly output a patch of size 256x256. The valid convolution is only necessary when using a sliding window approach to prevent border artefacts.
We will be releasing a repository of a HoVer-Net model trained on PanNuke that used to process ROIs and WSIs very soon. Please let me know if this is of interest.

Thanks a lot and okay sure, i would be interested in seeing this!


text:
HTML

#HTML
##User Story
As a bootcamp student
I want the prework notes to be structured on a webpage
so that I can easily find and read information
##Acceptance Criteria
GIVEN a Prework Study Guide website
WHEN I visit the website in my browser
THEN I see four boxes titled HTML, CSS, Git, and JavaScript with associated notes listed

Added HTML update


text:
Block edge 4.3.33

4.3.33 needs to be disabled:
2 clusters currently failing (14%),  0 gone ( 0%),and 12 successful (86%), out of 14 who attempted the update over 7d
Currently failing classification:
* Untriaged: 2

4.3.33 needs to be disabled:
12 clusters currently failing (29%),  8 gone (20%),and 19 successful (46%), out of 41 who attempted the update over 7d
Currently failing classification:
* API crashlooping: 1
* Logging issues: 1
* SDN issue: 1
* Single master: 1
* Slow etcd: 2
* UPI router degraded: 1
* Untriaged: 8

4.3.33 needs to be disabled:
15 clusters currently failing (25%), 13 gone (22%),and 30 successful (51%), out of 59 who attempted the update over 7d
Currently failing classification:
* Logging issues: 1
* SDN issue: 1
* Single master: 2
* Slow etcd: 3
* UPI router degraded: 1
* Untriaged: 11

repo: vrutkovs/cincinnati-graph-data


text:
Is json supported? Laravel emails are not translated L5.8

For example Reset Password Email is not translated.
In Laravel 5.8 we have lines like this:
->subject(Lang::getFromJson('Reset Password Notification'))
And it return always Reset Password Notification.
But when i remove getFromJson from library and original method is used, then translation works properly.

which version you pick to run with laravel 5.8?

"~2.6",

authors: mgralikowski victorsilent

repo: vsch/laravel-translation-manager


text:
No Icon for (.fprg) files.

There is a language that works on a similar principle of XML. The language is known as Flowgorithm. It has a separate icon for its file extension (.fprg). Will you add this icon to your extension?

Do you have a link to the icon or project?

Yes, here's a link to the icon of the file with extension .fprg
Hope it helps.
https://1drv.ms/u/s!Ar00rTB3hmIJjxLjEwTLfeGePq1m
On Sun, 1 Aug, 2021, 14:38 Roberto Huertas, @.***>
wrote:

Do you have a link to the icon or project?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/vscode-icons/vscode-icons/issues/2785#issuecomment-890481391,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUI5MV2T7QC2LJM7VCMXZILT2UFKHANCNFSM46EBHFDA
.

Tried to impliment this, the icon doesn't exist anymore.

Tried to impliment this, the icon doesn't exist anymore.

Ok, I'll attach it here directly.

authors: MRS73694 robertohuertasm sasial-dev

repo: vscode-icons/vscode-icons


text:
[Performance] Slim icon has too many details

Slim icon slows down tree-view scrolling
Even 2-3 icons cause perceptible lags. So when there are, say, 10 — it's unbearable
Please, consider replacing of it
Thanks :pray:

Indeed. Thanks for bringing this in our attention. We'll replace it asap.

authors: JimiC caudatecoder


text:
Duplicated insertion while typing korean

It seems something wrong in typing korean after update 0.0.89.

But when I downgraded vscode-neovim 0.0.88, it doesn't happen and everything works fine.

Version: 1.69.2 (user setup)
Commit: 3b889b090b5ad5793f524b5d1d39fda662b96a2a
Date: 2022-07-18T16:12:52.460Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: 10.0.139.17-electron.0
OS: Windows_NT x64 10.0.22000

This might be caused by #900. @BTBMan could you look into this? Thanks!

@zuhanit Could you tell me what input method that you are using to reproduce? And It's that happend after type space key? I'm sorry I'm not a korean user and I tried to reproduce with my only Mac, but It didn't happend, But I will try my best to fix that.

I'm using default IME of Windows 11, from Microsoft. It happens after type space key, but can happen like below:

Exit inserting mode

I pressed ㄷ+ㅐ+ㅎ+ㅏ+ㄴ+ㅁ+ㅣ+ㄴ and type ESC for exit.

Just type little long word

I pressed ㄷ+ㅐ+ㅎ+ㅏ+ㄴ+ㅁ+ㅣ+ㄴ+ㄱ+ㅜ+ㄱ and type ㅇ(not o, 0).
Type space key always produce characters before cursor.

Please tell me if you need any information for solve this 👀

This also occurs in Japanese.
Version: 1.70.0
Commit: da76f93349a72022ca4670c1b84860304616aaa2
Date: 2022-08-04T04:38:48.541Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: 10.0.139.17-electron.0
OS: Linux x64 5.15.0-43-generic
Ubuntu 22.04
NeoVim v0.5.0-dev+1041-g1607dd071

I typed the following
i[ENABLE JAPANESE INPUT]aiueo[SPACE]aiueo[ENTER]

It seems to occur when the Japanese conversion is started with the space key and then the next input is started without being confirmed with the enter key.

I'm facing same problem too (in Japanese).
Version: 1.70.0 (user setup)
Commit: da76f93349a72022ca4670c1b84860304616aaa2
Date: 2022-08-04T04:38:16.462Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: 10.0.139.17-electron.0
OS: Windows_NT x64 10.0.19043
Using with NeoVim on WSL2 (Ubuntu 20.04)

0.0.89 has this bug. Use 0.0.88 until new release containing the revert

authors: 74th BTBMan snaka theol0403 vlwkaos zuhanit

repo: vscode-neovim/vscode-neovim


text:
v1.0.3. backup broken

Describe the bug
if a backup takes longer as some seconds, it get an error. With v1.0.2. everything works fine.
Logs
I0312 12:32:36.453781       1 logging.go:180] wrestic/backup/progress "level"=0 "msg"="progress of backup"  "percentage"="0.00%"
I0312 12:32:36.454783       1 logging.go:180] wrestic/backup/progress "level"=0 "msg"="progress of backup"  "percentage"="0.00%"
E0312 12:32:36.455783       1 logging.go:156] wrestic/backup/progress "msg"="can't decode restic json output" "error"="invalid character 'L' looking for beginning of value"  "string"="Load(\u003cdata/4193b3e209\u003e, 0, 0) returned error, retrying after 391.517075ms: Access Denied."
E0312 12:32:36.458755       1 main.go:185] wrestic "msg"="backup job failed" "error"="cmd.Wait() err: -1"  ```

Environment

Image Version: e.g. v1.0.3
k3s version v1.20.4+k3s1 (838a906a)
go version go1.15.8

Hi @gi8lino
The error Load(\u003cdata/4193b3e209\u003e, 0, 0) returned error, retrying after 391.517075ms: Access Denied. indicates that restic can't access the backup bucket.
Does the exact same backup work with 1.0.2?

Hi @Kidswiss
Yes, with v1.0.2 everything worked fine!

Can you try to run the backup with another wrestic version? e.g. 0.1.9 or 0.2.0 and see if it still happens?

I tried it with wrestic v0.2.0 and got the same error:
I0312 13:11:15.721907       1 utils.go:81] wrestic/backup/progress "level"=0 "msg"="progress of backup"  "percentage"="0.00%"
E0312 13:11:15.723861       1 utils.go:69] wrestic/backup/progress "msg"="can't decode restic json output" "error"="invalid character 'L' looking for beginning of value"  "string"="Load(\u003cdata/4193b3e209\u003e, 0, 0) returned error, retrying after 391.517075ms: Copy: Access Denied."
E0312 13:11:15.739853       1 main.go:182] wrestic "msg"="backup job failed" "error"="cmd.Wait() err: signal: broken pipe"

@gi8lino
Can you share a Backup definition which triggers this behaviour on your side?
With that I would like to learn whether the Backup just takes a long time because it is big in size, or it because a BackupCommand is taking a long time, or what the reason is, so that I can model this locally.

I think this has nothing to do with how long the command runs.
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: annotated-subject-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: subject
  template:
    metadata:
      labels:
        app: subject
      annotations:
        k8up.syn.tools/backup: 'true'
        k8up.syn.tools/backupcommand: 'echo Hello' # This command runs almost instantly
        k8up.syn.tools/file-extension: '.txt'
    spec:
      containers:
      - name: subject-container
        image: quay.io/prometheus/busybox:latest
        imagePullPolicy: IfNotPresent
        args:
        - sh
        - -c
        - |
          printf '$BACKUP_FILE_CONTENT' | tee '/data/$BACKUP_FILE_NAME' && \
          ls -la /data && \
          echo "test file '/data/$BACKUP_FILE_NAME' written, sleeping now" && \
          sleep infinity
        securityContext:
          runAsUser: $ID
        volumeMounts:
        - name: volume
          mountPath: /data
      volumes:
      - name: volume
        persistentVolumeClaim:
          claimName: subject-pvc

This simple deployment (based on our E2E-tests) fails with the same error.

@cimnine Your example uses a prebackup command, does it also fail for backups from PVCs?

@cimnine
do you mean this:
apiVersion: backup.appuio.ch/v1alpha1
kind: Backup
metadata:
  name: test-backup-7r8bx
  namespace: test
spec:
  backend:
    s3:
      bucket: test

I think the backup size doesn't matter. The error occurs even it the pvc is only 4.0K

@gi8lino Do make use of PreBackupPods or the k8up.syn.tools/backupcommand annotation on Pods?

@cimnine
The PreBackupPods I use only for the cluster-backup (single node k3s).
For SQL'ish stuff I use the annotation k8up.syn.tools/backupcommand on the deployment.
For PVC's (all are RWO) I set the annotation k8up.syn.tools/backup: "true".

@gi8lino so far I was not able to replicate the exact same issue. I've found another problem (https://github.com/vshn/wrestic/issues/78), but that isn't actually the same problem.
Would you mind doing two things for me?

First, can you tell me what kind of S3 implementation you are using? I.e. is it minio, ceph, AWS? And – if it's self-hosted – what version you're using?
Second, could you try running K8up 1.0.3 with wrestic 0.1.9?
The reason I'm asking is that in version 0.2.x of wrestic, the underlying restic binary was updated, and as far as I understood it contains quite some changes to the S3-related code. Therefore I would like to rule out that this triggers some kind of incompatibility with your S3.

@cimnine
I have minio installed thru helm:
chart version: 8.0.10
VERSION: 2021-02-14T04:01:33Z
PLATFORM: Host: minio-74557b8485-s7x7v | OS: linux | Arch: amd64
RUNTIME: Version: go1.15.7 | CPUs: 4
with k8up 1.0.3 and wrestic 0.1.9 k8up it works fine.
It's a self-hosted single node k3s server.

Hi!
I wanted to report the same error on my infrastructure.
Minio, simple docker install: 2021-03-12T00:00:47Z on a baremetal host with the storage attached via NFS.
k8up is version k8up-1.0.3 installed via helm, on a K3s  3 node cluster.

I have updated my minio to the latest version 2021-03-17T02:33:02Z and the backup resumed.
What I did not check:

I didn't check the logs on the minio server side
I didn't restart minio to see if this might've been the cause. Maybe @gi8lino you can check?

What also seemed weird to me that it was about half of the namespaces that were failing. The other half was doing just fine continuing the backups on schedule.

@cimnine
I restarted the minio deployment and tried to do some backups.
One PVC (~17MB) worked fine.
For the other PVC (1.3 GB, 3.6 GB & 356 GB) I get this kind of errors:
I0325 10:42:11.373640       1 logging.go:180] wrestic/backup/progress "level"=0 "msg"="progress of backup"  "percentage"="35.26%"
E0325 10:42:11.373800       1 logging.go:156] wrestic/backup/progress "msg"="can't decode restic json output" "error"="unexpected end of JSON input"  "string"="{\"message_type\":\"status\",\"percent_done\":0.355037"
E0325 10:42:11.375847       1 main.go:185] wrestic "msg"="backup job failed" "error"="cmd.Wait() err: -1"

@gi8lino I get this error from time to time, it seems to be able to recover though after a few attempts.

I've created an issue in https://github.com/vshn/wrestic/issues/79 for the percentage problem.
While doing so, I've found the wrestic issue https://github.com/vshn/wrestic/issues/76. This seems to describe the same issue as @gi8lino reports, doesn't it?

I'd suggest to collect output parsing issues in vshn/wrestic#79. We should also not abort a backup on a single output line that can't be parsed.
I don't think it's related to  vshn/wrestic#76 though. Because restic won't exit in those cases. But here it returns as indicated by:
E0325 10:42:11.375847       1 main.go:185] wrestic "msg"="backup job failed" "error"="cmd.Wait() err: -1"

We decided that we first want to improve the part in wrestic that parses the log messages from restic. Because currently we're not sure whether the backup fails because the parsing of the output failes, or whether the underlying restic failed because of some reason.

I tested a bit how Minio behaves.
First I uploaded something to a local Minio instance and then removed the permissions of the file:
10:53:02 in baas/minio/test
➜ ll
total 664
drwxr-xr-x  3 simonbeck  staff      96 Mar 30 10:52 .
drwxr-xr-x@ 5 simonbeck  staff     160 Mar 30 10:52 ..
----------  1 simonbeck  staff  338373 Mar 30 10:52 Clipboard - March 29, 2021 1_18 PM.png

Then I tried to download the file, minio showed these errors in the log:
API: SYSTEM()
Time: 10:53:12 CEST 03/30/2021
DeploymentID: 0366f684-76ec-4f28-8a40-aa47d38e5a69
Error: Prefix access is denied: test/Clipboard - March 29, 2021 1_18 PM.png (cmd.PrefixAccessDenied)
       3: cmd/web-handlers.go:2442:cmd.toWebAPIError()
       2: cmd/web-handlers.go:2452:cmd.writeWebErrorResponse()
       1: cmd/web-handlers.go:1471:cmd.(*webAPIHandlers).Download()

Also it returned an access denied to my browser:

So this is not necessarily an issue of wrestic/restic itself but could indicate something wrong with the running Minio instance.

fyi
I updated k8up with helm to v1.0.4. Now it works:
I0330 23:00:42.314151       1 backup.go:54] wrestic/backup "level"=0 "msg"="starting backup for folder"  "foldername"="test-data"
I0330 23:00:42.314175       1 command.go:82] wrestic/backup/command "level"=0 "msg"="Defining RESTIC_PROGRESS_FPS"  "frequency"=0.016666666666666666
I0330 23:00:44.546191       1 logging.go:168] wrestic/backup/progress "level"=0 "msg"="progress of backup"  "percentage"="0.00%"
I0330 23:00:45.636605       1 logging.go:160] wrestic/backup/progress "level"=0 "msg"="backup finished"  "changed files"=9 "errors"=0 "new files"=0
I0330 23:00:45.636744       1 logging.go:161] wrestic/backup/progress "level"=0 "msg"="stats"  "bytes added"=6922430 "bytes processed"=143459545 "time"=2.782663316
I0330 23:00:45.636909       1 handler.go:44] wrestic/statsHandler/promStats "level"=0 "msg"="sending prometheus stats"  "url"="http://prometheus-pushgateway.monitoring.svc.cluster.local:9091"

To test it I've created a backup of a PVC and a DB.
exemplary:
kubectl apply -f - << EOF
apiVersion: backup.appuio.ch/v1alpha1
kind: Backup
metadata:
  name: manual-backup-2021-03-31-091709
  namespace: test
spec:
  backend:
    s3:
      bucket: test
EOF

I also tried to restore the DB-dump with the restic CLI. First, it didn't work, but after restarting minio it worked!

Great to hear that your problems have been solved!
Have you also tested a longer running backup?

That's great!
So to summarize:

We found some issues with the restic output parsing that were fixed

a buffer that gets filled up and leading to crashes for longer running backups
if a log line couldn't be parsed it cancelled the backup

The access denied errors were likely caused by some hiccups with Minio as restarts resolved them

@gi8lino I think we can close here?

@Kidswiss
All my backups did run tonight without an error, so yes, you can close it.
Thank you!

authors: Kidswiss cimnine gi8lino schemen


text:
Make certificate path length configurable

The purpose of this PR is to make the certificate path length configurable:

for the Root CA stored in KV, minimum should be 1
for the device identity and edge CA certificates obtained from the EST server, the path length should be 0.

The PR also contains minor code refactoring and renaming.

Thanks @Ioana37! Really great improvements!

repo: vslepakov/keyvault-ca


text:
[BUG] Plugin CTRL +A , CTRL+., CTRL +SHIFT. works in Obsidian help vault but not with my note vault

Describe the bug
Plugin CTRL +A , CTRL+., CTRL +SHIFT. works in Obsidian help vault but not with my note vault
To Reproduce
Open Obsidian help vault.
Install Outliner Plugin and turn on.
Make a list.

A

B

C

Placing cursor around any item, CTRL+A will  work
Doing the same thing in  my Notes Vault lselect whole note instead of line or whole outline.
CTRL . and CTR+SHIFT+. work in Obsidian Help Vault but not in my notes vaules.
I disabled all other plugin when testing.
Expected behavior
Shortcuts will have consistent behaviour and will not be buggy
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS] Linux OS
Obsidian Version: [e.g. 22] 0.11.9

Additional context
Add any other context about the problem here.

Tomorrow I will try to check output of the debug console

Is it possible that your lists prefixed with * sign, not - sign?
Currently - is only supported.

Yes, it was the case! Could you make it more explicit in the README?

@danieltomasz It's better to support spaces :)
Released in https://github.com/vslinko/obsidian-outliner/releases/tag/1.0.10

The speed of development astonishes me! Thanks for your hard work!

authors: danieltomasz vslinko

repo: vslinko/obsidian-outliner


text:
[BUG] Unable to delete bullet marker in first item of list

Describe the bug
Cannot erase the bullet point from the first item of the list to convert it into normal text.
To Reproduce
Steps to reproduce the behavior:

Create a list with a minimum of two items.
Go to the first character of the first item.
Press backspace to remove the bullet mark.

Expected behavior
The bullet mark should be removed converting the item to normal text (and the next item becomes the first item).
Screenshots
https://user-images.githubusercontent.com/29776685/114502492-7c7c5200-9c49-11eb-8be3-6d5624b0b189.mov
Desktop (please complete the following information):

OS: macOS Catalina 10.15.7
Obsidian Version: 0.11.13

The behaviour is happening when the list is at the top of the file
The behaviour is happening in vanilla Obsidian too with the plugin turned off too.

The behavior is happening when the list is at the top of the file
The behavior is happening in vanilla Obsidian with the plugin turned off too.

The behavior happens even if the list is not at the top of the file.
Not true from my experiment:

I created a new empty vault with all the default settings and no plugins - the behavior does not happen. The correct expected behavior happens.
I added the Outliner plugin and the behavior happens.
I disable the Outliner plugin and reopen the file and it is back to the behavior not happening (expected behavior happens). Reopening the file seems to be essential to bring back the vanilla Obsidian for some reason.

@kritika-gupta Thank you for your contribution!
I did it on purpose because I couldn't think of a better option.
Outliner tries not to break the structure of the list, and this is important.
I can create a specific rule that behaves like you suggested, but only for cases where the element is the first in the list and has no children.
But it worries me that this is not intuitive behavior.

@kritika-gupta Thank you for your contribution!
I did it on purpose because I couldn't think of a better option.
Outliner tries not to break the structure of the list, and this is important.
I can create a specific rule that behaves like you suggested, but only for cases where the element is the first in the list and has no children.
But it worries me that this is not intuitive behavior.

I agree, it makes sense only when the element has no children.
I came across this issue when I wanted to simply delete an item from the list and that item happened to be the first item on the list. The behavior occurred when I started to erase from the end of the item (which is how someone would probably delete an item from a list, I should have shown that in my screenshot, my bad).

Fixed in https://github.com/vslinko/obsidian-outliner/releases/tag/1.1.3

Fixed in https://github.com/vslinko/obsidian-outliner/releases/tag/1.1.3

Thanks. Your development speed is amazing. Great work on such a useful plugin!

Not for me. I recently (re)installed Obsidian and Outliner, and the first bullet point in any list cannot be removed.

@mathewlowry Yes, you cannot remove bullet markers when a the list item contains sub-items, because this will break the structure of the list. Please try removing the sub-items first.

press ⌘ ⇧ K to delete the entire line @mathewlowry This will screw up the entire list but it will get you what you want.

authors: danieltomasz kritika-gupta mariomui mathewlowry vslinko


text:
Add CrownControl

Project URL
https://github.com/huri000/CrownControl
Category
Scroll View I guess (couldn't find any better category)
Description
Inspired by Apple Watch Digital Crown, CrownControl is a tiny accessory view that enables scrolling through scrollable content possible without lifting your thumb.
Why it should be included to awesome-ios (mandatory)
It is an original (haven't seen any similar library) and experimental Digital Crown implemented for iOS, and a really cool addition to the awesome library IMHO.
(I've added unit-tests as required).
Checklist

[x] Only one project/change is in this pull request
[x] Has unit tests, integration tests or UI tests
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 9 / tvOS 10 or later
[x] Supports Swift 4 or later
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

          1 Warning

:warning:
Found 7 link issues, a project collaborator will take care of these, thanks :)

Link issues by awesome_bot

Line
Status
Link

206
403
https://www.udemy.com/arkit-beginner-to-professional/?couponCode=CREATORS

1497
301
https://github.com/mobilefirstinc/MFCard redirects tohttps://github.com/RC7770/MFCard

1516
301
https://github.com/IvanVorobei/RequestPermission redirects tohttps://github.com/IvanVorobei/SPPermission

1915
404
https://github.com/Cleveroad/CRParticleEffect

1959
404
https://github.com/Cleveroad/CRRulerControl

1967
404
https://github.com/Cleveroad/CRPageViewController

2273
404
https://github.com/Cleveroad/CRNetworkButton

  Generated by :no_entry_sign: Danger

Thanks for contributing! 🎉

authors: danger-awesome-ios huri000 lfarah

repo: vsouza/awesome-ios


text:
Add glide engine

Project URL
http://github.com/cocoatoucher/Glide
Category
Games
Description

glide is a SpriteKit and GameplayKit based engine for making 2d games, and I'm adding it under Games category within this repo's readme file.
Why it should be included to awesome-ios (mandatory)
glide is a well documented engine which can help interested devs learn to build games. Also, glide needs more collaborators.
Checklist

[x] Has 50 Github stargazers or more
[x] Only one project/change is in this pull request
[x] Isn't an archived project
[x] Has more than one contributor
[x] Has unit tests, integration tests or UI tests
[x] Addition in chronological order (bottom of category)
[x] Supports iOS 9 / tvOS 10 or later
[x] Supports Swift 4 or later
[ ] Has a commit from less than 2 years ago
[x] Has a clear README in English

          1 Warning

:warning:
Found 10 link issues, a project collaborator will take care of these, thanks :)

Link issues by awesome_bot

Line
Status
Link

371
301
https://github.com/YR/Cachyr redirects tohttps://github.com/nrkno/yr-cachyr

745
301
http://github.com/cocoatoucher/Glide redirects tohttps://github.com/cocoatoucher/Glide

1145
301
https://github.com/Inspirato/SwiftPhotoGallery redirects tohttps://github.com/justinvallely/SwiftPhotoGallery

1179
301
https://www.photoeditorsdk.com redirects tohttps://photoeditorsdk.com/

1386
301
https://www.airship.com/products/mobile-app-engagement redirects tohttps://www.airship.com/platform/channels/mobile-app/

1645
301
https://github.com/twitter/twitter-kit-ios redirects tohttps://github.com/twitter-archive/twitter-kit-ios

1840
301
https://github.com/dzenbot/Iconic redirects tohttps://github.com/home-assistant/Iconic

2414
301
https://github.com/jogendra/AnimatedMaskLabel redirects tohttps://github.com/jogendra/LoadingShimmer

3321
500
http://www.swiftplayhouse.com/

3331
301
https://itunes.apple.com/us/book/swift-programming-language/id881256329?mt=11 redirects tohttps://books.apple.com/us/book/swift-programming-language/id881256329

  Generated by :no_entry_sign: Danger

authors: cocoatoucher danger-awesome-ios


text:
ImportError: cannot import name cfg when running a training

Thanx for ur excellent job!
I got a issue when i tried to run a training.
Please help me if u r willing to. @gaochen315
I tired to run: python tools/Train_ResNet_HICO.py --num_iteration 1800000  but got this information:
Traceback (most recent call last):
File "tools/Train_ResNet_HICO.py", line 21, in
from models.train_Solver_HICO import train_net
File "/home/ydm/project-HOI/iCAN/tools/../lib/models/train_Solver_HICO.py", line 12, in
from ult.ult import Get_Next_Instance_HO_Neg_HICO
File "/home/ydm/project-HOI/iCAN/tools/../lib/ult/ult.py", line 22, in
from config import cfg
ImportError: cannot import name cfg
If you suspect this is an IPython bug, please report it at:
https://github.com/ipython/ipython/issues
or send an email to the mailing list at ipython-dev@python.org
You can print a more detailed traceback right now with "%tb", or use "%debug"
to interactively debug it.
Extra-detailed tracebacks for bug-reporting purposes can be enabled via:
%config Application.verbose_crash=True
I set my environment as u said and i tried tensorflow 1.1 and 1.2
How can i fix it?
Thanx again.

you can see from the error that the script utl.py is not able to detect the module config that is in the same directory, an easy fix would be to change line 22 in https://github.com/vt-vl-lab/iCAN/blob/master/lib/ult/ult.py  to  from ult.config import cfg . that should remove this error @BestSongEver

@unbiasedmodeler
Thanx for your reply. It works.

authors: BestSongEver unbiasedmodeler

repo: vt-vl-lab/iCAN


text:
from future import divisions

when running the code, it reports that:
 File "tools/Train_ResNet_VCOCO.py", line 20, in <module>
    from ult.config import cfg
SyntaxError: future feature divisions is not defined (config.py, line 8)

And I update the from __future__ import divisions of config.py with:
from __future__ import division
and solve this error. it seems a typo error of lib/ult/config.py.

Good catch!
It is fixed. Thanks.


text:
Fix several bugs:

lws::account height update should only go up.
Webhook confirmations can start after first new block
Webhook confirmations could face a rescan

Found these issues while digging deeper in the remote scanning code (although not related to that code). This will get merged relatively soon as these bugs need to be back-ported to release branch.

Added some more tests, and fixed another issue within the DB scan height (it previously wasn't an issue until changes in the lws::account object).

repo: vtnerd/monero-lws


text:
Missing features

Hello, is it possible to add these features?

clear button to remove all values in v-model. It's not very user friendly to remove 200 tags manually
close prop, so that I can close options list when I pick value from multiple/tags mode
limit options list to given length

+1 for No. 2
You can help yourself with @select="closeOptionLists" Event and
methods: {
closeOptionLists: function() {
document.querySelectorAll('.multiselect-input').forEach(function (el) {
el.blur();
});
}
}

Added all 2 in 1.3.1 @MartinKravec (the third should already exist).

Now it should automatically appear over the caret when multiple or tags mode has any selected options
Check out now API docs section
Isn't limit in props section what you're looking for?

I think also a interesting feature would be loading more options on scrolling.
I have a API that is using paging so would be dope if i could load more options of the other pages by scrolling the list till the end.

I think it would be great if you could group the options together
Group-Title 1

Option 1
Option 2
Group-Title 2
Option 3
Option 4

Closing this because we have #24 for groups. Feel free to create a new one with scroll-loading.

authors: MartinKravec adamberecz c4y luxterful

repo: vueform/multiselect


text:
Display values not updating properly when updating options and values with custom "value-prop"

Version

Vue version: 3

Description
When updating values and options, while using a custom "value-prop", the display doesn't update properly and displays the wrong informations. But when you open the multiselect dropdown, the correct values available in the dropdown but still not updated in the main multiselect input.
It seems like it is still using the old options list instead of the new one.
Demo
https://jsfiddle.net/edw13Lg8/
Please use our JSFiddle template to reproduce the bug. Issues without working reproduction might be ignored.

In the meantime, A quick workaround is to force the multiselect's update by adding a :key attribute bound to the options :
<VueFormMultiselect
 :key="options"
 :options="options"
 ...
>


text:
Allow ability to set default compilerOptions when compiling templates in the browser.

What problem does this feature solve?
I need to preserve whitespace when compiling templates in the browser. I have to manually set the compiler option everytime I call createApp.
What does the proposed API look like?
Unsure of the best api but it should be pretty simple.
Something like Vue.default.config.compilerOptions.whitespace = 'preserve'

I agree with your statement, but I dont think a framework should be influencing my design choices. What do you think about some kind callback or event handler to interact with the instance returned from createApp()?
This is my solution
window.Vue = Object.create(Vue);
Vue.createApp = function(...args){
  var app = this.__proto__.createApp(...args);
  app.config.compilerOptions.whitespace = 'preserve';
  return app;
}

I dont think a framework should be influencing my design choices

That's pretty much what a framework does: it sets a frame in which you can design as you please, but only within the boundaries set by the framework's APIs.
So yes, a framework will be influencing your design choices by its very nature.

Point taken.
I should have expressed my thoughts a bit different. In relation to this specific issue. Vue by default handles whitespace differently to browsers and there is no other way to change this other than coming up with a hacky work around.
On a separate note. Do you think my solution will cause any problems? Can you see any issues with it?

authors: LinusBorg ryanalbrecht

repo: vuejs/core


text:
fix: return the correct  name when stubbing a script setup component

When stubbing a component using the <script setup> syntax test-utils can't return its name correctly, so it skips the stub and the stub fails.There's an issue  that describes the problem.
This is because getComponentName() function doesn't return its __name property.

OK, I'll do it later

@cexbrayat If I want this test case to run expectedly I have to install unplugin-vue-vomponents and add it to Vitest configration file like this:

@cexbrayat If I want the test case to run expectedly I have to install unplugin-vue-components and add it to Vitest configration file like this:

Is it OK?

I guess we can, if that solves a specific issue for this plugin.
Is it possible to limit the application of this plugin only to the test you are adding?

I think I can't. As long as a component is imported, the plugin will take effect, so I can't limit the scope of this plugin to a test, but only control the target it transforms. So I specified that it can only transform the AutoImportScriptSetup component

Ok, it should be good enough. Push your test and we'll take a look 👍

You need to run pnpm i again to update the lockfile, and we should be ready to merge

Ok, sorry I forgot

Awesome, thanks @joeyhuang0235

repo: vuejs/test-utils