Add overlay/ directory and empty out manifest#66
Conversation
dustymabe
left a comment
dustymabe
left a comment
There was a problem hiding this comment.
I think this looks nice but I worry that it's easier to forget about some of the things in the overlay since they will be "out of sight, out of mind".
Yeah, that's a concern. I think the right thing to do there too is to have tracker issues to make sure it doesn't fall off the radar? |
Isn't it the opposite? My eyes glaze over a bit reading shell-in-yaml (edit: in some places shell-generating-shell-in-YAML!) but I think a directory |
It's definitely harder to read, but I don't think harder to miss.
yeah. I think it depends. The issues can mostly be helped by good use of grep, but it was worth pointing out |
jlebon
force-pushed
the
pr/integration-rpm
branch
from
4f90086 to
16ab320
Compare
jlebon
changed the title
jlebon
changed the title
jlebon
force-pushed
the
pr/integration-rpm
branch
from
16ab320 to
312be0a
Compare
|
OK, this is ready to go now! I've added tracking links for some of the hacks. |
|
/me will test this out today |
dustymabe
left a comment
dustymabe
left a comment
There was a problem hiding this comment.
Since various files are used to contribute to the same "fix" for certain things (i.e. a systemd unit and a executable file work together to achieve the same goal) I think it would be nice if we supported a way to group things together. One way to do this would be to support sub directories under overlay. Each sub directory could contain a readme that gets ignored but provides some more context for the group of files.
We could also still support a standalone or general directory as well for single file standalone goals.
WDYT?
Hmm, I like the idea of surfacing the fact that some of the files are related somehow, but having multiple rootfs'es feels like overkill. How about just |
jlebon
force-pushed
the
pr/integration-rpm
branch
from
312be0a to
7052201
Compare
overlay/usr/lib/systemd/journald.conf.d/10-coreos-persistent.conf
Outdated
Show resolved
Hide resolved
Right now the manifest's postprocess is a combination of temporary hacks and glue code. Split those out in a separate `overlay/` directory instead. This will be picked up by coreos-assembler and automatically transformed into an RPM.
jlebon
force-pushed
the
pr/integration-rpm
branch
from
7052201 to
d5644c6
Compare
Yeah. It's not something i would block you on, but I do think that it's easier to set up a structure where people do the right thing vs relying on them to do the right thing. I'll approve the PR and let you make the judgement call. |
OK cool, let's go with this for now, and if this we have more instances, we'll reconsider! |
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)
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.
3 participants
Right now the manifest's postprocess is a combination of temporary hacks
and glue code. Split those out in a separate
overlay/directoryinstead. This will be picked up by coreos-assembler and automatically
transformed into an RPM.
Uses: coreos/coreos-assembler#414