From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on atuin X-Spam-Level: X-Spam-Status: No, score=-1.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: from [127.0.1.1] (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id D2A10A9E0; Wed, 16 Oct 2019 23:15:58 +0000 (UTC) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by atuin.qyliss.net (Postfix) with ESMTPS id 2BAFAA9DA for ; Wed, 16 Oct 2019 23:15:56 +0000 (UTC) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 179742A9; Wed, 16 Oct 2019 19:15:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 16 Oct 2019 19:15:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alyssa.is; h= from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; s=fm1; bh=3vLBRMFRtqrdhjG6JcQxsh8170 aOf1SzHZJMYZeZ3HA=; b=VvTuVywyLHOt/0aCWsx/LibSiyV3zK7y2OasJodAtr Ecd75QI0h3ZHKD+O+fEXQAuGO5ZiCg7vbo0++6wQSkw/7yyZyH0dbnk3yklELh5v OoWT3ytTQrMdTj2siRNzobAexuvmJeSUHUnj8yLN93MDK2aICR439HW9kSroC9wE VaJbIzzxdDWTgOc8HNvmUHNVWCFu83Inhr95q8pnPy+NyoBgL3V7Pl16OVpOaxKv Cqo/xVkogwgsoRWZQoLkXp0eSxOYyJTFRAV6/nPsQiCerYDmmEFfcVz3N5KQdYh6 ibO4D0juKnVxL2PqrdK7eE91hiJhHdRGStFT+Va/ELww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3vLBRM FRtqrdhjG6JcQxsh8170aOf1SzHZJMYZeZ3HA=; b=R+JM2BPH/pdtYD5cotYSyf wgG0ccy+DyzEhpvE5jaJg98h8lau6oTSmpMDLUVlTUmKi0gwW4OW0c24AS1ePSYX jZN6b+pmhjjbMUHxW4Qq72ZHZd+xtdsFiz7w28jyghxgQIP6bFZnBiA2c7R2+t6q SJ9fU238ZMO6n0iQ2BYNMbbiC/szy0wsJ9tRL//9UJ4E206ypISY3JgjvTJxWddk x5EIsPBFd+6VdoMy+JZ5H79R4i0yBp5t3l74UScUwjTIRROsfi4BQw44obaivIUO vaBeOWgbXfWPcDf4ae/LZcN3HsA2hyzHdzxumitZXcU8QLqNaDhdZzADdZ9V545w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrjeeigddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufgjfhffkfggtgesghdtreertd dttdenucfhrhhomheptehlhihsshgrucftohhsshcuoehhihesrghlhihsshgrrdhisheq necukfhppeekgedrudekgedrvddvgedrudehtdenucfrrghrrghmpehmrghilhhfrhhomh ephhhisegrlhihshhsrgdrihhsnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from x220.qyliss.net (p54b8e096.dip0.t-ipconnect.de [84.184.224.150]) by mail.messagingengine.com (Postfix) with ESMTPA id 83E86D6005B; Wed, 16 Oct 2019 19:15:51 -0400 (EDT) Received: by x220.qyliss.net (Postfix, from userid 1000) id D67EC140076; Wed, 16 Oct 2019 23:15:49 +0000 (UTC) From: Alyssa Ross To: Michael Raskin <7c6f434c@mail.ru>, devel@spectrum-os.org In-Reply-To: References: <20191016202845.21132-1-hi@alyssa.is> <20191016202845.21132-1-hi@alyssa.is> Date: Wed, 16 Oct 2019 23:15:46 +0000 Message-ID: <87pniwb7tp.fsf@alyssa.is> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Message-ID-Hash: HA3DZQHOA5X3TJOWBV7AZIQB7KT2X3I6 X-Message-ID-Hash: HA3DZQHOA5X3TJOWBV7AZIQB7KT2X3I6 X-MailFrom: hi@alyssa.is X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: Jean-Philippe Ouellet X-Mailman-Version: 3.2.2 Precedence: list Subject: [spectrum-devel] Re: [PATCH www] design: state subdirectories, not block devices List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Michael Raskin <7c6f434c@mail.ru> writes: > I guess in the eventual design we want VM-in-jail, i.e. the VM process > itself (and the corresponding FS daemon, if separate from the VM) should > not have any access to the resources not intended for the application. Yes. Layers are good. >>+State directories and applications will be m:n. > > Note (probably not affecting the design right now): this can also be > a source of annoyance with running everything under unique single-use > UIDs: to have multiple UIDs access the same resource, setting ACLs is > a natural idea. It works well, but might require some cleanup of=20 > obsolete ACLs for a workflow with a large churn of instances ??? the=20 > maximum length of an ACL is limited. Yeah, we'll need something like that. ACLs sound sensible. >>+Some virtual machines may have no persistent storage, or even write >>+access to a disk, at all. In other cases, it might be desirable for >>+multiple applications to be able to access the same device, such as a >>+local mail store being shared by two mail clients. Other resources >>+and permissions, such as network cards and USB controllers, will >>+similarly be defined in Nix. There are three logical sections for the >>+Nix configuration -- applications, which are just packages, resources >> (virtual or physical devices), and application instances, which >> are mappings between applications and accessible resources. This >> structure allows users to have multiple instances of the same > > Given that it is sometimes convenient to spawn multiple VMs with almost=20 > identical settings on the fly (e.g. Firefox instances but with different > state directories for downloads/uploads), should we commit to define > a CLI layer for starting VMs (probably similar to the underlying VMM > software CLI, but adapted to the notions we want to use), with the=20 > Nix-based management of VM fleet built on top of this CLI? Yeah, I've been thinking about this too and agree. We should have a nix run analogue for temporary VMs. It would be nice for scripts that use multiple VMs to be able to start them on the fly as well. (But we should definitely not have a nix-env -i analogue, because there should be no hidden state on a host.)> > I suspect that building things the other way round is not much simpler, > but building a single VM image usable with slightly different settings > will have smaller overhead than evaluating a Nix expression for each > extra VM. Maybe. I'll have to think more about that. tbh I think we can assume that the evaluator will get faster at some point (because there's big potential for optimisations and caching in safe mode). It might be nice to invent yet another way to do options, and just keep that in Nix. But I could be swayed either way. > I guess it didn't make any difference in the previous design version > where the maximum goal was a VM per application, not per application > instance. It does matter now. Just to clarify, this was always the goal -- I just wrote the wrong thing when I was banging out the website initially. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEH9wgcxqlHM/ARR3h+dvtSFmyccAFAl2npKIACgkQ+dvtSFmy ccCFmg//YlZV3MKS4C3q4mxiYIywjKRvWXuBVciM6Jf2t+U/xWVI5eFJZpFKmWfQ a88y0zG55OhwFLqHtR50YXn/vMrEOvpo2qV6RdrJxUmSl1QLlIfcW4HvKUElFo5E v5HUPvfGtUGdJzDcYYoBUhNIjEOm1PMho6pGN1NXRBxFILEdmmMauBjJp9cd1xyd sduMumh98cp9Lrup9uGYXW84ii38KsdXNsoLcuKXcMwUPnLd8wr0L1YKD9ujolgG iqrMsBlNadejhwflZ8XaQ5Ihn2d9bq0c9gqohg5M/ZOBiP5uCxhztlDCuSjPLamO 5HudXdh8riwGWdmlm+8iFvuDxHW+zSMdUcXnqr/LINz08f5MTfQ5AbFEvHK6LyVz /dur3+lgFEo35a+iEORYBsC5xG496iCmx4E7UlSVuGWpVmfrlR1+FHaeeyFAyM1N sXykTRq+6npnKVKx56AwQG5k/461nqaictfF7t/VfzHJvV5u4bGFNwQI78w/gn7h oDandvo2hvsI7uq5qPFdIH4+v9NMzQmTDZN369AeD2ham2KacVTOU/+eml5wf1Ip UdBvhoNN/z5zHGQZjBHmgecVLva0CzgC+m1kkUT4wggUGfy4bJ9cd97dj1X86fTj V8lxIO1z1X6F/5Ad0+kjTg/So26QRE6r1qZcTG3GzyDcQol6mhM= =ngUh -----END PGP SIGNATURE----- --=-=-=--