Open Stack

I think I mangled my explanation a bit, sorry.  I'm suggesting 2 things:

1 - make Nova's use of 0-length polling period consistent with the Oslo
decorator.  Nova-only.

2 - have Oslo's decorator use 0-length to mean "call regularly at the
default period",
    rather than "call whenever any other task is run".

These can be done separately, but both are breaking changes to the current
behaviours so the approach of logging deprecation warnings and changing
behaviour in Juno seems appropriate in both cases.  I will make a start
soon on the Nova side, and see how it is received by the reviewers.

  Matthew





On Thu, Feb 6, 2014 at 11:44 AM, Matthew Gilliard <
matthew.gilliard at gmail.com> wrote:

> 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/20140207/41035574/attachment.html>