-
Notifications
You must be signed in to change notification settings - Fork 197
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
Add ostree-layers and ostree-overrride-layers #1830
Conversation
Related discussions in #1826. |
OK so trying to flesh this out more...there's an obvious chicken-egg (:chicken: ⇆ :egg:) situation here because the layers need SELinux labeling. Hmm. Probably the right thing is for us to always forcibly relabel them - treat them the same as pkgcache branches. |
This is strongly related to coreos/fedora-coreos-config#66 For development iteration, we want the ability to directly overlay binaries. This depends on coreos/rpm-ostree#1830 which adds rpm-ostree ability to inject ostree refs into the build. We could implement this in cosa by building an RPM but I think that's silly - we end up compressing the data only to immediately decompress it. Plus, while there are advantages to having entries for files in the RPM database, in practice we're lying about having these files built by RPM. So let's just directly generate an OSTree commit from them and inject that. (In practice for *this* use case rpm-ostree could actually learn a way to directly consume a directory, but indirecting via OSTree means it's equally easy to manage pre-generated ostree branches too in an efficient way rather than re-committing each time)
8b2d91f
to
7bebbb3
Compare
Downstream consumer in coreos/coreos-assembler#521 |
This is done now indirectly by just not populating the devino cache. |
Bigger picture one thing that excites me about this is that it's pulling rpm-ostree in the other direction - we support RPMs in a lot of ways but ironically don't make it easy to consume ostree refs. This helps to fix that. |
7bebbb3
to
e72c5de
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Looks good to me overall. Surprisingly small patchset.
Minor bikeshed: instead of ostree-layers
and ostree-override-layers
, how about just ostree-overlays
and ostree-overrides
? Matches the wording elsewhere in the CLI/codebase.
☔ The latest upstream changes (presumably 0c80aa9) made this pull request unmergeable. Please resolve the merge conflicts. |
The difference between |
What about just enhancing |
Yeah, I'd be fine doing that too I think, but: accepting content as ostree commits is just generally more flexible. Plus once we have this I'd like to rework |
To give a concrete example, rather than us walking all the files each time and checksumming them, a custom build system could fetch the ostree refs via HTTP. (That's really the next step here, support |
I'm mostly thinking of this as a user who has wanted this feature. From that end user perspective the key in the yaml would make most sense as an extension of
I think I agree here. Is this one step towards #442 ?
Sounds logical. |
e72c5de
to
50114eb
Compare
OK rebased 🏄♂️ and now with tests ✔️. |
50114eb
to
ef766d8
Compare
And now updated with docs ✍️ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some tiny nits! Also looks like one r
too many in that commit title... unless you're going for the pirate accent. ☠️
The use case for `ostree-layers` is to support injecting non-RPM content in a more flexible way than can be done with `add-files`, and also without dropping all the way to split composes. This starts with support on the `compose tree` side but down the line I'd like to make it more convenient to do *client* side too. For `ostree-override-layers` this is mainly a development thing for tools like coreos-assembler. Rather than building an RPM we just `make install DESTDIR` then commit and add to `ostree-override-layers`.
ef766d8
to
b57163c
Compare
All comments should be addressed ⬆️ |
⚡ Test exempted: pull fully rebased and already tested. |
One next step I want to take is something like this client side:
Where a user could overlay arbitrary content generated locally as well as
To install remote content. Tricky issues here involve cases where ordering matters, etc. But it'd be an advanced feature. |
This is strongly related to coreos/fedora-coreos-config#66 For development iteration, we want the ability to directly overlay binaries. This depends on coreos/rpm-ostree#1830 which adds to rpm-ostree the ability to inject ostree refs into the build. We could implement this in cosa by building an RPM (like we do for the overlay mentioned above) but I think that's silly - we end up compressing the data only to immediately decompress it. Plus, while there are advantages to having entries for files in the RPM database, in practice we're lying about having these files built by RPM. So let's just directly generate an OSTree commit from them and inject that. In practice for *this* use case rpm-ostree could actually learn a way to directly consume a directory, but indirecting via OSTree means it's equally easy to manage pre-generated ostree branches too in an efficient way rather than re-committing each time.
This is strongly related to coreos/fedora-coreos-config#66 For development iteration, we want the ability to directly overlay binaries. This depends on coreos/rpm-ostree#1830 which adds to rpm-ostree the ability to inject ostree refs into the build. We could implement this in cosa by building an RPM (like we do for the overlay mentioned above) but I think that's silly - we end up compressing the data only to immediately decompress it. Plus, while there are advantages to having entries for files in the RPM database, in practice we're lying about having these files built by RPM. So let's just directly generate an OSTree commit from them and inject that. In practice for *this* use case rpm-ostree could actually learn a way to directly consume a directory, but indirecting via OSTree means it's equally easy to manage pre-generated ostree branches too in an efficient way rather than re-committing each time.
This is strongly related to coreos/fedora-coreos-config#66 For development iteration, we want the ability to directly overlay binaries. This depends on coreos/rpm-ostree#1830 which adds to rpm-ostree the ability to inject ostree refs into the build. We could implement this in cosa by building an RPM (like we do for the overlay mentioned above) but I think that's silly - we end up compressing the data only to immediately decompress it. Plus, while there are advantages to having entries for files in the RPM database, in practice we're lying about having these files built by RPM. So let's just directly generate an OSTree commit from them and inject that. In practice for *this* use case rpm-ostree could actually learn a way to directly consume a directory, but indirecting via OSTree means it's equally easy to manage pre-generated ostree branches too in an efficient way rather than re-committing each time.
This is strongly related to coreos/fedora-coreos-config#66 For development iteration, we want the ability to directly overlay binaries. This depends on coreos/rpm-ostree#1830 which adds to rpm-ostree the ability to inject ostree refs into the build. We could implement this in cosa by building an RPM (like we do for the overlay mentioned above) but I think that's silly - we end up compressing the data only to immediately decompress it. Plus, while there are advantages to having entries for files in the RPM database, in practice we're lying about having these files built by RPM. So let's just directly generate an OSTree commit from them and inject that. In practice for *this* use case rpm-ostree could actually learn a way to directly consume a directory, but indirecting via OSTree means it's equally easy to manage pre-generated ostree branches too in an efficient way rather than re-committing each time.
So now that we have OSTree layer capabilities in rpm-ostree (coreos/rpm-ostree#1830), I think it makes more sense overall to make the overlay an OSTree layer. The fact that it *is* an RPM, but differs from all the other RPMs in various ways will (and already has) come up multiple times when we talk about signing, changelogs, lockfiles, overrides, etc... (See [1] and [2] for some already filed issues). Switching to an OSTree layer sidesteps many of those issues. Of course, we do lose some things from moving away from RPM: 1. it's harder to determine from where the overlay files come from on a host system (see [3] related to this) 2. invisible to `rpm-ostree db diff` (but then again, the diff we currently get isn't helpful) 3. not possible to issue an advisory for it to be consumed like the rest of the advisories (though with the current approach, making use of this without going through Bodhi would've required some non-trivial amount of work too) Overall though, I think those are things we could (and should strive to) fix in rpm-ostree rather than avoiding layers entirely. [1] coreos#544 [2] coreos#553 (comment) [3] coreos/rpm-ostree#1789
So now that we have OSTree layer capabilities in rpm-ostree (coreos/rpm-ostree#1830), I think it makes more sense overall to make the overlay an OSTree layer. The fact that it *is* an RPM, but differs from all the other RPMs in various ways will (and already has) come up multiple times when we talk about signing, changelogs, lockfiles, overrides, etc... (See [1] and [2] for some already filed issues). Switching to an OSTree layer sidesteps many of those issues. Of course, we do lose some things from moving away from RPM: 1. it's harder to determine from where the overlay files come from on a host system (see [3] related to this) 2. invisible to `rpm-ostree db diff` (but then again, the diff we currently get isn't helpful) 3. not possible to issue an advisory for it to be consumed like the rest of the advisories (though with the current approach, making use of this without going through Bodhi would've required some non-trivial amount of work too) Overall though, I think those are things we could (and should strive to) fix in rpm-ostree rather than avoiding layers entirely. [1] coreos#544 [2] coreos#553 (comment) [3] coreos/rpm-ostree#1789
So now that we have OSTree layer capabilities in rpm-ostree (coreos/rpm-ostree#1830), I think it makes more sense overall to make the overlay an OSTree layer. The fact that it *is* an RPM, but differs from all the other RPMs in various ways will (and already has) come up multiple times when we talk about signing, changelogs, lockfiles, overrides, etc... (See [1] and [2] for some already filed issues). Switching to an OSTree layer sidesteps many of those issues. Of course, we do lose some things from moving away from RPM: 1. it's harder to determine from where the overlay files come from on a host system (see [3] related to this) 2. invisible to `rpm-ostree db diff` (but then again, the diff we currently get isn't helpful) 3. not possible to issue an advisory for it to be consumed like the rest of the advisories (though with the current approach, making use of this without going through Bodhi would've required some non-trivial amount of work too) Overall though, I think those are things we could (and should strive to) fix in rpm-ostree rather than avoiding layers entirely. [1] #544 [2] #553 (comment) [3] coreos/rpm-ostree#1789
Followup issue in #1857 |
The use case for
ostree-layers
is to support injecting non-RPMcontent in a more flexible way than can be done with
add-files
,and also without dropping all the way to split composes.
This starts with support on the
compose tree
side but down theline I'd like to make it more convenient to do client side too.
For
ostree-override-layers
this is mainly a development thingfor tools like coreos-assembler. Rather than building an RPM
we just
make install DESTDIR
then commit and add toostree-override-layers
.