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