From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@proxmox.com> 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 6B3B362936 for <pve-devel@lists.proxmox.com>; Thu, 17 Sep 2020 17:06:59 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 572CFEFAD for <pve-devel@lists.proxmox.com>; Thu, 17 Sep 2020 17:06:59 +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 25AD8EFA0 for <pve-devel@lists.proxmox.com>; Thu, 17 Sep 2020 17:06:58 +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 E3CF545420 for <pve-devel@lists.proxmox.com>; Thu, 17 Sep 2020 17:06:57 +0200 (CEST) To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>, =?UTF-8?Q?Fabian_Gr=c3=bcnbichler?= <f.gruenbichler@proxmox.com> References: <20200917111658.1358831-1-f.gruenbichler@proxmox.com> From: Thomas Lamprecht <t.lamprecht@proxmox.com> Message-ID: <27b2c399-41fb-6e0e-fa27-2fb05a31adf2@proxmox.com> Date: Thu, 17 Sep 2020 17:06:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:81.0) Gecko/20100101 Thunderbird/81.0 MIME-Version: 1.0 In-Reply-To: <20200917111658.1358831-1-f.gruenbichler@proxmox.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.166 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.062 Looks like a legit reply (A) 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 <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Thu, 17 Sep 2020 15:06:59 -0000 On 9/17/20 1:16 PM, Fabian Grünbichler wrote: > otherwise we get strange errors when formatting data that was originally > JSON, and can thus contain JSON::true/JSON::false. > > one example is the QMP query-blockstats command, which gets called (and > the resulting values returned) by /nodes/NODE/qemu/VMID/status/current > > Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com> > --- > > Notes: > alternatives include: > - dropping --output-format yaml altogether 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. > - manually recursively mapping JSON::true/false to some sensible value before dumping hmm, could do, not ideal, mostly because we then recurse everything and the outputter does another time - feels not good. > - outputting JSON instead of YAML, since the former is a subset of the latter (thanks Dominik ;)) 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. 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. 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