rpm-ostree: Use upstream Rust bindings #491
Conversation
|
Draft until the rpm-ostree PR merges. I also only compile tested this. |
cgwalters
force-pushed
the
rpmostree-client-bindings
branch
2 times, most recently
from
d2eb1bb
to
c457ecb
Compare
|
OK rebased 🏄 and cleaned up to use the latest upstream client API. I think this turns out cleaner. Only compile tested though. |
Depends: coreos/rpm-ostree#2636 Use the upstream client bindings for the status data. An interesting note: In the upstream API, the commit metadata is exposed as a generic `HashMap<>` because that's how it's used by both ostree and rpm-ostree. It'd be a layering violation for us to hardcode `coreos-assembler.basearch` in the rpm-ostree git for example, not to mention `fedora-coreos.stream`. So those constants stay here in zincati. I dropped the `_json` terminology from various functions because that's weird - we parsed the data from JSON, but that's not really very relevant except as an implementation detail. It's just a `Deployment`, not a `DeploymentJSON`. Also I dropped for now the optimization of using `--booted`; it's not a huge amount of data. If we care we can re-add that later. Note it makes caching more complex because then we need to carefully check the booted state too.
cgwalters
force-pushed
the
rpmostree-client-bindings
branch
from
c457ecb
to
9a9c5f9
Compare
cgwalters
changed the title
|
OK so the |
| .base_checksum | ||
| .clone() | ||
| .unwrap_or_else(|| d.checksum.clone()), | ||
| version: d.version.clone().unwrap_or_default(), |
There was a problem hiding this comment.
This looks sketchy, and may break other logic in the app.
I don't know in which cases we can end up with a version-less commit, but it may be good to log a warning and filter it out.
| @@ -226,18 +147,4 @@ mod tests { | |||
| assert_eq!(deployments.len(), 1); | |||
| } | |||
| } | |||
|
|
|||
| #[test] | |||
| fn mock_booted_basearch() { | |||
There was a problem hiding this comment.
These two are some basic unit tests to ensure we don't regress on parsing FCOS-specific metadata, I'd rather not drop it.
| @@ -16,6 +17,16 @@ use failure::{ensure, format_err, Fallible, ResultExt}; | |||
| use serde::Serialize; | |||
| use std::cmp::Ordering; | |||
|
|
|||
| /// Metadata key the base (RPM) architecture; injected by coreos-assembler | |||
There was a problem hiding this comment.
| /// Metadata key the base (RPM) architecture; injected by coreos-assembler | |
| /// Metadata key for the base (RPM) architecture, injected by coreos-assembler. |
|
The crates.io tarball is the main artifact consumed by the Fedora specfile. We can back away from that by adjusting the release steps. But that would introduce maintenance skew compared to the other (coreos+rust) projects we maintain, and it would still be blocked by |
rpm-ostree: Use upstream Rust bindings
Depends: coreos/rpm-ostree#2636
Use the upstream client bindings for the status data. Note
that some functions switched to returning borrowed
&Stringbecause there's no need to clone unnecessarily.
An interesting note: In the upstream API, the commit
metadata is exposed as a generic
HashMap<>becausethat's how it's used by both ostree and rpm-ostree. It'd
be a layering violation for us to hardcode
coreos-assembler.basearchin the rpm-ostree git for example, not to mention
fedora-coreos.stream.So those constants stay here in zincati.
I dropped the
_jsonterminology from various functionsbecause that's weird - we parsed the data from JSON, but
that's not really very relevant except as an implementation
detail. It's just a
Deployment, not aDeploymentJSON.Also I dropped for now the optimization of using
--booted;it's not a huge amount of data. If we care we can re-add that
later. Note it makes caching more complex because then we
need to carefully check the booted state too.