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...
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.
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...
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,
-
Colin Walters -
Karanbir Singh