Justin Garrison

The repo syncing, I had a project at Animation where we had RHEL that we would sync all the repos internally. It all sits on NFS. And then we mount everything to NFS to pull in repos. And I forget, it was like a Jenkins tree of syncing jobs that would all run to register a system and pull down. It was like 300 or something repos that we would sync every night.

The repo syncing, I had a project at Animation where we had RHEL that we would sync all the repos internally. It all sits on NFS. And then we mount everything to NFS to pull in repos. And I forget, it was like a Jenkins tree of syncing jobs that would all run to register a system and pull down. It was like 300 or something repos that we would sync every night.

And I'm like, OK, let's fetch all the files now. Oh, yeah. And then squirrel those away somewhere on a drive and then host them so that everyone else can can sync to it and then have it roll out to the testing fleet.

And I'm like, OK, let's fetch all the files now. Oh, yeah. And then squirrel those away somewhere on a drive and then host them so that everyone else can can sync to it and then have it roll out to the testing fleet.

It's a lot of data and it's a lot of stuff that just have to, as packages get removed from upstream and you're using them in places, I'm assuming you have some isolation there because as far as I know, most of your workloads are containerized on the Twine, on TW shared as the base infrastructure, right?

It's a lot of data and it's a lot of stuff that just have to, as packages get removed from upstream and you're using them in places, I'm assuming you have some isolation there because as far as I know, most of your workloads are containerized on the Twine, on TW shared as the base infrastructure, right?

Is that an update for the base container layer or whatever they're building on top of?

Is that an update for the base container layer or whatever they're building on top of?

Can you describe TW Shared for the audience as well? Because that's one of the things that I think is really fascinating that you have your own container scheduler. And as far as I know, all those containers are running directly with system D, right? Like you're not having like a shim of like an agent. I mean, you have agents, but go ahead and describe it.

Can you describe TW Shared for the audience as well? Because that's one of the things that I think is really fascinating that you have your own container scheduler. And as far as I know, all those containers are running directly with system D, right? Like you're not having like a shim of like an agent. I mean, you have agents, but go ahead and describe it.

And that's systemd inside the container?

And that's systemd inside the container?

How does that work with the sidecar? I would assume, I've never really actually done this side, like systemd inside the container running on systemd. So if I log into a host, not the container, I see just services all the way down. They just look like standard systemd units. They're just isolated from each other. Is that right?

How does that work with the sidecar? I would assume, I've never really actually done this side, like systemd inside the container running on systemd. So if I log into a host, not the container, I see just services all the way down. They just look like standard systemd units. They're just isolated from each other. Is that right?

And that was the question I actually had. It was like, I assumed that JournalD would handle the unit logging, but you say there's a sidecar that I'm assuming is like getting that logs out to JournalD on the host or at least some way so that you don't lose those logs inside the container.

And that was the question I actually had. It was like, I assumed that JournalD would handle the unit logging, but you say there's a sidecar that I'm assuming is like getting that logs out to JournalD on the host or at least some way so that you don't lose those logs inside the container.

That's cool. At that point, it's just native system D, really. We're just using every feature of system D to isolate and run those jobs. And then you have an overarching scheduler, resource allocator, all that stuff.

That's cool. At that point, it's just native system D, really. We're just using every feature of system D to isolate and run those jobs. And then you have an overarching scheduler, resource allocator, all that stuff.

One of the things that I found super interesting in the white paper was host profiles, where different workloads, you basically virtually allocate clusters, I guess, for lack of better, entitlements is what you call them, for like, hey, this job gets this set of hosts, and then you can dynamically switch those hosts to needing different kernel parameters, file systems, huge pages.

One of the things that I found super interesting in the white paper was host profiles, where different workloads, you basically virtually allocate clusters, I guess, for lack of better, entitlements is what you call them, for like, hey, this job gets this set of hosts, and then you can dynamically switch those hosts to needing different kernel parameters, file systems, huge pages.