<div dir="ltr"><div>Hi All,</div><div><br></div><div>I'm working to get a strategy in place for delivery of OpenStack snaps. Below I've outlined an initial strategy, and I'd like to get your input.</div><div><br></div><div>I'm particularly interested in input from snap folks of course, but also from projects that install OpenStack and may want to be involved in snap CI/gating (ie. Ansible, Puppet, Charms, etc).</div><div><br></div><div><br></div><div>First a quick background of snaps, tracks, channels, and versions (skip to "Strategy" if you're already familiar with these concepts):</div><div><br></div><div>Snaps</div><div>---------</div><div>If you're not familiar with OpenStack snaps, see James Pages' intro at: <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-January/109743.html">http://lists.openstack.org/pipermail/openstack-dev/2017-January/109743.html</a></div><div>And if you'd like to just tip your toes in the water quickly, you can give the openstackclients snap a try: <a href="https://javacruft.wordpress.com/2017/02/03/snap-install-openstackclients/">https://javacruft.wordpress.com/2017/02/03/snap-install-openstackclients/</a></div><div><br></div><div>Tracks</div><div>---------</div><div>Snaps have the concept of tracks, which allow for publishing different series of software (ie. newton, ocata, pike would be separate tracks). In each track, you can publish a snap to any of the 4 channels based on how stable it is.</div><div><br></div><div>Channels</div><div>-------------</div><div>Snaps can be published to 4 different channels:</div><div>* edge:  for your most recent changes, probably untested</div><div>* beta:  used to provide preview releases of tested changes</div><div>* candidate:  used to vet uploads that should require no further code changes before moving to stable</div><div>* stable:  what most users will consume, stable and tested</div><div><br></div><div>Version</div><div>----------</div><div>Snaps include metadata where the software version can be specified.</div><div><br></div><div>For more details on tracks, channels, and versions, see: <a href="https://snapcraft.io/docs/reference/channels">https://snapcraft.io/docs/reference/channels</a></div><div><br></div><div><br></div><div>Strategy</div><div>-----------</div><div>Ok on to the strategy. Below I've outlined a proposed strategy for delivering snaps to the 4 different channels based on the level of testing they've undergone. Long-term we'd like to see the majority of this process automated, therefore the strategy I describe here is the end goal (and hence my overuse of "auto-").</div><div><br></div><div>Track Strategy</div><div>--------------------</div><div>pike:  auto-publish to pike channels according to channel strategy</div><div>ocata -> latest [0]:  auto-publish to latest (ocata) channels according to channel strategy</div><div>newton:<span class="gmail-Apple-tab-span" style="white-space:pre">     </span> auto-publish to newton channels according to channel strategy<span class="gmail-Apple-tab-span" style="white-space:pre">                </span></div><div>mitaka:<span class="gmail-Apple-tab-span" style="white-space:pre">        </span> auto-publish to mitaka channels according to channel strategy<span class="gmail-Apple-tab-span" style="white-space:pre">                </span></div><div>[0] The 'latest' track is the default for users when they install a snap. Therefore the 'latest' track will always include the latest stable release.</div><div><br></div><div>New repo in support of channel strategy</div><div>-----------------------------------------------------</div><div>snap-releases:</div><div>In order to enable channel testing, and publishing, of a known good set of snaps across OpenStack projects, I'd like to create a new 'snap-releases' repo. This would be a simple repo of yaml mappings, similar to [1], that would contain the current tracks/channels/versions for candidate and stable channels. For example, the snap-releases/ocata/cinder file may have 'candidate: 9.1.1' and 'stable: 9.0.0'.</div><div>[1] <a href="https://github.com/openstack/releases/tree/master/deliverables">https://github.com/openstack/releases/tree/master/deliverables</a></div><div><br></div><div>Channel<span class="gmail-Apple-tab-span" style="white-space:pre">       </span>Strategy</div><div>-------------------------</div><div>edge: each snap is auto-published to edge on every upstream commit</div><div>1) edge stage is triggered by each new upstream commit</div><div>2) version field is auto-populated with short git hash or pbr version</div><div>3) auto-publish snap to edge channel</div><div>notes:</div><div>* unit tests will have already passed on upstream gate by this time and prior to all future stages (and snaps don't apply any new patches)</div><div>* voting projects may want to vote more often than beta releases but voting on every edge update seems overboard; they could also vote on individual snap repo changes but they may be seldom.</div><div><br></div><div>beta: each snap is auto-published to beta on every upstream stable point release or development milestone</div><div>1) beta stage is triggered by new upstream release tar, e.g. cinder newton watches for 9.x.x</div><div>2) version field auto-populated with release version, e.g. for cinder, version=9.1.1</div><div>3) auto-open launchpad bug for SRU (stable release update)</div><div>4) auto-publish snap to beta channel</div><div>5) auto-propose snap-releases gerrit review to change candidate version; for example:</div><div>- candidate: 9.0.0, stable: 9.0.0</div><div>+ candidate: 9.1.1, stable: 9.0.0</div><div>6) voting projects smoke test, and vote, with this snap from beta, and all other snaps from candidate</div><div>7) SRU bug auto-updated with results of review</div><div>8) human interaction required if tests fail and may require fixed snap to be re-published</div><div><br></div><div>candidate: each snap is auto-published to candidate after successful testing of beta</div><div>1) candidate stage is triggered when snap-releases gerrit review for candidate is merged</div><div>2) auto-publish snap to candidate channel</div><div>3) SRU bug tagged with verification-needed</div><div>4) auto-propose snap-releases gerrit review to change stable version; for example:</div><div>- candidate: 9.1.1, stable: 9.0.0</div><div>+ candidate: 9.1.1, stable: 9.1.1</div><div>5) voting projects run, and vote, with this snap from candidate, and all other snaps from stable</div><div>6) SRU bug auto-tagged verification-done or verfication-failed based on snap-releases gerrit review</div><div>7) human interaction required if tests fail and may require fixed snap to be re-published</div><div><br></div><div>stable: each snap is auto-published to stable after successful testing of candidate and snap has lived in candidate channel for 7 days [2]</div><div>1) stable stage is triggered when snap-releases gerrit review for stable is merged</div><div>2) auto-publish snap to stable channel and auto-close SRU bug</div><div>[2] 7 day wait doesn't apply to development release.</div><div><br></div><div>If you made it this far, thanks for reading and I appreciate your feedback!</div><div><br></div><div>Regards,</div><div>Corey</div></div>