From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 4B3F31FF0AF for ; Fri, 06 Nov 2026 14:25:18 +0100 (CET) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 0401E215E8; Fri, 06 Nov 2026 14:25:16 +0100 (CET) From: Kefu Chai To: m.koeppl@proxmox.com Subject: Re: [PATCH e2e-tests/test-tools 00/38] tests: add tests for guests, Ceph, PBS and cluster workflows Date: Fri, 6 Nov 2026 21:25:02 +0800 Message-ID: <20261106132502.276083-1-k.chai@proxmox.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20261104190345.2573464-1-m.koeppl@proxmox.com> References: <20261104190345.2573464-1-m.koeppl@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1793971507167 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.234 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) 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 Message-ID-Hash: NGVJTV2ZQTSO7FDRWGGH3IUWEZRPGOUN X-Message-ID-Hash: NGVJTV2ZQTSO7FDRWGGH3IUWEZRPGOUN X-MailFrom: k.chai@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi Michael, > [snip] > - Ceph: setting up a hyper-converged cluster with dedicated public and > cluster networks, containers and VMs on RBD storage (VMs with and > without krbd), a CephFS with a storage for backups, and replacing an > OSD. The old Ceph setup that was outdated anyway is replaced. > [snip] The recent aes256k migration got me thinking about upgrade coverage. What do you think about a small upgrade test as a follow-up? For Ceph, we could create a cluster on an older supported version, put some known data in a guest on RBD, then upgrade and check that the cluster is healthy and the guest can still read its data. Since these tests create the cluster after updating packages, that would give us a basic check of upgrading an existing setup. Would it be straightforward to do with the current framework?