Skip to content
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

core: Add standard SOURCE_TITLE metadata key #1296

Closed

Conversation

cgwalters
Copy link
Member

This is a freeform string useful to track/display when a commit is "derived"
from some other format. For example, in the rpm-ostree test we make a
vmcheck ref that conceptually overlays the default ref like
fedora-atomic:fedora/26/x86_64/atomic-host.

My current patch sets the source title to e.g.
"Dev overlay on fedora-atomic:fedora/26/x86_64/atomic-host".

Another case I'm working on now is importing OCI images to use
as host images. For that case, the source title is
With this patch we could then set the original OCI image name + tag
as the source name, like:
"oci:cgwalters/demo-custom-fedora-atomic-host:26".

cgwalters added a commit to cgwalters/rpm-ostree that referenced this pull request Oct 19, 2017
Depends: ostreedev/ostree#1296

As I mention in the commit there, I see two uses for this in rpm-ostree; first
in our test suite, and second for OCI-built image imports.

I also took a step further here and inject an `original-origin` metadata
key, though we aren't actually using that yet.  The problem I'm trying
to solve there is that repeated `make vmoverlay` starts chaining things up,
but that gets very confusing.  I think we should always have `vmoverlay` unwind
back to the base ref.  (Or at least do that by default)
@cgwalters
Copy link
Member Author

rpm-ostree consumption patch: coreos/rpm-ostree#1069

@jlebon
Copy link
Member

jlebon commented Oct 20, 2017

This is a cool idea! Should we also add a related SOURCE_CHECKSUM key? I.e. a hash that represents the state of the source at the time. E.g. in the vmcheck case, it'd be the ostree commit hash of the original fedora-atomic commit. In the OCI case, it'd be the checksum of the image. And in the "from a bag of packages" case, it could be the goal hash, or the git commit hash, etc... The advantage of standardizing it vs letting each case invent its own key is that it makes it easier to introspect and display regardless of the source.

@cgwalters
Copy link
Member Author

I'm not sure...for the OCI case the checksum means a different thing than ostree.

For rpm-ostree compose, I'm not totally sure how useful the goal hash would be.

I think my high level feeling here is - let's let the relevant tools add whatever metadata keys are specific to what they're doing, and if there's something to standardize down the line, we circle back here and do that?

@cgwalters
Copy link
Member Author

But hold off on merging, I'm going to update this PR to also render in ostree admin status.

@cgwalters cgwalters changed the title core: Add standard SOURCE_TITLE metadata key WIP: core: Add standard SOURCE_TITLE metadata key Oct 20, 2017
@jlebon jlebon added the WIP label Oct 20, 2017
@cgwalters cgwalters removed the WIP label Oct 20, 2017
@cgwalters cgwalters changed the title WIP: core: Add standard SOURCE_TITLE metadata key core: Add standard SOURCE_TITLE metadata key Oct 20, 2017
No functional changes; prep for more work.
Pull out the commit metadata explicitly; still just rendering the version, but
this is prep for rendering other metadata keys.
This is a freeform string useful to track/display when a commit is "derived"
from some other format.  For example, in the rpm-ostree test we make a
`vmcheck` ref that conceptually overlays the default ref like
`fedora-atomic:fedora/26/x86_64/atomic-host`.

My current patch sets the source title to e.g.
"Dev overlay on fedora-atomic:fedora/26/x86_64/atomic-host".

Another case I'm working on now is importing OCI images to use
as host images.  For that case, the source title is
With this patch we could then set the original OCI image name + tag
as the source name, like:
"oci:cgwalters/demo-custom-fedora-atomic-host:26".
@cgwalters
Copy link
Member Author

OK, rebased 🏄 and updated with some prep commits and adds testing. Lifting WIP.

@jlebon
Copy link
Member

jlebon commented Oct 20, 2017

Looks good! Though the tests are complaining it seems.

@cgwalters
Copy link
Member Author

Whee, that was fun. Provoked a uboot integration bug. Fixup ⬆️

@jlebon
Copy link
Member

jlebon commented Oct 23, 2017

@rh-atomic-bot r+ 339a094

@rh-atomic-bot
Copy link

⌛ Testing commit 339a094 with merge 795a953...

rh-atomic-bot pushed a commit that referenced this pull request Oct 23, 2017
Pull out the commit metadata explicitly; still just rendering the version, but
this is prep for rendering other metadata keys.

Closes: #1296
Approved by: jlebon
rh-atomic-bot pushed a commit that referenced this pull request Oct 23, 2017
This is a freeform string useful to track/display when a commit is "derived"
from some other format.  For example, in the rpm-ostree test we make a
`vmcheck` ref that conceptually overlays the default ref like
`fedora-atomic:fedora/26/x86_64/atomic-host`.

My current patch sets the source title to e.g.
"Dev overlay on fedora-atomic:fedora/26/x86_64/atomic-host".

Another case I'm working on now is importing OCI images to use
as host images.  For that case, the source title is
With this patch we could then set the original OCI image name + tag
as the source name, like:
"oci:cgwalters/demo-custom-fedora-atomic-host:26".

Closes: #1296
Approved by: jlebon
@rh-atomic-bot
Copy link

☀️ Test successful - status-atomicjenkins
Approved by: jlebon
Pushing 795a953 to master...

cgwalters added a commit to cgwalters/rpm-ostree that referenced this pull request Oct 23, 2017
Depends: ostreedev/ostree#1296

As I mention in the commit there, I see two uses for this in rpm-ostree; first
in our test suite, and second for OCI-built image imports.

I also took a step further here and inject an `original-origin` metadata
key, though we aren't actually using that yet.  The problem I'm trying
to solve there is that repeated `make vmoverlay` starts chaining things up,
but that gets very confusing.  I think we should always have `vmoverlay` unwind
back to the base ref.  (Or at least do that by default)
cgwalters added a commit to cgwalters/rpm-ostree that referenced this pull request Oct 24, 2017
Depends: ostreedev/ostree#1296

As I mention in the commit there, I see two uses for this in rpm-ostree; first
in our test suite, and second for OCI-built image imports.

I also took a step further here and inject an `original-origin` metadata
key, though we aren't actually using that yet.  The problem I'm trying
to solve there is that repeated `make vmoverlay` starts chaining things up,
but that gets very confusing.  I think we should always have `vmoverlay` unwind
back to the base ref.  (Or at least do that by default)
rh-atomic-bot pushed a commit to coreos/rpm-ostree that referenced this pull request Oct 25, 2017
Depends: ostreedev/ostree#1296

As I mention in the commit there, I see two uses for this in rpm-ostree; first
in our test suite, and second for OCI-built image imports.

I also took a step further here and inject an `original-origin` metadata
key, though we aren't actually using that yet.  The problem I'm trying
to solve there is that repeated `make vmoverlay` starts chaining things up,
but that gets very confusing.  I think we should always have `vmoverlay` unwind
back to the base ref.  (Or at least do that by default)

Closes: #1069
Approved by: jlebon
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants