Open Stack

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 <mikal at stillhq.com> wrote:

> On Thu, Feb 6, 2014 at 8:16 PM, Matthew Gilliard
> <matthew.gilliard at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140206/ff5a22e1/attachment.html>