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.