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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id D2D8DBBE5C for ; Wed, 20 Dec 2023 13:24:47 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B8934C3BB for ; Wed, 20 Dec 2023 13:24:47 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (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 for ; Wed, 20 Dec 2023 13:24:46 +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 A59BF409A4 for ; Wed, 20 Dec 2023 13:24:45 +0100 (CET) Message-ID: <6796372e-2fd1-421b-b786-69733f37d33b@proxmox.com> Date: Wed, 20 Dec 2023 13:24:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Content-Language: en-GB To: Proxmox VE development discussion , Mira Limbeck References: <20231218142507.505335-1-m.sandoval@proxmox.com> <40082f8a-ce7c-4a8a-b5b8-16a2f8d4c826@proxmox.com> From: Thomas Lamprecht In-Reply-To: <40082f8a-ce7c-4a8a-b5b8-16a2f8d4c826@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.059 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH manager] ui: ceph installer: Run ceph/init if joining a cluster 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: Wed, 20 Dec 2023 12:24:47 -0000 On 20/12/2023 10:53, Mira Limbeck wrote: > On 12/19/23 18:09, Aaron Lauterer wrote: >> The commit message doesn't explain the actual issue that it is trying to >> solve. >> AFAICT we do not need the ceph.conf symlinked right away for normal PVE >> operations. If it is not present in /etc/ceph/ceph.conf, the RBD and >> CephFS connections will use the dedicated parameters to connect and >> authenticate against the Ceph cluster, which are all present in the >> /etc/pve/priv... directory. >> >> And even in a newly set up HCI PVE + Ceph cluster, the symlink for the >> Ceph config will only be created once you set up a Ceph service (MON, >> MGR, MDS, OSD) on that node. >> >> Even with a valid use case (see first line of my response), I am not >> sure if the UI is the right place, as a user can still run into the same >> situation if they use 'pveceph install' on the CLI without running >> 'pveceph init' afterwards. >> Therefore, if there is a reason to always have the symlink, wouldn't it >> be better to add it to the install routine to create the symlink if the >> /etc/pve/ceph.conf file is detected? > > > Yes, you're right. Since we call `pveceph install` even when installing > from the GUI, that should be the place to add it. > > We've had a few cases where Ceph commands could not be run on the newly > added host, even though Ceph was installed because of the missing symlink. > Usually on a hyper-converged I'd assume that Ceph commands can simply be > run without specifying a Ceph config, since that's how we set it up. But > for newly added nodes that's currently not the case. > > This also affects the system reports, since we don't pass the Ceph > config there at all for any of the Ceph commands. > FWIW, we could also create such links on cluster join if ceph.conf is present in the pmxcfs, as then client-operations would already work without running pveceph (server) install, e.g., on a cluster with both ceph server nodes and others, e.g., compute/guest focused, nodes. Not saying that this is the ultimate way to go, but should be IMO at least evaluated w.r.t pros/cons.