<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.gmail-apple-tab-span
{mso-style-name:gmail-apple-tab-span;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:Calibri;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Adding the [deployment] tag as the catch-all for deployment projects as I think they’d be interested.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-family:Calibri;color:black">From:
</span></b><span style="font-family:Calibri;color:black">Corey Bryant <corey.bryant@canonical.com><br>
<b>Reply-To: </b>"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org><br>
<b>Date: </b>Thursday, March 2, 2017 at 3:31 PM<br>
<b>To: </b>OpenStack Development Mailing List <openstack-dev@lists.openstack.org><br>
<b>Subject: </b>[openstack-dev] [snaps][ansible][puppet][charms] OpenStack snaps delivery strategy<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Hi All,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">First a quick background of snaps, tracks, channels, and versions (skip to "Strategy" if you're already familiar with these concepts):<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Snaps<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">---------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Tracks<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">---------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Channels<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">-------------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Snaps can be published to 4 different channels:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">* edge: for your most recent changes, probably untested<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">* beta: used to provide preview releases of tested changes<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">* candidate: used to vet uploads that should require no further code changes before moving to stable<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">* stable: what most users will consume, stable and tested<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Version<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">----------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Snaps include metadata where the software version can be specified.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">For more details on tracks, channels, and versions, see:
<a href="https://snapcraft.io/docs/reference/channels">https://snapcraft.io/docs/reference/channels</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Strategy<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">-----------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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-").<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Track Strategy<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">--------------------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">pike: auto-publish to pike channels according to channel strategy<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">ocata -> latest [0]: auto-publish to latest (ocata) channels according to channel strategy<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">newton:<span class="gmail-apple-tab-span">
</span>auto-publish to newton channels according to channel strategy<span class="gmail-apple-tab-span"><o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">mitaka:<span class="gmail-apple-tab-span">
</span>auto-publish to mitaka channels according to channel strategy<span class="gmail-apple-tab-span"><o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">[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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">New repo in support of channel strategy<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">-----------------------------------------------------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">snap-releases:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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'.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">[1] <a href="https://github.com/openstack/releases/tree/master/deliverables">
https://github.com/openstack/releases/tree/master/deliverables</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Channel<span class="gmail-apple-tab-span">
</span>Strategy<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">-------------------------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">edge: each snap is auto-published to edge on every upstream commit<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">1) edge stage is triggered by each new upstream commit<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">2) version field is auto-populated with short git hash or pbr version<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">3) auto-publish snap to edge channel<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">notes:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">* 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)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">* 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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">beta: each snap is auto-published to beta on every upstream stable point release or development milestone<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">1) beta stage is triggered by new upstream release tar, e.g. cinder newton watches for 9.x.x<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">2) version field auto-populated with release version, e.g. for cinder, version=9.1.1<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">3) auto-open launchpad bug for SRU (stable release update)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">4) auto-publish snap to beta channel<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">5) auto-propose snap-releases gerrit review to change candidate version; for example:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">- candidate: 9.0.0, stable: 9.0.0<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">+ candidate: 9.1.1, stable: 9.0.0<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">6) voting projects smoke test, and vote, with this snap from beta, and all other snaps from candidate<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">7) SRU bug auto-updated with results of review<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">8) human interaction required if tests fail and may require fixed snap to be re-published<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">candidate: each snap is auto-published to candidate after successful testing of beta<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">1) candidate stage is triggered when snap-releases gerrit review for candidate is merged<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">2) auto-publish snap to candidate channel<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">3) SRU bug tagged with verification-needed<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">4) auto-propose snap-releases gerrit review to change stable version; for example:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">- candidate: 9.1.1, stable: 9.0.0<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">+ candidate: 9.1.1, stable: 9.1.1<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">5) voting projects run, and vote, with this snap from candidate, and all other snaps from stable<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">6) SRU bug auto-tagged verification-done or verfication-failed based on snap-releases gerrit review<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">7) human interaction required if tests fail and may require fixed snap to be re-published<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">stable: each snap is auto-published to stable after successful testing of candidate and snap has lived in candidate channel for 7 days [2]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">1) stable stage is triggered when snap-releases gerrit review for stable is merged<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">2) auto-publish snap to stable channel and auto-close SRU bug<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">[2] 7 day wait doesn't apply to development release.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">If you made it this far, thanks for reading and I appreciate your feedback!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Regards,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Corey<o:p></o:p></p>
</div>
</div>
</div>
<hr>
Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy
- This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately
by e-mail at abuse@rackspace.com and delete the original message. Your cooperation is appreciated.
</body>
</html>