-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Copy rootfs Ignition mountOptions to rootflags karg #805
Labels
jira
For syncing to Jira. Only works for issues (i.e. not PRs)
Comments
jlebon
added a commit
to jlebon/fedora-coreos-config
that referenced
this issue
Mar 19, 2021
By default, we use `prjquota` for the rootfs for container orchestrators to monitor and set drive space limits. However, with the added support for rootfs reprovisioning, we made this conditional on the rootfs not being reprovisioned, with the assumption that you can just set whatever options you'd like instead. Though actually doing that is really awkward right now, and it requires surfacing prjquota in user documentations (see https://bugzilla.redhat.com/show_bug.cgi?id=1940704#c2). Since AFAICT `prjquota` doesn't actually have any significant overhead, let's just simplify the messaging to: we *always* enable prjquota on XFS root filesystems. Users who want to override this can fallback to `rpm-ostree kargs` (and eventually once we have coreos#805, to `mountOptions: []`). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1940704
jlebon
added a commit
to jlebon/fedora-coreos-config
that referenced
this issue
Mar 19, 2021
By default, we use `prjquota` for the rootfs for container orchestrators to monitor and set drive space limits. However, with the added support for rootfs reprovisioning, we made this conditional on the rootfs not being reprovisioned, with the assumption that you can just set whatever options you'd like instead. Though actually doing that is really awkward right now, and it requires surfacing prjquota in user documentations (see https://bugzilla.redhat.com/show_bug.cgi?id=1940704#c2). Since AFAICT `prjquota` doesn't actually have any significant overhead, let's just simplify the messaging to: we *always* enable prjquota on XFS root filesystems. Users who want to override this can fallback to `rpm-ostree kargs` (and eventually once we have coreos#805, to `mountOptions: []`). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1940704
jlebon
added a commit
to jlebon/fedora-coreos-config
that referenced
this issue
Mar 19, 2021
By default, we use `prjquota` for the rootfs for container orchestrators to monitor and set drive space limits. However, with the added support for rootfs reprovisioning, we made this conditional on the rootfs not being reprovisioned, with the assumption that you can just set whatever options you'd like instead. Though actually doing that is really awkward right now, and it requires surfacing prjquota in user documentations (see https://bugzilla.redhat.com/show_bug.cgi?id=1940704#c2). Since AFAICT `prjquota` doesn't actually have any significant overhead, let's just simplify the messaging to: we *always* enable prjquota on XFS root filesystems. Users who want to override this can fallback to `rpm-ostree kargs` (and eventually once we have coreos#805, to `mountOptions: []`). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1940704
jlebon
added a commit
that referenced
this issue
Mar 19, 2021
By default, we use `prjquota` for the rootfs for container orchestrators to monitor and set drive space limits. However, with the added support for rootfs reprovisioning, we made this conditional on the rootfs not being reprovisioned, with the assumption that you can just set whatever options you'd like instead. Though actually doing that is really awkward right now, and it requires surfacing prjquota in user documentations (see https://bugzilla.redhat.com/show_bug.cgi?id=1940704#c2). Since AFAICT `prjquota` doesn't actually have any significant overhead, let's just simplify the messaging to: we *always* enable prjquota on XFS root filesystems. Users who want to override this can fallback to `rpm-ostree kargs` (and eventually once we have #805, to `mountOptions: []`). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1940704
jlebon
added a commit
to jlebon/fedora-coreos-config
that referenced
this issue
Mar 19, 2021
Right now, specifying `mountOptions` for the rootfs in the Ignition config is ignored. To fix that, we simply need to have `coreos-rootflags` inspect the Ignition config if the rootfs was reprovisioned and extract the field. This then takes effect on first boot (via `ignition-ostree-mount-sysroot.sh` calling out to it) and subsequent boots (via `rdcore rootmap` calling out to `coreos-rootflags`). Closes: coreos#805
jlebon
added a commit
to jlebon/fedora-coreos-config
that referenced
this issue
Mar 19, 2021
By default, we use `prjquota` for the rootfs for container orchestrators to monitor and set drive space limits. However, with the added support for rootfs reprovisioning, we made this conditional on the rootfs not being reprovisioned, with the assumption that you can just set whatever options you'd like instead. Though actually doing that is really awkward right now, and it requires surfacing prjquota in user documentations (see https://bugzilla.redhat.com/show_bug.cgi?id=1940704#c2). Since AFAICT `prjquota` doesn't actually have any significant overhead, let's just simplify the messaging to: we *always* enable prjquota on XFS root filesystems. Users who want to override this can fallback to `rpm-ostree kargs` (and eventually once we have coreos#805, to `mountOptions: []`). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1940704 (cherry picked from commit a57a999)
miabbott
pushed a commit
that referenced
this issue
Mar 22, 2021
By default, we use `prjquota` for the rootfs for container orchestrators to monitor and set drive space limits. However, with the added support for rootfs reprovisioning, we made this conditional on the rootfs not being reprovisioned, with the assumption that you can just set whatever options you'd like instead. Though actually doing that is really awkward right now, and it requires surfacing prjquota in user documentations (see https://bugzilla.redhat.com/show_bug.cgi?id=1940704#c2). Since AFAICT `prjquota` doesn't actually have any significant overhead, let's just simplify the messaging to: we *always* enable prjquota on XFS root filesystems. Users who want to override this can fallback to `rpm-ostree kargs` (and eventually once we have #805, to `mountOptions: []`). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1940704 (cherry picked from commit a57a999)
jlebon
added a commit
that referenced
this issue
Mar 24, 2021
Right now, specifying `mountOptions` for the rootfs in the Ignition config is ignored. To fix that, we simply need to have `coreos-rootflags` inspect the Ignition config if the rootfs was reprovisioned and extract the field. This then takes effect on first boot (via `ignition-ostree-mount-sysroot.sh` calling out to it) and subsequent boots (via `rdcore rootmap` calling out to `coreos-rootflags`). Closes: #805
HuijingHei
pushed a commit
to HuijingHei/fedora-coreos-config
that referenced
this issue
Oct 10, 2023
By default, we use `prjquota` for the rootfs for container orchestrators to monitor and set drive space limits. However, with the added support for rootfs reprovisioning, we made this conditional on the rootfs not being reprovisioned, with the assumption that you can just set whatever options you'd like instead. Though actually doing that is really awkward right now, and it requires surfacing prjquota in user documentations (see https://bugzilla.redhat.com/show_bug.cgi?id=1940704#c2). Since AFAICT `prjquota` doesn't actually have any significant overhead, let's just simplify the messaging to: we *always* enable prjquota on XFS root filesystems. Users who want to override this can fallback to `rpm-ostree kargs` (and eventually once we have coreos#805, to `mountOptions: []`). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1940704
HuijingHei
pushed a commit
to HuijingHei/fedora-coreos-config
that referenced
this issue
Oct 10, 2023
Right now, specifying `mountOptions` for the rootfs in the Ignition config is ignored. To fix that, we simply need to have `coreos-rootflags` inspect the Ignition config if the rootfs was reprovisioned and extract the field. This then takes effect on first boot (via `ignition-ostree-mount-sysroot.sh` calling out to it) and subsequent boots (via `rdcore rootmap` calling out to `coreos-rootflags`). Closes: coreos#805
HuijingHei
pushed a commit
to HuijingHei/fedora-coreos-config
that referenced
this issue
Oct 10, 2023
By default, we use `prjquota` for the rootfs for container orchestrators to monitor and set drive space limits. However, with the added support for rootfs reprovisioning, we made this conditional on the rootfs not being reprovisioned, with the assumption that you can just set whatever options you'd like instead. Though actually doing that is really awkward right now, and it requires surfacing prjquota in user documentations (see https://bugzilla.redhat.com/show_bug.cgi?id=1940704#c2). Since AFAICT `prjquota` doesn't actually have any significant overhead, let's just simplify the messaging to: we *always* enable prjquota on XFS root filesystems. Users who want to override this can fallback to `rpm-ostree kargs` (and eventually once we have coreos#805, to `mountOptions: []`). Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1940704
HuijingHei
pushed a commit
to HuijingHei/fedora-coreos-config
that referenced
this issue
Oct 10, 2023
Right now, specifying `mountOptions` for the rootfs in the Ignition config is ignored. To fix that, we simply need to have `coreos-rootflags` inspect the Ignition config if the rootfs was reprovisioned and extract the field. This then takes effect on first boot (via `ignition-ostree-mount-sysroot.sh` calling out to it) and subsequent boots (via `rdcore rootmap` calling out to `coreos-rootflags`). Closes: coreos#805
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Originally posted by @jlebon in #503 (comment)
The text was updated successfully, but these errors were encountered: