17:07:52 <boris-42> #startmeeting Rally
17:07:53 <openstack> Meeting started Tue Feb  3 17:07:52 2015 UTC and is due to finish in 60 minutes.  The chair is boris-42. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:07:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:07:56 <openstack> The meeting name has been set to 'rally'
17:07:59 <boris-42> #topic Rally API
17:08:05 <boris-42> msdubov_: you are welcome
17:08:14 <msdubov_> boris-42, Yep
17:08:54 <msdubov_> So we have merged the first patch that adds the new API classes https://review.openstack.org/#/c/149597/
17:09:04 <msdubov_> Those are going to be used instead of pure methods
17:09:10 <msdubov_> So that the API gets more structures
17:09:14 <msdubov_> *structured
17:09:37 <msdubov_> The old API is now marked as deprecated
17:09:50 <msdubov_> We are going to switch the Rally internals to the new API in https://review.openstack.org/150468
17:10:10 <msdubov_> Finally, we will remove the old API in Rally v.0.1.0 (now we are working on v0.0.2)
17:10:11 <msdubov_> eom
17:12:13 <msdubov_> boris-42, ^
17:12:15 <boris-42> msdubov_: great
17:12:43 <boris-42> msdubov_: so what about moving objects under API?
17:13:09 <msdubov_> boris-42: I think we should implement the get() and list() methods in API
17:13:17 <msdubov_> It will look then much more consistent
17:13:29 <boris-42> msdubov_: yep seems good
17:13:39 <boris-42> okay any questions?
17:14:25 <boris-42> #topic Murano base
17:14:30 <boris-42> rvasilets_: hey there
17:14:39 <boris-42> rvasilets_: so what is the status of those patches?
17:16:46 <rvasilets_> I was working on it. I have done everything from my side except unit tests. Today I have tolking with Murano team and they disappionted why it's not working
17:18:04 <rvasilets_> I have submit patch to gerrit and they are romise to see in logs of murano what is going
17:18:40 <boris-42> rvasilets_: lol
17:18:42 <rvasilets_> Now I get error "Invalid json response...."
17:18:46 <boris-42> rvasilets_: probably we caught some bug
17:18:50 <boris-42> rvasilets_: in Murano
17:18:58 <boris-42> rvasilets_: so I think we should finsih and merge those patches
17:19:04 <rvasilets_> That meen that murano is broken
17:19:09 <boris-42> rvasilets_: lol
17:19:12 <boris-42> rvasilets_: maybe lol
17:19:23 <rvasilets_> Why? - I don't now
17:19:32 <boris-42> rvasilets_: it happens with programs
17:19:43 <boris-42> rvasilets_: usually they are broken, it's hard to make then not broken lol
17:19:52 <rvasilets_> Ok, I would write units and submit it
17:19:57 <boris-42> rvasilets_: yep nice
17:20:03 <rvasilets_> eom
17:20:10 <boris-42> rvasilets_: thanks for update
17:20:20 <boris-42> #topic Stop on SLA failures
17:20:26 <boris-42> msdubov_: please one more time=)
17:20:38 <msdubov_> boris-42, with pleasure!
17:21:16 <msdubov_> boris-42 Okay our idea is that it would be continue to be able to stop scenario execution when the SLA for it fail - even before all the iterations have finished
17:21:23 <msdubov_> to do that, we have implement 2 things:
17:21:29 <msdubov_> 1) ScenarioRunner.abort() method
17:21:38 <msdubov_> That's in https://review.openstack.org/151678
17:22:08 <msdubov_> 2) Iterative SLA checks - so that they check SLAs after each iteration of benchmark scenarios, and still have linear complexity
17:22:20 <msdubov_> I'm working on that here: https://review.openstack.org/152459
17:22:54 <msdubov_> There also is a new parameter to the "rally task start" command that introduces this "stop on SLA failure" mode: --stop-on-sla-failure
17:23:16 <boris-42> msdubov_: tooolong
17:23:22 <msdubov_> boris-42, One problem I see about the whole thing is that it's not quite clear how to implement the iterative "failure_rate" SLA check
17:23:34 <msdubov_> because the failure rate actually changes from iteration to iteration
17:23:43 <msdubov_> and we may abort a scenario when it's too early
17:23:48 <boris-42> msdubov_: we are not interested in whole amount of results
17:24:02 <boris-42> msdubov_: if current amount of errors is bigger then something stop
17:24:05 <boris-42> msdubov_: that'sall
17:24:35 <msdubov_> boris-42, I see, but if the first iteration is an error, then failure rate = 100% and we will stop, but next iterations may be perfectly OK
17:24:47 <msdubov_> I think we should start those checks after a few iterations
17:25:07 <boris-42> msdubov_: It can be parametrized
17:25:27 <msdubov_> boris-42, in the task file?
17:25:32 <msdubov_> boris-42, or better in CLI?
17:25:40 <boris-42> msdubov_: in sla failure rate
17:25:53 <boris-42> msdubov_: but it will be dirty
17:26:06 <boris-42> msdubov_: I would prefer for now
17:26:09 <boris-42> msdubov_: just to stop
17:26:25 <msdubov_> boris-42, Ok!
17:26:45 <msdubov_> boris-42, Then what is left for me are unit tests and a couple of corrections in the code
17:27:22 <boris-42> msdubov_: sure nice
17:27:26 <boris-42> msdubov_: let's get it in
17:27:30 <boris-42> any questions?
17:28:39 <boris-42> okay let's move
17:28:59 <boris-42> #topic HMTL reports making them scale
17:29:04 <boris-42> amaretskiy: any news?
17:29:41 <amaretskiy> I'm currently working on https://review.openstack.org/#/c/146814/
17:29:50 <amaretskiy> this patch set is set back to WIP
17:30:03 <amaretskiy> in order to rework it and implement chunks
17:30:44 <amaretskiy> so I'm going to rework plot.py completely so task processing will be using chunks generator
17:31:01 <amaretskiy> and we will have ability to process huge data
17:31:28 <boris-42> amaretskiy: nice so any progress on it/
17:31:30 <boris-42> ?
17:32:32 <amaretskiy> of course, this is patch set is related to plot part only, so another part is update in objects.task.Task.get_results() - this should return chunks generator
17:32:48 <amaretskiy> i think some results (WIP) will be tomorrow
17:32:54 <amaretskiy> eom
17:34:58 <boris-42> amaretskiy: ok
17:35:07 <boris-42> #topic Rally task validate refactoring
17:35:23 <boris-42> oh there is no Oleg....
17:35:33 <boris-42> amaretskiy: msdubov_ did you take a look at patches?
17:36:07 <msdubov_> msdubov_, Not yet, but I've planned that for the evening
17:36:11 <msdubov_> boris-42, ^
17:36:12 <amaretskiy> I reviewed this patch yesterday, now we have new patch set
17:36:38 <boris-42> amaretskiy: ok
17:36:42 <boris-42> msdubov_: thanks
17:36:52 <boris-42> #topic One Plugin base
17:37:04 <boris-42> Okay guys I didn't have enough time to continue work on it
17:37:14 <boris-42> But Olga send on review one patch
17:37:28 <boris-42> that changes servers providers and deploy engines
17:37:34 <boris-42> so I think I will update tonight that patch
17:37:53 <boris-42> and hopefully we will be able to go forward=)
17:38:03 <boris-42> and I will be able to rework verfication mechanism
17:38:12 <msdubov_> boris-42, Nice. I've commented your patch, it misses a couple of files
17:38:19 <boris-42> msdubov_: thanks
17:38:25 <boris-42> I saw I will fix
17:38:33 <boris-42> I was quite ill when I was writting that=)
17:38:38 <msdubov_> lol
17:38:39 <boris-42> so mistakes are possible=)
17:39:02 <boris-42> #topic Free disucssion
17:39:09 <boris-42> do we have something to discus?
17:39:14 <amaretskiy> no
17:39:29 <olkonami> boris-42, I have some proposal to switch to plugins base, part 2
17:40:00 <olkonami> for deploy engines, serverproviders and scenario classes into get_name method are used cls.__name__
17:40:15 <olkonami> so to avoid put decorator @plugin.plugin with the actual class name for all such classes
17:40:24 <olkonami> I propose revrite in get_name method of Plugin class
17:40:35 <olkonami> return getattr(cls, "_plugin_name", None) to return getattr(cls, "_plugin_name", cls.__name__)
17:40:42 <boris-42> olkonami: so don't touch scenarios
17:40:43 <olkonami> so if we set name with decorator, we will use it, otherwise we will use name of class
17:40:53 <boris-42> olkonami: they are quite differnet from everything else
17:41:14 <boris-42> olkonami: I would prefer to have unified and explicit way to set names
17:41:16 <olkonami> not scenario methods, scenario class
17:41:27 <boris-42> olkonami: get_name() will return both
17:41:30 <boris-42> olkonami: depending on name
17:41:42 <boris-42> olkonami: so as i am saying it's quite different from others
17:42:05 <boris-42> olkonami: about Engines, ServerProviders it's better to use plugin.plugin(name=) approach cause it's simpler for end users
17:42:10 <boris-42> and newbies to understand
17:42:27 <boris-42> cause it's unclear why cls.__name__ should be the name of plugin
17:43:09 <olkonami> boris-42, ok
17:43:31 <olkonami> but also also I don't like name plugin.plugin for decorator, I think it's a bit misunderstanding
17:43:44 <olkonami> I prefer smth like plugin.set_name
17:44:19 <boris-42> olkonami: and what if our plugin.plugin will set new parameters?
17:44:27 <boris-42> olkonami: not only name?
17:44:32 <boris-42> olkonami: but version and so on
17:46:43 <olkonami> boris-42, than I prefer smth like plugin.set_params, becouse we have class Plugin and decorator plugin and when I looked at that first, I was confused
17:48:25 <boris-42> olkonami: maybe just plugin.set?
17:50:16 <olkonami> boris-42, deal :)
17:50:55 <msdubov_> boris-42, I also like this name
17:50:55 <boris-42> olkonami: ok I think it's not a big deal to rename it
17:51:06 <boris-42> olkonami: msdubov_ ok I will rename it
17:51:22 <boris-42> it's not hard because we didn't switch yet to it
17:51:28 <boris-42> okay any other topics to disucss?
17:53:41 <boris-42> okay let's end meeting
17:53:43 <boris-42> #endmeeting