<div dir="ltr"><div><div><div><div>If there is agreement that it's a change worth making, then I expect something like:<br><br></div>1/ Add a warning for users who use period of 0 or use the default.  Both in the literal sense of log.warning() and in the documentation.<br>
</div>2/ wait for a full release-cycle<br></div>3/ make the actual change in Juno.<br><br></div><div>Does that make sense?<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 6, 2014 at 9:46 AM, Michael Still <span dir="ltr"><<a href="mailto:mikal@stillhq.com" target="_blank">mikal@stillhq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Feb 6, 2014 at 8:16 PM, Matthew Gilliard<br>
<<a href="mailto:matthew.gilliard@gmail.com">matthew.gilliard@gmail.com</a>> wrote:<br>
> Hello everyone.<br>
><br>
>   wrt these bugs: <a href="https://bugs.launchpad.net/nova/+bug/1276203" target="_blank">https://bugs.launchpad.net/nova/+bug/1276203</a><br>
> <a href="https://bugs.launchpad.net/nova/+bug/1272830" target="_blank">https://bugs.launchpad.net/nova/+bug/1272830</a> - I'd just like to make sure<br>
> that the approach I'm planning makes sense.<br>
><br>
>   To summarise: Currently there are a number of methods in<br>
> compute/manager.py that use the @periodic_task decorator.  Some of them also<br>
> do their own checks about how often they are called, and use a convention of<br>
> polling period = 0 to disable the method by returning early (although this<br>
> is sometimes implemented as <=0 [1] and sometimes as ==0 [2]).  In the<br>
> decorator itself though, a polling period of 0 is used to mean "call this<br>
> method any time any other period task is run" [3].  It's difficult to<br>
> predict how often this might be, and it may not be at regular intervals.<br>
><br>
>   I'd like to make this more consistent and predictable.  My plan is to use<br>
> the following:<br>
><br>
>   - Any positive integer: the method is called every <this many> seconds,<br>
> best effort is made not to call it more or less often.<br>
>   - 0: the method will be called regularly at the default period.  Currently<br>
> hard-coded to 60s [4] this could be made into a config option<br>
>   - Any negative integer: the method will not be called<br>
><br>
>   All this logic would be contained in the decorator so that the methods<br>
> themselves can just get on with whatever business they have.  So far, I hope<br>
> this isn't too contentious - just clean code.  Is there any case that I've<br>
> missed?  The fix will necessarily be a breaking change.  So how do you<br>
> suggest I approach that aspect?  As it's common code, should I actually be<br>
> looking to make these changes in Oslo first then porting them in?<br>
<br>
</div></div>The decorator comes from oslo, so you're talking about changing the<br>
default flag behaviour for pretty much every openstack project here.<br>
How do we do this in a way which doesn't have unexpected side effects<br>
for deployments?<br>
<span class="HOEnZb"><font color="#888888"><br>
Michael<br>
<br>
--<br>
Rackspace Australia<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div>