Open Stack

út 27. 9. 2016 v 18:21 odesílatel Timur Nurlygayanov <
tnurlygayanov at mirantis.com> napsal:

> Hi milan,
>
> we have measured the test coverage for OpenStack components with
> coverage.py tool [1]. It is very easy tool and it allows measure the
> coverage by lines of code and etc. (several metrics are available).
>
> [1] https://coverage.readthedocs.io/en/coverage-4.2/
>
> Timur, the project  I linked was, besides an experimental AST-based stats
processor, a monkey-patch to the coverage.py module that allowed  remote
code coverage collection through a Redis store. It would allow one to
instrument multiple running processes from couple of nodes at the same time
while executing e.g functional tests.
The main point of it was to create a service that one would run if they
wanted to collect the stats from a project; of course all would get slowed
down 100-fold.

I'm curious if the OS projects want to execute similar code measurements on
e.g daily basis w/ selected DSVM jobs to collect stats.



> On Tue, Sep 27, 2016 at 1:06 PM, Jordan Pittier <
> jordan.pittier at scality.com> wrote:
>
>> Hi,
>>
>> On Tue, Sep 27, 2016 at 11:43 AM, milanisko k <vetrisko at gmail.com> wrote:
>>
>>> Dear Stackers,
>>> I'd like to gather some overview on the $Sub: is there some
>>> infrastructure in place to gather such stats? Are there any groups
>>> interested in it? Any plans to establish such infrastructure?
>>>
>> I am working on such a tool with mixed results so far. Here's my approach
>> taking let's say Nova as an example:
>>
>> 1) Print all the routes known to nova (available as a python-routes
>> object:  nova.api.openstack.compute.APIRouterV21())
>> 2) "Normalize" the Nova routes
>> 3) Take the logs produced by Tempest during a tempest run (in
>> logs/tempest.txt.gz). Grep for what looks like a Nova URL (based on port
>> 8774)
>> 4) "Normalize" the tested-by-tempest Nova routes.
>> 5) Compare the two sets of routes
>> 6) ????
>> 7) Profit !!
>>
> So the hard part is obviously the normalizing of the URLs. I am currently
>> using a tons of regex.... :) That's not fun.
>>
> I took simpler approach that just collects the stats (code execution hit
count) through coverage.py but with a "central" store, not sure that would
satisfy your use case.


> I'll let you guys know if I have something to show.
>>
>> I think there's real interest on the topic (it comes up every year or
>> so), but no definitive answer/tool.
>>
>> That wouldn't imply much interest :)


> Cheers,
>> Jordan
>>
>>
>>
>>
>> <https://www.scality.com/backup/?utm_source=signatures&utm_medium=email&utm_campaign=backup2016>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> Timur,
> Senior QA Manager
> OpenStack Projects
> Mirantis Inc
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20160929/c2211bc6/attachment.html>