From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:470:142:3::10]:37456) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhZ2u-0006tL-MU for guix-patches@gnu.org; Sun, 30 Jun 2019 08:35:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hhZ2t-0002hp-BG for guix-patches@gnu.org; Sun, 30 Jun 2019 08:35:04 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:60163) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hhZ2t-0002hO-7L for guix-patches@gnu.org; Sun, 30 Jun 2019 08:35:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hhZ2t-0001g3-3B for guix-patches@gnu.org; Sun, 30 Jun 2019 08:35:03 -0400 Subject: [bug#36404] [PATCH 2/5] gnu: Add machine type for deployment specifications. Resent-Message-ID: References: <87o92ianbj.fsf@sdf.lonestar.org> <87imspj0ks.fsf_-_@sdf.lonestar.org> <87ef3dj0j9.fsf_-_@sdf.lonestar.org> <87a7e1j0hy.fsf_-_@sdf.lonestar.org> <87k1d4kra8.fsf@dustycloud.org> <877e93ewyj.fsf@sdf.lonestar.org> <8736jrvfcw.fsf@zancanaro.id.au> From: Christopher Lemmer Webber In-reply-to: <8736jrvfcw.fsf@zancanaro.id.au> Date: Sun, 30 Jun 2019 08:34:38 -0400 Message-ID: <87a7dzl09t.fsf@dustycloud.org> MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Carlo Zancanaro Cc: 36404@debbugs.gnu.org Carlo Zancanaro writes: > Hey Jakob/Chris, > > I can't comment on much of the deploy code, but I can help out with > some stuff about the Shepherd. > > On Sun, Jun 30 2019, Jakob L. Kreuze wrote: >>> I'm a bit unsure from the above code... I'm guessing one of two >>> things >>> is happening: >>> >>> - Either it's starting services that haven't been started yet, >>> but >>> leaving alone services that are running but which aren't >>> "new" >>> - Or it's restarting services that are currently running >>> >>> Which is it? And mind adding a comment explaining it? >> >> The former. I've intentionally avoided restarting services since >> 'guix >> system' warns that "many essential services cannot be meaningfully >> restarted." (which is why 'guix system reconfigure' spits out "To >> complete the upgrade, run 'herd restart SERVICE' to stop, upgrade, >> and >> restart each service that was not automatically restarted." (which >> AFAIK >> is always none of them)). > > There was discussion earlier this year around restarting services that > are already running during a reconfigure[1]. I wonder if this problem > is more worth solving if we're deploying to remote systems. I have a > few patches in that issue to implement service restarting, but I > didn't follow them up enough to get them into Guix. > > [1]: https://issues.guix.info/issue/33508 Wow! This seems highly desireable, especially if, as you pointed out in the issue, an update to nginx is pushed across the wire with a security update... in that case, we'd want to restart that, too. Jakob, do you mind checking out the issue above? I think it shouldn't block merging these patches but perhaps we should file an issue saying that when the shepherd issue is merged, changes should be made to guix deploy as well. What do you think? >>> By the way, is there anything about the dependency order in which >>> services might need to be restarted to be considered? I'm honestly >>> not >>> sure. >> >> I'm not sure either. Would any Shepherd hackers out there care to >> chime >> in? > > The Shepherd will start any necessary dependencies in an appropriate > order. > > Carlo Ok, good to know!