Okay, we're going to start, unfortunately we have to kick people out, it's not our choice,
but next one is by this guy, I don't know him personally, maybe you know him, and it's
about native OCI container support in the system D.
Okay, hi, I'm Lena Paduring, I work at the startup called Amirable, and yeah, I want
to talk about native OCI support in the system D. As you might know, the system D is the
status manager that kind of is what most of the distributions these days use. OCI, well, I'm
in the container, that room I don't think I have to explain what that is, but yeah, to elaborate
a little bit though, it's three different things. The first of all is the OCI image
format, like the official name that is a specified an OCI image specification. There's
the runtime format, which is defined in the OCI runtime specification, and then there's
the invocation interface, right? So if people just say OCI, they usually mean depending
on the context one of these things, but there's these three things, like, and particularly
the last one is kind of annoying because there's no specification of it, but yeah, it also
exists. Something I wanted to say is OCI already exists in system D, and many people know
this, but basically there has been for a while, system D and Spongebondel, and you can specify
OCI bundle, OCI bundle is usually not the thing that most people who deal with OCI and
Dr. Stark containers come in contact with, because that is the runtime spec thing, but it
has been there for years actually, and you can make it work, but we never advertise this,
and yeah, so nobody really knows it. It only covers the second of these specs. Yeah,
not well, not much used, but yeah, it's also not too useful, because yeah, it won't help you
was actually acquiring the image that you can actually run this way, so it's kind of in a chain
of things how you're going to contain it to run, it's like the middle thing, but we left
the first thing open. Yeah, so it already exists, not too useful, but yeah, it's probably not
even the right place to expose it, because OCI containers are mostly understood as being the
single service thing, right, like where you run one demon inside of OCI container, and that
set. Certainly the end spawn is this container tool, which is mostly focused on running
entire systems, right, like not just one service, but many, like the kind where you SSH
in the kind of the system do runs in. I mean, this is not strictly that way, this is more
by convention, because that's the intended use case, you could also do the single service thing,
but yeah, so it's philosophically the wrong place, it's not technically the wrong place.
So, why even do this? Well, I'm not a fan of the OCI format, like I think it's like the way
how this all put together, this is just tables and the reproducible and the reproducibility and
the cryptographic semantics are very, let's say, uninspired, like even when it was created,
it was like, I don't know, like, I live in this world where we care about it at a stage
in way, we have verified everything, where you have offline secure images, where, yeah,
de-embarrassing these kind of things. So, if I look at OCI, I if you don't really see much
interesting, but then again, it's certainly widely used, right, like everybody who does something
with IT these days and when it comes into contact with OCI sooner or later. So, might not be a
great format, but it's certainly widely used. In a way, it's, you know, in system D, we deal with services,
with system services, and they are mostly written, like you have a unit file, and then you have
some files in disk, and that's it, so they are an alternative service format, if you still will.
System D in many ways already does most of the hot parts, like of the more complex parts
that you need to learn a container, because service management and container management,
not that different, right? Like, it's also, you end up creating namespaces all the time,
you need to put everything in a C group, you do resource management for them.
There is, like, the differences between service management, which is more probably more local
thing, and a service thing, like, there's, it's a blurry distinction, hence, yeah, it's actually,
yeah, all the tough stuff has already been addressed anyway. By making OCI stuff natively,
like, supported in system D, we get better integration with all these things, right? Like, because
you can just use system D, and then you can deploy OCI stuff, and you can immediately use system
control these kind of things to actually numerate the containers, and they're just going to be
service like everything else. So, I also see it as a stepping stone to do new stuff that is
does not exist in the OCI world, or at least does not come in the OCI world, so far.
Because in system D, we are big of doing measurements of the stuff we do, like, TPM stuff,
getting event logs, and things like this. So, if system D generally defines the semantics, like,
in which PCRs things are being done, and how we do the measurements in the first place,
if we have OCI containers as a native concept and system, we can, like, all of that opens up
a completely natural. We can measure the OCI services as they happen, and can have it in the TPM,
event log, and there is no, it's just that, right? Like, nobody has to to think about this.
There are a couple of other things, like, you know, the way how OCI containers currently
always do use a namespacing. I'm not going to explain what use a namespacing is. I hope some of
you at least know it. Let's just say, I'm not a big fan how this is currently done, because it's
involved suit binaries and static allocations of UID ranges. I don't think it's a scabbel way to do
these things and provides, because they, because they don't dynamically allocate these things,
the individual containers are not as separated, it's not isolated as they, I think they should be.
And system, we have come up with different concepts around, like the foreign UID space,
basically, where you can have the ownership of a container on disk, be exclusively by these foreign
use IDs, and then when you actually spawn the container, you get a transient runtime use ID
range of sign, and we map between those two, which in my view is much nicer, because it basically
means that the UIDs are never persisted to disk. The transient ones, and you have full isolation
of the runtime objects, like the way how it should be, because after all, UID-based isolation
is kind of the most fundamental of isolations that we have on Unix, and hence there's a lot of value
in it to be properly able to isolate the container for that as well. Also, for deployments,
it's kind of relevant that you can have this level of more dynamic, right? Because you might
want to be able to pack a lot of containers onto the same node, but still make sure that they're
all nicely isolated, and has this in a scalable fashion. So, anyway, so this is the reason why
I think this makes a lot of sense, right? Integration, isolation, and yeah, all the first
it acts as stepping stone of doing so much more like measurements, and say, like this.
By the way, I have very little time, so ideally, I always do my talks so that we can do questions
right away, but with 20 minutes, I'm going to show how we're going to do this. I'm going to rush through
this, and maybe we can do the questions afterwards in the hallway. So, yeah, so, as mentioned,
like some parts of OSI, we have been doing, have been doing for years, but nobody knows about them.
Something that I have implemented recently is support for downloading OSI, like the support
for the OSI image format. If you are, I hope the attention is to get this merged in the current
cycle, so that it shows up in the next version. What it basically does is it allows you to download
OSI and have it dropped into a directory, and then you can spawn it via an spawner as a
assistant to service, works unprivileged, and all these kind of nice things. Yeah, so it's very close
to being merged. How will this feel like? There's this important control tool, it has been there
for a while. You just specify the container name, how you would do it for Docker, and then it ends up
there, and you can just run it. On the lower level, it turns the layers, layering stuff that
the OSI is built from into something we call dot mstack. I would love to explain what that is,
but I don't think we have the time here. Just let's say it's powerful in your future. It's
independent of OSI that allows you to really nicely put together overlay of s stuff and encoded
in the file system itself. Then there's the other thing the OSI runtime format. This is mentioned
to think that the system the end spawn does already, but again, probably not at the right place.
It's a stuff once it landed on disk, how you have the bundles then, and now you want to run them.
As mentioned, the end spawn can do this. The work from A sets everything up, that end spawn works,
but there's a scope, it's mismatch. The idea is that we're going to have a new tool called
system the OSI. It's just going to read these bundles and turn them into system the services
natively. First, it's important control. You download the thing, and then with system the OSI
just run it as a regular service like any other. Then the source part is that I listed earlier
was the invocation interface, like the runcic command line comma the ability. The same thing
that system the OSI is supposed to be the multicoled binary. System the OSI does not exist yet.
I did not put together PR, but ultimately it's going to be trivial as a nice work. It's not
going to be trivial. It's going to be relatively simple because we already have, first of all,
all the end spawn can already parse all this, and then we have system the run, which already
can run this stuff. So it's just about putting things together, we already have in a different way.
So putting these three things together, we have the complete OSI support, right? Like you can
take it down, you can run it and show up as a system the service, you can do resource management
logging, all of this will be integrated with the rest. The next thing we're then hooking up
was Kubernetes, but my time is not there for this. So I actually managed to go through this
pretty quickly, so I actually do have time for questions. So yeah, let's do questions. I'm kind of
amazed that this was so quick.
The email FS works, it's going on in ICI, it looks quite relevant to your interest, so you're
going to be looking at supporting the email FS images.
Okay, so the question was, I don't have to repeat this now, right? Like because you actually
haven't like. So yeah, this is definitely interesting to us, but I think we want something
even stronger because we want, like for our case, we want the variety stuff, right? Like we
care about offline security and the like putting in make it eros into the OSI stuff is nice
and it's pinned by the hash already, but we kind of wanted also that it can be pinned by the
variety route hash that the kernel then understands because that is useful because then they
kernel can do the measurements and sync like this and we get the the progress it up. So yeah,
I think it's going into the right direction. I don't think it's going far enough in the way I see it
is that ultimately we probably want something that we call the DDIs, which are basically disc images
that are carry the eros carry a variety data thing and carry the little JSON that has the signature
of it and that's kind of what I want to focus on. For OSI downloads, we'll you support all the
authentication plugins. It's not in the spec, but you need to have all of these binaries for every
cloud to be able to authenticate. Yeah. That's trivial, yeah.
That's it.
They're seem to be some cap. They're seem to be some kind of overlap with spotman. They're some
synergy or some work together between podman team and what you are doing on systemy.
So I think I have trouble understanding everything, but my understanding was that there was a
question about podman. And if there is some synergy with podman. Yeah. Well podman exists.
Certainly podman does different things, right? Like it's a docker like interface and a wrapper
around runcy. The stuff that I see is mostly that whatever we're doing here is kind of replacing
for the runcy part so that ideally you could run podman on top of it if you care about
docker like semantics. So if that is an explanation. I don't think we care about docker like
semantics at all here. Sorry. I don't think we care about docker like semantics at all here.
But are you going to replace the pupil at basically in the future? Is that on your roadmap?
I'm not a Cuban anti-sperson. I'm a low level or ass person. Like so there's definitely
going to be a hook up to this. How this precisely looks like we'll have to see. I'm not going to
work on this because I'm not a Cuban anti-sperson. Let's just say we want to make sure this is
nicely integrated in the end, right? So that the end goal definitely is you have system D. You can
run the containers in the lower level and then you put Cuban antisentop and you can use a classic
Cuban antiseptop. But you know, need anything else, right? Like you have those two components and
that's just this. Follow up on that then. Do you have any plans for integration with spiffy and or
spire? No framework. We've found any companies you might know and this is certainly
a topic that has come up a lot so we will have something that I guess. But I'm not going to talk
too much about our plans but we're very well aware of these kind of things and we think
they should be something that we can do in the west itself because they are concepts that are
not specific to containers and think like this for the whole last. So I've been finding
myself in situation of rebuilding a lot of these tools. I worked on Docker early on. I am now
building a container management a top of system D, but system D is optional which means I'm now
reproducing all the parts of system D in the main reason is because I don't want to be tied to Linux.
So if you're going to support virtual machines and you're also going to support containers,
what are your thoughts of the coupling system D front of Linux? No.
Like I don't know like system D is using Linux API and that's the only reason why I can do what
I can do it like use C groups and in the second one. I'm working with him all the time he's
the longest kernel guy implement all the wishes that I have. This is not going to happen with any other
operating system. I'm still not actually reasonable. Yeah. So anyway so no.
I mean there are illusions in the wider community that you could do all this stuff completely abstracted
that postsick so whatever is sufficient for this. I'm not a believer in this, right? Like these
shortcomings of postsicks. Like I mean the basic concepts are just so terrible like a PAD.
No that's just yeah you can't do this. Anyway uh something else?
What about networking for the containers? Can you repeat this?
So yeah you have a question how will the networking site work there inside the containers?
Okay so the question was regarding the networking site. Let's a good question.
We're going to add a little bit of infrastructure there. I mean we found this company and let's
talk about this recently. So we'll have something there. Let's just say
I mean it already like system you already have some kind of integration that you can have like
your network namespace and think like this and hook it up with some certain things. It's not nice right
now to hook this up with networking that is independent of the container because you have to do a lot
of manual steps right now. The wheel suddenly makes this cleaner like so that there is a
there's a concept for for me because I'm very recently I was looking at it.
Okay my time thank you everyone and if you've heard a question, let's just do that okay.