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

Hi,

On 15/07/15 22:41, Colin Walters wrote:
> 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.

sounds good, lets do that!

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

That makes sense... compare the commit, and if changed, rebuild images
as well.

>> 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?

we could do that as well. But mostly, my point was that if folks are
running a nightly ostree upgrade, does not automatically mean they are
running the latest tree

>> 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:

yup, sorry - mistyped that in. (a) is not signed.
> 
>> 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.

agreed. But it would be nice to get some level of testing in place for
this though, i just feel a bit uncomfortable doing this otherwise. Also
there are a few fiddly mechanics to link this into the regular distro
rpm updates process. Something for next month :).

regards,

-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc