You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now rpm-ostree compose tree is very prescriptive about how things work.
Trying to add anything that isn't an RPM is absolutely fighting the system. Our
postprocessing system enforces no network access (good for reproducibilty, but
still prescriptive).
There's really a logical split between three phases:
install: "build a rootfs that installs packages"
postprocess: "run magical ostree postprocessing like kernel"
commit: "commit result to ostree"
So there are two high level flows I'd like to enable here. First is to allow
people to do arbitrary postprocessing between install and commit. For
example, run Ansible and change /etc. This path basically is like what we have
today with postprocess-script.sh, except the builder can do anything they want
with network access enabled.
Going much farther, this helps us support a "build with Dockerfile" style flow.
We can then provide tooling to extract the container image, and combine postprocess and commit.
Or completely the other way - if for example someone wants to use rpm-ostree compose install, they could tar up the result as a Docker/OCI image. That's now
easier; an advantage of this flow over e.g. yum --installroot is the "change
detection" code we have.
One disadvantage of this approach right now is that if one does go for
the split approach, we lose the "input hash" metadata for example. And
down the line, I'd like to add even more metadata, like the input rpm repos,
which could also be rendered on the client side.
But, I think we can address that later by e.g. caching the metadata in a file in
the install root and picking it back up or something.
The text was updated successfully, but these errors were encountered:
cgwalters
changed the title
Split commit -> install-root and commit-root
bin/compose: Expose phases as [install, postprocess, commit] cmds
Oct 17, 2017
Right now
rpm-ostree compose tree
is very prescriptive about how things work.Trying to add anything that isn't an RPM is absolutely fighting the system. Our
postprocessing system enforces no network access (good for reproducibilty, but
still prescriptive).
There's really a logical split between three phases:
So there are two high level flows I'd like to enable here. First is to allow
people to do arbitrary postprocessing between
install
andcommit
. Forexample, run Ansible and change
/etc
. This path basically is like what we havetoday with
postprocess-script.sh
, except the builder can do anything they wantwith network access enabled.
Going much farther, this helps us support a "build with Dockerfile" style flow.
We can then provide tooling to extract the container image, and combine
postprocess
andcommit
.Or completely the other way - if for example someone wants to use
rpm-ostree compose install
, they could tar up the result as a Docker/OCI image. That's noweasier; an advantage of this flow over e.g.
yum --installroot
is the "changedetection" code we have.
Related issues/PRs:
One disadvantage of this approach right now is that if one does go for
the split approach, we lose the "input hash" metadata for example. And
down the line, I'd like to add even more metadata, like the input rpm repos,
which could also be rendered on the client side.
But, I think we can address that later by e.g. caching the metadata in a file in
the install root and picking it back up or something.
The text was updated successfully, but these errors were encountered: