Re: [openstack-dev] [nova] Making periodic tasks config consistent.
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.gilli...@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 wrote: > >> On Thu, Feb 6, 2014 at 8:16 PM, Matthew Gilliard >> 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 >> 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
Re: [openstack-dev] [nova] Making periodic tasks config consistent.
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 wrote: > On Thu, Feb 6, 2014 at 8:16 PM, Matthew Gilliard > 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 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
Re: [openstack-dev] [nova] Making periodic tasks config consistent.
On Thu, Feb 6, 2014 at 8:16 PM, Matthew Gilliard 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 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] [nova] Making periodic tasks config consistent.
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 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? Thanks, Matthew Gilliard [1] https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4702 [2] https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4702 [3] https://github.com/openstack/nova/blob/master/nova/openstack/common/periodic_task.py#L144 [4] https://github.com/openstack/nova/blob/master/nova/openstack/common/periodic_task.py#L39 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
