Re: [openstack-dev] [all]-ish : Updates required for readthedocs publishers

2018-09-06 Thread Ilya Shakhat
What is the process once webhook_id is added to project's zuul.yaml?
Should I propose a change into project-config/zuul.d/projects.yaml or it
will be done automatically?

BTW (not completely related to this topic, but since I'm touching zuul.yaml
anyway) - what are the best practices for non-official projects - should
zuul configuration stay in project-config or better be moved to local
zuul.yaml?

Thanks,
Ilya

чт, 6 сент. 2018 г. в 1:31, Ian Wienand :

> On 09/06/2018 02:10 AM, Doug Hellmann wrote:
> > Those instructions and the ones linked at
> >
> https://docs.openstack.org/infra/openstack-zuul-jobs/project-templates.html#project_template-docs-on-readthedocs
> > say to "generate a web hook URL".
>
> I think you got the correct answers, thanks Dmitry.  Note it is also
> illustrated at
>
>   https://imgur.com/a/Pp4LH31
>
> Thanks
>
> -i
>
> __
> 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


[openstack-dev] [DriverLog] DriverLog future

2018-03-01 Thread Ilya Shakhat
Hi!

For those who do not know, DriverLog is a community registry of 3rd-party
drivers for OpenStack hosted together with Stackalytics [1]. The project
started 4 years ago and by now contains information about 220 drivers. The
data from DriverLog is also consumed by official Marketplace [2].

Here I would like to discuss directions for DriverLog and 3rd-party driver
registry as general.

1) Being a single community-wide registry was good initially, it allowed to
quickly collect description for most of drivers in a single place. But in a
long term this approach stopped working - not many projects remember to
update the information stored in some random place, right?

Mike already pointed to this problem a year ago [3] and the idea was to
move driver list to projects (and thus move responsibility to them too) and
have an aggregated list of drivers produced by infra. Do we have any
progress in this direction? Is it a time to start deprecation of DriverLog
and consider transition during Rocky release?

2) As a project with 4 years history DriverLog's list only increased over
the time with quite few removals. Now it still has drivers with the latest
version Liberty or drivers for non-maintained projects (e.g. Fuel). While
it maybe makes sense to keep all of them for operators who run older
versions, it may produce a feeling that the majority of drivers are old.
One of solutions for this is to show by default drivers for active releases
only (Pike and ahead). If done this will apply to both DriverLog and
Marketplace.

Any other ideas or suggestions?

Thanks,
I

[1] http://stackalytics.com/report/driverlog
[2] https://www.openstack.org/marketplace/drivers/
[3]
http://lists.openstack.org/pipermail/openstack-dev/2017-January/110151.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] Pike release update on driverlog/etc/default_data.json

2017-09-06 Thread Ilya Shakhat
Hi Sumit,

It's just been done in https://review.openstack.org/#/c/500670/3 ("Update
Dell EMC drivers info").

Best regards,
Ilya

2017-09-06 10:43 GMT+02:00 Shatwara, Sumit :

> Hi Team,
>
>
>
> When will the details related to Pike release be added in “releases”
> section of etc/default_data.json file?
>
>
>
> Reference link: https://github.com/openstack/driverlog/blob/master/etc/
> default_data.json
>
>
>
> Regards,
>
> Sumit
>
> __
> 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] [QA][LCOO] MEX-ops-meetup: OpenStack Extreme Testing

2017-08-14 Thread Ilya Shakhat
2017-08-14 13:41 GMT+02:00 Ghanshyam Mann <ghanshyamm...@gmail.com>:

> On Mon, Aug 14, 2017 at 7:56 PM, Boris Pavlovic <bo...@pavlovic.me> wrote:
> > Sam,
> >
> > Seems like a good plan and huge topic ;)
> >
> > I would as well suggest to take a look at the similar efforts in
> OpenStack:
> > - Failure injection: https://github.com/openstack/os-faults
>
> Yea, we are considering this lib, more details in this spec -
> https://review.openstack.org/#/c/443504/
>
> - Rally Hooks Mechanism (to inject in rally scenarios failures):
> > https://rally.readthedocs.io/en/latest/plugins/implementation/hook_and_
> trigger_plugins.html
> >
>

As a little demonstration of Rally and os-faults working together:
OpenStack reliability tests from performance documentation:
 * test plan:
https://docs.openstack.org/performance-docs/latest/test_plans/reliability/version_2/plan.html#reliability-testing-version-2
 * example of report:
https://docs.openstack.org/performance-docs/latest/test_results/reliability/version_2/reports/neutron/create_and_list_networks_with_kill_mysql_service_on_one_node/index.html

Best regards,
Ilya Shakhat
__
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] [oslo][performance] Proposing tail-based sampling in OSProfiler

2017-08-04 Thread Ilya Shakhat
Hi,

Continuous tracing is a cool story, but before proceeding it would be good
to estimate the overhead. There will be an additional delay introduced by
OSProfiler library itself and delay caused by events transfer to consumer.
OSProfiler overhead is critical to minimize. E.g. VM creation produces >1k
events, which gives almost 2 times performance penalty in DevStack. Would
be definitely nice to have the same test run on real environment --
something that Performance Team could help with.

Transfer part of delay can be reduced by e.g. writing events to local file
and then processing them with Logstash + Grok. Agent-based approach is good
for more real-time processing -- can we consider to use Logstash UDP [1]
input or Elastic Beat [2] framework? OSProfiler has drivers support (works
in Pike!) and we can give operators freedom to choose the pipeline they
prefer.

[1] https://www.elastic.co/guide/en/logstash/current/plugins-inputs-udp.html
[2]
https://www.elastic.co/guide/en/beats/libbeat/current/beats-reference.html

Best regards,
Ilya Shakhat


2017-08-04 4:04 GMT+02:00 vin...@vn.fujitsu.com <vin...@vn.fujitsu.com>:

> Hi Rajul,
>
>
>
> For the `agent idea`, I think it is very good.
>
> However, in OpenStack, that idea may be really hard for us.
>
> The reason is the same with what Boris think.
>
>
>
> For the sampling part, head-based sampling can be implemented in
> OSprofiler.
>
> For tail-based and adaptive sampling, it is another story.
>
> However, in naïve way, we can use sampling abilities from other
> OpenTracing compatible tracers
>
> such as Uber Jaeger, Appdash, Zipkin (has an open pull request), LighStep
> … by making OSprofiler
>
> compatible with OpenTracing API.
>
>
>
> ICYMI, Boris is father of OSprofiler in OpenStack [1]
>
>
>
> [1] https://specs.openstack.org/openstack/oslo-specs/specs/
> mitaka/osprofiler-cross-service-project-profiling.html
>
>
>
> Best regards,
>
>
>
> Vinh Nguyen Trong
>
> PODC – Fujitsu Vietnam Ltd.
>
>
>
> *From:* Rajul Kumar [mailto:kumar.r...@husky.neu.edu]
> *Sent:* Friday, 04 August, 2017 03:49
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [oslo][performance] Proposing tail-based
> sampling in OSProfiler
>
>
>
> Hi Boris
>
>
>
> That is a point of concern.
>
> Can you please direct to any of those?
>
>
>
> Anyways, we don't have anything in place for OpenStack yet.
>
> Now, either we pick another tracing solution like Zipkin, Jaeger etc.
> which have their own limitations OR enhance OSProfiler.
>
> We pick the later as it's most native and better coupled with OpenStack as
> of now.
>
> I understand that we may be blocked by these issues. However, I feel it'll
> be better to fight with OSProfiler than anything else till we come up with
> something better :)
>
>
>
> Thanks
>
> Rajul
>
>
>
>
>
>
>
> On Thu, Aug 3, 2017 at 4:01 PM, Boris Pavlovic <bo...@pavlovic.me> wrote:
>
> Rajul,
>
>
>
> May I ask why you think so?
>
>
>
> Exposed by OSprofiler issues are going to be really hard to fix in current
> OpenStack architecture.
>
>
>
> Best regards,
>
> Boris Pavlovic
>
>
>
> On Thu, Aug 3, 2017 at 12:56 PM, Rajul Kumar <kumar.r...@husky.neu.edu>
> wrote:
>
> Hi Boris
>
>
>
> Good to hear from you.
>
> May I ask why you think so?
>
>
>
> We do see some potential with OSProfiler for this and further objectives.
>
>
>
> Thanks
>
> Rajul
>
>
>
> On Thu, Aug 3, 2017 at 3:48 PM, Boris Pavlovic <bo...@pavlovic.me> wrote:
>
> Rajul,
>
>
>
> It makes sense! However, maybe it's a bit too late... ;)
>
>
>
> Best regards,
>
> Boris Pavlovic
>
>
>
> On Thu, Aug 3, 2017 at 12:16 PM, Rajul Kumar <kumar.r...@husky.neu.edu>
> wrote:
>
> Hello everyone
>
>
>
> I have added a blueprint on having tail-based sampling as a sampling
> option for continuous tracing in OSProfiler. It would be really helpful to
> have some thoughts, ideas, comments on this from the community.
>
>
>
> Continuous tracing provides a good insight on how various transactions
> behave across in a distributed system. Currently, OpenStack doesn't have a
> defined solution for continuous tracing. Though, it has OSProfiler that
> does generates selective traces, it may not capture the occurrence. Even if
> we have OSProfiler running continuously [1], we need to sample the traces
> so as to cut down the data generated and still keep the useful info.
>
>
>
> Head based sampling c

Re: [openstack-dev] [FEMDC][MassivelyDistributed] Strawman proposal for message bus analysis

2017-06-21 Thread Ilya Shakhat
Hi Ken,

Please check scenarios and reports that exist in Performance Docs. In
particular you may be interested in:
 * O.M.Simulator -
https://github.com/openstack/oslo.messaging/blob/master/tools/simulator.py
 * MQ  performance scenario -
https://docs.openstack.org/developer/performance-docs/test_plans/mq/plan.html#message-queue-performance
 * One of RabbitMQ reports -
https://docs.openstack.org/developer/performance-docs/test_results/mq/rabbitmq/cmsm/index.html
 * MQ HA scenario -
https://docs.openstack.org/developer/performance-docs/test_plans/mq_ha/plan.html
 * One of RabbitMQ HA reports -
https://docs.openstack.org/developer/performance-docs/test_results/mq_ha/rabbitmq-ha-queues/cs1ss2-ks2-ha/omsimulator-ha-call-cs1ss2-ks2-ha/index.html


Thanks,
Ilya

2017-06-21 15:23 GMT+02:00 Ken Giusti :

> Hi All,
>
> Andy and I have taken a stab at defining some test scenarios for anal the
> different message bus technologies:
>
> https://etherpad.openstack.org/p/1BGhFHDIoi
>
> We've started with tests for just the oslo.messaging layer to analyze
> throughput and latency as the number of message bus clients - and the bus
> itself - scale out.
>
> The next step will be to define messaging oriented test scenarios for an
> openstack deployment.  We've started by enumerating a few of the tools,
> topologies, and fault conditions that need to be covered.
>
> Let's use this epad as a starting point for analyzing messaging - please
> feel free to contribute, question, and criticize :)
>
> thanks,
>
>
>
> --
> Ken Giusti  (kgiu...@gmail.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] [Shaker] Shaker Image Builder fails in Ocata due to OS::Glance::Image deprecation

2017-03-03 Thread Ilya Shakhat
Hi Sai,

As we discussed at PTG, I've added an option to build image using
diskimage-builder tool. The code is not merged yet, please see
https://review.openstack.org/#/c/441126/. With this patch
shaker-image-builder can automatically switch to do local build using
diskimage-builder when Glance v1 is not available. The behavior can also be
enforced by --image-builder-mode parameter.

Thanks,
Ilya



2017-02-03 13:16 GMT+04:00 Ilya Shakhat <ishak...@mirantis.com>:

> Starting Ocata, looks like only glance v2 is enabled by default. This
>> breaks the shaker image builder template since we make use of the resource
>> type OS::Glance::Image and creating images from url links is not
>> supported in v2. How do we want deal with this? Maybe have the user pass in
>> the name/image-id and pass them as properties to the shaker image builder
>> template or instead advise the use to turn on the v1 API?
>> Thoughts/suggestions?
>>
>>
> Looks like the only way to deal with that is to build the image manually
> and then pass its name via --image-name parameter (or name the image
> 'shaker-image').
>
> Thanks,
> Ilya
>
__
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] [karbor][stackalytics] Karbor Missing Commits in Stackalytics

2017-02-09 Thread Ilya Shakhat
Sure, I'll take a look at this.

--Ilya

2017-02-09 13:47 GMT+04:00 Zhenguo Niu :

> After the rename of Nimble to Mogan, all git-related stats are lost as
> well.
>
> http://stackalytics.com/?metric=commits_type=opensta
> ck-others=mogan
>
> Ilya, Can you please assist with rectifying this?
>
> On Thu, Feb 9, 2017 at 5:00 PM, Thierry Carrez 
> wrote:
>
>> Yuval Brik wrote:
>> > By looking
>> > at http://stackalytics.com/?metric=commits=all_
>> type=all=karbor
>> > > _type=all=karbor> I
>> > noticed that Karbor has only 195 commits in Stackalytics, while in fact,
>> > it has 721 commits (438 of them are not Jenkin's merges). It seems like
>> > this happens because of the past Smaug -> Karbor rename. The cause might
>> > be the fact that Stackalytics only counts diffs, and older commits are
>> > already counted for Smaug instead of Karbor, but I'm not sure, and have
>> > no way of verifying that.
>> > The problem happens only in the Stackalytics commits and lines of code
>> > sections, and affects karbor-dashboard and python-karborclient as well.
>> > The reviews part in Stackalytics seem to be accurate
>> > ( http://stackalytics.com/?metric=marks=all_
>> type=all=karbor
>> > > type=all=karbor> )
>> >
>> > Can anyone advise?
>>
>> I suspect you're right, must be related to the rename. I would have
>> thought adding aliases would be sufficient:
>>
>> http://git.openstack.org/cgit/openstack/stackalytics/commit/
>> ?id=606df2029ab4d3d03ba43fe6d3884346cb59ef16
>>
>> Maybe Ilya can shed some light onto this...
>>
>> --
>> Thierry Carrez (ttx)
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Best Regards,
> Zhenguo Niu
>
> __
> 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] [Shaker] Shaker Image Builder fails in Ocata due to OS::Glance::Image deprecation

2017-02-03 Thread Ilya Shakhat
>
> Starting Ocata, looks like only glance v2 is enabled by default. This
> breaks the shaker image builder template since we make use of the resource
> type OS::Glance::Image and creating images from url links is not
> supported in v2. How do we want deal with this? Maybe have the user pass in
> the name/image-id and pass them as properties to the shaker image builder
> template or instead advise the use to turn on the v1 API?
> Thoughts/suggestions?
>
>
Looks like the only way to deal with that is to build the image manually
and then pass its name via --image-name parameter (or name the image
'shaker-image').

Thanks,
Ilya
__
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] [Performance][Shaker]

2017-01-23 Thread Ilya Shakhat
Hi Sai,

In UDP testing PPS represents packets sent by iperf client to server. Loss
is the percentage of packets that were not received by server (more
specifically the server tracks packets and sums gaps between of them,
https://github.com/esnet/iperf/blob/3.0.7/src/iperf_udp.c#L64).

While reported PPS depends on bandwidth and concurrency it makes sense to
increase them until loss starts going up, meaning that the communication
channel is near the limit.

Thanks,
Ilya

2017-01-21 1:19 GMT+04:00 Sai Sindhur Malleni :

> Hey,
>
> When using the "iperf3" class in shaker for looking at UDP small packet
> performance, we see that as we scale up the concurrency the average PPS
> goes up and also the loss % increases. Is the loss % a percentage of the
> PPS or does the PPS only represent successful transmissions? Thanks!
>
> --
> Sai Sindhur Malleni
> Software Engineer
> Red Hat Inc.
> 100 East Davie Street
> Raleigh, NC, USA
> Work: (919) 754-4557 | Cell: (919) 985-1055
>
> __
> 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] [Performance][shaker] Triangular topology

2016-12-06 Thread Ilya Shakhat
Hi Matt,

I would suggest to let users specify custom topology in Shaker scenario via
graphs (e.g. directed triangle would look like: A -> B, B -> C, C -> A),
where every pair of nodes is pair of VMs and every edge corresponds to the
traffic flow. The above example will be deployed as 6 VMs, 2 per compute
node (since we need to separate ingress and egress flows).

I already have a patch that allows to deploy graph-based topology:
https://review.openstack.org/#/c/407495/ but it does not configure
concurrency properly yet (concurrency still increments by pairs, solution
tbd)

Please check whether my approach suits your use case, feedback appreciated
:)

Thanks,
Ilya

2016-11-24 19:57 GMT+04:00 Matthieu Simonin <matthieu.simo...@inria.fr>:

> Hi Ilya,
>
> Thanks for your answer, let me know your findings.
> In any case I'll be glad to help if needed.
>
> Matt
>
> ps : I just realized that I missed a proper subjet to the thread :(.
> If this thread continue it's maybe better to change that.
>
> - Mail original -
> > De: "Ilya Shakhat" <ishak...@mirantis.com>
> > À: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> > Envoyé: Jeudi 24 Novembre 2016 13:03:33
> > Objet: Re: [openstack-dev] [Performance][shaker]
> >
> > Hi Matt,
> >
> > Out of the box Shaker doesn't support such topology.
> > It shouldn't be hard to implement though. Let me check what needs to be
> > done.
> >
> > Thanks,
> > Ilya
> >
> > 2016-11-24 13:49 GMT+03:00 Matthieu Simonin <matthieu.simo...@inria.fr>:
> >
> > > Hello,
> > >
> > > I'm looking to shaker capabilities and I'm wondering if this kind
> > > of accomodation (see attachment also) can be achieved
> > >
> > > Ascii (flat) version :
> > >
> > > CN1 (2n VMs) <- n flows -> CN2 (2n VMs)
> > > CN1 (2n VMs) <- n flows -> CN3 (2n VMs)
> > > CN2 (2n VMs) <- n flows -> CN3 (2n VMs)
> > >
> > > In this situation concurrency could be mapped to the number of
> > > simultaneous flows in use per link.
> > >
> > > Best,
> > >
> > > Matt
> > >
> > >
> > > 
> __
> > > 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
> >
>
> __
> 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] [stackalytics][neutron] some big tent projects included into 'Neutron Official'

2016-11-28 Thread Ilya Shakhat
Hi Ihar,

This sounds like a bug - the contents of official group should be in sync
with the governance repo.
I'll take a look what went wrong with it.

Thanks,
Ilya

2016-11-26 2:28 GMT+03:00 Ihar Hrachyshka :

> Hi all,
>
> I am looking at http://stackalytics.com/?project_type=openstack=
> neutron-group and I see some reviews counted for projects that are for
> long out of neutron stadium (f.e. dragonflow or kuryr or
> networking-hyperv). How can we get them excluded from the official neutron
> stats?
>
> I’ve briefly looked at the code, and it seems like the project should
> reflect what’s defined in governance repo, but apparently it’s not the
> case. So what does it reflect?
>
> Ihar
> __
> 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] [Performance][shaker]

2016-11-24 Thread Ilya Shakhat
Hi Matt,

Out of the box Shaker doesn't support such topology.
It shouldn't be hard to implement though. Let me check what needs to be
done.

Thanks,
Ilya

2016-11-24 13:49 GMT+03:00 Matthieu Simonin :

> Hello,
>
> I'm looking to shaker capabilities and I'm wondering if this kind
> of accomodation (see attachment also) can be achieved
>
> Ascii (flat) version :
>
> CN1 (2n VMs) <- n flows -> CN2 (2n VMs)
> CN1 (2n VMs) <- n flows -> CN3 (2n VMs)
> CN2 (2n VMs) <- n flows -> CN3 (2n VMs)
>
> In this situation concurrency could be mapped to the number of
> simultaneous flows in use per link.
>
> Best,
>
> Matt
>
>
> __
> 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


[openstack-dev] [QA][os-faults] OpenStack destructive and reliability testing announcement

2016-10-21 Thread Ilya Shakhat
Hello,

A while ago we've introduced a new library called os-faults [1]. The main
purpose of the library is to provide a unified API to perform different
destructive actions in OpenStack cloud. The library can do service-related
operations (e.g. kill particular service) and node-related (e.g. switch
power off). The library have been already used in reliability testing [2]
and is used in a new project called stepler [3].

If you are interested in reliability and destructive testing of OpenStack
welcome to our design session at the summit, 10/27 (Thurs) 11:00 - 11:40.

More information on the topic:
 * official docs - http://os-faults.readthedocs.io/
 * os-faults intro - https://youtu.be/tawwDFWZL80
 * reliability testing - https://youtu.be/9puoDd14IxU

Thanks,
Ilya

[1] https://github.com/openstack/os-faults
[2]
http://docs.openstack.org/developer/performance-docs/test_results/reliability/version_2/index.html
[3] https://github.com/Mirantis/stepler
__
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] [stackalytics]

2016-09-29 Thread Ilya Shakhat
Roman,

  There are certainly exist a bug in stackalytics [1]. Current contribution
> to different openstack/* projects was counted for deb-* . Now all affected
> commit records on stackalytics are removed from deb-* projects, but they
> should be moved to proper non-deb projects. Is there any one how could
> solve this bug?
>

This duplication is one of the reasons why we removed all deb-* projects
from statistics. Now it seems like we need to fix all other stats as well.

Thanks for reporting this.

--Ilya
__
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] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects

2016-09-21 Thread Ilya Shakhat
2016-09-21 14:37 GMT+03:00 Thierry Carrez <thie...@openstack.org>:

> Ilya Shakhat wrote:
> > Hi,
> >
> > tldr; Commits stats are significantly skewed by deb-* projects
> > (http://stackalytics.com/?metric=commits=packaging-deb-group)
> >
> > By default Stackalytics processes commits from project's master branch.
> > For some "old core" projects there is configuration to process stable
> > branches as well. If some commit is cherry-picked from master to stable
> > it is counted twice in both branches / releases. The configuration for
> > stable branch is simple - branch starting with branching point (e.g.
> > stable/newton that starts with rc1)
> >
> > In deb-* projects master branch corresponds to upstream Debian
> > community. All OpenStack-related contribution goes into debian/
> > branch. But unlike in the rest of OpenStack, git workflow differs and
> > the branch contains merge commits from master. This makes filtering
> > "pure" branch commits from those that came from master quite tricky (not
> > possible to specify the branch-point). And support of this will require
> > changes in Stackalytics code.
> >
> > Since currently we are at the time when people may get nervous about
> > numbers, I'd suggest to temporary hide all commits from deb-* projects
> > and revise stats processing in a month.
>
> Sounds good. Are you working on it ?


Yep. I'm working on this, will update on the results.

--Ilya Shakhat
__
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] [stackalytics] [deb] [packaging] OpenStack contribution stats skewed by deb-* projects

2016-09-20 Thread Ilya Shakhat
Hi,

tldr; Commits stats are significantly skewed by deb-* projects (
http://stackalytics.com/?metric=commits=packaging-deb-group)

By default Stackalytics processes commits from project's master branch. For
some "old core" projects there is configuration to process stable branches
as well. If some commit is cherry-picked from master to stable it is
counted twice in both branches / releases. The configuration for stable
branch is simple - branch starting with branching point (e.g. stable/newton
that starts with rc1)

In deb-* projects master branch corresponds to upstream Debian community.
All OpenStack-related contribution goes into debian/ branch. But
unlike in the rest of OpenStack, git workflow differs and the branch
contains merge commits from master. This makes filtering "pure" branch
commits from those that came from master quite tricky (not possible to
specify the branch-point). And support of this will require changes in
Stackalytics code.

Since currently we are at the time when people may get nervous about
numbers, I'd suggest to temporary hide all commits from deb-* projects and
revise stats processing in a month.

Thanks,
Ilya
__
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] Cloud Reliability and Resilience for OpenStack (Fault Injection, Chaos Engineering, and Google SRE)

2016-09-01 Thread Ilya Shakhat
Hi Jorge,

Reliability testing automation is the thing that OpenStack Performance team
[1] is working right now. The whole solution will consist of:
 * Fault injection library os-failures [2] that provides an API to do
different kind of faults on different OpenStack clouds. The lib is
currently under active development, our primary goal is to support
Fuel-based clouds and then DevStack-based.
 * Rally as an engine to run different types of test scenarios. As Boris
mentioned the main feature is called "hooks" - it allows to execute
arbitrary code at predefined points of scenario. In our case we will have
plugin that uses os-failures library.
 * Set of scenarios and reports to them - this will go into OpenStack
Performance Docs [3].
 * Rally plugin for results processing. Basically we are interested in
calculating the following metrics:
 * Count errors appeared during scenario execution (e.g. number of
failed requests)
 * Performance degradation - compare performance (e.g. operation
duration) after the failure against sample data collected before
 * MTTR - how long does it takes for all errors to disappear and how
long does it takes for performance to become normal

If you are interesting in contribution, we have meetings by Tuesday at
15:30 UTC at #openstack-performance IRC channel.

Thanks,
Ilya

[1] https://wiki.openstack.org/wiki/Performance_Team
[2] https://github.com/openstack/os-failures
[3] http://docs.openstack.org/developer/performance-docs/


2016-09-01 10:33 GMT+03:00 Boris Pavlovic :

> Hi Jorge,
>
> Rally team is working on feature called "Hooks".
> "Hooks" are going to allow to use Rally to run workloads and inject any
> actions (including using existing Chaos frameworks)
>
> Here is the patch: https://review.openstack.org/#/c/352276/
> Here is merged spec: https://github.com/openstack/rally/blob/master/
> doc/specs/in-progress/hook_section.rst
>
>
> You are very welcome to join this effort and help Rally team deliver it
> faster.
>
> Thanks!
>
> Best regards,
> Boris Pavlovic
>
> On Wed, Aug 31, 2016 at 11:55 PM, Jorge Cardoso (Cloud Operations and
> Analytics, IT R Division)  wrote:
>
>>
>>
>> Hi all,
>>
>>
>>
>> Is there any work being done on Reliability for OpenStack using e.g.
>> fault-injection, Chaos Engineering from Netflix, and Site Reliability
>> Engineering principles from Google?
>>
>>
>>
>> I only found this page in the documentation
>> http://docs.openstack.org/developer/performance-docs/test_
>> results/reliability/index.html#openstack-reliability-testing.
>>
>>
>>
>> I am working on Cloud Reliability and Resilience and I would like to
>> explore this area for OpenStack.
>>
>> You can check some of my interests and work at:
>> http://jorge-cardoso.github.io/research/
>>
>>
>>
>> Any interest from you guys?
>>
>> Any suggestions on how to proceed?
>>
>>
>>
>>
>>
>> Best Regards,
>>
>> Jorge Cardoso
>>
>>
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
>
>
__
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] [stackalytics] Proposal for some code/feature changes

2016-04-12 Thread Ilya Shakhat
Hi Nikhil,

2016-04-12 5:59 GMT+03:00 Nikhil Komawar :

> Hello,
>
> I was hoping to make some changes to the stackalytics dashboard
> specifically of this type [1] following my requested suggestions here
> [2]; possibly add a few extra columns for +0s and just Bot +1s. I think
> having this info gives much clearer picture of the kind of reviews
> someone is/wants to be involved in. I couldn't find documentation in the
> README or anywhere else and the minimal amount of docstrings are making
> it difficult for me to figure the changes.
>
> What's the best possible route to accomplish this?
>

Well, I see two different metrics here: the first counts +0s and the second
is additional analytic over existing reviews.

Counting +0s or comments is something that is asked from time to time and
something that I'd like to avoid. The reason is that retrieving comments
lead to higher load on Gerrit and slows down the update cycle.

However Stackalytics already retrieves comments for some projects (those
that have external CIs, like nova), so we can try this new metric there as
experiment. The metric should probably be different from "reviews" not to
skew the current numbers. As of implementation, the changes should be in
both processor and dashboard; the code similar to existing counting reviews.

The second feature is counting votes against patch-sets posted by bots.
This one should be easier to implement and all data is already available.
In the report like [1] every vote record can be extended with info from
patch-set; the filtering should take into account the author's company, all
bots are assigned to '*robots'.

Thanks,
Ilya


>
> [1] http://stackalytics.com/report/contribution/astara-group/30
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2016-April/091836.html
>
> --
>
> Thanks,
> Nikhil
>
>
> __
> 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] [i18n][stackalytics] Translations metrics

2016-02-26 Thread Ilya Shakhat
2016-02-25 13:42 GMT+03:00 Ying Chun Guo :

> Is it possible to link two IDs with email ?
>
> The link is possible by adding user profile into Stackalytics
default_data.json. The patch needs to be similar to
https://review.openstack.org/#/c/284638/1/etc/default_data.json. Basically
it lists all user identities in different systems.

Thanks,
Ilya
__
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] [i18n][stackalytics] Translations metrics

2016-02-25 Thread Ilya Shakhat
Hi Shu,

Thanks for bringing attention to this. The reason is that Stackalytics
tries to match Zanata id with LP id, and expects both to be the same. But
if they are different (or point to different people) then a static profile
should help. I will add the one for you soon.

Best regards,
Ilya Shakhat

2016-02-25 12:19 GMT+03:00 Akihiro Motoki <amot...@gmail.com>:

> Hi Shu,
>
> I am confused with the sentence "My Zanata ID "shu" is used by "Seihu"
> in Launchpad".
> I think Zanata ID is linked with OpenStack Foundation profile
> and is not linked directly with launchpad ID.
> Could you clarify the situation?
>
>
>
> 2016-02-25 18:08 GMT+09:00 Shuu Mutou <shu-mu...@rf.jp.nec.com>:
> > Hi,
> >
> > Stackalytics shows my translations as other ones.
> > Does the difference between Zanata ID and Launchpad ID cause the problem?
> >
> > * My Zanata ID "shu" is used by "Seihu" in Launchpad.
> > * My Launchpad ID is "shu-mutou".
> >
> > If so, I hope that email address will be used for matching user.
> >
> > Shu Muto
> > NEC Solution Innovators, Ltd.
> >
> >
> >
> __
> > 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
>
__
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] [infra][stackalytics] some projects not visible in stackalytics now

2016-01-11 Thread Ilya Shakhat
2016-01-11 12:48 GMT+03:00 Thierry Carrez <thie...@openstack.org>:

>
> I totally agree. Stackalytics contains data for non-OpenStack projects
> anyway (see under "complementary"), so I think it's fine to list unofficial
> projects under "Others" or "Unofficial".


Will be renamed soon: https://review.openstack.org/#/c/265741/

Thanks,
Ilya Shakhat


> --
> Thierry Carrez (ttx)
>
> __
> 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] [OpenStack-Infra] [infra][stackalytics] some projects not visible in stackalytics now

2016-01-11 Thread Ilya Shakhat
Hi everyone!

It appears that Stackalytics host is banned by review.openstack.org. It
gets "Received disconnect from 2001:4800:7818:102:be76:4eff:fe05:9b12: 7:
Too many concurrent connections" while attempting to execute "gerrit"
command. As consequence Stackalytics fails to retrieve list of projects (so
only those from governance list are visible), and all review stats is not
updated.

Infra folks, could you please check at Gerrit side that my hypothesis is
valid? is there anything to be done in Stackalytics to reduce the load on
review.o.o?

Thanks,
Ilya

PS.
project list will be fixed soon by https://review.openstack.org/#/c/265730/

2016-01-07 18:39 GMT+03:00 Jay Pipes :

> Hi everyone, and happy New Year!
>
> Ilya and a number of other Mirantis folks are currently on holiday until
> the 10th. I'm sure he will address the issues promptly upon his return.
>
> All the best,
> -jay
>
> On 01/07/2016 09:34 AM, Michał Dulko wrote:
>
>> On 01/07/2016 02:59 PM, Shake Chen wrote:
>>
>>> seem some project not update many day.like
>>>
>>> http://stackalytics.com/?project_type=openstack=kolla-group
>>>
>>> the data still stay 02 Jan 2016
>>>
>>>
>> And I can report that for some users (like me [1]) actions are not
>> tracked since the beginning of 2016. I can assure that I've did quite a
>> few reviews and got some patches merged.
>>
>> [1]
>>
>> http://stackalytics.com/?metric=marks=mitaka_id=michal-dulko-f
>>
>> ___
>> OpenStack-Infra mailing list
>> openstack-in...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>>
> __
> 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] [all] how to add/list drivers @ https://www.openstack.org/marketplace/drivers/

2015-11-25 Thread Ilya Shakhat
Community-maintained list of drivers exists within the project DriverLog.
The UI is available at http://stackalytics.com/report/driverlog , it has
all options to filter the data.


Thanks,
Ilya

2015-11-25 11:48 GMT+03:00 Mohan Kumar :

> Hi Team,
>
>  In the following link, i can see only some vendor plug-ins, not all is
> listed here! ..
>
>  https://www.openstack.org/marketplace/drivers/
>
> So [1]  what is the criteria to get a vendor plug-in listed on this page?
> [2]  where can i see the supported vendor plugins/drivers for a given
> Openstack release (specfically Liberty) ??
>
> Thanks.,
> Mohankumar.N
>
> __
> 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] [stackalytics] [metrics] Review metrics: average numbers

2015-11-12 Thread Ilya Shakhat
Hi Mike,

> Do I understand right, that average numbers
> > here are calculated out of open reviews, not total number of reviews?


Average numbers are calculated for reviews within the group. But I'd expect
them to be "time since the last vote", not "time when patch proposed" as
they do now.

> The most important number which I'm trying to get, is an average time
> > change requests waiting for reviewers since last vote or mark, from
> > all requests (not only those which remain in open state, like it is
> > now, I believe).


Do you mean to calculate stats not only for open, but also for those that
are already closed? Should it be for all times, or during specified period?

Regards,
--Ilya


2015-11-12 1:14 GMT+03:00 Jesus M. Gonzalez-Barahona :

> Hi, Mike,
>
> I'm not sure what you are looking for exactly, but maybe you can have a
> look at the quarterly reports. AFAIK, currently there is none specific
> to Fuel, but for example for Nova, you have:
>
> http://activity.openstack.org/dash/reports/2015-q3/pdf/projects/nova.pd
> f
>
> In page 6, you have "time waiting for reviewer" (from the moment a new
> patchset is produced, to the time a conclusive review vote is found in
> Gerrit), and "time waiting for developer" (from the conclusive review
> vote to next patchset).
>
> We're working now in a visualization for that kind of information. For
> now, we only have complete changeset values, check if you're
> interested:
>
> http://blog.bitergia.com/2015/10/22/understanding-the-code-review-proce
> ss-in-openstack/
>
> Saludos,
>
> Jesus.
>
> On Wed, 2015-11-11 at 21:45 +, Mike Scherbakov wrote:
> > Hi stackers,
> > I have a question about Stackalytics.
> > I'm trying to get some more data from code review stats. For Fuel,
> > for instance,
> > http://stackalytics.com/report/reviews/fuel-group/open
> > shows some useful stats. Do I understand right, that average numbers
> > here are calculated out of open reviews, not total number of reviews?
> >
> > The most important number which I'm trying to get, is an average time
> > change requests waiting for reviewers since last vote or mark, from
> > all requests (not only those which remain in open state, like it is
> > now, I believe).
> >
> > How hard would it be to get / extend Stackalytics to make it..?
> >
> > Thanks!
> > --
> > Mike Scherbakov
> > #mihgen
> > _
> > _
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> > cribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> --
> Bitergia: http://bitergia.com
> /me at Twitter: https://twitter.com/jgbarah
>
>
> __
> 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] [release][stackalytics] possibly breaking bug closing statistics?

2015-11-11 Thread Ilya Shakhat
2015-11-11 16:38 GMT+03:00 Thierry Carrez :

>
> date_fix_committed is probably not set if we directly switch the bug to
> "Fix released", and that is what we plan to do now with Launchpad bugs.
>
> We might therefore need a backward-compatible patch to Stackalytics so
> that it uses (date_fix_committed or date_fix_released) instead.


Good point, Thierry.

I have one bug that was transferred from New directly into Fix Released
state
(https://bugs.launchpad.net/stackalytics/+bug/1479791). Launchpad sets all
intermediate
states, including date_fix_committed:
"date_fix_committed": "2015-08-03T08:37:49.270140+00:00",
"date_fix_released": "2015-08-03T08:37:49.270140+00:00",

Not sure if it's documented behavior or not, so the patch to Stackalytics
would probably
be preferred.

Thanks,
Ilya
__
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] [release][stackalytics] possibly breaking bug closing statistics?

2015-11-10 Thread Ilya Shakhat
Doug,

You are right, there should not be any changes in the stats. Bugs are
mapped to release only by date, target milestone is not taken into account.
For resolved bugs metric Stackalytics uses 'date_fix_commited' field, for
filed bugs metric - 'date_created'.

Thanks,
Ilya

2015-11-10 0:53 GMT+03:00 Doug Hellmann :

> Stackalytics experts,
>
> When we roll out the launchpad process changes described in my earlier
> email [1], we will no longer be targeting bugs as part of closing them.
>
> Thierry raised a concern that this might break the way stackalytics
> calculates closed bug statistics for a cycle. Looking at the code
> in [2] and [3], I see it querying by date range and looking at the
> status, but not looking at the milestone to which the bug is targeted.
>
> Am I right in believing that we won't have any change in our
> statistics gathering if we go ahead with the current plan?
>
> Thanks,
> Doug
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.html
> [2]
> http://git.openstack.org/cgit/openstack/stackalytics/tree/stackalytics/processor/main.py#n99
> [3]
> http://git.openstack.org/cgit/openstack/stackalytics/tree/stackalytics/processor/record_processor.py#n511
>
__
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] Stackalytics 0.9: new features and improvements

2015-10-23 Thread Ilya Shakhat
Hi all,

During the last month we've made a number of changes and improvements in
Stackalytics that deserve version tag and special announcement. The most
important feature is tracking history of official projects list - highly
demanded after shift to 'big tent' model.

The full list of changes below:

1. Stackalytics now respects history of changes in the official programs
list. Changes are tracked per-release, so if some project was accepted
officially in Liberty, it does not appear in the past and thus does not
affect Kilo stats. As anchor points we use tags in governance repo (e.g.
april-2015-elections)[1]
. These tags are
related to elections and created a bit before the release thus saving from
last-minute changes in the stats.

2. With removal of Stackforge, all projects are now classified in 2 groups:
'OpenStack' = listed in the official projects.yaml [2]

and 'OpenStack Others' = those that are in openstack organization, but not
accepted officially. As before, by default Stackalytics shows official
projects.

3. CI metric [3]  is redesigned from
scratch. Now it analyses votes in merged patches only, the numbers are
shown for every driver. List of drivers is synced with DriverLog [4]

.

4. Added a new driver status report [5]
. The report shows total number
of votes, success rate and the latest result per every driver per module.
The report is available for projects that have external CI configured
(Nova, Neutron, Cinder, Manila, Sahara, number of Fuel plugins) The data
may be not complete now and requires proper configuration in DriverLog's
default data (maintainers are welcome to contribute into [4]

)

5. Abandoning a change request is now treated as reviewing [6]
 and is included into review
metric. Only abandoning of other's CRs is taken into account.

6. Reviews for own patches are not included into the stats anymore. In the
activity log such reviews are marked with prefix 'Self-' (e.g.
Self-Code-Review and Self-Approve)

7. Review processing is made compatible with Gerrit 2.9+, making
Stackalytics ready for infra upgrade.

Thanks,
Ilya

[1] - https://git.openstack.org/cgit/openstack/governance/
[2] -
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
[3] - http://stackalytics.com/?metric=ci
[4] -
http://git.openstack.org/cgit/openstack/driverlog/tree/etc/default_data.json
[5] - http://stackalytics.com/report/ci/cinder/7
[6] - https://bugs.launchpad.net/bugs/1498769
__
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] [stackalytics] Broken stats after project rename

2015-09-30 Thread Ilya Shakhat
Hi Jesse,

Thanks for letting know. Stackalytics team will fix the issue during the
day.

--Ilya

2015-09-30 12:19 GMT+03:00 Jesse Pretorius :

> Hi everyone,
>
> After the rename of os-ansible-deployment to openstack-ansible it appears
> that all git-related stats (eg: commits) prior to the rename have been lost.
>
> http://stackalytics.com/?metric=commits=openstack-ansible
>
> Can anyone assist with rectifying this?
>
> --
> Jesse Pretorius
> IRC: odyssey4me
>
> __
> 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] [Stackalytics] Complementary projects

2015-06-19 Thread Ilya Shakhat
Some reasons of having complementary projects in Stackalytics:
 * to compare efforts in other communities with OpenStack - just to feed
curiosity on what is larger OpenStack or Kubernetes?
 * to light interest to contribute to projects that OpenStack depends on,
like OVS and Ansible.
 * to keep an eye on commercial interest and know who is sponsoring near-by
technologies.

I agree that adding complementary projects was an authoritarian decision
and ready to remove them in the community version if TC decides so.

Thanks,
Ilya

2015-06-19 10:48 GMT+03:00 Thierry Carrez thie...@openstack.org:

 Paul Belanger wrote:
  I am wondering the reason for the complementary projects listing[1] in
  Stackalytics?  Specifically, why does stackalytics-processor import
  docker and cloudfoundry projects into the stats?
 
  [1] http://stackalytics.com/?project_type=complementarymetric=commits

 It's not a community decision. I'd say it is an editorial decision of
 the current owner of the project and website. While we are trying to
 move this project under the Infra project team and the Technical
 Committee oversight, it is currently still a Stackforge project owned by
 Mirantis.

 Personally if we were to move it under Infra I would (1) remove the
 complementary projects and (2) make sure that whoever wants to reuse
 stackalytics code to track Docker / CloudFoundry activity can easily do so.

 --
 Thierry Carrez (ttx)

 __
 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


[openstack-dev] [Neutron] Data-plane performance testing with Shaker

2015-05-14 Thread Ilya Shakhat
Hi all!

Let me introduce you Shaker - a tool for data-plane performance testing in
OpenStack. The motivation behind it is to have a simple way for measuring
networking bandwidth between instances.

Shaker key features are:

1. *User-defined topology*. The topology is specified as Heat template, so
users may do arbitrary configuration for instances, networks, routers,
floating ips, etc. Instance scheduling is controlled, it is possible to
specify number of instances per compute node and their location.

2. *Simultaneous test execution*. By default Shaker runs tests
synchronously on all deployed instances. It is also possible to increase
the load, thus measuring dependency on number of concurrently working
instances. The feature is useful when one needs to find bottleneck in the
cloud (like usage of non-DVR routers).

3. *Pluggable tools*. Out of the box Shaker supports iperf, netperf and
able to calculate aggregated stats based on their output. Adding a new tool
is easy, in the simplest case it does not even require coding.

4. *Interactive report*. Shaker produces report as single-page HTML
application. The report contains aggregated charts for bandwidth depending
on concurrency, bandwidth per node and precise timeline of traffic on every
node. The report does not have any dependencies and can be shared easily.

If you are interested in knowing more about Shaker welcome to Neutron
Lightning talk presentation by Oleg Bondarev next Wed in Vancouver (
http://sched.co/3BNR).

And certainly welcome to use and contribute!
Code: https://github.com/stackforge/shaker
Docs: http://pyshaker.readthedocs.org/
Launchpad: https://launchpad.net/shaker/
PyPi - https://pypi.python.org/pypi/pyshaker/

Thanks,
Ilya
__
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] [Fuel] Logstash and grok patterns

2015-03-10 Thread Ilya Shakhat
Hi,

Here are some suggestions from my experience:

1. Input patterns could be simplified by * matches, e.g.:

file {
path = [ /var/log/remote/*.domain.tld/neutron* ]
exclude = *.gz
}

2. Logs could be parsed by the following pattern:
  grok {
patterns_dir = patterns
match = { message = %{MOS_FUEL_PREFIX} }
  }
  where
 MOS_FUEL_PREFIX %{TIMESTAMP_ISO8601:fuel_timestamp}
%{LOGLEVEL:fuel_level}:\s+%{GREEDYDATA:fuel_message}
  (the pattern is stored in file called 'patterns')

Regards,
Ilya

2015-03-09 17:13 GMT+03:00 Foss Geek thefossg...@gmail.com:

 Dear All,

 I have a openstack HA environment deployed using fuel 5.1. Fuel master
 node collects all the node logs under /var/log/docker-logs/remote/
 directory.

 I have installed Logstash on fuel master node. Here is Logstash.conf:

 http://paste.openstack.org/show/190985/

 Here is rsyslog Template format:

 # cat /etc/rsyslog.d/00-remote.conf  | grep Template

 # Templates
 $Template RemoteLog, %pri%%timestamp% %hostname%
 %syslogtag%%msg:::sp-if-no-1st-sp%%msg%\n

 $ActionFileDefaultTemplate RemoteLog

 Is there any grok pattern reference for fuel centralized logs?

 Thanks for your time.

 --
 Thanks  Regards
 E-Mail: thefossg...@gmail.com
 IRC: neophy
 Blog : http://lmohanphy.livejournal.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] EOL and Stable Contributions (was Juno is flubber at the gate)

2015-02-10 Thread Ilya Shakhat

  Secondly, it's difficult to get stack-analytics credit for back
  ports, as the preferred method is to cherry pick the code, and
  that keeps the original author's name. I've personally gotten a
  few commits into stable, but have nothing to show for it in
  stack-analytics (if I'm doing it wrong, I'm happy to be
  corrected).
 [...]
 Stackalytics isn't an official OpenStack project, but you should
 file a bug[2] against it if there's a feature you want its authors
 to consider adding.


Stackalytics tracks commits into stable branches, e.g. for Neutron
stable/juno they are visible at
http://stackalytics.com/?metric=commitsmodule=neutronrelease=juno.
Commits are also shown in activity log for specific project or person, so
if someone interested in pulling them into weekly report - they will be
there.

Thanks,
Ilya

2015-02-10 19:45 GMT+03:00 Jeremy Stanley fu...@yuggoth.org:

 On 2015-02-10 15:20:46 + (+), Kevin Bringard (kevinbri) wrote:
 [...]
  I've been talking with a few people about this very thing lately,
  and I think much of it is caused by what appears to be our
  actively discouraging people from working on it. Most notably, ATC
  is only being given to folks committing to the current branch
  (
 https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/
 ).

 The comments on that answer are somewhat misleading, so I'll follow
 up there as well to set the record straight. The script[1] which
 identifies ATCs for the purpose of technical elections and summit
 passes is based entirely on Gerrit owners (uploaders) of changes
 merged to official projects within a particular time period. It
 doesn't treat master differently from any other branches. People who
 do the work to upload backports to stable branches absolutely do get
 counted for this purpose. People who only review changes uploaded by
 others do not (unless they are manually added to the extra-atcs
 file in the openstack/governance repo), but that is the case for all
 branches including master so not something stable-branch specific.

 Though I *personally* hope that is not the driving force to convince
 people to work on stable support. If it is, then we've already lost
 on this front.

  Secondly, it's difficult to get stack-analytics credit for back
  ports, as the preferred method is to cherry pick the code, and
  that keeps the original author's name. I've personally gotten a
  few commits into stable, but have nothing to show for it in
  stack-analytics (if I'm doing it wrong, I'm happy to be
  corrected).
 [...]

 Stackalytics isn't an official OpenStack project, but you should
 file a bug[2] against it if there's a feature you want its authors
 to consider adding.

 [1]
 https://git.openstack.org/cgit/openstack-infra/system-config/tree/tools/atc/email_stats.py
 [2] https://bugs.launchpad.net/stackalytics/+filebug
 --
 Jeremy Stanley

 __
 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


[openstack-dev] [Rally] Load testing of dependent resources

2014-09-18 Thread Ilya Shakhat
Ralliers,

I'd like to share with you an idea on how to test dependent resources.

Let's consider the following example: there is a network and ports
belonging to it and we would like to test port creation process. Currently
I see 2 options of writing scenario:
 a) The scenario creates network and then creates a specified number of
ports. Runner executes the scenario specified number of times. -- In this
case ports belonging to different networks are created in parallel, but all
ports belonging to the same network are created serially.
 b) The network already exists and the scenario just creates ports, -- This
case allows to test concurrent creation of ports belonging to the same
network but not between multiple networks.
It would be really cool to get benefits from both cases, i.e. to test
parallel port creation but without limiting to parent network resource.

One of possible approaches may be to construct chain of scenarios where
preceding scenario prepares context for the further one. From the above
example the execution would be:
 1) The task contains sequence of 2 scenarios:
* network creation - it creates network and returns it
* port creation - it picks the network from incoming params and creates
port on it
 2) The runner has execution pipeline (which currently is represented as
generator producing identical scenario runners). The pipeline starts with
sequence of network creation scenario runners. Once one of runner finishes,
it then puts the further scenario and the result into pipeline. The
pipeline ends once no further scenarios left.

From the above example execution flow would be like:
 * pipeline is filled with N network scenarios (not actually filled, but
contains a generator that is able to do this)
 * R runners pick scenarios from pipeline
 * pipeline contains N-R network scenarios
 * one of runners finishes the scenario and updates pipeline with P port
scenarios
 * pipeline contains N-R-1 network scenarios followed by P port scenarios
 * work-work-work until pipeline is empty

This execution covers case from a) and b) but there still will be sequences
of child resources belonging to the same parent. The improvement may be to
pick scenario from pipeline randomly.

How does it sound?

Thanks,
Ilya
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit

2014-06-30 Thread Ilya Shakhat
2014-06-30 19:17 GMT+04:00 Kurt Taylor krtay...@us.ibm.com:

 Dan Smith d...@danplanet.com wrote on 06/27/2014 12:33:48 PM:
  If it really does show up right in Gerrit as if it were integrated,
  then that would be fine with me. I think the biggest problem we have
  right now is that a lot of the CI systems are very inconsistent in
  their reporting and we often don't realize when one of them *hasn't*
  voted. If the new thing could fill out the chart based on everything
  we expect to see a vote from, so that it's very clear that one is
  missing, then that's a net win right there.


 There is a similar old bug for that, with a good suggestion for how it
 could possibly be done:

 https://bugs.launchpad.net/openstack-ci/+bug/1251758


What about to have report like this:
http://stackalytics.com/report/ci/neutron/7 ?

Thanks,
Ilya
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [neutron] [third-party] Neutron 3rd Party CI status dashboard

2014-06-29 Thread Ilya Shakhat
Hi!

During last couple weeks there is an increasing demand on tracking
3rd-party CI statuses. We at Stackalytics decided to be in trend and (with
some inspiration from Salvatore's proposal) implemented report that shows
summary on external CI status. The initial version is available for Neutron
- http://stackalytics.com/report/ci/neutron/7

The report shows summary of all CI jobs during specified period of time,
including:
 * stats of runs on merged patch sets:
- total number of runs
- success rate (success to total ratio)
- time of the latest run
- last test result
  * stats for all patch sets (the same set as for merged)
  * last test results for every merged patch set grouped by days (useful to
see how different CIs correlate with each other and how often they run)

Under merged patch set report means the last patch set in the merged
change request, thus it is almost the same as the trunk code. CI
configuration is taken from DriverLog's default data
https://git.openstack.org/cgit/stackforge/driverlog/tree/etc/default_data.json.
Standard Stackalytics screen is also available for CIs -
http://stackalytics.com/?metric=ci, including votes breakdown and activity
log.

Since this is the first version there are some open questions:
 * Currently report shows results per CI id, but there are CIs that run
tests against multiple drivers and this case is not supported. What would
be more useful: to get stats for a driver or for CI?
 * Most CIs run tests when patch set is posted. So even if change request
is merged within selected time period corresponding CI results may be
missing.
 * Patterns for non-voting CIs need to be verified. For example Cisco CI
now runs 5 jobs, but DriverLog data still contains old data.

Thanks,
Ilya

2014-06-16 17:52 GMT+04:00 Salvatore Orlando sorla...@nicira.com:


 However, it would be great if we could start devising a solution for
 having health reports from the various CI systems.
 This report should report the following kind of information:
 - timestamp of last run
 - timestamp of last vote (a system might start job which then get aborted
 for CI infra problems)
 - % of success vs failures (not sure how important is that one but
 provides a metric of comparison with upstream jenkins)
 - % of disagreements with jenkins (this might allow us to quickly spot
 those CI systems which are randomly -1'ing patches)

 The percentage metrics might be taken over a 48 hours or 7 days interval,
 or both.
 Does this idea sound reasonable?


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron] [third-party] Current status of Neutron 3rd Party CI and how to move forward

2014-06-16 Thread Ilya Shakhat

  However, it would be great if we could start devising a solution for
 having
  health reports from the various CI systems.
  This report should report the following kind of information:
  - timestamp of last run
  - timestamp of last vote (a system might start job which then get aborted
  for CI infra problems)
  - % of success vs failures (not sure how important is that one but
 provides
  a metric of comparison with upstream jenkins)
  - % of disagreements with jenkins (this might allow us to quickly spot
 those
  CI systems which are randomly -1'ing patches)
 
  The percentage metrics might be taken over a 48 hours or 7 days
 interval, or
  both.
  Does this idea sound reasonable?
 
 This sounds like a very good idea. Now we just need to find someone
 with the time to write this. :)


That's exactly what Stackalytics/DriverLog may do! It already collects the
latest CI votes and it wouldn't be hard to calculate metrics based on them.

Ilya


2014-06-16 18:11 GMT+04:00 Salvatore Orlando sorla...@nicira.com:




 On 16 June 2014 15:58, Kyle Mestery mest...@noironetworks.com wrote:

 On Mon, Jun 16, 2014 at 8:52 AM, Salvatore Orlando sorla...@nicira.com
 wrote:
  I will probably be unable, as usual, to attend today's CI meeting (falls
  right around my dinner time).
  I think it's a good idea to starting keeping track of the status of the
  various CI systems, but I feel the etherpad will not work very well in
 the
  long term.
 
 Agreed. The etherpad was a starting point, I'll move this information
 to a wiki page later today.

  However, it would be great if we could start devising a solution for
 having
  health reports from the various CI systems.
  This report should report the following kind of information:
  - timestamp of last run
  - timestamp of last vote (a system might start job which then get
 aborted
  for CI infra problems)
  - % of success vs failures (not sure how important is that one but
 provides
  a metric of comparison with upstream jenkins)
  - % of disagreements with jenkins (this might allow us to quickly spot
 those
  CI systems which are randomly -1'ing patches)
 
  The percentage metrics might be taken over a 48 hours or 7 days
 interval, or
  both.
  Does this idea sound reasonable?
 
 This sounds like a very good idea. Now we just need to find someone
 with the time to write this. :)

  Also, regarding [1]. I agree that more is always better...  but I would
 like
  a minimum required set of tests to be enforced.
  Is this something that can be achieved?
 
 I think the tests that are in there are the minimum tests I'd like to
 see run. I'll clarify the language on the wiki page a bit.


 If the intention is to have the minimum set of test we'd like to see run
 then it's perfect!
 I was trying to say we should impose that set as a minimum requirement...



  Salvatore
 
  [1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
 
 
 
 
  On 16 June 2014 07:07, YAMAMOTO Takashi yamam...@valinux.co.jp wrote:
 
  hi,
 
   My initial analysis of Neutron 3rd Party CI is here [1]. This was
   somewhat correlated with information from DriverLog [2], which was
   helpful to put this together.
 
  i updated the etherpad for ofagent.
  currently a single CI system is running tests for both of ofagent and
 ryu.
  is it ok?
 
  YAMAMOTO Takashi
 
  ___
  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
 

 ___
 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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [metrics] How to group activity in git/gerrit repositories

2014-06-16 Thread Ilya Shakhat
Let me explain how Stackalytics grouping works.

Most of groups are created from the official programs http://programs.yaml
.yaml. Every program turns into item in the module list (colored in
violet), for example 'Nova Compute' is a group containing 'nova',
'python-novaclient' and 'nova-specs'. Every type of repo (integrated,
incubated and others) turns into the project type, for example 'integrated'
type would contain all modules for a chosen release.

Also Stackalytics has a few custom project types
https://github.com/stackforge/stackalytics/blob/master/etc/default_data.json#L7833-L7879,
for example 'infra' is every project under 'openstack-infra' git, or
'documentation' which is the group 'documentation' from programs.yaml.
Custom module groups
https://github.com/stackforge/stackalytics/blob/master/etc/default_data.json#L7749-L7778
are also possible, but actually used for stackforge projects only.
Currently there's no group for python clients, but it would be very easy to
add such group.

Thanks,
Ilya

2014-06-16 21:57 GMT+04:00 Stefano Maffulli stef...@openstack.org:

 On Fri 13 Jun 2014 10:51:24 AM PDT, Stangel, Dan wrote:
  You can also refer to the example of Stackalytics, who have created
  their own hierarchy and groupings for metrics reporting:
 
 https://github.com/stackforge/stackalytics/blob/master/etc/default_data.json

 It's a very neat grouping. It seems to me that the clients are grouped
 with their parent git/gerrit repo (nova with python-novaclient, under
 'Compute' program) and Nova is shown alone. I don't see the python
 clients individual repositories or grouped: is that correct?

 For the quarterly reports I will need granularity because I believe
 that clients have different dynamics than their parent project (and if
 that proves not to be the case, we can remove this complexity later and
 merge data).

 can you share a concrete example of how you group things?

 --
 Ask and answer questions on https://ask.openstack.org

 ___
 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] [DriverLog] What to fix and when

2014-06-11 Thread Ilya Shakhat
Anita, I put the meeting on my schedule.

Jay, can you be a back-up person?

Thanks,
Ilya


2014-06-10 22:18 GMT+04:00 Anita Kuno ante...@anteaya.info:

 On 06/10/2014 01:58 PM, Jay Pipes wrote:
  Stackers,
 
  OK, we are fully aware that there are problems with the early DriverLog
  data that is shown in the dashboard. Notably, the Nova driver stuff is
  not correct for the default virt drivers. We will work on fixing that
 ASAP.
 
  Our focus to date has mostly been on the Cinder and Neutron driver
  stats, since it is those communities that have most recently been
  working on standing up external CI systems. The Nova driver systems
  simply, and embarrassingly, fell through the cracks. My apologies to
  anyone who was offended or misled.
 
  Please, if you have any problems with DriverLog, be sure to log a bug on
  Launchpad [1] and we'll get things fixed ASAP.
 
  Best,
  -jay
 
  [1] https://launchpad.net/driverlog
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 Thanks Jay:

 Can we have a driver log representative present at third-party meetings
 to participate in discussions? That would be great.

 Thanks Jay,
 Anita

 https://wiki.openstack.org/wiki/Meetings/ThirdParty

 ___
 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] [neutron] [driverlog] Tail-f CI and it's lack of running and it's DriverLog status

2014-06-10 Thread Ilya Shakhat
Hi!

Tail-f driver seems to be configured correctly. DriverLog will poll Gerrit
in the next 4 hours and update driver details screen.

Regarding green mark on summary screen - it is shown for those drivers that
have configured CI and CI ran at least once. But it doesn't take into
account when the last successful run was. I suppose this mark may be
changed to something like CI health and be green only if tests passed on
master and were run during the last month.

Thanks,
Ilya


2014-06-10 18:33 GMT+04:00 Luke Gorrie l...@tail-f.com:

 Howdy!

 Here is a successful Sandbox test from right now:
 https://review.openstack.org/#/c/99061/. I don't immediately see how to
 list all historical sandbox tests. (The previous ones are from before the
 Summit anyway.)

 I enabled the CI for the openstack/neutron Gerrit feed now. Here is a
 change that it tested right now: https://review.openstack.org/#/c/95526/.
 (Voting is disabled on the account and the config conservatively is set to
 vote 0 on failure.)

 Yes, I believe you can just submit a patch to DriverLog to reflect the
 current status.


 DriverLog is sourced from default_data.json (
 https://github.com/stackforge/driverlog/blob/master/etc/default_data.json#L1007)?
 If so then it does reflect the current status:

 ci: {
 id: tailfncs,
 success_pattern: Successful,
 failure_pattern: Failed
 }

 i.e. it specifies which CI account is associated with this driver, and
 that corresponds to a CI that is now up and running.



 ___
 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] [DriverLog][nova][neutron][cinder] Call for vendor participation please

2014-05-07 Thread Ilya Shakhat
Hi Akihiro,

Please see my comments inline.

2014-05-07 10:35 GMT+04:00 Akihiro Motoki mot...@da.jp.nec.com:

 Hi,

 Thanks for the effort.
 While I am looking the website and the driver database,
 I have a couple of questions and suggestions.

 - Is it better to include trunk (= Juno) in releases in each driver
if it is a part of the trunk or to wait it until Juno is released?
We need some guidelines on this.


For drivers that have external CI application explicitly converts results
for master branch into the latest release (=Juno), but probably this is a
bit misleading since release doesn't exist yet. I give Evgenia and Boris a
chance to comment on this.


 - Which is better as maintainer email, an individual mail address or CI
 account contact address?
IMO an individual mail address looks better because CI account
 contact address receives
all review comments and mails to the address can be missed or not
 noticed soon from my experience.
It is better to have some guideline on the maintainer email.


I'd prefer individual email too or (as an option) an alias of team that
supports driver.



 - How is the status of CI tested determined?
I am not sure how it is handled in Wiki informaiton.


Status CI tested means that driver is tested by vendor and test results
are attached to gerrit review. Currently DriverLog takes into account votes
only, so if CI doesn't vote (even if leaves a comment) then it is treated
as CI not present. The code is implemented this way because format of
test result comment is not unified and differs from driver to driver.
To specify that driver has CI the one needs to provide CI's gerrit id in
attribute ci_id, for example like this
https://github.com/stackforge/driverlog/blob/master/etc/default_data.json#L343


 - (Related to the above) How does DriverLog handle a case
where multiple drivers are tested under once CI account?
AFAIK some CI acounts run third party testing for multiple drivers.


It is not handled correctly and is subject to discuss and re-implement. For
example in Neutron Big Switch CI runs tests against 2 drivers, but sets
only 1 vote. Seems like solution may be to parse comment from CI.


 - releases in drivers section is a list of release names now.
It means we need to update releases in every release.
I wonder we can support [from_release, to_release] style.
 If to_release is omitted, it means trunk.


This is made intentionally, so maintainers verify list of drivers before
every release and add new release only if everything works.



 Thanks,
 Akihiro



Thanks,
Ilya



 (2014/04/29 2:05), Jay Pipes wrote:
  Hi Stackers,
 
  Mirantis has been collaborating with a number of OpenStack
  contributors and PTLs for the last couple months on something called
  DriverLog. It is an effort to consolidate and display information
  about the verification of vendor drivers in OpenStack.
 
  Current implementation is here:
 
  http://staging.stackalytics.com/driverlog/
 
  Public wiki here: https://wiki.openstack.org/wiki/DriverLog
 
  Code is here: https://github.com/stackforge/driverlog
 
  There is currently a plan by the foundation to publicly announce this
  in the coming weeks.
 
  At this point Evgeniya Shumakher, in cc, is manually maintaining the
  records, but we aspire for this to become a community driven process
  over time with vendors submitting updates as described in the wiki and
  PTLs and cores of the respective projects participating in update
  reviews.
 
  A REQUEST: If you are vendor that has built an OpenStack driver,
  please check that it is listed on the dashboard and update the record
  (following the process in the wiki) to make sure the information is
  accurately reflected. We want to make sure that the data is accurate
  prior to announcing it to general public.
 
  Also, if anybody has a suggestion on what should be improved / changed
  etc. == please don’t hesitate to share your ideas!
 
  Thanks!
  Jay and Evgeniya
 
  ___
  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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Fuel] Rabbit in HA mode for Glance

2014-04-10 Thread Ilya Shakhat
Hi,

Recently Glance switched to oslo.messaging library and as benefit got
support of HA for Rabbit queues (parameter 'rabbit_ha_queues'). There are
similar parameters in other projects (Nova, Heat, Ceilometer) and they are
configured in corresponding manifest files. Are there plans to add the same
into Glance manifests?

Thanks,
Ilya
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [savanna] Nominate Andrew Lazarew for savanna-core

2014-02-21 Thread Ilya Shakhat
2014-02-21 16:46 GMT+04:00 Matthew Farrellee m...@redhat.com:


 fyi, some of those links don't work, but these do,

 http://stackalytics.com/report/contribution/savanna-group/30
 http://stackalytics.com/report/contribution/savanna-group/90
 http://stackalytics.com/report/contribution/savanna-group/180


Yep. These reports were upgraded and now show not only review stats, but
also a number of posted patches, commits and emails sent to openstack-dev -
thus covering almost all engineer's contribution to project.

Glad to see Andrew on top of the list.


Thanks,
Ilya
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [WSME] Can't install WSME 0.6 due to ipaddr library

2014-02-07 Thread Ilya Shakhat
Hi Doug,

I'm trying to install WSME 0.6, but today it fails due to inability to
install ipaddr dependency.

Pip output:
Downloading/unpacking ipaddr (from WSME)
  You are installing a potentially insecure and unverifiable file. Future
versions of pip will default to disallowing insecure files.
  HTTP error 403 while getting
https://googledrive.com/host/0Bwh63zyus-UlZ1dxQ08zczVRbXc/ipaddr-2.1.11.tar.gz(from
http://code.google.com/p/ipaddr-py/)
  Could not install requirement ipaddr (from WSME) because of error HTTP
Error 403: Forbidden

ipaddr is distributed via Google Drive and it appears that the quota on
file downloading is reached: Sorry, you can't view or download this file
at this time. Too many users have viewed or downloaded this file
recently message is shown if url is opened in browser.

The dependency was introduced by commit
https://github.com/stackforge/wsme/commit/f191f32a722ef0c2eaad71dd33da4e7787ac2424ipaddr
is used for IP validation purposes.

Can ipaddr be replaced by some other library? I suspect the validation code
should already exist at least in Neutron.

Thanks,
Ilya
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Reviewing reviewers

2014-01-24 Thread Ilya Shakhat
And it is worth mentioning activity report in Stackalytics, the link to it
is located in contribution summary block on user's statistics screen. The
report looks like http://stackalytics.com/report/users/zaneb and contains
all reviews, posted patches, commits, emails and blueprints.

Thanks,
Ilya


2014/1/24 Joshua Harlow harlo...@yahoo-inc.com

 Another one:

 https://github.com/harlowja/gerrit_view#qgerrit

 That's similar to :)

 Sent from my really tiny device...

  On Jan 23, 2014, at 2:42 PM, Zane Bitter zbit...@redhat.com wrote:
 
  I don't know about other projects, but we in the Heat project are
 constantly on the lookout for people who can be converted into core
 reviewers. Inevitably part of that process is evaluating whether someone
 has developed the depth of knowledge of the code that would allow them to
 catch a reasonable proportion of issues. One way to do that is to look at a
 a large selection of their past reviews, but the web interface is very much
 not conducive to doing that.
 
  The data is available through the Gerrit API, so I threw together a tool
 to obtain and print it:
 
  https://github.com/zaneb/metareview
 
  Basically it outputs the text of every review by a particular user in a
 particular project, along with a link.
 
  The output is pretty basic, but would be easy to modify if somebody has
 other uses in mind. I hope this might prove useful to somebody.
 
  cheers,
  Zane.
 
  ___
  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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] Stackalytics 0.4 released!

2013-12-12 Thread Ilya Shakhat
Hello everyone!

Stackalytics team is happy to announce the release of version 0.4. This
release is completely dedicated to different types of reports. We added
highly demanded top reviewers chart acknowledged as an essential tool for
finding most active reviewers (ex.
http://stackalytics.com/report/reviews/neutron-group/30). Open reviews
report to help core engineers with tracking the backlog and reviews that
stay for too long (http://stackalytics.com/report/reviews/nova/open). And
activity report, the one to show all work done by engineer and another by
company. Also this report includes nice punch-card and the one can find
that there are really world-wide never-sleeping contributors like
http://stackalytics.com/report/companies/red%20hat :)

In details, total changes are:

   - Added review stats
reporthttp://stackalytics.com/report/reviews/neutron-group/30that
shows top reviewers with breakdown by marks and disagreement ratio
   against core's decision
   - Added open reviews
reporthttp://stackalytics.com/report/reviews/nova/openthat shows top
longest reviews and backlog summary
   - Added activity report
http://stackalytics.com/report/users/boris-42with engineer's
activity log and punch-card of usual online hours (in UTC).
   The same report is available for companies
   - Fixed review stats calculation, now Approve marks are counted
   separately
   - Fixed commit date calculation, now it is date of merge, not commit
   - Minor improvements in filter selectors
   - Incorporated 21 updates to user and company profiles in default data

The next Stackalytics meeting will be on Monday, Dec 16 at 15:00 UTC in
#openstack-meeting. Come and join us, we have somemore things for the next
release.

Thanks,
Ilya
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra] How to determine patch set load for a given project

2013-11-19 Thread Ilya Shakhat
Matt,

As an option you may estimate the load using Stackalytics data on number of
commits -
http://stackalytics.com/?release=icehousemetric=commitsproject_type=allmodule=sqlalchemy-migrateNumber
of commits is certainly less than number of patches, but for project
sqlalchemy-migrate the multiplier 2 will give a good estimation.

Thanks,
Ilya


2013/11/19 Matt Riedemann mrie...@linux.vnet.ibm.com

 We have a team working on getting CI setup for DB2 10.5 in
 sqlalchemy-migrate and they were asking me if there was a way to calculate
 the patch load through that project.

 I asked around in the infra IRC channel and Jeremy Stanley pointed out
 that there might be something available in http://graphite.openstack.org/by 
 looking for the project's test stats.

 I found that if you expand stats_counts  zuul  job and then search for
 your project (sqlalchemy-migrate in this case), you can find the jobs and
 their graphs for load. In my case I care about stats for
 gate-sqlalchemy-migrate-python27.

 I'm having a little trouble interpreting the data though. From looking at
 what's out there for review now, there is one new patch created on 11/19
 and the last new one before that was on 11/15. I see spikes in the graph
 around 11/15, 11/18 and 11/19, but I'm not sure what the 11/18 spike is
 from?

 --

 Thanks,

 Matt Riedemann


 ___
 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] [stackalytics] Official Programs tag?

2013-11-01 Thread Ilya Shakhat
Sean,

Currently the grouping is two-layer: the higher is to split between
openstack-hosted and stackforge-hosted projects, the lower is to split
core, incubation, docs, etc. The grouping may be not so accurate since it
needs to comply with the latest changes in integrated / incubated projects
(bug https://bugs.launchpad.net/stackalytics/+bug/1244485).

I see there's a need to have stats for official projects (more correctly to
say projects belonging to official programs
https://wiki.openstack.org/wiki/Programs), and separate that stats from
other openstack-hosted projects.
So will it work to have the grouping like that?
 - Official OpenStack Projects
- core
- integrated
- incubated
 - OpenStack complimentary projects (e.g. infra projects like jeepyb, gitdm)
 - Stackforge projects (everything from github/stackforge)

Thanks,
Ilya


2013/10/27 Robert Collins robe...@robertcollins.net

 On 28 October 2013 04:32, Sean Dague s...@dague.net wrote:
  I've been looking at the stackalytics code and one of the areas that I
 think
  stackalytics has a structural issue is around the project_group tag.
 
  The existing project_group tags of core, incubation, documentation,
  infrastructure, and other are all fine and good, however none of
 these
  actually represent a number I'd like to see, which is Official Programs
  contributions over all.
 
  Which would be core + documentation + infrastructure + QA / Devstack
 trees
  (+ maybe Tripleo? I don't remember if that's Official or Incubated
 program
  at this point).

 TripleO is official

 NB: Incubation happens to projects, not programs.

 -Rob



 --
 Robert Collins rbtcoll...@hp.com
 Distinguished Technologist
 HP Converged Cloud

 ___
 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


[openstack-dev] [stackalytics] team meeting minutes October 21

2013-10-22 Thread Ilya Shakhat
Thanks everyone who have joined Stackalytics meeting.

The team reviewed and prioritized blueprints. For the next 0.4 release the
following bps were selected:
 * 
module-review-backlog-statshttps://blueprints.launchpad.net/stackalytics/+spec/module-review-backlog-stats
-
reports on review activity for modules
 * 
review-punchcardhttps://blueprints.launchpad.net/stackalytics/+spec/review-punchcard
-
report usual working hours for engineer, similar to
https://github.com/stackforge/stackalytics/graphs/punch-card
 * 
web-filters-cachinghttps://blueprints.launchpad.net/stackalytics/+spec/web-filters-caching
-
cache search queries to improve performance

The full logs are available below:

Minutes:
http://eavesdrop.openstack.org/meetings/stackalytics/2013/stackalytics.2013-10-21-15.01.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/stackalytics/2013/stackalytics.2013-10-21-15.01.txt
Log:
http://eavesdrop.openstack.org/meetings/stackalytics/2013/stackalytics.2013-10-21-15.01.log.html


Sincerely yours,
Ilya Shakhat
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Tuskar] Weekly IRC meetings

2013-09-05 Thread Ilya Shakhat
Oleg,

Savanna meeting is on Thursdays at 18:00 UTC (
https://wiki.openstack.org/wiki/Meetings#Savanna_.28Hadoop.29_meeting)

Ilya.


2013/9/5 Oleg Gelbukh ogelb...@mirantis.com

 Tomas,

 Thanks for very interesting project and this meeting as opportunity to
 follow its progress!

 Just to clarify, it looks like this time slot already booked for Savanna
 meeting on #openstack-meeting-alt channel, isn't it?

 --
 Best regards,
 Oleg Gelbukh
 Mirantis, Inc.


 On Thu, Sep 5, 2013 at 5:37 PM, Tomas Sedovic tsedo...@redhat.com wrote:

 Hey everyone,

 after much wrangling, we've come to something resembling a consensus: the
 weekly IRC meetings will be held on Tuesdays 19:00 UTC. This should
 accommodate the US folks (who always have it easy), and both lifeless and
 devs in Europe.

 The details are documented here:

 https://wiki.openstack.org/**wiki/Meetings#Tuskar_meetinghttps://wiki.openstack.org/wiki/Meetings#Tuskar_meeting

 I'll send out the agenda for the first meeting later (at most 24 hours
 before the meeting starts).

 Three cheers for timezones!

 --
 Tomas Sedovic
 Tuskar PTL

 __**_
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://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


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Stackalytics] 0.2 release

2013-08-21 Thread Ilya Shakhat
Hello everyone!

We are excited to present the new release of
Stackalyticshttp://www.stackalytics.com/- 0.2. One of major features
of this release is review processing. It gives
data on who reviews most, distribution of reviews by engineers or by
modules, what is the ratio of positive to negative marks. Also the service
now shows all projects from OpenStack world - nearly 150 active projects!
And the last but not the least - filtering options are made more intuitive,
user may slice the stats by release, project type, module, company,
engineer and, of course, by metric.

Full release notes are below:

   - Changed internal architecture. Got rid of persistent storage in Mongo.
   Configuration file
default_data.jsonhttps://github.com/Mirantis/stackalytics/blob/master/etc/default_data.jsonnow
serves as persistent storage.
   - Added polling of Gerrit for retrieval of review related source data.
   - Implemented basic statistics for reviews: number of reviews over time,
   number of negative/positive review, ratio of positive and negative reviews.
   - Redesigned navigation and layout of statistics pages.
   - Implemented auto-assignment of commits to release cycles based on
   dates.
   - Implemented automated retrieval of projects list from GitHub API.
   - Cleanup of default_data.json (reduced from 14k LOC to 4k)
   - Added to corrections.json all commits which are over 3k LOC and looks
   like auto-generated.
   - Implemented feature request Sort bugs ID as numbers, not as
stringshttps://bugs.launchpad.net/stackalytics/+bug/1204926
   - Fixed bunch deletion from
memcachedhttps://bugs.launchpad.net/stackalytics/+bug/1209211

More details on the architecture are on project's wiki:
https://wiki.openstack.org/wiki/Stackalytics And certainly welcome everyone
who wants to run the service on their own:
https://wiki.openstack.org/wiki/Stackalytics/HowToRun

We currently gather feature requests for version 0.3 - feel free to post
blueprint to project's space at launchpad:
https://launchpad.net/stackalytics/

Thanks,
Ilya
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev