[CentOS-devel] numbering and building the CentOS Atomic story

[Colin Walters]

Thanks for posting this!

On Wed, Jul 15, 2015, at 06:18 AM, Karanbir Singh wrote:
>
> For (a) above, I propose we run an ostree repo, managed by a
> centos-release-projectatomic rpm file; the ostree repo for this should
> be delivered from buildlogs.centos.org, and updated in sync with the
> rest of the content in the CentOS Linux repos, as well as the atomic sig
> run repos in the community build service. In order to keep things
> simple, it might be good enough to run this ostree update on a nightly
> basis.

With current rpm-ostree it is very inexpensive to just run it constantly (e.g
every 5 minutes), or better, edge triggered from push notification from
one of the rpm-md input repos being regenerated, and it will quickly do
nothing if there's nothing to do.

See:
https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-June/msg00041.html

> I propose this nightly build be run from an automated harness at
> ci.centos.org, which would pull down the last ostree repo, do its
> updates, commit the changeset, and have a way to push back into the
> buildlogs.centos.org host the new repo. 

Transitioning it from CI to CD then.  There's lots of interesting aspects to
this...

> As an additional downstream
> trigger, we should then build nightly the images derived from this

Not sure I understand the rationale of this nightly thing here either.  Why
not just trigger all images when the ostree commit changes?  That can
be implemented by a few lines of shell to compare the previous/new
commit IDs, and/or rpm-ostree compose tree --touch-if-changed.

> ostree repo ( this would be the GenericCloud, Vagrant, ISO files etc for
> the atomic build that maps to the latest commit in that ostree repo).
> For numbering, I propose we use datestamp with a build id eg:
> 20150715_01, this maps well to user expectations and also sets suitable
> confidence in the build.

That versioning seems fine to me.

> Key requirement to applying updates is that the atomic host needs a
> reboot to consume the latest ostree propagated changes. So while the
> updated tree would be available nightly, uses might chose to still apply
> it nightly, they can control to a fairly good granularity the point in
> time they wish to run.

That sounds like a different branch name?

> The atomic sig can then decide which point in time build they wish to
> promote as their 4wk 'release' image. The ostree repo + images +
> documentation for that build can then be promoted to a release location.
> This would then be announced via projectatomic.io
> 
> I'm also proposing that this build be called the project atomic build.
> 
> for (b) above, I'm proposing we use the same process as for (a), except
> for the following major changes :
> - content in (a) is signed, 

Is *not* signed?  Or is?  Note that OSTree actually supports multiple
GPG signatures per commit, intended for "binary promotion" workflows.
But:

> so while we can build things nightly, we
> cant promote that content as is. 

Right, and the SIG build may have things that aren't in the rebuild,
so it wouldn't make sense to binary-promote.

> - the update cycle for the ostree repo should be undecided, so we can
> promote a new update if there are security issues that merit this work,
> and also when there is a new version of a core component that we might
> want to push out out of band ( i.e not wait on the next upstream build )

I doubt anyone would object if we unconditionally always included the Z stream
errata and released the tree commit immediately after the RPM rebuild.