út 27. 9. 2016 v 18:21 odesílatel Timur Nurlygayanov < tnurlygaya...@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.pitt...@scality.com> wrote: > >> Hi, >> >> On Tue, Sep 27, 2016 at 11:43 AM, milanisko k <vetri...@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-requ...@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-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
