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