Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Michał Dulko 
On 01/12/2016 03:02 PM, Chris Dent wrote:
> On Tue, 12 Jan 2016, Amrith Kumar wrote:
>
>> if var > 0:
>> ... something ...
>>
>> To
>>
>> if var:
>> ... something ...
>
> I may be missing something but the above is not a stylistic change
> if var can ever be negative. In one of the ceilometer changes[1] for
> example, this change will change the flow of the code. In this
> particular example if some caller do _do_test_iter_images sends
> page_size=-1 bad things will happen. Since it is test code the scope
> of the damage is limited, but I prefer the more explicit > 0.
>
> I've not checked all the reviews but if it is showing up in one
> place seems like it could in others.
>
> [1]
> https://review.openstack.org/#/c/266211/1/ceilometer/tests/unit/image/test_glance.py
>

Same thing for Cinder change - it's failing multiple unit tests because
this changes the logic of the statement.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread gord chung 
not a fan of these changes since it messes up git blame and it becomes 
harder to track down author if you have questions relating to bug/code.


that said, "if var > 0" is not the same as "if var". in the latter, var 
can be any number (negative or positive) or any other datatype and it'll 
evaluate to True. so... don't blindly do this.


On 12/01/2016 8:51 AM, Amrith Kumar wrote:

I've tagged this message with the projects impacted by a series of change sets:

[trove] https://review.openstack.org/#/c/266220/
[neutron] https://review.openstack.org/#/c/266156/1
[cinder] https://review.openstack.org/#/c/266099/2
[swift] https://review.openstack.org/#/c/266185/1
[ceilometer] https://review.openstack.org/#/c/266211/1
[nova] https://review.openstack.org/#/c/266143/2
[keystone] https://review.openstack.org/#/c/266203/2
[sahara] https://review.openstack.org/#/c/266230/1
[glance] https://review.openstack.org/#/c/266192/1
[neutron-lbaas] https://review.openstack.org/#/c/266181/1

I would like the guidance of the developer community in figuring out how to 
proceed with this change, and changes like this.

The change, in essence changes a construct of the kind:

if var > 0:
... something ...

To

if var:
... something ...

In a couple of cases, it also changes messages from (for example, in Trove)

"Limit value must be > 0" to
"Limit value must be greater than zero"

My question to the ML is this, should stylistic changes of this kind be handled 
in a consistent way across all projects, maybe with a hacking rule and some 
discussion on the ML first? After all, if this change is worthwhile, it is 
worth ensuring that this construct that we are seeking to eliminate, does not 
reenter the code base.

For what it is worth, I agree with Vitaly Grindev [sahara, in review 
https://review.openstack.org/#/c/266230/1]. I think the code before the change 
was more intuitive and readable.

Thanks,

-amrith


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
gord


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Ihar Hrachyshka 

Amrith Kumar  wrote:

I've tagged this message with the projects impacted by a series of change  
sets:


[trove] https://review.openstack.org/#/c/266220/
[neutron] https://review.openstack.org/#/c/266156/1
[cinder] https://review.openstack.org/#/c/266099/2
[swift] https://review.openstack.org/#/c/266185/1
[ceilometer] https://review.openstack.org/#/c/266211/1
[nova] https://review.openstack.org/#/c/266143/2
[keystone] https://review.openstack.org/#/c/266203/2
[sahara] https://review.openstack.org/#/c/266230/1
[glance] https://review.openstack.org/#/c/266192/1
[neutron-lbaas] https://review.openstack.org/#/c/266181/1

I would like the guidance of the developer community in figuring out how  
to proceed with this change, and changes like this.


The change, in essence changes a construct of the kind:

if var > 0:
... something ...

To

if var:
... something …


The change is not stylistic. F.e. before the change, var == -1 would not  
result in triggering the conditional body; while in the new version, it  
does trigger it. Unless the assumption that var is >= 0 is always true,  
it’s just a wrong change. F.e. I suspect in *, you effectively make error  
code returned by fork() (-1) to be considered as successful value.


* https://review.openstack.org/#/c/266156/1/neutron/agent/linux/daemon.py

I also don’t see any value in such a change.



In a couple of cases, it also changes messages from (for example, in Trove)

"Limit value must be > 0" to
"Limit value must be greater than zero"

My question to the ML is this, should stylistic changes of this kind be  
handled in a consistent way across all projects, maybe with a hacking  
rule and some discussion on the ML first? After all, if this change is  
worthwhile, it is worth ensuring that this construct that we are seeking  
to eliminate, does not reenter the code base.




If a stylistic change is worth it and can be automated, yes, it’s better to  
have a hacking rule for that. Though I doubt that’s the case here.


For what it is worth, I agree with Vitaly Grindev [sahara, in review  
https://review.openstack.org/#/c/266230/1]. I think the code before the  
change was more intuitive and readable.


Thanks,

-amrith


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Chris Dent 

On Tue, 12 Jan 2016, Amrith Kumar wrote:


if var > 0:
... something ...

To

if var:
... something ...


I may be missing something but the above is not a stylistic change
if var can ever be negative. In one of the ceilometer changes[1] for
example, this change will change the flow of the code. In this
particular example if some caller do _do_test_iter_images sends
page_size=-1 bad things will happen. Since it is test code the scope
of the damage is limited, but I prefer the more explicit > 0.

I've not checked all the reviews but if it is showing up in one
place seems like it could in others.

[1] 
https://review.openstack.org/#/c/266211/1/ceilometer/tests/unit/image/test_glance.py

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread David Stanek 
On Tue, Jan 12, 2016 at 8:51 AM, Amrith Kumar  wrote:

> I've tagged this message with the projects impacted by a series of change
> sets:
>
> [trove] https://review.openstack.org/#/c/266220/
> [neutron] https://review.openstack.org/#/c/266156/1
> [cinder] https://review.openstack.org/#/c/266099/2
> [swift] https://review.openstack.org/#/c/266185/1
> [ceilometer] https://review.openstack.org/#/c/266211/1
> [nova] https://review.openstack.org/#/c/266143/2
> [keystone] https://review.openstack.org/#/c/266203/2
> [sahara] https://review.openstack.org/#/c/266230/1
> [glance] https://review.openstack.org/#/c/266192/1
> [neutron-lbaas] https://review.openstack.org/#/c/266181/1
>
> I would like the guidance of the developer community in figuring out how
> to proceed with this change, and changes like this.
>
> The change, in essence changes a construct of the kind:
>
> if var > 0:
> ... something ...
>
> To
>
> if var:
> ... something ...
>
> In a couple of cases, it also changes messages from (for example, in Trove)
>
> "Limit value must be > 0" to
> "Limit value must be greater than zero"
>
> My question to the ML is this, should stylistic changes of this kind be
> handled in a consistent way across all projects, maybe with a hacking rule
> and some discussion on the ML first? After all, if this change is
> worthwhile, it is worth ensuring that this construct that we are seeking to
> eliminate, does not reenter the code base.
>

The code above is not stylistic in nature.  It actually changes the
semantics of the check. This should not be done blindly across the board.

In the first case it looks for a value to be greater than a constant. In
the second case it looks for a value to have a truthy value.


> For what it is worth, I agree with Vitaly Grindev [sahara, in review
> https://review.openstack.org/#/c/266230/1]. I think the code before the
> change was more intuitive and readable.
>

Only if the code is correct. In that review I saw you changing "len(x) > 0"
to "len(x)" and that's fine. But you also changed a check looking at the
status code from a conductor call to no longer allow negative return
values. I have no idea if it returns negative numbers, but in this case I
would guess the "> 0" had a purpose.

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Amrith Kumar 
I've tagged this message with the projects impacted by a series of change sets:

[trove] https://review.openstack.org/#/c/266220/
[neutron] https://review.openstack.org/#/c/266156/1
[cinder] https://review.openstack.org/#/c/266099/2
[swift] https://review.openstack.org/#/c/266185/1
[ceilometer] https://review.openstack.org/#/c/266211/1
[nova] https://review.openstack.org/#/c/266143/2
[keystone] https://review.openstack.org/#/c/266203/2
[sahara] https://review.openstack.org/#/c/266230/1
[glance] https://review.openstack.org/#/c/266192/1
[neutron-lbaas] https://review.openstack.org/#/c/266181/1

I would like the guidance of the developer community in figuring out how to 
proceed with this change, and changes like this.

The change, in essence changes a construct of the kind:

if var > 0:
... something ...

To

if var:
... something ...

In a couple of cases, it also changes messages from (for example, in Trove)

"Limit value must be > 0" to 
"Limit value must be greater than zero"

My question to the ML is this, should stylistic changes of this kind be handled 
in a consistent way across all projects, maybe with a hacking rule and some 
discussion on the ML first? After all, if this change is worthwhile, it is 
worth ensuring that this construct that we are seeking to eliminate, does not 
reenter the code base.

For what it is worth, I agree with Vitaly Grindev [sahara, in review 
https://review.openstack.org/#/c/266230/1]. I think the code before the change 
was more intuitive and readable. 

Thanks,

-amrith


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Sergey Lukjanov 
Hi,

IMO if you want to do the stylistic changes - make the hacking rule for it
first. Not all of this particular changes are useful and even correct. The
explicit comparison with zero in Python where we have number of implicit
casts to bool is much better in such cases.

Thanks.

On Tue, Jan 12, 2016 at 5:02 PM, Chris Dent  wrote:

> On Tue, 12 Jan 2016, Amrith Kumar wrote:
>
> if var > 0:
>> ... something ...
>>
>> To
>>
>> if var:
>> ... something ...
>>
>
> I may be missing something but the above is not a stylistic change
> if var can ever be negative. In one of the ceilometer changes[1] for
> example, this change will change the flow of the code. In this
> particular example if some caller do _do_test_iter_images sends
> page_size=-1 bad things will happen. Since it is test code the scope
> of the damage is limited, but I prefer the more explicit > 0.
>
> I've not checked all the reviews but if it is showing up in one
> place seems like it could in others.
>
> [1]
> https://review.openstack.org/#/c/266211/1/ceilometer/tests/unit/image/test_glance.py
>
> --
> Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Amrith Kumar 
Chris, Ihar,

I assumed that this was stylistic based on the fact that in the places where I 
was seeing it, it seemed to be the case that the LHS was intuitively positive 
(a length, for example). I did not exhaustively verify this but yes, you are 
correct, the construct 

If var 

is the same as  (I believe)

if var is not None

and therefore the change does change the semantic of the code. Modulo my 
assumption though, it would be strictly stylistic which is why I phrased it as 
such.

Thanks for the quick responses, so far it sounds like the tally is:

Not-Worthwhile: 3
Changes semantics: 1
Others: 0

I created a quick poll to tally results

https://www.surveymonkey.com/r/DLRN9TP

Thanks,

-amrith




> -Original Message-
> From: Chris Dent [mailto:cdent...@anticdent.org]
> Sent: Tuesday, January 12, 2016 9:03 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev]
> [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance
> ][neutron-lbaas][imm] stylistic changes to code, how do we handle them?
> 
> On Tue, 12 Jan 2016, Amrith Kumar wrote:
> 
> > if var > 0:
> > ... something ...
> >
> > To
> >
> > if var:
> > ... something ...
> 
> I may be missing something but the above is not a stylistic change if var can
> ever be negative. In one of the ceilometer changes[1] for example, this
> change will change the flow of the code. In this particular example if some
> caller do _do_test_iter_images sends
> page_size=-1 bad things will happen. Since it is test code the scope of the
> damage is limited, but I prefer the more explicit > 0.
> 
> I've not checked all the reviews but if it is showing up in one place seems 
> like
> it could in others.
> 
> [1]
> https://review.openstack.org/#/c/266211/1/ceilometer/tests/unit/image/te
> st_glance.py
> 
> --
> Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
> freenode: cdent tw: @anticdent
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread David Stanek 
On Tue, Jan 12, 2016 at 9:13 AM, Amrith Kumar  wrote:

> Chris, Ihar,
>
> I assumed that this was stylistic based on the fact that in the places
> where I was seeing it, it seemed to be the case that the LHS was
> intuitively positive (a length, for example). I did not exhaustively verify
> this but yes, you are correct, the construct
>
> If var
>
> is the same as  (I believe)
>
> if var is not None


Those two statements are also not the same. 'if var' will be True is 'var'
is *only* True values. 'if var is not None' will be True *everything*
except None, so 0, '', [], etc. will not pass the first test, but will pass
the second.



-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek
www: http://dstanek.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Stefano Maffulli 
On 01/12/2016 06:13 AM, Amrith Kumar wrote:
[...]
> I did not exhaustively verify this but 
[...]

A fair question to ask then is, why are you proposing these patches?

> I created a quick poll to tally results

oh no, not another survey! :) Sometimes I feel that survey-itis[1] is a
consequence of the chronic meeting-itis[2] that OpenStack suffers from.

/stef

[1] a disease of online communities whose leaders are afraid to take
actions and revert to online polls before making any decision. It's
caused by the same pathogens that forces governments to appeal to the
interests and conceptions (such as hopes and fears) of the general
population (see populism).
[2] another disease

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Amrith Kumar 
Stefano, 

I didn't propose the changes. They are largely -1'ed or -2'ed now.

Fair point on the survey!

-amrith

> -Original Message-
> From: Stefano Maffulli [mailto:stef...@openstack.org]
> Sent: Tuesday, January 12, 2016 1:00 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev]
> [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance
> ][neutron-lbaas][imm] stylistic changes to code, how do we handle them?
> 
> On 01/12/2016 06:13 AM, Amrith Kumar wrote:
> [...]
> > I did not exhaustively verify this but
> [...]
> 
> A fair question to ask then is, why are you proposing these patches?
> 
> > I created a quick poll to tally results
> 
> oh no, not another survey! :) Sometimes I feel that survey-itis[1] is a
> consequence of the chronic meeting-itis[2] that OpenStack suffers from.
> 
> /stef
> 
> [1] a disease of online communities whose leaders are afraid to take
> actions and revert to online polls before making any decision. It's
> caused by the same pathogens that forces governments to appeal to the
> interests and conceptions (such as hopes and fears) of the general
> population (see populism).
> [2] another disease
> 
> __
> 
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread Flavio Percoco 

On 12/01/16 15:01 +0100, Ihar Hrachyshka wrote:

Amrith Kumar  wrote:

I've tagged this message with the projects impacted by a series of 
change sets:


[trove] https://review.openstack.org/#/c/266220/
[neutron] https://review.openstack.org/#/c/266156/1
[cinder] https://review.openstack.org/#/c/266099/2
[swift] https://review.openstack.org/#/c/266185/1
[ceilometer] https://review.openstack.org/#/c/266211/1
[nova] https://review.openstack.org/#/c/266143/2
[keystone] https://review.openstack.org/#/c/266203/2
[sahara] https://review.openstack.org/#/c/266230/1
[glance] https://review.openstack.org/#/c/266192/1
[neutron-lbaas] https://review.openstack.org/#/c/266181/1

I would like the guidance of the developer community in figuring out 
how to proceed with this change, and changes like this.


The change, in essence changes a construct of the kind:

if var > 0:
... something ...

To

if var:
... something …


The change is not stylistic. F.e. before the change, var == -1 would 
not result in triggering the conditional body; while in the new 
version, it does trigger it. Unless the assumption that var is >= 0 is 
always true, it’s just a wrong change. F.e. I suspect in *, you 
effectively make error code returned by fork() (-1) to be considered 
as successful value.


* https://review.openstack.org/#/c/266156/1/neutron/agent/linux/daemon.py

I also don’t see any value in such a change.



In addition to the above, I believe `if var > 0` is faster than `if var` just
like `if x is None` is (normally?) faster than `if not x`.



In a couple of cases, it also changes messages from (for example, in Trove)

"Limit value must be > 0" to
"Limit value must be greater than zero"

My question to the ML is this, should stylistic changes of this kind 
be handled in a consistent way across all projects, maybe with a 
hacking rule and some discussion on the ML first? After all, if this 
change is worthwhile, it is worth ensuring that this construct that 
we are seeking to eliminate, does not reenter the code base.




If a stylistic change is worth it and can be automated, yes, it’s 
better to have a hacking rule for that. Though I doubt that’s the case 
here.


For what it is worth, I agree with Vitaly Grindev [sahara, in review 
https://review.openstack.org/#/c/266230/1]. I think the code before 
the change was more intuitive and readable.


Thanks,

-amrith


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove][neutron][cinder][swift][ceilometer][nova][keystone][sahara][glance][neutron-lbaas][imm] stylistic changes to code, how do we handle them?

2016-01-12 Thread michael mccune 

On 01/12/2016 08:51 AM, Amrith Kumar wrote:

My question to the ML is this, should stylistic changes of this kind be handled 
in a consistent way across all projects, maybe with a hacking rule and some 
discussion on the ML first? After all, if this change is worthwhile, it is 
worth ensuring that this construct that we are seeking to eliminate, does not 
reenter the code base.


in general, i would prefer to leave these stylistic choices up to 
individual projects. the specific change that is being proposed may make 
sense for some projects but not for others.


i like the idea of a "hacking rule" or some sort of coding style guides, 
but i'm sceptical about creating some sort of openstack coding guide. 
i'm happy with us continuing to use pep8 and the individual projects' 
guidance as the bar.



For what it is worth, I agree with Vitaly Grindev [sahara, in review 
https://review.openstack.org/#/c/266230/1]. I think the code before the change 
was more intuitive and readable.


+1

regards,
mike

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev