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