Perl 6 - the future is here, just unevenly distributed

IRC log for #openstack-rally, 2015-10-15

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

All times shown according to UTC.

Time Nick Message
00:00 harshs joined #openstack-rally
00:25 yingjun joined #openstack-rally
01:13 yeungp joined #openstack-rally
01:29 yingjun joined #openstack-rally
01:31 arnoldje joined #openstack-rally
01:48 ilbot3 joined #openstack-rally
01:48 Topic for #openstack-rally is now ☁ Rally RoadMap: http://goo.gl/JZkmwY ☁ Review Dashboard: http://goo.gl/YuCJfl ☁ IRC logs http://irclog.perlgeek.de/openstack-rally ☁ Key persons to ask:  boris-42, yfried, msdubov, rediskin, andreykurilin, amaretskiy  ☁ Documentation: https://rally.readthedocs.org/en/latest/ ☁ To publish changes to Rally:  https://rally.readthedocs.org/en/latest/contribute.html
02:09 yunpengli joined #openstack-rally
02:19 dmorita joined #openstack-rally
02:33 yingjun joined #openstack-rally
02:47 baker joined #openstack-rally
02:54 yingjun joined #openstack-rally
02:58 boris-42 joined #openstack-rally
03:26 puranamr joined #openstack-rally
03:48 yingjun_ joined #openstack-rally
03:58 puranamr joined #openstack-rally
04:01 yingjun joined #openstack-rally
04:02 puranamr joined #openstack-rally
04:06 puranamr joined #openstack-rally
04:10 baker joined #openstack-rally
04:12 puranamr joined #openstack-rally
04:19 puranamr joined #openstack-rally
04:21 baker joined #openstack-rally
04:23 puranamr joined #openstack-rally
04:32 puranamr joined #openstack-rally
04:34 puranamr_ joined #openstack-rally
04:37 emagana joined #openstack-rally
04:41 puranamr joined #openstack-rally
05:16 psd joined #openstack-rally
05:20 harshs joined #openstack-rally
05:41 harshs_ joined #openstack-rally
05:48 puranamr joined #openstack-rally
05:51 puranamr joined #openstack-rally
06:00 harshs joined #openstack-rally
06:01 yfried joined #openstack-rally
06:04 yfried_ joined #openstack-rally
06:14 yingjun joined #openstack-rally
06:16 pythonguy joined #openstack-rally
06:20 yfried_ jaredrohe: still here?
06:21 neeti joined #openstack-rally
06:24 openstackgerrit Yair Fried proposed openstack/rally: [spec] Refactoring scenario utils  https://review.openstack.org/172831
06:26 boris-42 jaredrohe: you should update your plugins
06:26 boris-42 jaredrohe: plugins of varions 0.0.4 and 0.1.x are not compatible
06:26 boris-42 jaredrohe: about keystone v3 it is supporeted for quite long amount of time
06:27 boris-42 jaredrohe: and 0.0.4 works with keystone v3
06:27 boris-42 jaredrohe: internally in Mirantis we are testing clouds with keystone v3
06:27 yfried_ boris-42: how are you?
06:27 boris-42 yfried_: hi there
06:27 boris-42 yfried_: almost good
06:27 yfried_ boris-42: almost?
06:27 boris-42 yfried_: wife's bike was stolen
06:27 boris-42 =(
06:28 yfried_ boris-42: that's bad.
06:28 yfried_ boris-42: was it insured?
06:29 boris-42 yfried_: nope
06:29 boris-42 yfried_: they stole it from our renters storage
06:29 yfried_ boris-42: back home? (Russia?)
06:29 boris-42 yfried_: so I am trying to get compensation from them
06:29 boris-42 yfried_: hm?
06:30 boris-42 yfried_: not it happened here in US in common storage for aparts
06:30 kiran-r joined #openstack-rally
06:34 yingjun joined #openstack-rally
06:39 rajesht_ joined #openstack-rally
06:43 adiantum_ joined #openstack-rally
06:46 yfried_ boris-42: ok. hope you get full compensation.
06:46 yfried_ boris-42: re https://review.openstack.org/#/c/172831/22
06:47 yfried_ boris-42: I need some help with the mechanism of self.services()
06:47 yfried_ boris-42: I was thinking about something similar to the self.clients mechanism (with caching, etc...)
06:48 yfried_ boris-42: don't know how to make it, though
06:57 boris-42 yfried_: so let's not do the any caching in services
06:58 boris-42 yfried_: it's not the purpose of service to do the optimal stuff
06:58 boris-42 yfried_: they need to generate real and in clear way load
06:58 boris-42 yfried_: caching in oslclients is done because it is typical usage of cloud
06:59 boris-42 yfried_: you don't generate for each request new token
06:59 boris-42 yfried_: you are generating it once and using
06:59 boris-42 yfried_: as well as creating any of clients
07:00 rdas joined #openstack-rally
07:32 anshul joined #openstack-rally
07:35 arxcruz joined #openstack-rally
07:54 openstackgerrit Merged openstack/rally: [PLUGINS] Follow symlinks in plugin discovery  https://review.openstack.org/234702
07:56 fhubik joined #openstack-rally
08:01 boris-42 yfried_: btw could you please review patches from 2 guys
08:02 boris-42 yfried_: Chris and Pavel
08:02 yfried_ boris-42: will do
08:02 boris-42 yfried_: thanks we really need to review more...
08:09 yingjun joined #openstack-rally
08:21 openstackgerrit Endre Karlson proposed openstack/rally: Add Designate API V2 support  https://review.openstack.org/229350
08:31 amaretskiy joined #openstack-rally
08:35 aix joined #openstack-rally
08:36 adiantum joined #openstack-rally
08:36 vponomaryov joined #openstack-rally
08:57 kiranr joined #openstack-rally
08:58 cdent joined #openstack-rally
08:59 exploreshaifali joined #openstack-rally
09:01 berendt joined #openstack-rally
09:16 redixin joined #openstack-rally
09:20 amaretskiy joined #openstack-rally
09:26 e0ne joined #openstack-rally
09:33 openstackgerrit Sergey Skripnick proposed openstack/rally: Add neutron quota info only if neutron available  https://review.openstack.org/234950
09:50 exploreshaifali joined #openstack-rally
09:58 aix joined #openstack-rally
09:58 psd joined #openstack-rally
09:59 tosky joined #openstack-rally
10:08 openstackgerrit Sergey Skripnick proposed openstack/rally: Add neutron quota info only if neutron available  https://review.openstack.org/234950
10:37 aix joined #openstack-rally
10:43 rvasilets joined #openstack-rally
10:50 openstackgerrit Andrey Kurilin proposed openstack/rally: WIP! Add new context plugin to support different API versions  https://review.openstack.org/232546
10:50 openstackgerrit Andrey Kurilin proposed openstack/rally: Add ability to specify service types for clients  https://review.openstack.org/235255
10:59 rajesht_ since we have cleanup module in rally, can we remove all delete resource calls from all scenarios ??
11:01 boris-42 rajesht_: nope
11:01 boris-42 rajesht_: because we will get different loads
11:02 boris-42 rajesht_: no-deletion -> scale testing
11:02 boris-42 rajesht_: deletion -> performance testing under load
11:03 rajesht_ boris-42: in that case, is this comment valid https://review.openstack.org/#/c/234644/1/rally/plugins/openstack/scenarios/nova/servers.py
11:06 boris-42 kun_huang: ^
11:06 boris-42 kun_huang: nope comment is not OK
11:06 boris-42 rajesht_: ^
11:06 boris-42 rajesht_: you can make special argument do_delete
11:06 rajesht_ boris-42: so the delete call should be there ??
11:06 boris-42 rajesht_: yep
11:07 boris-42 rajesht_: but you can add do_delete argument
11:07 boris-42 rajesht_: True/False and if it is specified or not you can change behaviour
11:07 rajesht_ boris-42: how ?? let me check
11:07 rajesht_ boris-42: is do_delete implemented in any scenario ?
11:07 boris-42 rajesht_: add argument to function
11:08 boris-42 rajesht_: https://github.com/openstack/rally/blob/master/rally/plugins/openstack/scenarios/mistral/workbooks.py#L45
11:08 boris-42 rajesht_: like here
11:08 openstackgerrit Yaroslav Lobankov proposed openstack/rally: Adding command to show tempest.conf  https://review.openstack.org/234126
11:09 rajesht_ boris-42: thanks, will try with that.
11:09 openstackgerrit Chris St. Pierre proposed openstack/rally: Handle tracebacks in chart generation  https://review.openstack.org/232742
11:11 rajesht_ boris-42: in that case, I need to add do_delete parameter in json and yaml scripts as well
11:11 rajesht_ boris-42: right ??
11:14 boris-42 rajesht_: yep you may add them
11:15 rajesht_ boris-42: will upload a patchset soon
11:15 rajesht_ boris-42: thanx for your time :)
11:16 boris-42 rajesht_: I am going to sleep
11:16 boris-42 4:16 a.m.
11:16 rajesht_ boris-42: 0_0
11:16 rajesht_ boris-42: from where are you ??
11:17 rajesht_ boris-42: Good night sleep well
11:17 boris-42 rajesht_ San Jose US
11:32 kbaikov joined #openstack-rally
11:40 ekarlso boris-42: rvasilets can I get some looks at the designate patches ?
11:41 rvasilets ekarlso, Hi will look at you patches
11:47 openstackgerrit Yaroslav Lobankov proposed openstack/rally: Adding command to show tempest.conf  https://review.openstack.org/234126
12:06 adiantum joined #openstack-rally
12:07 openstackgerrit Merged openstack/rally: [Sahara] Add support for proxy node  https://review.openstack.org/212036
12:12 _hanhart joined #openstack-rally
12:22 openstackgerrit Roman Vasilets proposed openstack/rally: [WIP] Change rps by function  https://review.openstack.org/234195
12:24 kbaikov joined #openstack-rally
12:32 openstackgerrit Andrey Kurilin proposed openstack/rally: Add ability to specify service types for clients  https://review.openstack.org/235255
12:33 puranamr joined #openstack-rally
12:36 MaxPC joined #openstack-rally
12:37 _hanhart joined #openstack-rally
12:37 aix joined #openstack-rally
12:45 puranamr joined #openstack-rally
12:46 albertw joined #openstack-rally
12:47 adiantum_ joined #openstack-rally
12:47 stpierre joined #openstack-rally
12:49 openstackgerrit Chris St. Pierre proposed openstack/rally: Implement new random name generator for scenario plugins  https://review.openstack.org/226385
12:49 openstackgerrit Chris St. Pierre proposed openstack/rally: Implement new random name generator for wrapper plugins  https://review.openstack.org/226387
12:49 openstackgerrit Chris St. Pierre proposed openstack/rally: Remove old random name generator  https://review.openstack.org/226388
12:51 MaxPC joined #openstack-rally
12:52 afazekas joined #openstack-rally
13:22 openstackgerrit Alexander Maretskiy proposed openstack/rally: [Reports] Add an option for embedding JS/CSS libs into report  https://review.openstack.org/235335
13:32 puranamr joined #openstack-rally
13:36 adiantum joined #openstack-rally
13:42 openstackgerrit Andrey Kurilin proposed openstack/rally: WIP! Add new context plugin to support different API versions  https://review.openstack.org/232546
13:45 MaxPC1 joined #openstack-rally
13:46 openstackgerrit Andrey Kurilin proposed openstack/rally: WIP: check simple cinder scenario with V2 API  https://review.openstack.org/235352
13:47 emagana joined #openstack-rally
13:49 yfried_ joined #openstack-rally
13:51 openstackgerrit Andrey Kurilin proposed openstack/rally: WIP: try to use keystoneclient.client.Client  https://review.openstack.org/235360
13:58 openstackgerrit Chris St. Pierre proposed openstack/rally: Use network context for Neutron scenarios  https://review.openstack.org/210612
14:01 openstackgerrit Roman Vasilets proposed openstack/rally: [WIP] Change rps by function  https://review.openstack.org/234195
14:08 kir joined #openstack-rally
14:10 kir Hi all, I've got the following after git pull ./install_rally.sh -d ~/VE/rally: PluginWithSuchNameExists: Plugin with such name: `base_context` already exists in `default` namespace. Any clue on that?
14:13 baker joined #openstack-rally
14:14 coolsvap joined #openstack-rally
14:18 mwagner_ joined #openstack-rally
14:19 openstackgerrit Roman Vasilets proposed openstack/rally: [WIP] Change rps by function  https://review.openstack.org/234195
14:20 MaxPC joined #openstack-rally
14:28 MaxPC joined #openstack-rally
14:29 openstackgerrit Yaroslav Lobankov proposed openstack/rally: Adding command to show tempest.conf  https://review.openstack.org/234126
14:35 MaxPC1 joined #openstack-rally
14:35 arnoldje joined #openstack-rally
14:48 MaxPC joined #openstack-rally
14:49 openstackgerrit Andrey Kurilin proposed openstack/rally: WIP: try to use keystoneclient.client.Client  https://review.openstack.org/235360
15:06 openstackgerrit Andrey Kurilin proposed openstack/rally: WIP! Add new context plugin to support different API versions  https://review.openstack.org/232546
15:06 openstackgerrit Andrey Kurilin proposed openstack/rally: WIP: check simple cinder scenario with V2 API  https://review.openstack.org/235352
15:07 stpierre kir: i've never seen that, but i'd be tempted to nuke the virtualenv and start fresh, if that's an option
15:13 yfried joined #openstack-rally
15:22 puranamr joined #openstack-rally
15:25 e0ne joined #openstack-rally
15:31 openstackgerrit joined #openstack-rally
15:33 arxcruz joined #openstack-rally
15:43 ukinau joined #openstack-rally
16:02 jaredrohe yfried_: yes, I'm here!!
16:02 puranamr joined #openstack-rally
16:08 ehaselwanter joined #openstack-rally
16:11 puranamr joined #openstack-rally
16:19 puranamr joined #openstack-rally
16:19 openstackgerrit Andrey Kurilin proposed openstack/rally: WIP! Add new context plugin to support different API versions  https://review.openstack.org/232546
16:20 boris-42 jaredrohe: did you see my messages?
16:24 MaxPC joined #openstack-rally
16:25 puranamr joined #openstack-rally
16:26 MaxPC1 joined #openstack-rally
16:27 openstackgerrit Andrey Kurilin proposed openstack/rally: WIP: check simple cinder scenario with V2 API  https://review.openstack.org/235352
16:28 puranamr joined #openstack-rally
16:29 boris-42 stpierre: I really don't know what to do about this https://review.openstack.org/#/c/232742/
16:30 boris-42 stpierre: because like it is hiding the bug in scenarios ...
16:30 stpierre how do we distinguish between a hidden bug and an expected failure?
16:33 boris-42 stpierre:  ?
16:33 stpierre the case i'm trying to solve is where a scenario contains a call that it expects to fail. it's not a bug -- it knows the action is going to fail and expects that. if the action succeeded, that would denote a problem.
16:34 stpierre the case you're trying to avoid is where an overaggressive 'except' clause hides an error in a scenario
16:34 stpierre how do we distinguish between those two cases?
16:40 boris-42 stpierre: it is the bug
16:40 boris-42 stpierre: in scenario
16:40 stpierre how is that a bug?
16:40 boris-42 stpierre: you must gurantee the consistance of atomic actions
16:40 stpierre so no scenario can ever expect something to fail?
16:40 stpierre that seems unnecessarily restrictive
16:40 boris-42 stpierre: it can fail
16:41 stpierre so no successful scenario can ever expect something to fail?
16:41 boris-42 stpierre: but you can't do the hiding of atomic in such way
16:41 boris-42 stpierre: yep
16:41 boris-42 stpierre: or it is success or it is failed
16:41 stpierre given the number of people who use rally as a testing tool, and given that this worked until very recently, i'm guessing that this is going to break a lot of local rally plugins. i know it'll break a bunch of ours.
16:42 stpierre and if we're going to be that restrictive, i think we should probably convert everything to using optional_atomic_action() instead of atomic_action(), so that we can have expected failures
16:43 boris-42 stpierre: that is bad actually
16:43 boris-42 stpierre: or we need to change whole model of everything in rally related to atomic actions
16:43 boris-42 stpierre: and all reporting
16:43 stpierre why? it a) has worked just fine heretofore; and b) with a small patch can continue to work fine. no model changes are necessary.
16:43 boris-42 stpierre: nope id didn't work fine before
16:44 boris-42 stpierre: like we have bug in cinder scenario
16:44 stpierre well we never noticed whatever was broken about it
16:44 boris-42 stpierre: that was creating random amount of atomic actions
16:44 boris-42 stpierre: it was showing success rate of some of atomic actions 60%
16:44 boris-42 stpierre: I noticed that..
16:44 stpierre i'm not sure i understand how that's related to this patch
16:46 stpierre but if you prefer, i'd be happy to submit a new patch that basically just does s/atomic_action/optional_atomic_action/ so that we can have expected failures, without having failed atomic actions in a successful scenario
16:47 boris-42 stpierre: I do not understand the concept of failed atomic actions at all
16:47 boris-42 stpierre: we don't support that and never had supported
16:47 stpierre well, it worked :)
16:47 boris-42 stpierre: well it was not supported
16:47 boris-42 stpierre: I belive we should stop hacking around it
16:48 stpierre that's fine. would you accept a patch that does s/atomic_action/optional_atomic_action/ ?
16:48 boris-42 stpierre: and make support of it without hacks if you need it
16:48 boris-42 stpierre: I do not understand how that will help you
16:48 stpierre because then i can disable the atomic action timer for things i expect to fail
16:49 boris-42 stpierre: why not just fixing the atomic action mechanism it self
16:49 stpierre i guess i don't understand what the fix would be.
16:49 boris-42 stpierre: so it deffintely should be in atomic actions
16:49 boris-42 stpierre: not hack in reports
16:49 boris-42 stpierre: there shouldn't be any difference whatever atomic raised exception or not
16:50 stpierre so, the atomic action timer should catch the exception, capture timing information, and then reraise the exception?
16:51 openstackgerrit Chris St. Pierre proposed openstack/rally: Implement new random name generator for scenario plugins  https://review.openstack.org/226385
16:51 openstackgerrit Chris St. Pierre proposed openstack/rally: Implement new random name generator for wrapper plugins  https://review.openstack.org/226387
16:51 openstackgerrit Chris St. Pierre proposed openstack/rally: Remove old random name generator  https://review.openstack.org/226388
16:52 boris-42 stpierre: yep
16:52 boris-42 stpierre: as well I have some idea about overall refactoring atomic_actions
16:52 stpierre okay, let me see how that'll work
16:52 boris-42 stpierre: that will work just perfectly
16:53 boris-42 stpierre: in any case seeems like we need to have error field in atomic actions
16:53 puranamr joined #openstack-rally
16:53 boris-42 stpierre: in any case it looks all a bit ugly
16:53 boris-42 =)
16:54 boris-42 stpierre: how it should be displayed
16:54 boris-42 even if we keep errors in atomic actions
16:54 boris-42 how we should show it on graphs?
16:54 boris-42 like overall success is 100% but success of some specific atomic actions is 60%?
16:55 boris-42 how would you explain that to the customer?)
16:55 boris-42 stpierre: ^
16:55 stpierre "There's a bug in Rally" :)
16:56 boris-42 stpierre: but it is not the bug
16:56 boris-42 stpierre: in your opinion
16:57 stpierre that's not true at all. there's clearly a bug in that scenario. but there is no bug in a scenario that expects a given action to fail, and sees it fail, so that overall success is 100% but some specific actions have a success rate of 0%. that's expected. the bug in your case is that 60% success of some actions but 100% success overall is unexpected -- that's not how it should work.
17:02 puranamr joined #openstack-rally
17:04 boris-42 stpierre: I don' t see the difference between to cases that you described
17:04 boris-42 stpierre: if my manager or his manager see in reports
17:05 boris-42 stpierre: that there is test case with atomic_action that has success rate 60% and overall success 100% he will call me and say WTF?
17:05 stpierre the difference is the expectation. in one case failure is expected, in the other case it's not. without that context, there is no difference in isolation. but in reality, there is.
17:05 boris-42 stpierre: (it already happend)
17:05 stpierre so that scenario clearly needs to be fixed.
17:05 puranamr joined #openstack-rally
17:06 stpierre conversely, if my manager sees a test case that's testing instance quotas, and sees 11 successful boot_server actions instead of 10 successful and one failed, then he will call me and say the same thing.
17:07 boris-42 stpierre: he won't see 11 boot_servers successfully
17:07 boris-42 stpierre: he will see 10
17:07 boris-42 stpierre: in any case current hack in reports is not good long term solution
17:08 boris-42 stpierre: I will start spec about atomic actions
17:08 boris-42 stpierre: as we are moving to version 0.2.0 and we have window of changing internal data of rally
17:08 boris-42 stpierre: let's refactor them to collect all infromation required for reports
17:08 boris-42 stpierre: and make them in proper order withou OrderdDict
17:08 boris-42 stpierre: add to them timestamps and so on
17:09 boris-42 stpierre: as well we can think about "expected error" story
17:13 harshs joined #openstack-rally
17:13 bitblt joined #openstack-rally
17:13 pvaneck joined #openstack-rally
17:21 boris-42 stpierre: http://logs.openstack.org/13/233913/2/experimental/gate-rally-dsvm-cue-rabbitmq/df83264/console.html#_2015-10-15_17_15_39_572
17:21 boris-42 stpierre: these guys are facing the same issues=(
17:25 stpierre it looks like making all atomic actions collect timing info is a one-line fix, and it seems to work. i'm gonna go grab lunch, but when i get back i'll get unit tests working and have this submitted later today
17:25 stpierre thanks for pointing me in the right direction
17:32 openstackgerrit Merged openstack/rally: Add task format converter  https://review.openstack.org/211160
17:43 cdent joined #openstack-rally
17:45 spyderdyne joined #openstack-rally
18:09 e0ne joined #openstack-rally
18:10 ekarlso what's wronghere guys: https://review.openstack.org/#/c/229350/
18:10 ekarlso I dont get any errors on my tox :/
18:10 kir sometimes I have 2015-10-15 12:31:56.483 3004 INFO rally.task.runner [-] Task 80dd159e-211e-4e87-8738-810d2bee4d96 | ITER: 9 END: Error BadRequest: Multiple possible networks found, use a Network ID to be more specific. (HTTP 400) (Request-ID: req-a0547cd5-22b1-40bb-8bdf-014a466db5ce)
18:11 kir this network is created as a context, is it a way to get rid of that without specifying net ID?
18:13 exploreshaifali joined #openstack-rally
18:18 openstackgerrit Yaroslav Lobankov proposed openstack/rally: Adding command to show tempest.conf  https://review.openstack.org/234126
18:21 openstackgerrit Yaroslav Lobankov proposed openstack/rally: Adding command to show tempest.conf  https://review.openstack.org/234126
18:21 MaxPC joined #openstack-rally
18:22 openstackgerrit Merged openstack/rally: Fix random miss in comsumer/publisher broker  https://review.openstack.org/234257
18:27 stpierre ekarlso: 2015-10-15 09:31:43.165 | Build timed out (after 70 minutes). Marking the build as failed.
18:27 stpierre looks like it needs a recheck
18:29 openstackgerrit Yaroslav Lobankov proposed openstack/rally: Changing URL to repo to pull Tempest from  https://review.openstack.org/235538
18:31 openstackgerrit Yaroslav Lobankov proposed openstack/rally: Changing URL to repo to pull Tempest from  https://review.openstack.org/235538
18:32 spyderdyne joined #openstack-rally
18:35 adiantum joined #openstack-rally
18:54 klindgren_ joined #openstack-rally
19:06 MaxPC joined #openstack-rally
19:15 openstackgerrit Chris St. Pierre proposed openstack/rally: Capture timing information for failed atomic actions  https://review.openstack.org/235554
19:20 arnoldje joined #openstack-rally
19:30 MaxPC joined #openstack-rally
19:48 openstackgerrit Yaroslav Lobankov proposed openstack/rally: Adding command to show tempest.conf  https://review.openstack.org/234126
19:51 adiantum joined #openstack-rally
20:08 MaxPC joined #openstack-rally
20:13 MaxPC1 joined #openstack-rally
20:32 emagana joined #openstack-rally
20:40 baker joined #openstack-rally
21:11 jjmb joined #openstack-rally
21:21 mwagner_ joined #openstack-rally
21:29 darkhuy joined #openstack-rally
21:42 aix joined #openstack-rally
21:50 adiantum joined #openstack-rally
22:08 adiantum1 joined #openstack-rally
22:11 openstackgerrit Yaroslav Lobankov proposed openstack/rally: Changing URL to repo to pull Tempest from  https://review.openstack.org/235538
22:12 harshs joined #openstack-rally
22:20 yfried joined #openstack-rally
22:39 adiantum joined #openstack-rally
22:40 openstackgerrit Marcela Bonell proposed openstack/rally: New command to install Tempest's plugins in rally verify.  https://review.openstack.org/235605
22:57 baker joined #openstack-rally
22:57 baker_ joined #openstack-rally
23:31 baker joined #openstack-rally
23:31 vipul joined #openstack-rally
23:34 albertw joined #openstack-rally
23:39 bapalm joined #openstack-rally

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