14:02:03 #startmeeting Rally 14:02:04 Meeting started Mon Nov 16 14:02:03 2015 UTC and is due to finish in 60 minutes. The chair is boris-42. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:05 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:07 The meeting name has been set to 'rally' 14:02:12 Hi 14:02:21 hi 14:02:27 ping andreykurilin ikhudoshyn oanufriev rvasilets 14:02:28 hi 14:02:35 hi 14:03:07 o/ 14:03:40 #link meeting Agenda https://wiki.openstack.org/wiki/Meetings/Rally 14:04:36 let's wait for a second for redixin 14:04:46 -_- 14:04:51 hi all 14:05:04 #topic [redixin] Unsafe self.context usage by contexts. Any context may damage data of any other context. 14:05:14 it's not unsafe it's how it should be done and how rally works 14:05:25 ok 14:05:28 next topic 14:05:30 -_- 14:05:34 redixin: ok 14:06:01 redixin: it's really nice because it allows you to connect data to specific object (in our case user or tenant) 14:06:19 redixin: otherwise all the stuff would look like a mess 14:06:23 is it unsafe because the same memory address of both? 14:06:35 there a lot of code in context, like this" self.context["some_key"] = some_value 14:06:47 yep 14:06:54 kun_huang: redixin and what? 14:07:03 what if other context working with same key? 14:07:32 change the value of that address 14:07:37 we can make a class based on dict with freeze_key() method 14:07:37 redixin: it will be wrong written borken context 14:07:50 GUYS 14:07:55 we don't need that 14:08:21 Most of OpenStack Context classes WON'T work 14:08:38 because they have specified for user resources 14:09:19 in other words we need to change what is inside ["users"] and ["tenants"] keys 14:09:32 so it is ok to do self.context["key"] = value? no setdefault or other checks? 14:10:04 redixin: yep it is ok 14:10:11 We could check before and after context is it the same self.context 14:10:30 if its needed 14:10:34 rvasilets: it won't be the same whole GOAL of context class is to change self.context 14:10:53 before setup() and after cleanup() 14:11:12 i just thought to propose some dict-like object for this purpose 14:11:40 rvasilets: there is no requirements to change back self.conetxt 14:11:42 ofcause its bad in terms of persistence context 14:11:59 We could add such requirements) 14:12:02 rvasilets: it's bad overall I don't know any of case where it will work 14:12:16 rvasilets: why? just to make life harder? 14:12:27 like self.context.push(key, value); self.context.pop(key) 14:12:44 redixin: it's now always the key in first level 14:12:45 No. I just try to support you discussion 14:12:51 redixin: and it's not always such simple change 14:13:04 rvasilets: like push(), pop() sometimes people want to "change" 14:13:06 okay. move on 14:13:57 redixin: I really don't thing that we can do here anything... 14:15:33 Okay let's move to next topic 14:15:42 #topic [amaretskiy] Proposal of improvements for scenario output format 14:15:52 #link https://review.openstack.org/#/c/237632/ 14:16:21 There is a feature wanted - we need task results format with improved output 14:16:29 and spec is ready for review 14:16:45 i will start implementing this immediately after spec is merged :) 14:16:49 please review 14:16:53 eom :) 14:17:30 looking 14:19:38 amaretskiy: okay we will take a look 14:20:33 amaretskiy: so I don't like the methods names 14:20:39 amaretskiy: they are too long to remember 14:20:45 amaretskiy: and it's interface 14:20:52 so seems like it's bad interface 14:21:12 no problem, please give comments and we will go ahead 14:21:14 add_complete_output and add_additive_output I would make 10 typos writing this 14:21:24 ok 14:21:50 anybody else agree on this? 14:21:54 redixin: kun_huang ^ 14:21:58 i thought that `add' and `output' should be in names 14:22:26 I'm not good at naming... 14:22:29 we can have single method 14:22:40 add_output(additive=True) 14:23:26 or `set_output()' (set is better that add since we can call this only once) 14:23:49 *than 14:23:49 amaretskiy: set is bad 14:24:01 amaretskiy: because add allows you to call it many times 14:24:13 amaretskiy: set is something that you would like to call once 14:24:18 (additive=True) is definitely bad 14:24:27 yes, current spec allows calling only once 14:25:22 amaretskiy: but why? 14:25:23 amaretskiy: i guess it allows calling only once per output 14:25:38 what is really important is how to make scenarios saving consistent output 14:25:47 amaretskiy: ikhudoshyn users should be able to call any amount of times each time adding one more graph 14:26:07 boris-42: exactly 14:26:25 amaretskiy: it is code if they don't have "if" or "e;lse" in code they will be equal 14:26:27 for example some scenario adds additive data for `foo_duration' twice 14:26:41 this will draw 2 points on chart 14:26:41 amaretskiy: rally can't gurantee that you won't shoot your head by gun 14:26:52 amaretskiy: especially on level of plugins 14:27:10 in this case - yes, we can give full freedom to scenario 14:27:11 amaretskiy: that's exactly what I'd expect 14:27:13 amaretskiy: it will be always possible to write wrong plugin because it is code 14:27:29 actually it is hard (but possible) to check output of each scenario 14:27:30 amaretskiy: and that is okay 14:27:35 amaretskiy: it should add 2 graphs 14:27:51 amaretskiy: he will run it and see that something is wrong and he will fix the code 14:28:07 ok 14:28:17 amaretskiy: writing dummy protections in code on runtime doesn't seem like a good plan 14:28:26 running add_* many times - agreed 14:28:32 but what about naming? 14:28:40 amaretskiy: naming is bad.. 14:28:46 no ideas 14:31:04 amaretskiy: I can't give a fast suggestion 14:31:09 ok 14:31:58 i think we do not need fast decisions 14:32:26 so i believe we #ageed on maing it possilbe to call many times 14:32:30 graphs 14:32:35 yes 14:32:41 ok 14:32:52 Okay let's move to open disucssion 14:32:57 #topic Open Disucssion 14:33:02 so anything to discuss? 14:33:09 no 14:33:09 nothing from mine 14:33:18 nothing for me 14:34:02 I have a question, what scenario I can add to rally ,what I can't ? 14:34:03 I'd like to encourage everyone to take a look at distributed runner spec 14:34:34 https://review.openstack.org/#/c/236979/ 14:35:11 chenli: basically you can add any of sceanrios 14:35:12 Ok 14:35:29 chenli: currently rally is a bit hardcoded for OpenStack but I hope some days this will be fixed 14:36:15 boris-42, yes, that's true. then, what scenario would be accepted into rally branch ? 14:36:22 for example, recently I did a lot of test about ping.. we have many many instances in the cloud, we want to test the ping latency.. 14:36:50 I might have a scenario by my own. 14:37:05 can I also add this to rally master tree ? 14:37:15 chenli: at least you can try 14:37:40 chenli: we can add specialy context "existing_servers" 14:37:51 chenli: and have scenario that works only with this context 14:37:57 chenli: like ping one 14:38:14 that sound's good. 14:40:12 so I think we covered all topics for today? 14:40:15 anything else? 14:42:51 boris-42: what about the plan of osprofiler? (is it okay to talk about it here?) 14:44:27 kun_huang: yep it is okay to talk here about it 14:44:33 kun_huang: DinaBelova is doing well=) 14:44:48 kun_huang: we cut recently new release https://github.com/openstack/osprofiler/releases 14:45:07 kun_huang: that allows to use osprofiler without having parameters in api-paste.ini file 14:45:22 kun_huang: as far as I know DinaBelova is fixing current integration with Ceilometer 14:45:28 kun_huang: and fixing all projects 14:45:48 boris-42, kun_huang - yep 14:45:55 I 14:46:05 boris-42: good, I have a meeting with QA team of my company 14:46:05 will start owrking on the multi backend then 14:46:18 it's time to introduce rally and osprofiler 14:46:27 kun_huang - cool :) 14:46:37 kun_huang: great=) 14:46:43 I hope they could try to fix some basic issues themselves 14:46:54 so I could do some easy review ;) 14:47:00 kun_huang: so currently osprofiler seems like broken 14:47:07 kun_huang: because of changes in ceilometer 14:47:16 DinaBelova: btw did you fix it at the end?) 14:47:38 boris-42 - yep, right now it works 14:47:44 although in the minimal way 14:47:56 due to the fact ceilometer is not able to store all payload now 14:47:59 boris-42: I know google dapper, so I could introduce the similiar ideas 14:48:13 boris-42 - it requires full declarative definition 14:48:41 that's not possible in osprofiler general use case, where user can place everything in the args/kwargs 14:48:47 DinaBelova: do you need ceilometer guy to help? 14:48:56 kun_huang - found already :) 14:49:00 ityaptin will work on that 14:49:11 DinaBelova: nice 14:49:32 DinaBelova: that overall sucks 14:49:38 :D 14:49:52 DinaBelova: is it possible to get some improvements in Ceilometer to keep such values? 14:49:52 https://drive.google.com/a/mirantis.com/file/d/0ByRtVrZu5ifzSGhmbVI0Ynp4NVE/view?usp=sharing - here is the report I was able to generate for glance create image 14:50:06 boris-42 - yep, Ilya will work on that 14:50:14 DinaBelova: oh great 14:50:14 ityaptin I mean :) 14:51:00 DinaBelova: I don't see DB points 14:51:10 I did not turn them on 14:51:20 DinaBelova: heh 14:51:25 boris-42 - I will do that 14:51:40 DinaBelova: and you won't see DB queires 14:51:45 DinaBelova: which is important=) 14:51:53 DinaBelova: so do we need to merge your fix in osprofiler? 14:52:01 DinaBelova: to get such traces? 14:52:12 boris-42 - I was trying to start with basics :D 14:52:14 well, yep 14:52:18 I'm fixing tests right now 14:52:34 then I was planning to go to DB requests tracing 14:52:56 to ensure they work / do not work without specific event definition 14:53:26 DinaBelova: =) 14:53:35 I think it will work with the needed definitions 14:53:45 DinaBelova: in any case it's at least collecitng data and fethcing them 14:53:46 =) 14:54:01 although I'll ask you not to merge my change until I'll give you report with DB part 14:54:05 just in case 14:54:21 DinaBelova: no worries I am expert in non merging patches 14:54:22 =) 14:54:25 :D 14:54:34 I never thought it'll be easy :D 14:54:43 so everything as expected 14:54:45 :D 14:55:03 DinaBelova: =) 14:55:42 kun_huang: btw I will try to update maybe today Oslo Spec for OSProfiler 14:56:26 boris-42 - that will be cool 14:56:55 yep, it is useful for to introduce it 14:57:34 DinaBelova: kun_huang ok 14:58:00 kun_huang: it's here just in case https://review.openstack.org/#/c/103825/ 14:58:04 okay let's end meeting 14:58:06 see you next week 14:58:09 #endmeeting