Perl 6 - the future is here, just unevenly distributed

IRC log for #openstack-rally, 2015-06-23

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

All times shown according to UTC.

Time Nick Message
00:00 mahito joined #openstack-rally
00:28 dmorita joined #openstack-rally
00:50 echoingumesh joined #openstack-rally
00:52 yingjun joined #openstack-rally
01:36 georgem1 joined #openstack-rally
02:30 yingjun joined #openstack-rally
02:56 yingjun joined #openstack-rally
03:48 yingjun joined #openstack-rally
04:01 kiran-r joined #openstack-rally
04:02 kun_huang boris-42: any blueprints or spec on report series patches (https://review.openstack.org/#/c/159458/)?
04:16 PrashantS joined #openstack-rally
04:33 rdas joined #openstack-rally
04:33 zerda joined #openstack-rally
04:34 tfreger joined #openstack-rally
04:53 PrashantS joined #openstack-rally
05:01 PrashantS joined #openstack-rally
05:15 PrashantS joined #openstack-rally
05:16 yingjun joined #openstack-rally
05:42 agarciam joined #openstack-rally
05:52 yfried__ joined #openstack-rally
06:02 exploreshaifali joined #openstack-rally
06:19 yingjun joined #openstack-rally
07:02 openstackgerrit Kiran proposed openstack/rally: Add ability to create pool in Neutron context  https://review.openstack.org/193432
07:04 tfreger joined #openstack-rally
07:06 yfried__ joined #openstack-rally
07:26 openstackgerrit Kiran proposed openstack/rally: Add Neutron LoadBalancer v1 create and list vips  https://review.openstack.org/193527
07:29 neeti joined #openstack-rally
07:32 boris-42 joined #openstack-rally
07:35 arxcruz joined #openstack-rally
07:41 boris-42 kun_huang: no
07:50 anshul joined #openstack-rally
08:03 amaretskiy joined #openstack-rally
08:04 karimb joined #openstack-rally
08:16 fhubik joined #openstack-rally
08:22 openstackgerrit Pavel Boldin proposed openstack/rally: unit-tests: fix mock check error messages  https://review.openstack.org/194403
08:25 openstackgerrit Kun Huang proposed openstack/rally: Optimize task table order  https://review.openstack.org/194537
08:25 yingjun joined #openstack-rally
08:27 openstackgerrit Kun Huang proposed openstack/rally: Optimize task table order  https://review.openstack.org/194537
08:32 e0ne joined #openstack-rally
08:48 e0ne joined #openstack-rally
08:50 openstackgerrit Li Yingjun proposed openstack/rally: Support validate parameter list for restricted_parameters  https://review.openstack.org/194552
08:52 openstackgerrit Pavel Boldin proposed openstack/rally: unit-tests: fix mock check error messages  https://review.openstack.org/194403
08:56 openstackgerrit Ivan Kolodyazhny proposed openstack/rally: WIP. DO NOT MERGE!!!! Switch Cinder scenarios to APIv2  https://review.openstack.org/193685
08:58 cdent joined #openstack-rally
09:07 aix joined #openstack-rally
09:15 yfried joined #openstack-rally
09:15 e0ne joined #openstack-rally
09:17 openstackgerrit Kairat Kushaev proposed openstack/rally: [Heat] create-snapshot-restore-delete stack scenario  https://review.openstack.org/179037
09:30 tosky joined #openstack-rally
09:40 nihilifer_ joined #openstack-rally
09:47 nihilifer joined #openstack-rally
09:50 nihilifer_ joined #openstack-rally
09:59 openstackgerrit Merged openstack/rally: Fix sqlite file permission for system-wide install  https://review.openstack.org/192034
10:00 openstackgerrit Merged openstack/rally: Add specs in doc/README.rst file  https://review.openstack.org/194379
10:07 tfreger joined #openstack-rally
10:49 openstackgerrit Merged openstack/rally: Keystone get_entities scenario backwards compat  https://review.openstack.org/194151
11:09 e0ne joined #openstack-rally
11:28 aix joined #openstack-rally
11:32 stpierre joined #openstack-rally
11:38 kiran-r joined #openstack-rally
11:45 tfreger1 joined #openstack-rally
12:02 rvasilets left #openstack-rally
12:16 frayedknot joined #openstack-rally
12:20 tfreger joined #openstack-rally
12:29 MaxPC joined #openstack-rally
12:37 e0ne joined #openstack-rally
12:43 mwagner_afk joined #openstack-rally
12:47 aix joined #openstack-rally
12:54 georgem1 joined #openstack-rally
13:01 kairat_kushaev stpierre: I really confused why do you need such attribute=)
13:02 kairat_kushaev stpierre: I am also thinking about delta attribute
13:02 kairat_kushaev stpierre: Why do we need it if we want to test change in scaling policy
13:03 stpierre because we need to know that the scaling operation has completed
13:13 jaypipes joined #openstack-rally
13:15 openstackgerrit Kairat Kushaev proposed openstack/rally: [Heat] create-snapshot-restore-delete stack scenario  https://review.openstack.org/179037
13:19 openstack joined #openstack-rally
13:22 agarciam joined #openstack-rally
13:25 kairat_kushaev stpierre: So you can hard-code delta in scenario
13:26 stpierre it needs to be configurable, because different scaling policies will result in different deltas
13:27 kairat_kushaev stpierre: but changing delta also will require change in scaling adjustment
13:27 kairat_kushaev otherwise the scenario will never end
13:27 stpierre the delta needs to reflect the scaling_adjustment in the ScalingPolicy object
13:27 stpierre so yes, if you change the scaling_adjustment in a Heat template to 5, but keep the delta at 1, then the benchmark will time out
13:28 stpierre err, other way around, sorry
13:28 stpierre if you change scaling_adjustment to 1 but keep delta=5, then it will timeout
13:28 kairat_kushaev yep
13:28 stpierre and that's okay; the end user needs to configure things sanely.
13:28 stpierre if there was a way to discover this automatically short of reinventing the HOT parser, i'd do it, but AFAICT there isn't
13:29 kairat_kushaev you can define scaling adjustment as input parameter
13:30 stpierre that's precisely what the delta is
13:30 kairat_kushaev but I see that it is hard-coded now=)
13:30 kairat_kushaev it is not calculated based on delta
13:30 stpierre the only difference is that scaling_adjustment can be a percentage; delta needs to be an absolute number, to avoid possible math errors. (e.g., i don't want rally to round up when Heat rounds down)
13:31 kairat_kushaev yep, it is reasonable
13:32 kairat_kushaev in addition setiing up scale_adjustment as input will allow to avoid redundant scaling policy in your template)
13:32 kairat_kushaev you will need only 1 policy in this case
13:33 stpierre the goal here is not to provide one Heat template to rule them all, though
13:33 stpierre the end user should be able to supply their own template if they wish, and they should not have to go out of their way to structure it explicitly for Rally
13:34 stpierre this scenario should be able to be used with any Heat template that contains a ScalingPolicy.
13:35 stpierre right now, it can. you're proposing to make it so that the scenario can only be used with a Heat template that contains a ScalingPolicy whose scaling_adjustment is derived from a template parameter, but that's an unnecessary constraint
13:36 stpierre if we're willing to constrain the user we can do lots of things differently -- for instance, we could require a specific scaling webhook URL key -- but i don't think it's reasonable to constrain the user thusly. let them use HOT however they feel fit, and make Rally work with that -- not require them to write a template to our arbitrary specifications
13:41 kairat_kushaev stpierre: I think that the main idea of rally is quite the different
13:41 kairat_kushaev as a user I would like to deal with rally parameters only
13:41 kairat_kushaev the bad thing here is that I need to know the realisation of the test
13:42 kairat_kushaev and I cannot modify rally scenario parameters without updating a template
13:42 aix joined #openstack-rally
13:42 stpierre if you want to do more advanced benchmarking than what is provided in the scenario then yes, you do need to have some familiarity with the subsystems that are being benchmarked.
13:42 stpierre s/provided in the scenario/provided in the samples/
13:43 stpierre remember, what we're providing are just samples. they're not intended to be exhaustive or complete or all the rally you'll ever need
13:43 stpierre they're a starting point.
13:44 stpierre if you want to do fancy benchmarking of nova instances with VMTasks, you'd better familiarize yourself with bash, JSON, and floating IP pools. you'll have to write scripts. that's okay -- good, even.
13:44 stpierre this follows one of the points of the Unix philosophy: be liberal in what you accept (and conservative in what you produce, although that doesn't really apply here). we should let the end user provide literally any Heat template, and work with that -- not require some constrained subset of HOT.
13:47 kairat_kushaev stpierre: Should the rally scenario work with different parameters without any updates in normal case?
13:48 stpierre not when the scenario references external files (i.e., Heat and VMTasks scenarios)
13:50 stpierre if i run VMTasks.boot_runcommand_delete and change the 'script' argument, I'd better also make sure that the script i've referenced exists. conversely, if i change the script that it's running, i may need to make changes to the scenario description (for example, changing the interpreter to bash instead of sh, or using a more full-featured image than cirros)
13:54 stpierre that happens in other places, too: if you change volume_type to True for CinderVolumes.create_snapshot_and_attach_volume, then you need to make sure that at least one volume type has been created in Cinder.
13:57 kairat_kushaev you can completely follow the unix-way when you will introduce the input parameter in the template
13:58 cdent joined #openstack-rally
13:58 kairat_kushaev will it be complex to introduce this parameter in the template?
13:58 stpierre no, but it unnecessarily constrains the end user.
13:58 kairat_kushaev we already require some output key for them in the scenario
13:59 kairat_kushaev but it also will be easier for them to test with rally later
13:59 stpierre unless they want to write their own template
13:59 stpierre then it will be harder
14:00 stpierre your suggestion optimizes for the case of someone who doesn't know (or want to know) how to modify a simple Heat template, but who wants to test different scaling policies. (I do not think this person exists.) mine optimizes for the case of someone who wants to test arbitrary scaling policies in arbitrary templates, without imposing additional artificial constraints on the HOT they can write
14:01 kairat_kushaev if somebody is familiar with templates will it be hard for them to introduce input parameter>
14:01 kairat_kushaev my proposal is just to make testing easier
14:02 stpierre but it doesn't -- it makes testing easier in one very narrow case. in other cases -- say i have an existing Heat template that i want to benchmark -- it makes it harder. now i have to parameterize that template so that it works with Rally's magic
14:03 stpierre instead of telling Rally about my template, Rally tells me about artificial constrains my template must satisfy
14:15 kairat_kushaev stpierre: What do you think about this simplification
14:16 kairat_kushaev 1. When stack is scaling it should be IN_PROGRESS
14:16 kairat_kushaev 2. When scaling has finished then it should be in COMPLETE state
14:17 kairat_kushaev So perhaps it will be much easier first to wait untill stack become IN_PROGRESS
14:17 stpierre if that's the case, then i'm happy to use that instead of checking for the size of the stack
14:17 kairat_kushaev you can check it on your env
14:17 kairat_kushaev it should work
14:18 kairat_kushaev and finally it should in COMPLETE state again when autoscaling has finished
14:18 stpierre the problem is that we can't wait for the stack to become IN_PROGRESS first, because on an installation with low load the webhook POST is very nearly synchronous -- that is, the scaling operation is complete by the time the POST returns
14:19 stpierre so i'm not sure how we'll tell the difference between a stack that has finished scaling, and one that hasn't started
14:20 kairat_kushaev The one possibility is to track if stack was updated or not
14:20 kairat_kushaev if yes then is has been scaled
14:21 kairat_kushaev otherwise it was not
14:21 kairat_kushaev AFAIK you can just wait for stack to be UPDATE_COMPLETE
14:21 kairat_kushaev It should mean that the stack scale finished
14:21 stpierre okay, i'll look into that today
14:24 karimb joined #openstack-rally
14:31 nihilifer joined #openstack-rally
14:43 yeungp joined #openstack-rally
14:50 tosky joined #openstack-rally
14:51 kiran-r joined #openstack-rally
14:55 openstackgerrit Andrey Kurilin proposed openstack/rally: Try catch everything while running scenarios  https://review.openstack.org/194690
14:57 stpierre kairat_kushaev: in Juno, the stack status doesn't change for scaling operations :(
14:59 stpierre turns out that kilo heat is wildly less shitty than juno heat
15:04 frayedknot joined #openstack-rally
15:06 kairat_kushaev stpierre: or kilo heat is much greater then juno heat=)
15:07 stpierre is the glass half full or half empty?
15:07 kairat_kushaev stpierre: that's bad(
15:08 kairat_kushaev stpierre: BTW are you going to support last 2 cycles in rally?
15:08 kairat_kushaev because we can stay it as it is right now but need to improve in the future
15:08 stpierre afaik there's no official stance on that, but i think we need to do our best to support currently supported OpenStack
15:09 stpierre yeah, we can improve the hell out of this when all we need to support is Kilo
15:09 stpierre in kilo we can access alarm urls without output keys, too -- just get them directly from the scalingpolicy attributes
15:10 psd joined #openstack-rally
15:11 kairat_kushaev Ok, let's move on untill next cycle
15:11 stpierre let me add a todo to this so we remember
15:11 kairat_kushaev ok,
15:11 kairat_kushaev One small remark also
15:12 kairat_kushaev We need to ensure also that the stack is not in FAILED state
15:13 stpierre _create_stack() does that. or do you mean after the scaling operation?
15:13 kairat_kushaev yep
15:13 stpierre ok
15:13 kairat_kushaev otherwise it is possible that nnum of instances increased but some of them failed and the whole stack is failed
15:14 kairat_kushaev so it should be complete after resizing
15:23 kiran-r joined #openstack-rally
15:27 openstackgerrit Chris St. Pierre proposed openstack/rally: Add Heat scenario to test scaling policies  https://review.openstack.org/178436
15:36 kiranr joined #openstack-rally
15:46 PrashantS joined #openstack-rally
15:49 cdent joined #openstack-rally
16:00 frayedknot joined #openstack-rally
16:05 yfried joined #openstack-rally
16:14 openstackgerrit Roman Vasilets proposed openstack/rally: Add Ironic create_and_list_node and create_node scenario  https://review.openstack.org/186064
16:16 redixin joined #openstack-rally
16:16 openstackgerrit Kairat Kushaev proposed openstack/rally: [Heat] create-snapshot-restore-delete stack scenario  https://review.openstack.org/179037
16:28 yfried joined #openstack-rally
16:28 _kiran_ joined #openstack-rally
16:36 _kiran_ joined #openstack-rally
16:43 kiranr joined #openstack-rally
16:44 davideagnello joined #openstack-rally
16:56 cdent left #openstack-rally
17:01 dontalton joined #openstack-rally
17:04 openstackgerrit Alexander Maretskiy proposed openstack/rally: [Reports] Add class for merging data stream  https://review.openstack.org/194745
17:05 openstackgerrit Alexander Maretskiy proposed openstack/rally: [Reports] Add class for merging data stream  https://review.openstack.org/194745
17:22 openstackgerrit Pavel Boldin proposed openstack/rally: unit-tests: fix mock check  https://review.openstack.org/194403
17:26 yfried joined #openstack-rally
17:26 harlowja joined #openstack-rally
17:29 openstackgerrit Pavel Boldin proposed openstack/rally: unit-tests: fix mock check errors messages  https://review.openstack.org/194403
17:29 openstackgerrit Pavel Boldin proposed openstack/rally: unit-tests: inception: add mock check unit-tests  https://review.openstack.org/194754
18:08 e0ne joined #openstack-rally
18:35 echoingumesh joined #openstack-rally
18:41 e0ne joined #openstack-rally
18:52 nihilifer joined #openstack-rally
18:56 tfreger joined #openstack-rally
19:22 openstackgerrit joined #openstack-rally
19:43 aix joined #openstack-rally
19:43 marcoceppi joined #openstack-rally
20:00 marcoceppi joined #openstack-rally
20:00 marcoceppi joined #openstack-rally
20:07 tosky joined #openstack-rally
20:19 marcoceppi joined #openstack-rally
20:19 marcoceppi joined #openstack-rally
20:33 dontalton joined #openstack-rally
20:42 Prashan__ joined #openstack-rally
21:02 PrashantS joined #openstack-rally
21:09 gubouvier joined #openstack-rally
21:12 gubouvier Hi guys, quick question: Is it normal, when I run a scenario on an existing tenant/user, that rally will cleanup everything after his tests, not only what it created ?
21:12 gubouvier example, I'm running NeutronNetworks.create_and_delete_networks, at the end, Rally will delete all the network of the tenant, not only his tests
21:18 jaredroh_ joined #openstack-rally
21:18 karimb joined #openstack-rally
21:21 jaredrohe I have a question:  Is it possible to have an __init__ method() in my scenario test that I want to benchmark with rally?  If I include a very simple __init__() method with only the keyword pass in the method body, I receive the following error:
21:22 jaredrohe "TypeError: __init__() got an unexpected keyword argument 'admin_clients'"
21:23 jaredrohe If I remove the __init__() method, rally benchmarks my script just fine
21:27 stpierre joined #openstack-rally
21:34 e0ne joined #openstack-rally
21:36 anshul joined #openstack-rally
21:39 stpierre joined #openstack-rally
22:19 dontalton2 joined #openstack-rally
22:28 openstackgerrit Omar Khalid proposed openstack/rally: Boot public images and test connectivity  https://review.openstack.org/194846
22:49 masa_ joined #openstack-rally
22:52 PrashantS joined #openstack-rally
23:02 masa_ joined #openstack-rally
23:22 BitSmith joined #openstack-rally
23:33 masa_ joined #openstack-rally
23:34 masa_ joined #openstack-rally
23:37 masa_ left #openstack-rally
23:37 masa_ joined #openstack-rally
23:57 masa_ joined #openstack-rally

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