From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 1F4C262B20 for ; Fri, 18 Sep 2020 09:13:46 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 044E412FB0 for ; Fri, 18 Sep 2020 09:13:16 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id A1FB812FA3 for ; Fri, 18 Sep 2020 09:13:14 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 73A594540B for ; Fri, 18 Sep 2020 09:13:14 +0200 (CEST) Date: Fri, 18 Sep 2020 09:13:07 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox VE development discussion , Thomas Lamprecht References: <20200917111658.1358831-1-f.gruenbichler@proxmox.com> <27b2c399-41fb-6e0e-fa27-2fb05a31adf2@proxmox.com> In-Reply-To: <27b2c399-41fb-6e0e-fa27-2fb05a31adf2@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.15.0 (https://github.com/astroidmail/astroid) Message-Id: <1600412785.57pvbm8v64.astroid@nora.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.029 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH common] properly encode YAML via YAML::XS X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2020 07:13:46 -0000 On September 17, 2020 5:06 pm, Thomas Lamprecht wrote: > On 9/17/20 1:16 PM, Fabian Gr=C3=BCnbichler wrote: >> otherwise we get strange errors when formatting data that was originally >> JSON, and can thus contain JSON::true/JSON::false. >>=20 >> one example is the QMP query-blockstats command, which gets called (and >> the resulting values returned) by /nodes/NODE/qemu/VMID/status/current >>=20 >> Signed-off-by: Fabian Gr=C3=BCnbichler >> --- >>=20 >> Notes: >> alternatives include: >> - dropping --output-format yaml altogether >=20 > FWIW: I like yaml, but we do not have it yet in PBS. > It's at least not an option for the 6.x release. >=20 >> - manually recursively mapping JSON::true/false to some sensible val= ue before dumping >=20 > hmm, could do, not ideal, mostly because we then recurse everything > and the outputter does another time - feels not good. >=20 >> - outputting JSON instead of YAML, since the former is a subset of t= he latter (thanks Dominik ;)) >=20 > NAK, while technical true I see no point in doing that. yaml is used > over JSON for being more concise and having less syntax noise getting > in ones way when reading it. >=20 > Was this issued raised on the currently used module's upstream? > Maybe we/they could fix it there too, helping more than just our use > case. not raised, but given the docs/description I'd say chances are rather=20 slim: This module implements a subset of the YAML specification for use in reading and writing CPAN metadata files like META.yml and MYMETA.yml. I= t should not be used for any other general YAML parsing or generation task. it's based on/derived from YAML::Tiny, which states: It only supports a very basic subset of the full YAML specification. Usage is targeted at files like Perl's META.yml, for which a small and easily-embeddable module is extremely attractive. Features will only be added if they are human readable, and can be written in a few lines of code. Please don't be offended if your reques= t is refused. Someone has to draw the line, and for YAML::Tiny that someone is me. >=20 >=20 > That said, I have no real objection against using this XS binding of > libyaml-0-2. > btw. we get that already installed on ceph setups through the dependency > chain: ceph-mgr -> python3-yaml -> libyaml-0-2 install size is also very small (xs+lib are ~200kb), memory overhead=20 probably quite a bit more? we could load it only in the code-path where=20 we render yaml ;) =