<div dir="ltr">Sure, I can take a pass at this.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 15, 2015 at 2:11 AM, Tom Fifield <span dir="ltr"><<a href="mailto:tom@openstack.org" target="_blank">tom@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
One of our long mooted tags has been something that captures the ease of upgrade for a service.<br>
<br>
We've got a lot of inherit knowledge about this stuff that would be great to capture, for example:<br>
<br>
* Swift just eats upgrades up - whether you go for every point release, or do the N to N+1 jump, provided you read the release notes it's basically always a good time with Swift.<br>
* Nova's upgrade_levels is pretty amazing, too. In recent versions you can run N+1 apis with a mix of N and N+1 compute nodes - quite convenient.<br>
* Neutron in some configurations dumps all of the flows, you have to watch dhcp timeouts, how long services are offline etc, so a few little traps that keep it from being perfect.<br>
<br>
If we could somehow make this into a tag, that'd be great. Anyone want to have a go?<br>
<br>
<br>
Regards,<br>
<br>
<br>
<br>
Tom<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div><br></div>