kickstart: enable prjquota for quota enablement

[dustymabe]

This enables platforms like kubernetes to limit the storage of
containers so malicious actors in a multi-tenant environment
can't eat up a ton of storage.

https://bugzilla.redhat.com/show_bug.cgi?id=1658386

[dustymabe]

not sure why but the changes as is don't seem to be working for me. They make it into the /etc/fstab but don't make it to the booted system. I need to use rootflags=defaults,prjquota on the kernel command line in order to get it to work.

then project quotas are enabled and I see some output from xfs_quota -x -c state:

[root@coreos ~]# xfs_quota -x -c state
User quota state on /sysroot (/dev/vda2)
  Accounting: OFF
  Enforcement: OFF
  Inode: N/A
Group quota state on /sysroot (/dev/vda2)
  Accounting: OFF
  Enforcement: OFF
  Inode: N/A
Project quota state on /sysroot (/dev/vda2)
  Accounting: ON
  Enforcement: ON
  Inode: #99 (1 blocks, 1 extents)
Blocks grace time: [7 days]
Inodes grace time: [7 days]
Realtime Blocks grace time: [7 days]
User quota state on /sysroot (/dev/vda2)
  Accounting: OFF
  Enforcement: OFF
  Inode: N/A
Group quota state on /sysroot (/dev/vda2)
  Accounting: OFF
  Enforcement: OFF
  Inode: N/A
Project quota state on /sysroot (/dev/vda2)
  Accounting: ON
  Enforcement: ON
  Inode: #99 (1 blocks, 1 extents)
Blocks grace time: [7 days]
Inodes grace time: [7 days]
Realtime Blocks grace time: [7 days]
User quota state on /sysroot (/dev/vda2)
  Accounting: OFF
  Enforcement: OFF
  Inode: N/A
Group quota state on /sysroot (/dev/vda2)
  Accounting: OFF
  Enforcement: OFF
  Inode: N/A
Project quota state on /sysroot (/dev/vda2)
  Accounting: ON
  Enforcement: ON
  Inode: #99 (1 blocks, 1 extents)
Blocks grace time: [7 days]
Inodes grace time: [7 days]
Realtime Blocks grace time: [7 days]
User quota state on /sysroot (/dev/vda2)
  Accounting: OFF
  Enforcement: OFF
  Inode: N/A
Group quota state on /sysroot (/dev/vda2)
  Accounting: OFF
  Enforcement: OFF
  Inode: N/A
Project quota state on /sysroot (/dev/vda2)
  Accounting: ON
  Enforcement: ON
  Inode: #99 (1 blocks, 1 extents)
Blocks grace time: [7 days]
Inodes grace time: [7 days]
Realtime Blocks grace time: [7 days]

good reference: https://www.thegeekdiary.com/how-to-enable-disk-quotas-on-an-xfs-file-system/

Should we enable group and user quota support in addtion to project quota support?

[mrunalp]

@rhvgoyal @nalind ptal

[dustymabe]

i'm guessing I'll need to go digging into the initrd to find the answer

[cgwalters]

I need to use rootflags=defaults,prjquota on the kernel command line in order to get it to work.

Yeah, that's a known thing; the problem is the flag needs to be set on the initial mount, and we don't have our /etc/fstab in the initramfs. (We could though for FCOS as our partitioning is fixed)

[dustymabe]

(We could though for FCOS as our partitioning is fixed)

yeah - I can test that. Considering our partitioning is fixed are there any issues with doing that that you know of?

[dustymabe]

we don't have our /etc/fstab in the initramfs

actually this won't work. We generate the initramfs when we generate the ostree, but the fstab gets created by anaconda during initial boot.

I think we should just use the rootflags argument and manage filesystem options for the root filesystem that way?

[cgwalters]

We generate the initramfs when we generate the ostree, but the fstab gets created by anaconda during initial boot.

Yeah; we could change the ostree to include it though. Which would make more sense once we're not using anaconda.

I think we should just use the rootflags argument and manage filesystem options for the root filesystem that way?

Yeah, fine by me for now. Main downside with that is we don't have a good way to remove/upgrade kargs after shipping right now.

[dustymabe]

Main downside with that is we don't have a good way to remove/upgrade kargs after shipping right now.

meaning no way to change them when we ship a new ostree (i.e. upgrade)? With ostreedev/ostree#479 would we be able to keep knowledge about default provided kernel args and allow them to be changed over time when a new ostree gets shipped?

[dustymabe]

pushed ⬆️ using rootflags

[cgwalters]

meaning no way to change them when we ship a new ostree (i.e. upgrade)?

Yeah although a specific issue for this kernel argument is...what are the semantics if e.g. we decide to stop enabling quota? Can we later re-enable it?

But yeah, we need to implement that ostree issue at some point in general.

[cgwalters]

LGTM

[ashcrow]

Backporting the changes.