Re: [openstack-dev] [Manila] ALLOWED_EXTRA_MISSING is cover.sh

2016-02-11 Thread John Spray 
On Wed, Feb 10, 2016 at 6:39 PM, Valeriy Ponomaryov
 wrote:
> Hello, John
>
> Note, that digit "4" defines amount of "python code blocks", not "python
> code lines". So, you can have uncovered some log message that consists of
> 100 lines. But it will be counted as just 1.

Ah, good to know.

> Who "we" have requirement that new drivers have 90% unit test coverage?

http://docs.openstack.org/developer/manila/devref/driver_requirements.html#unit-tests

> And, Manila CI coverage job non-voting. So, you are not blocked by it.
>
> On Wed, Feb 10, 2016 at 8:30 PM, Knight, Clinton 
> wrote:
>>
>> Hi, John.  This is but one reason the coverage job doesn¹t vote; it has
>> other known issues.  It is primarily a convenience tool that lets core
>> reviewers know if they should look more deeply into unit test coverage.
>> For a new driver such as yours, I typically pull the code and check
>> coverage for each new file in PyCharm rather than relying on the coverage
>> job.  Feel free to propose enhancements to the job, though.
>>
>> Clinton
>>
>>
>> On 2/10/16, 1:02 PM, "John Spray"  wrote:
>>
>> >Hi,
>> >
>> >I noticed that the coverage script is enforcing a hard limit of 4 on
>> >the number of extra missing lines introduced.  We have a requirement
>> >that new drivers have 90% unit test coverage, which the ceph driver
>> >meets[1], but it's tripping up on that absolute 4 line limit.
>> >
>> >What do folks think about tweaking the script to do a different
>> >calculation, like identifying new files and permitting 10% of the line
>> >count of the new files to be missed?  Otherwise I think the 90% target
>> >is going to continually conflict with the manila-coverage CI task.
>> >
>> >Cheers,
>> >John
>> >
>> >1.
>>
>> > >http://logs.openstack.org/11/270211/19/check/manila-coverage/47b79d2/cover
>> >/manila_share_drivers_cephfs_py.html
>> >2.
>>
>> > >http://logs.openstack.org/11/270211/19/check/manila-coverage/47b79d2/conso
>> >le.html
>> >
>>
>> > >__
>> >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
>
>
>
>
> --
> Kind Regards
> Valeriy Ponomaryov
> www.mirantis.com
> vponomar...@mirantis.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 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] [Manila] ALLOWED_EXTRA_MISSING is cover.sh

2016-02-10 Thread Valeriy Ponomaryov 
Hello, John

Note, that digit "4" defines amount of "python code blocks", not "python
code lines". So, you can have uncovered some log message that consists of
100 lines. But it will be counted as just 1.
Who "we" have requirement that new drivers have 90% unit test coverage?
And, Manila CI coverage job non-voting. So, you are not blocked by it.

On Wed, Feb 10, 2016 at 8:30 PM, Knight, Clinton 
wrote:

> Hi, John.  This is but one reason the coverage job doesn¹t vote; it has
> other known issues.  It is primarily a convenience tool that lets core
> reviewers know if they should look more deeply into unit test coverage.
> For a new driver such as yours, I typically pull the code and check
> coverage for each new file in PyCharm rather than relying on the coverage
> job.  Feel free to propose enhancements to the job, though.
>
> Clinton
>
>
> On 2/10/16, 1:02 PM, "John Spray"  wrote:
>
> >Hi,
> >
> >I noticed that the coverage script is enforcing a hard limit of 4 on
> >the number of extra missing lines introduced.  We have a requirement
> >that new drivers have 90% unit test coverage, which the ceph driver
> >meets[1], but it's tripping up on that absolute 4 line limit.
> >
> >What do folks think about tweaking the script to do a different
> >calculation, like identifying new files and permitting 10% of the line
> >count of the new files to be missed?  Otherwise I think the 90% target
> >is going to continually conflict with the manila-coverage CI task.
> >
> >Cheers,
> >John
> >
> >1.
> >
> http://logs.openstack.org/11/270211/19/check/manila-coverage/47b79d2/cover
> >/manila_share_drivers_cephfs_py.html
> >2.
> >
> http://logs.openstack.org/11/270211/19/check/manila-coverage/47b79d2/conso
> >le.html
> >
> >__
> >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
>



-- 
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.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] [Manila] ALLOWED_EXTRA_MISSING is cover.sh

2016-02-10 Thread John Spray 
Hi,

I noticed that the coverage script is enforcing a hard limit of 4 on
the number of extra missing lines introduced.  We have a requirement
that new drivers have 90% unit test coverage, which the ceph driver
meets[1], but it's tripping up on that absolute 4 line limit.

What do folks think about tweaking the script to do a different
calculation, like identifying new files and permitting 10% of the line
count of the new files to be missed?  Otherwise I think the 90% target
is going to continually conflict with the manila-coverage CI task.

Cheers,
John

1. 
http://logs.openstack.org/11/270211/19/check/manila-coverage/47b79d2/cover/manila_share_drivers_cephfs_py.html
2. 
http://logs.openstack.org/11/270211/19/check/manila-coverage/47b79d2/console.html

__
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] [Manila] ALLOWED_EXTRA_MISSING is cover.sh

2016-02-10 Thread Knight, Clinton 
Hi, John.  This is but one reason the coverage job doesn¹t vote; it has
other known issues.  It is primarily a convenience tool that lets core
reviewers know if they should look more deeply into unit test coverage.
For a new driver such as yours, I typically pull the code and check
coverage for each new file in PyCharm rather than relying on the coverage
job.  Feel free to propose enhancements to the job, though.

Clinton


On 2/10/16, 1:02 PM, "John Spray"  wrote:

>Hi,
>
>I noticed that the coverage script is enforcing a hard limit of 4 on
>the number of extra missing lines introduced.  We have a requirement
>that new drivers have 90% unit test coverage, which the ceph driver
>meets[1], but it's tripping up on that absolute 4 line limit.
>
>What do folks think about tweaking the script to do a different
>calculation, like identifying new files and permitting 10% of the line
>count of the new files to be missed?  Otherwise I think the 90% target
>is going to continually conflict with the manila-coverage CI task.
>
>Cheers,
>John
>
>1. 
>http://logs.openstack.org/11/270211/19/check/manila-coverage/47b79d2/cover
>/manila_share_drivers_cephfs_py.html
>2. 
>http://logs.openstack.org/11/270211/19/check/manila-coverage/47b79d2/conso
>le.html
>
>__
>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