Feature: Templates

[bsdci]

Feature: Templates

[foo2342]

Another approach would be to use unionfs to create a diff between a release and modifications a user makes on a template. I think this was support on iocage-legacy. This would enable to ability to apply security updates to templates by just updating the release. @skarekrow could you comment on why the unionfs approach was ditched?

[igalic]

@skarekrow is the patch unstable, or unionfs?

[skarekrow]

@igalic unionfs. The warnings are legit. It really will eat your cat.

[skarekrow]

They're not a hard concept really. You set up a jail how you would like it, and mark it as a template. Then you create from that template instead of a RELEASE.

That I believe is already intuitive, performant and convenient.

I believe that simply setting a jail to readonly and changing it's type should be enough to distinguish these from jails. Alternatively since it's slightly redundant to clone jails, we can just drop templates and have users clone.

[igalic]

yeah, i was thinking of implementing the concept of templates in puppet-jail even if there was no hard distinguished feature.

HOWEVER, it's much much easier — for management purposes to distinguish templates, if the type is actually template.

[skarekrow]

I agree, so my suggestion is:

type = template
readonly = on

That should be all that's needed to distinguish a template. We have legacy users using POOL/iocage/templates but they could easily be moved to this system when they choose by setting templates=no and back to yes.

[igalic]

you wouldn't move those jails on iocage upgrade?

[skarekrow]

Why would they be moved on upgrade? That's for jails, not templates. Templates should be immutable. So that means no starting, or modifying them in anyway.

Upgrade shouldn't change the structure of the filesystem outside the jail, that's way out of scope.

[igalic]

what does that mean if i want to upgrade all the jails derived from a certain template?
If they were NullFS based, it could mean:

• destroy template
• rebuild template from new RELEASE
• reinstall needed packages
• …
• set type = template & readonly = on

and now, we can reboot our jails, and they'll be up-to-date.

Does this make sense?

[skarekrow]

No that doesn't make sense.

You don't need to destroy the template, you simply set template to no. Then it's a jail you can change, and when you're happy set it back to yes. Instead of requiring the user to set both of those properties, that one will handle that internally. The current structure of templates mean that once created from them, the jail inherits nothing else from that template.

Destroying the template means destroying the jails, as they are children of that template.

From ZFS's viewpoint they are forever linked. Unless you're suggesting some nullfs approach to templates, but that is not currently how it's done. Templates for all intents and purposes serve the same role as RELEASE, except they have modifications. The reason being they could just be meant as an initial seed, that is then modified for each jail.

[skarekrow]

@foo2342 It is an abandoned patch afaik. And that meant it was incredibly unstable with any workload i put on it. I tried to figure out some way to keep it but in the end had to leave it.

[rwestlund]

I tried using unionfs with ZFS underneath and got reproducible kernel panics. I think whiteout support is incomplete. It's a shame, because that would be amazing. It just needs a little more work.

[gronke]

@rwestlund that should not prevent us from implementing it. Who should fix it if nobody uses UnionFS? 😼

We only need UnionFS while changing a template. This could be even done on a virtual host. As long as UnionFS is not known to corrupt data, I'd like to spike on the feature.

[gronke]

We already have a dependency on rsync. We can use it to achieve the same behavior by using rsync --compare-dest:

RELEASE_DIR=/iocage/release/11.1-RELEASE/root
TEMPLATE_JAIL_DIR=/tmp/11.1-RELEASE-clone/root
TARGET_DIR=/iocage/template/my-template
rsync --compare-dest=$RELEASE_DIR $TEMPLATE_JAIL_DIR $TARGET_DIR

Found here: https://serverfault.com/a/508272