From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14087 invoked from network); 16 Oct 2022 16:02:09 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 16 Oct 2022 16:02:09 -0000 Received: (qmail 3063 invoked by uid 89); 16 Oct 2022 16:02:34 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 3050 invoked from network); 16 Oct 2022 16:02:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antonovs.family; s=20200215; t=1665936118; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=HmnhtS9rOYZ6gOGah5vczjpDSzoal1GB2ZG9/a2jCWg=; b=ZGHk7BERzQu/rnMERVCezoKiS0znpJZ3m/zbIiFEj8kOxU8rAeHSVKVvsSzU0Hv4tXkJmg Kxi3s8g/xuJU/HuYI+FWQxhX0KgqaJBCPleGhDYtlHYXADTcj1zAmpNHe43zFJcCTz4HLA YBDSsjVqmBM9Dpk07A0gHjw2TW0IjBU= Date: Sun, 16 Oct 2022 09:02:28 -0700 From: Ihor Antonov To: supervision@list.skarnet.org Cc: supervision@list.skarnet.org Subject: Re: s6-rc user experience question Message-ID: <20221016160228.bypf5lyje6wfvbnc@localhost> References: <20221016062822.ohngiq54sr2qhti3@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On 2022-10-16 10:39, Laurent Bercot wrote: > ... > I agree it's confusing, and one of the reasons (but not the main one) > why s6-rc needs a redesign: you currently get access to all the internal > workings of the service manager, even when they're not relevant to you, > which is not ideal. Perhaps I can offer a few suggestions how to improve usability: - combine compile + svscan on empty dir + init steps into one, like `s6-rc init source_dir` and it does those steps under the hood. - maybe instead of creating file based database take on sqlite as a dependency and keep compiled + live state there? sqlite is ubiquitous and very light weight. It can save the trouble of inventing our own compiled database formats and folder strucutres > ... > Having this duplication is the only way of ensuring that your > modifications do not change the snapshots you take when compiling and > do not impact the current machine state, and also that the operation > of your current services does not impact the set of services you're > booting on (which could lead to failed boots). > > Other service managers do not make the distinction between the > user working set, the system working set, and immutable snapshots; that > is a big issue I have with them, because it's difficult to make them > safe. This makes sense. Popular cloud infrastructure management tool Terraform does this too. It does 3-way diff on each operation, comparing desired state of the system, currently observed state, and state recorded after finishing previous operation. This way it knows when things need to be added/removed/modified. This cannot be done reliably with 2-way diff approach, and tools like ansible fall short here. Removal of a resource from ansible playbook simply makes ansible forget about it, where terraform detects the absense and undersands that previously managed resource needs to be de-provisioned. What you describe sounds very similar, but applied to the state of service dependency tree. > Hope this helps, It does, thank you. What are your plans / thoughts on s6-rc redesign? Ihor