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

[Matthew Miller <mattdm mattdm org>]

On Thu, Jun 18, 2015 at 11:11:12PM -0400, Colin Walters wrote:
> > Now updated based on some feedback and with a schematic of how I
> > envision the build→test→release→present process working. If anything in 
> > that looks wrong, let's fix it sooner rather than later.
> One thing that's absolutely essential here is to determine how the OSTree
> commit process happens.  Your diagram omits this AFAICS.

Thanks — yes, it does. My assumption was/is that it happens before the
nightly timer.

> Currently the tree compose happens as part of Bodhi for updates,
> so whenever a package passes karma, and then goes through the whole
> updates signing process etc, it gets committed to the tree
> too - there's no Atomic-specific gating or checking.

So, maybe it's better to actually trigger image build on tree compose
(iff there's an actual change)? 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.

> But the high level question is - for delivery, does the tree stay
> sync'd to the images, and have the same version, or not?
> My initial take here is to sync the tree commit with the image for delivery,
> but to have the tree operate asynchronously of image generation for
> updates-testing.  There needs to be a fast feedback cycle for
> development inside the two weeks - this could be the updates-testing
> ref that already exists.

Is there a glossary of ostree terms somewhere? A ref is basically a
branch, right?

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.) The main branch would consist of "release +
updates + selected packages from updates-testing".

*thinking while typing*

Hmmm, actually, it might make sense for _both_ of these branches to be
"release plus human-selected updates from both updates and
updates-testing", with those updates merged from the atomic testing
branch to the atomic main branch when someone on the team judges
they're ready.

Mostly, I imagine, the updates that would be pulled in (first to
testing, then to main) would be ones directly affecting the work —
others could be left out, or there could be yet another branch which
includes them all for people who want to opt in to them.

This would also require someone to be responsible for selecting and
including packages with security fixes. (Or possibly updates which are
marked as security fixes in bodhi would go into at least the testing
branch automatically?)

Anyway, then: the nightly (and/or triggered) images would be in sync
with the main branch. The released images would correspond to commits
along that branch — possibly with specific names/tags (like 2015-w43 or
2015-r6 or whatever scheme we pick), if there's a way to go back and
add those to the tree retrospectively — but there wouldn't be a
released image for every commit.


> (And for all of this two week discussion, we need to think about async
>  security errata and how that's versioned/tested/shipped)

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`.

-- 
Matthew Miller            mattdm mattdm org             <http://mattdm.org/>
Fedora Project Leader  mattdm fedoraproject org  <http://fedoraproject.org/>