On 15/06/15 23:48, Andrew Stuart wrote:
3) support for linking an arbitrary file system image into the binary
"3" is, AFAICT, useful only when you can't have a block device. What are such
cases? I know Andrew used it for platform bootstrap, but adding an entire mechanism to
support a small phase in platform bringup is out of the question.
How do you justify "2" and "3", and how do you plan to fix "4"?
Caveat, all this is subjective opinion of course, presented as fact, happy to
have my points argued or my technical assumptions corrected. My initial
expectation and thinking when approaching the topic of rump/unikernels in
general is that 3 would be the primary use case. I only later gave much thought
to attaching block storage.
I'll assume all your points are in favor of "3" (or something "3"'ish)
and you make no arguments for or against the rest of the proposal.
*****************Self contained kernels are easier to configure and deploy than
those requiring block storage
It is vastly easier not to have to deal with block storage. A standlone kernel
that can run without any dependencies is appealing because it is easy to start
and stop and you need never give any thought to what is on the external file
system, what files are required to be present on the external file system,
versioning, backups, security of the external file system.
They are harder to manage. You don't know what the image ate, since
there are no standard tools to peek in there. Also, to change anything
you must go back and rebuild everything. Having to do a full rebuild
might be what you're after, but it really offers no guarantees, since
someone can tediously go poke around with a hex editor if they want to.
*****************Self contained kernels are easier to manage without block
storage
Managing running applications without file system dependencies is very easy. If
you have the kernel, you can run it, end of story. With file system
dependencies you must immediately answer a long series of questions before you
can run and manage the application. With self contained kernels, if you have it
you can run it. This alone solves much of the ridiculous complexity in
managing computing environments.
If you have any sort of bundle format, you can run it, also end of story.
*****************Self contained kernels are more reliable
Block storage devices are a relatively fragile component of a system and might
fail for a variety of reasons.
This argument is "file system image should be permanently loaded into
memory at boot". Building the file system image into wired text is
*one* way to accomplish it, not the only way.
*****************Self contained kernels are more scalable
Creating 1,000 self contained kernels is easier than creating 1,000 kernels
that require block storage.
How is it easier? Just point 1000 kernels to the same read-only image.
I call that quite easy.
The opposite, however, is not easier. If you want 1000 different
kernels operating on the same data, you need 1000 copies of the data.
*****************Self contained kernels can contain entire application
ecosystems
My Linux root file system contains plenty of those ecosystems. That's
hardly an argument in any direction.
*****************Self contained kernels solve some of the resource intensive
complexity inherent in testing and versioning
Again, runtime binary vs. distribution bundle. Same result regardless
of mechanism.
*****************Self contained kernels make the entire application ecosystem
verifiable.
Any bundle can be hashed.
*****************Self contained kernels are more secure
It is harder for security of an application to be compromised where there is no
read/write file system.
I don't think anyone was suggesting getting rid of read-only file
systems, neither at the guest level nor the hypervisor level.
*****************Self contained kernels are immutable and form ther basis of
the concept of “”immutable infrastructure”.
Read-only file systems are immutable more or less per dictionary definition.
*****************Self contained kernels will enable new, as yet unthought of
paradigms for software execution
I can't argue with that.
*****************Self contained kernels appear to be a good entry point for
learning and understanding
Even if a bundle format will make it some aspects easier, consider the
bigger picture of the current proposal: adding parallel mechanisms to
accomplish what is already possible will make it more difficult to learn
and understand what's going on! "which one do I need to use?" "what
are the tradeoffs?" "why couldn't the developers provide just one
mechanism instead of a maze of mechanisms with minor differences?!?"
*****************Summary.
I’m hoping for an effective implementation for baked in read only file system
to be able to do the above stuff.
Summary: like I've been saying, we first need to figure out what we
want, then we figure out how we best make it happen.
I think your main requirement around which most of your points revolved
around was that you want a single image to distribute. If you had other
requirement proposals (i.e. forget the implementation mechanism for
now), please list them succinctly so that they don't get lost in the
argumentation.
