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)
cgwalters
force-pushed
the
compose-overlay
branch
from
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. |
cgwalters
force-pushed
the
compose-overlay
branch
from
7bebbb3
to
e72c5de
Compare
cgwalters
changed the title
|
☔ 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. |
cgwalters
force-pushed
the
compose-overlay
branch
from
e72c5de
to
50114eb
Compare
|
OK rebased 🏄♂️ and now with tests ✔️. |
cgwalters
changed the title
cgwalters
force-pushed
the
compose-overlay
branch
from
50114eb
to
ef766d8
Compare
|
And now updated with docs ✍️ |
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`.
cgwalters
force-pushed
the
compose-overlay
branch
from
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-layersis 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 treeside but down theline I'd like to make it more convenient to do client side too.
For
ostree-override-layersthis is mainly a development thingfor tools like coreos-assembler. Rather than building an RPM
we just
make install DESTDIRthen commit and add toostree-override-layers.