Perl 6 - the future is here, just unevenly distributed

IRC log for #openstack-rally, 2015-03-16

| Channels | #openstack-rally index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:21 openstackgerrit Merged stackforge/rally: [unblock-gates] Reduce cirteria of success for Neutron  https://review.openstack.org/164539
00:23 openstackgerrit Marian Krcmarik proposed stackforge/rally: Add a maximum concurrency option to rps runner  https://review.openstack.org/140150
00:30 aix joined #openstack-rally
00:43 rook-tmp joined #openstack-rally
01:00 mwagner_lap joined #openstack-rally
02:16 kun_huang boris-42: On next Monday, I will ping you for some tasks in rally. I have an exam and some paper work in this week.
02:16 kun_huang boris-42: could be almost free one week later
03:59 asrangne joined #openstack-rally
04:21 zerda joined #openstack-rally
04:31 yfried|afk joined #openstack-rally
04:38 Aswad joined #openstack-rally
04:58 k4n0 joined #openstack-rally
05:03 nkhare joined #openstack-rally
05:10 echoingumesh joined #openstack-rally
05:10 neeti joined #openstack-rally
05:14 asrangne joined #openstack-rally
05:15 aswadr joined #openstack-rally
05:16 k4n0_ joined #openstack-rally
05:18 echoingumesh joined #openstack-rally
05:24 rdas joined #openstack-rally
05:26 echoingumesh joined #openstack-rally
05:34 echoingumesh joined #openstack-rally
05:37 tfreger joined #openstack-rally
05:38 tfreger1 joined #openstack-rally
05:45 tfreger1 left #openstack-rally
05:54 Aswad joined #openstack-rally
06:08 asrangne__ joined #openstack-rally
06:47 abehl joined #openstack-rally
07:07 tfreger joined #openstack-rally
07:07 tfreger left #openstack-rally
07:22 yfried|afk joined #openstack-rally
07:26 yfried joined #openstack-rally
07:27 yfried boris-42: https://review.openstack.org/#/c/140150/8
07:27 yfried boris-42: could you please take a look? I'm not sure I understood the logic all the way. The code seems fine
07:34 echoingumesh joined #openstack-rally
07:34 e0ne joined #openstack-rally
07:37 andreykurilin_ joined #openstack-rally
07:44 Miouge joined #openstack-rally
08:14 fhubik joined #openstack-rally
08:27 nmagnezi joined #openstack-rally
08:32 Miouge joined #openstack-rally
08:44 Miouge joined #openstack-rally
09:43 boris-42 kun_huang: hi there)
09:43 boris-42 kun_huang: you are going to be phd?)
09:43 boris-42 yfried: hi threre
09:51 cdent joined #openstack-rally
09:53 boris-42 yfried: I will take a look
10:02 boris-42 yfried: btw did you see this one https://review.openstack.org/#/c/164384/3 ?
10:03 yfried boris-42: No. mirantis ci is trashing my reviews because of its -1
10:03 yfried boris-42: could you please solve this?
10:04 yfried boris-42: I'll review. next time, tag me on the reviewer list
10:05 boris-42 yfried: so that's why I don't like filtering
10:05 boris-42 yfried: actually we don't have too much changes
10:05 boris-42 so they don't need to be filtered
10:05 yfried boris-42: I understand, but I have limited time for review, so for now, I'd like to focus on code that's ready to go
10:06 boris-42 yfried: I removed Mirantis Rally CI from voting
10:07 yfried boris-42: I don't have time to look at code that fails Jenkins, unless I've been asked to look at it. there are enough patches waiting
10:07 boris-42 yfried: but all reviews will be -1
10:07 boris-42 yfried: but Mirantis Rally CI is not Jenkins
10:07 yfried boris-42: what do you mean "all reviews will be -1"
10:07 boris-42 yfried: they are not -1 from Jenkins
10:07 boris-42 yfried: they are -1 from Rally Mirantis CI
10:07 boris-42 yfried: it got broken =(
10:07 yfried boris-42: I know it isn't but it registers in board as -1 (filter actually helps with that)
10:12 arxcruz joined #openstack-rally
10:37 echoingumesh joined #openstack-rally
10:49 dpaterson joined #openstack-rally
10:51 exploreshaifali joined #openstack-rally
11:07 boris-42 yfried: I left comment on that patch with rps runner
11:07 boris-42 yfried: I believe that in future we should continue refactoring of it, but for now that solution is acceptable
11:11 neeti joined #openstack-rally
11:15 rdas joined #openstack-rally
11:22 yfried boris-42: https://review.openstack.org/#/c/164384/3//COMMIT_MSG,cm
11:22 yfried boris-42: do you have an explanation why tests/unit/aas is useless?
11:26 yfried boris-42: what does "# noqa" means
11:26 yfried ?
11:29 yfried boris-42: also, what does "Q000" mean in         yield (i, "Q000 Remove Single quotes") https://review.openstack.org/#/c/164384/3/tests/hacking/checks.py,cm ?
11:31 boris-42 yfried: just the name of hacking
11:32 boris-42 yfried: rule
11:32 boris-42 yfried: it's used to add abbility to ignore this rule
11:33 yfried so the rule is "q000"?
11:33 boris-42 yfried: about aas tests, we removed code, but didn't removed the tests, and they were not run because __init__.py was missing
11:33 boris-42 yfried: yep
11:33 yfried boris-42: why not a meaningful num?
11:33 boris-42 yfried: it can be any
11:34 yfried boris-42: so could you please change commit to explain what "useless" mean?
11:34 boris-42 yfried: goign to do that
11:34 boris-42 yfried: I found small issue as well
11:38 yfried_ joined #openstack-rally
11:42 openstackgerrit Boris Pavlovic proposed stackforge/rally: Add test that checks rational usage of rally.exceptions module  https://review.openstack.org/164548
11:42 openstackgerrit Boris Pavlovic proposed stackforge/rally: Improve hacking and remove useless unit tests  https://review.openstack.org/164653
11:42 boris-42 yfried_: ^ done
11:48 psd joined #openstack-rally
11:50 jaypipes joined #openstack-rally
11:52 openstackgerrit Merged stackforge/rally: Add a maximum concurrency option to rps runner  https://review.openstack.org/140150
11:55 openstackgerrit Boris Pavlovic proposed stackforge/rally: Add test that checks rational usage of rally.exceptions module  https://review.openstack.org/164548
11:55 openstackgerrit Boris Pavlovic proposed stackforge/rally: Improve hacking and remove useless unit tests  https://review.openstack.org/164384
11:56 mwagner_lap joined #openstack-rally
12:03 dpaterson joined #openstack-rally
12:11 panbalag joined #openstack-rally
12:29 psd joined #openstack-rally
12:33 pboros joined #openstack-rally
12:33 rook-tmp joined #openstack-rally
12:38 echoingumesh joined #openstack-rally
12:43 rook-tmp joined #openstack-rally
12:50 openstackgerrit joined #openstack-rally
12:54 fhubik joined #openstack-rally
12:55 psd_ joined #openstack-rally
13:01 yfried_ joined #openstack-rally
13:10 aix joined #openstack-rally
13:32 yfried_ boris-42: asked about "# noqa" what does this do?
13:32 boris-42 yfried_: ah sorry
13:32 boris-42 yfried_: it's standard way to ingore pep check for that line
13:33 boris-42 yfried_: if you need to ignore rules in some place of code, but don't want to ignore it for whole project
13:33 boris-42 yfried_: rally own pep check ignored that
13:33 yfried_ boris-42: tnx. didn't know that
13:34 boris-42 yfried_: typical usage https://github.com/stackforge/rally/blob/master/rally/objects/__init__.py#L17-L20
13:41 exploreshaifali joined #openstack-rally
13:48 yfried_ boris-42: IMO this demands a spec
13:49 boris-42 yfried_: what?)
13:49 yfried_ boris-42: https://review.openstack.org/#/c/162418/
13:49 yfried_ boris-42: my bad
13:51 boris-42 yfried_: heh
13:51 boris-42 yfried_: I don't see there a much to discuss =)
13:51 boris-42 like for example in input format
13:58 yfried_ boris-42: virtualenv by default?
13:58 yfried_ boris-42: I disagree with that
13:58 yfried_ boris-42: virtualenv is dev related. default installation would be in production and shouldn't set virutalenv
13:59 yfried_ boris-42: also - I would like to see a configurable virtualenv
14:02 boris-42 yfried_: so the idea that we would like is to install rally in venv
14:02 boris-42 yfried_: but do some hackings
14:02 nmagnezi joined #openstack-rally
14:02 boris-42 yfried_: so you will have in your system rally command (without activating that env)
14:04 yfried_ boris-42: why?
14:05 yfried_ boris-42: if you use venv, it should be explicit, and if user doesn't know venv, you shouldn't do this for him
14:06 boris-42 yfried_: using venv is in a lot of case curcial
14:06 yfried_ boris-42: could you please give an example?
14:06 boris-42 yfried_: like if you have old python clients they will be replaced by requriemnts of rally
14:07 boris-42 yfried_: for example rally devstack plugin doesn't work on any stable release of OpenStack
14:07 boris-42 because of different requriments
14:07 openstackgerrit Vitaly Gusev proposed stackforge/rally: Add rally tests for Ceilometer  https://review.openstack.org/153994
14:12 openstackgerrit Vitaly Gusev proposed stackforge/rally: [Ceilometer] Add CeilometerAlarms.create_alarm_and_get_history scenario  https://review.openstack.org/153994
14:14 nmagnezi joined #openstack-rally
14:24 yfried_ boris-42: so that's either a rally problem or a release problem
14:24 yfried_ boris-42: you shouldn't force stuff from under the hood like this
14:25 yfried_ boris-42: you could provide these options but the MUST be explicit and not default
14:25 yfried_ boris-42: if I want to test my stable release, I shouldn't be worried that Rally will be replacing the clients with non-stable clients
14:25 yfried_ boris-42: that's bad practice
14:27 boris-42 yfried_: ?
14:27 boris-42 yfried_: I mean rally has own requirments that are aligned with OpenStack master
14:27 boris-42 yfried_: requirements are changed over time
14:27 boris-42 yfried_: so 1 year old openstack is using different stuff then master Rally
14:28 yfried_ boris-42: that was an example
14:28 boris-42 yfried_: and the only way to mitigate this is to use proper approach for working with python
14:28 boris-42 yfried_: virtualenv
14:28 boris-42 yfried_: btw why not just commnet that patch and dicuss it?
14:28 yfried_ boris-42: so we should have 3 install mods
14:29 yfried_ boris-42: default should be system
14:29 boris-42 yfried_: yep in system, in system (with venv), in custom venv
14:29 yfried_ boris-42: but as I said, default should be in system (as if you are doing pip install <whatever>)
14:31 yfried_ boris-42: anyway, that's just a single issue with this patch. I really think changing/defining  rally installation modes requires a discussion over spec and real documentation in rally-docs
14:31 yfried_ boris-42: and a major version bump
14:32 boris-42 yfried_: we don't have yet major versions =)
14:32 boris-42 yfried_: we are still 0.0.x
14:32 yfried_ boris-42: so minor
14:33 yfried_ 0.1.0
14:33 boris-42 yfried_: yep agree with that
14:33 yfried_ boris-42: could I demand a spec for this?
14:35 openstackgerrit Vitaly Gusev proposed stackforge/rally: Add Ceilometer scenario for nova notifications  https://review.openstack.org/154803
14:36 boris-42 yfried_: heh bureaucracy
14:37 boris-42 yfried_: but okay
14:37 boris-42 yfried_: I hope he won't stop contributing to rally after such comment=)
14:37 boris-42 yfried_: because when I need to make some spec I usually stop contributing=)
14:38 yfried_ boris-42: those this count as -2 or -1?
14:41 boris-42 yfried_: no -2 in rally
14:41 yfried_ boris-42: ack
14:41 boris-42 yfried_: never use that mark
14:41 yfried_ boris-42: you are too nice :)
14:41 yfried_ boris-42: jk
14:41 boris-42 boris-42:  http://boris-42.me/thoughts-on-making-openstack-community-more-user-friendly/
14:42 boris-42 yfried_: ^ read this =)
14:42 openstackgerrit Vitaly Gusev proposed stackforge/rally: [Ceilometer] Add CeilometerNovaMetrics.get_nova_notifications scenario  https://review.openstack.org/154803
14:43 openstackgerrit Vitaly Gusev proposed stackforge/rally: Add Ceilometer scenario for nova pollsters  https://review.openstack.org/160387
14:46 openstackgerrit Vitaly Gusev proposed stackforge/rally: [Ceilometer] Add CeilometerNovaMetrics.get_nova_pollsters scenario  https://review.openstack.org/160387
14:47 boris-42 yfried_: so we should try to avoid bureaucracy if it is possible
14:47 boris-42 yfried_: and work for community not against it=)
14:49 yfried_ boris-42: agreed, but the discussion we just had (re venv) should be public and ideally done BEFORE some poor fellow writes 800 bash lines
14:49 openstackgerrit Marian Krcmarik proposed stackforge/rally: Fix some typos in comments/doc strings  https://review.openstack.org/164719
14:53 psd joined #openstack-rally
14:54 serverascode joined #openstack-rally
14:54 yfried_ boris-42: also - do we really have to stick with bash installer?
14:55 yfried_ boris-42: I really hate that, and it would take me years to review. can't we move toward some python CLI script?
15:10 arcimboldo joined #openstack-rally
15:12 openstackgerrit Olga Kopylova proposed stackforge/rally: Implementation of 'rally task abort' command  https://review.openstack.org/161636
15:22 boris-42 arcimboldo: hi there
15:22 boris-42 yfried_: so about installer
15:23 boris-42 yfried_: I believe that we should provide many ways to consume rally
15:23 boris-42 yfried_: bash script/ansible/puppet/packages/docker image
15:24 arcimboldo hi boris-42
15:25 yfried_ boris-42: agreed. but I prefer python script to bash. this installer is getting too complicated to remain a single long bash script
15:25 boris-42 arcimboldo: we are discussion your work=)
15:25 yfried_ boris-42: and a lot of the stuff should be covered by regular pip install (which I have no dev experience with)
15:26 yfried_ boris-42: unrelated interesting query
15:26 arcimboldo boris-42, I'm sorry, in these days I wasn't able to check the latest comments
15:26 yfried_ boris-42: I just got a user-story from a colleague
15:27 boris-42 arcimboldo: it's okay=) actually I was surprised how fast you are addressing comments=)
15:27 arcimboldo yfried_, it's not complicated, it's complex
15:27 yfried_ arcimboldo: what do you mean?
15:28 boris-42 yfried_: oh could you publish it
15:28 boris-42 yfried_: here https://github.com/stackforge/rally/tree/master/doc/user_stories
15:29 yfried_ boris-42: user story might be the wrong term. that's actually a feature request.
15:29 yfried_ boris-42: he would like to see a single (or multiple) VM enduring multiple scenarios instead of VMs being deleted and recreated between scenarios
15:29 boris-42 yfried_: https://github.com/stackforge/rally/tree/master/doc/feature_request put it here
15:30 boris-42 yfried_: hm this seems like will be covered by new input task format
15:30 yfried_ boris-42: example boot_run_command->migrate->resize all done on a single VM
15:30 boris-42 arcimboldo: so actually overall I like your script
15:30 yfried_ boris-42: I thought so at first but I also think it should be handled by context
15:30 boris-42 arcimboldo: it looks amazing for bash=)
15:30 arcimboldo thnx
15:31 yfried_ arcimboldo: I agree
15:31 boris-42 yfried_: so why not do such scenario?
15:32 yfried_ boris-42: this would demand creating a different scenario for each permutation
15:32 boris-42 yfried_: so I was thinking on making such scenario
15:32 boris-42 yfried_: that can run others scenarios
15:32 boris-42 yfried_: but didn'f find simple solution for that
15:33 yfried_ boris-42: while what I had in mind was more like a context that creates VMs as resources (like tenants) and then _boot_server would pull from the context instead of booting and deleting the VMs
15:35 boris-42 yfried_: More and more looking at the code and new input format I am thinking that it's better not to make complicated context (that consumes runners and scenarios)
15:35 yfried_ arcimboldo: however since boris-42 said " amazing for bash" wouldn't you agree that perhaps it should be broken to several component and maybe ported to python for better long term support and management?
15:35 boris-42 yfried_: I don't want to port it to python
15:36 yfried_ boris-42: why not?
15:36 boris-42 yfried_: as I said before python installers looks ugly usually
15:36 boris-42 yfried_: because python was not developed for that
15:36 boris-42 yfried_: and I like idea of keeping one file (if it is good written you don't need to read it at all)
15:37 arcimboldo writing the installscript in python will make it only uglier and harder to understand, imho
15:37 boris-42 yfried_: as well I said that I will be ok with other kinds of installers
15:37 boris-42 arcimboldo: +1
15:37 arcimboldo and will have more dependencies
15:37 * yfried_ dropping the issue :)
15:37 boris-42 But I think that rally team should provided tested
15:37 boris-42 * packages
15:37 boris-42 * ansible installator
15:38 boris-42 * puppet inslattor
15:38 boris-42 bash & docker are already done
15:38 boris-42 and bash will look nice soon=)
15:38 yfried_ boris-42: ansible will consume bash, right?
15:38 yfried_ boris-42: ansible-installer will consume bash-insatller
15:39 psd joined #openstack-rally
15:39 boris-42 yfried_: I think rather no then yes
15:40 yfried_ boris-42: ack
15:40 boris-42 yfried_: but devstack plugin will consume install_rally.sh
15:40 yfried_ boris-42: what does devstack plugin do?
15:41 echoingumesh joined #openstack-rally
15:41 boris-42 yfried_: the same what do nova/cinder/glance/any_other plugin
15:41 boris-42 yfried_: installs rally & configure it
15:41 boris-42 (specify db/ do rally-manage db recreate/ register cloud)
15:41 yfried_ boris-42: ???
15:41 boris-42 so you can just run rally against it
15:42 boris-42 yfried_: ?
15:42 boris-42 yfried_: if you would like to get all-in-one
15:42 boris-42 by running stack.sh
15:42 boris-42 then you need to use rally plugin for devstack
15:42 yfried_ boris-42: oh
15:42 yfried_ boris-42: it allows devstack to install rally
15:43 arcimboldo boris-42, totally unrelated question: what's the status of "support-existing-users" feature? I'm going to install a mid-size openstack cloud, and I would like to start using rally asap on it, but it'll have ldap RO accounts
15:43 yfried_ boris-42: ^ +1 on that question
15:44 arcimboldo I actually wanted to use it already to do some performance tests on the network (running iperf from within rally), but I couldn't...
15:44 boris-42 arcimboldo: yfried_ I am working on that
15:44 boris-42 arcimboldo: yfried_ this chain of patches https://review.openstack.org/#/c/160142/
15:44 arcimboldo I don't want to put you under pressur, I just wanted to know if there is an estimated date...
15:45 arcimboldo s/pressur/pressure/
15:45 boris-42 arcimboldo: so I am doing my best and spending a lot of time on this task
15:45 boris-42 arcimboldo: but it is very very very deep
15:45 boris-42 arcimboldo: I think now I see the end result=)
15:45 boris-42 arcimboldo: I started work on this stuff about 10 months ago=)
15:45 arcimboldo I'ts what I thought looking at the patches ...
15:46 boris-42 arcimboldo: but if you need
15:46 boris-42 arcimboldo: fast way to run with existing users
15:46 boris-42 arcimboldo: you can hack benchmark.context.users
15:46 boris-42 to return existing users instead of creating them
15:47 boris-42 arcimboldo: it's quite simple to do
15:47 boris-42 but it is very dirty hack=)
15:48 arcimboldo I just need to overload setup() and set self.context dictionary?
15:49 arcimboldo boris-42, thnx I'll take a look
15:50 yfried_ arcimboldo: if you succeed, could you please share your code?
15:51 arcimboldo yfried_, sure
15:51 arcimboldo boris-42, one more question: is there a way to ensure that the requested command is executed in parallel on all the machines, even if one is slower to start?
15:51 kairat_kushaev joined #openstack-rally
15:52 arcimboldo boris-42, I'll explain: I'm doing some benchmarks on the network, and I need to run iperf on multiple VMs at the same time.
15:53 arcimboldo boris-42, right now I'm running pdsh, which is working, but I have to 1) start the VMs, 2) update /etc/hosts 3) update /etc/genders, so I was thinking of using rally instead
15:53 arcimboldo (and having graphs for free)
15:56 imarnat joined #openstack-rally
15:57 * boris-42 arcimboldo: me back
15:58 boris-42 arcimboldo: sooo
15:58 boris-42 arcimboldo: paboldin is working on this task
15:58 boris-42 arcimboldo: the idea is that you should use context to create required env
15:59 boris-42 arcimboldo: users/tenants/networks/vms
15:59 boris-42 arcimboldo: and in scenario just trigger benchmark
15:59 boris-42 arcimboldo: so we are working on framework inside rally that simplifies thsi
16:01 boris-42 arcimboldo: this set of patches https://review.openstack.org/#/c/141671/
16:02 boris-42 arcimboldo: btw regarding to support of existing users https://github.com/cernops/rally/commit/d8213e6ffb6d02d45d61185e9c4dc278edb5a62a
16:02 boris-42 arcimboldo: cern guys have few patches related to it (that makes required hack)
16:07 tosky joined #openstack-rally
16:11 psd joined #openstack-rally
16:11 openstackgerrit joined #openstack-rally
16:43 exploreshaifali joined #openstack-rally
16:47 plieb joined #openstack-rally
16:48 plieb usage question: for rally sahara benchmarks, is it possible to specify an existing image (already imported to glance and tagged for sahara) rather than a image_url in the job file?
16:54 openstackgerrit joined #openstack-rally
17:00 boris-42 plieb: hi there
17:00 plieb hi boris-42
17:00 boris-42 plieb: could you point me what exactly benchmark
17:00 plieb sure
17:02 plieb rally/samples/tasks/scenarios/sahara/create_and_list_node_group_templates.json
17:02 yfried_ joined #openstack-rally
17:03 plieb sorry this one: create_and_delete_cluster.json
17:03 plieb under sahara_image: { image_url:
17:04 plieb my use case is that I already have a sahara image registered, i want to test my existing image (instead of downloading and importing a new image)
17:04 boris-42 plieb: then I belive you should remove that context
17:04 boris-42 plieb: at all
17:04 boris-42 ah no
17:06 boris-42 plieb: so short answer is NO
17:06 boris-42 plieb: but code can be refactored to add support for this
17:06 plieb boris-42, thanks
17:06 plieb i just started looking into adding the floating ip creation test this week
17:07 boris-42 plieb: so let's ping NikitaKonovalov
17:07 boris-42 NikitaKonovalov: hi there
17:07 plieb i had a bunch of deadlines i had to hit but now i have some time to look at it
17:07 boris-42 plieb: sure sure=)
17:09 boris-42 plieb: so actually change for sahara is quite simple
17:10 boris-42 plieb: you need to change this https://github.com/stackforge/rally/blob/master/rally/benchmark/context/sahara/sahara_image.py#L32-L52
17:10 boris-42 plieb: so it will support image_url or image
17:10 plieb okay i will take a crack at it
17:11 boris-42 plieb: yep be free to publish patch
17:11 boris-42 plieb: we will help you with this
17:11 plieb thanks again my friend!
17:12 boris-42 plieb: np=)
17:18 boris-42 meteorfox: ping
17:19 meteorfox boris-42: pong!
17:20 echoingumesh joined #openstack-rally
17:28 harlowja joined #openstack-rally
17:28 openstackgerrit Merged stackforge/rally: Improve hacking and remove useless unit tests  https://review.openstack.org/164384
18:01 mwagner_lap joined #openstack-rally
18:20 psd joined #openstack-rally
18:48 rook-tmp joined #openstack-rally
18:58 PerfBeing joined #openstack-rally
19:09 rook_run joined #openstack-rally
19:21 boris-42 meteorfox: so did you have a chance to take a look at graphs refactoring?
19:21 meteorfox boris-42: not in detail
19:21 meteorfox boris-42: I glanced over it
19:22 boris-42 meteorfox: so I think that we need spec
19:22 boris-42 meteorfox: that described what graphs would you like to have in rally reports
19:22 boris-42 meteorfox: what do you think?
19:23 meteorfox boris-42: yeah, I agree
19:24 boris-42 meteorfox: so here is https://github.com/stackforge/rally/blob/master/doc/specs/template.rst
19:24 boris-42 meteorfox: just copy-paste it with changing stuff inside it
19:24 meteorfox boris-42: is this spec a new thing in Openstack?
19:24 meteorfox boris-42: it seems similar to the bps
19:25 boris-42 meteorfox: blueprints?
19:25 meteorfox meteorfox: yeah, blueprints
19:25 boris-42 meteorfox: specs are not new there are already in OpenStack for few releases
19:25 boris-42 meteorfox: they are new in rally only
19:25 meteorfox boris-42: ah I see. I haven't been following other projects this closely
19:25 boris-42 meteorfox: we just use them when we need to dicuss something big that requires discussion=)
19:28 meteorfox boris-42: ok, make sense. I'll think about the graphs I'll need, then I'll draft the spec. I'll add it to my todos
19:28 boris-42 meteorfox: ok sounds great
19:29 boris-42 dpaterson: your patch looks ok for me (I mean idea)
19:29 boris-42 dspano: be free to continue work on it
19:30 dpaterson boris-42: doing the refactor suggested in reviews and adding some tests, thanks!
19:35 psd_ joined #openstack-rally
20:22 psd__ joined #openstack-rally
20:39 e0ne joined #openstack-rally
20:41 plieb joined #openstack-rally
20:50 andreykurilin_ joined #openstack-rally
20:57 jaypipes joined #openstack-rally
21:27 echoingumesh joined #openstack-rally
21:38 cdent joined #openstack-rally
22:05 echoingumesh joined #openstack-rally
22:18 openstackgerrit Marian Krcmarik proposed stackforge/rally: Add to constant and rps runneres limits for maximun Core usage  https://review.openstack.org/164888
22:41 PerfBeing joined #openstack-rally
22:43 PerfBein_ joined #openstack-rally
23:08 mwagner_lap joined #openstack-rally
23:14 panbalag joined #openstack-rally
23:15 openstackgerrit Marian Krcmarik proposed stackforge/rally: Add to constant and rps runneres limits for maximun Core usage  https://review.openstack.org/164888
23:20 andreykurilin_ joined #openstack-rally
23:43 openstackgerrit Boris Pavlovic proposed stackforge/rally: Future improvment of plugin base  https://review.openstack.org/160142
23:43 openstackgerrit Boris Pavlovic proposed stackforge/rally: Switch to plugin base: context, sla, runners  https://review.openstack.org/150647
23:47 karimb joined #openstack-rally

| Channels | #openstack-rally index | Today | | Search | Google Search | Plain-Text | summary