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 25CEC6BCB1 for ; Thu, 18 Mar 2021 12:13:36 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 10962185AC for ; Thu, 18 Mar 2021 12:13:06 +0100 (CET) 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 7A8281859E for ; Thu, 18 Mar 2021 12:13:05 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 4B1184582E for ; Thu, 18 Mar 2021 12:13:05 +0100 (CET) Message-ID: <4ec0219a-4465-be3d-bb61-9e7e1e8c1171@proxmox.com> Date: Thu, 18 Mar 2021 12:13:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:87.0) Gecko/20100101 Thunderbird/87.0 Content-Language: en-US To: Dominik Csapak , Proxmox Backup Server development discussion References: <20210316115623.9368-1-d.csapak@proxmox.com> <20210316115623.9368-2-d.csapak@proxmox.com> <611140b4-dd43-2ecd-e03a-d7d93db979de@proxmox.com> <870f2fff-5bce-14ea-23d4-85c9106ab326@proxmox.com> From: Thomas Lamprecht In-Reply-To: <870f2fff-5bce-14ea-23d4-85c9106ab326@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.046 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.001 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: [pbs-devel] [PATCH proxmox-backup 2/3] server/email_notifications: do not panic on template registration X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 11:13:36 -0000 On 18.03.21 11:31, Dominik Csapak wrote: > On 3/18/21 11:21, Thomas Lamprecht wrote: >> On 18.03.21 10:57, Dominik Csapak wrote: >>> On 3/17/21 20:38, Thomas Lamprecht wrote: >>>> On 16.03.21 12:56, Dominik Csapak wrote: >>>>> instead print an error and continue, the rendering functions will error >>>>> out if one of the templates could not be registered >>>>> >>>>> if we `.unwrap()` here, it can lead to problems if the templates are >>>>> not correct, i.e. we could panic while holding a lock, if something holds >>>>> a mutex while this is called for the first time >>>> >>>> how can they error? >>>> And any error (with or without this patch) would lead to emails notification not >>>> working anymore, some may seem this as quite fatal error if they do not get notified >>>> on erroneous jobs anymore? We may not be able to do much here, that's why above >>>> question about what the error source can be. >>> >>> they can error if they do not compile, e.g. they have syntax errors >>> while we should catch that during developement/reviewing, >>> if it does happen, it generates some weird behaviour >>> (for example panicing while holding a mutex) >> >> can't we just add a test for that instead, so that it is actually "compile checked" >> when building a package? >> >> Then such errors would be actually fixed before getting released, relying on > review/test tends to fail and let slip something trhough sooner or later. > > yes ofc, thats a good idea, nonetheless would i prefer to not panic in such a situation, especially if there are no real downsides I mean if those situation cannot happen in practice anymore I see no reason for band-aiding a theoretical problem... But if you really want, OK, but I'd prefer to only take it in with the testing in place; to avoid that such errors are now completely missed as overlooking a log message is easy. >>> also we may want to put the templates into files in the future >>> so that users can adapt it and we can more easily change >>> them (maybe localize them?) >>> >> >> would need a sane reload mechanism then though, and in any way the one we ship >> should be tested for basic validity on build. >> > > wouldn't it be enough to leave it like it is and document the > necessary daemon reload for use customized templates? reload isn't exactly cheap, and we want to avoid that whenever possible, that includes things like template reloads or certificates update (in the future). > > (i'd imagine a system like for pmg, where we have the > shipped templates separate from the ones the user > customizes) I'd wait for file templates until some are actually requested for a sensible use case..