Re: [atomic-devel] draft of Every-two-week Fedora Atomic Host change proposal

[Colin Walters <walters verbum org>]

On Fri, Jun 19, 2015, at 09:50 AM, Matthew Miller wrote:
>
> So, maybe it's better to actually trigger image build on tree compose
> (iff there's an actual change)?

Everything should trigger on its inputs IMO and not time.
For example, images are triggered by tree compose *and* the spin-kickstarts git repo.

> Although, actually, skipping builds if
> nothing changes for a day actually introduces complication down the
> line, because testing/release systems need to know that the build was
> skipped on purpose, not a failure.

Direct support for *exactly that* is implemented today in the new rpm-ostree, based
on libhif(hawkey/librepo), as opposed to the old yum wrapper:

https://github.com/projectatomic/rpm-ostree/commit/aa190edfbf5a91ee7c92d3d9b1b186bda0e93f4a

We hit an issue trying to deploy it in Fedora 22 which will
be fixed once I get a newer libhif.

This is actually a quite powerful feature as it means rpm-ostree is now
much easier to toss into a CD pipeline of a larger yum repo (as Fedora is).
Trigger it on any change in the repo.  Then it'll just download the metadata,
do a depsolve, checksum all of our inputs, then compare that with a checksum
from the previous tree.

And you want to know whether or not the tool actually made a commit?
The --touch-if-changed is a simple way to do that, designed to be consumed
by higher level systems like Bodhi, Jenkins, shell scripts in cron, etc.

Every image-like tool in Fedora should do something like this IMO (e.g.
lorax).  Only the tool knows how it processes its input, so it's the right
place to understand whether it has something to do.

> Is there a glossary of ostree terms somewhere? 

It's mostly the same as git.

> A ref is basically a branch, right?

Yes.

> I was thinking that there would be two branches — main and testing. The
> testing branch would consist of "release + updates + updates-testing".
> (Possibly in the future this could be updates-bleeding, pulled directly
> from koji or some Copr with no bodhi step, but I don't want to
> overcomplicate initially.) 

We could go a *lot* faster if we dropped the requirement that individual
RPMs were signed, and relied on signing the tree itself.  That's a major
time sink in the current process.  (There's ways that could be improved
obviously too...)

> One possibility would be a manual trigger for the normally-twoweekly
> release scan. We should check with the security team, but I'm thinking
> that for a first pass, we could document the images as not being
> rebuilt async for security and advising doing an `atomic update`.

Yeah, a manual trigger should be fine.