14:00:44 <boris-42> #startmeeting Rally
14:00:45 <openstack> Meeting started Mon Oct 19 14:00:44 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:00:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:49 <boris-42> YOYOYO
14:00:50 <openstack> The meeting name has been set to 'rally'
14:01:09 <boris-42> ping 4everybody
14:01:12 <idegtiarov> hi!
14:01:13 <albertw> hello
14:01:30 <yfried> boris-42: hey
14:01:35 <boris-42> yfried: hi there
14:01:47 <boris-42> amaretskiy: andreykurilin ping
14:01:55 <amaretskiy> hi
14:02:08 <ikhudoshyn> щ.
14:02:08 <andreykurilin> \o/
14:02:08 <rvasilets> o/
14:02:11 <ikhudoshyn> o/
14:02:28 <redixin> Zdravo!
14:02:46 <boris-42> Piet: idegtiarov
14:02:50 <boris-42> ping idegtiarov
14:02:55 <idegtiarov> i'm here
14:02:55 <boris-42> Piet: sorry*
14:03:18 <boris-42> stpierre: ping
14:03:19 <ylobankov> hi
14:03:24 <stpierre> boris-42: yo
14:03:33 <boris-42> stpierre: u nice that you are here
14:03:34 <boris-42> =)
14:03:51 <idegtiarov> my question is can we have optional parameter for set resource_id manual for our samples in context?
14:04:05 <idegtiarov> or it should be random
14:04:10 <boris-42> idegtiarov: wait wait
14:04:18 <boris-42> =)
14:04:22 <boris-42> #topic idegtiarov] Mandatory demand for unique resources names in Ceilometer context. Ceilometer team is interested to have optional possibility to set resources names manually.
14:04:30 <boris-42> okay now your turn
14:04:48 <idegtiarov> ones more! :) my question is can we have optional parameter for set resource_id manual for our samples in context?
14:04:52 <idegtiarov> or it should be random
14:05:11 <boris-42> idegtiarov: resource_id ?
14:05:18 <idegtiarov> yes
14:06:04 <idegtiarov> our aim is to fill database and measure get requests with same resource_id in query
14:06:31 <idegtiarov> I mean fill database step by step with rally context creation
14:06:40 <boris-42> idegtiarov: resource must be deleted after the load is done
14:06:56 <boris-42> idegtiarov: this must happen no matter what is the purpouse of testing
14:07:18 <boris-42> idegtiarov: otherwise operators will find me by my IP address and kill
14:07:19 <boris-42> =)
14:07:57 <idegtiarov> context will be deleted but we will have all data in databese after test is finish or Ive missed something?
14:08:31 <boris-42> idegtiarov: hm resources created by Rally should be deleted by Rally
14:08:54 <boris-42> idegtiarov: that is why we are forcing the way how things are named so we will be able to delete them in 100% cases no matter what happend
14:08:54 <idegtiarov> yep, but ceilometer collected data what about that data
14:09:33 <boris-42> idegtiarov: so as far as I understand rally won't touch it
14:10:08 <idegtiarov> that it, and are interested to measure ceilometer performance to get that collected data
14:10:25 <boris-42> stpierre: are you here ^
14:10:28 <stpierre> yeah
14:10:37 <idegtiarov> and for that case we need to collect data with certain reaource_id
14:11:08 <boris-42> idegtiarov: so what we are working on is extending the scenario output
14:11:21 <stpierre> this seems to me like it subverts an important part of rally cleanup in order to depend on a side-effect of rally to fill up the database
14:11:22 <boris-42> idegtiarov: so you will be able to put any information from scenario to reports
14:12:18 <stpierre> it seems to me that, in the best of all possible worlds, rally *would* delete the data that ceilometer collected during the rally run; IMO that's a cleanup bug. so depending on that isn't a great idea, and breaking rally cleanup to depend on it is an even worse idea
14:13:15 <idegtiarov> amiright that we a interested in rally side-effect! ))))
14:13:19 <boris-42> stpierre: idegtiarov btw is it possible to delete it?
14:13:33 <boris-42> I mean collected data from ceilometer
14:13:37 <boris-42> as far as I remember no
14:13:58 <boris-42> idegtiarov: so why you can't collect this data during the scenario run /
14:13:59 <idegtiarov> boris-42, not with ceilometer-api
14:14:24 <idegtiarov> but it could be done using Mongo TTL feature
14:15:34 <stpierre> otoh, if a future version of the ceilometer API added the ability to purge collected data, i think rally would want to use it. that's obviously speculation, but it's still breaking an important feature of rally in order to depend on an unwanted (but currently necessary) side-effect of rally
14:16:08 <boris-42> idegtiarov: so can we collect required data in rally scenario?
14:16:17 <boris-42> idegtiarov: instead of using this side effect?
14:16:28 <idegtiarov> as i mentioned we are interested to measure ceilometer performance depends on database fulfill so we create 100k samples in one test generate statistics request
14:16:58 <idegtiarov> after that create new 300k samples and repeat request
14:17:15 <idegtiarov> and so on
14:17:49 <boris-42> what request
14:17:50 <boris-42> ?
14:17:52 <stpierre> i think you should just create 400k samples, instead of using leftover data in subsequent rally runs
14:18:18 <boris-42> idegtiarov: I mean what request you run after creating N samples?
14:18:23 <stpierre> IMO a rally run should be completely self-contained, not dependent on out-of-band setup (like a previous rally run)
14:18:32 <oanufriev> hi all
14:19:12 <idegtiarov> we can write data from zero to required value if we would be able to cleann database after test, but our tests will go for hours
14:21:11 <boris-42> idegtiarov: so what request do you run please say me
14:21:32 <boris-42> idegtiarov: stpierre there is another way to implement this (as we already merge base for new task format)
14:21:56 <boris-42> idegtiarov: stpierre after we get new DB models we will be able to run any amount of sceanrios one by one in single context
14:22:16 <stpierre> that would seem to a perfect solution to this
14:22:19 <idegtiarov> is it possible to have optional resource_id in ceilometer context untill rally will be able to clean database?
14:23:16 <boris-42> idegtiarov: rally won't be able to cleanup database (imho this should be covered by Ceilometer API)
14:23:45 <boris-42> idegtiarov: let's discuss this after meeting
14:23:47 <idegtiarov> got it
14:23:52 <idegtiarov> ok
14:23:53 <boris-42> idegtiarov: I need to get more in context of this stuff
14:23:54 <idegtiarov> thanks
14:24:12 <boris-42> idegtiarov: in any case we will find something that will work for you
14:24:21 <idegtiarov> thanks a lot
14:25:04 <boris-42> idegtiarov: btw are any plans in ceilometer related to such kind of API?
14:25:56 <boris-42> okay in any case let's move to next topic
14:26:09 <boris-42> #topic  [rvasilets] New Rally dashboard - https://goo.gl/BcCAkU https://review.openstack.org/#/c/235957/
14:26:16 <boris-42> rvasilets: ping
14:26:25 <rvasilets> Hi I'm working on the new Rally dash board and if you interested in some user cases please tell me about this here is WIP link of the new dashboard https://goo.gl/BcCAkU After it would be finished I will announce it eom
14:27:27 <boris-42> rvasilets: You are a reviewer, but haven't voted in the current revision
14:27:36 <boris-42> rvasilets: why this topic is on top?
14:27:46 <boris-42> rvasilets: I have like 30 patches
14:27:55 <boris-42> rvasilets: and it doesn't make any sesnse for me
14:28:48 <rvasilets> boris-42, The order of topics was suggested by your earlier. Feel free to request the new order
14:28:53 <stpierre> rvasilets: i get an error on the new dashboard: "limit of 10 queries"
14:29:03 <boris-42> rvasilets: I didn't suggest that point
14:29:23 <boris-42> rvasilets: at all
14:29:40 <rvasilets> boris-42, ok. So you don't want to see this section?
14:29:48 <boris-42> rvasilets: yep
14:29:52 <boris-42> rvasilets: it's useless
14:29:59 <stpierre> i'm not sure that section is really that useful, since i can already easily scan through the "Incoming reviews" section of My Changes and see which ones are bold
14:30:15 <boris-42> stpierre: or just read mailing box
14:30:16 <rvasilets> stpierre, I don't have any errors. Do other have it?
14:30:20 <boris-42> stpierre: or just open base page
14:30:25 <stpierre> boris-42: only suckers read email :)
14:30:31 <boris-42> stpierre: lool
14:30:37 <albertw> same error here 'limit of 10 queries'
14:31:14 <boris-42> rvasilets: I will just remove that new ueless panel
14:31:26 <boris-42> rvasilets: maybe people won't face the issue with limit of 10 queries
14:31:27 <rvasilets> boris-42, ok
14:31:48 <rvasilets> stpierre, albertw strange I don't see any reason for that
14:31:49 <boris-42> rvasilets: btw what is critical for next release?
14:32:47 <rvasilets> as earlier Critical are starred by you AND me. Important starred by you OR me.
14:33:12 <boris-42> rvasilets: why you?
14:33:17 <boris-42> rvasilets: I mean important
14:33:22 <rvasilets> boris-42, I just swap mdubov with me.
14:33:45 <boris-42> rvasilets: so let's just left one critical for next release
14:33:57 <boris-42> rvasilets: important should be removed
14:34:02 <boris-42> rvasilets: as well as need feedback
14:34:03 <rvasilets> boris-42, ok
14:34:36 <rvasilets> boris-42, Needs Feedback (Changes older than 5 days that have not been reviewed by anyone) this section you want to remove too?
14:34:41 <boris-42> rvasilets: yep
14:34:47 <rvasilets> boris-42, ok
14:35:01 <boris-42> rvasilets: it's better to sort ready for review patches in order first oldest
14:35:05 <rvasilets> boris-42, just I found it interesting
14:35:32 <boris-42> rvasilets: when you have on one page more then 200 links it becomes useless
14:35:41 <rvasilets> boris-42, if there would be possibility to sort by age I wiil do it
14:35:44 <rvasilets> ok
14:36:02 <boris-42> rvasilets: in any case list should be short as possible
14:36:25 <rvasilets> there is a limit)
14:36:59 <rvasilets> we could set the limit in any section
14:36:59 <boris-42> okay let's move to the next topic
14:37:05 <boris-42> rvasilets: no no limit
14:37:10 <boris-42> rvasilets: just remove useless sections
14:37:10 <boris-42> =)
14:37:23 <boris-42> #topic stpierre] Bug (?) in @types processing of images created by context
14:37:25 <rvasilets> boris-42, ok
14:37:32 <boris-42> hey there stpierre
14:37:34 <boris-42> sooo
14:37:41 <stpierre> basically, if you create an image in the images context and try to use it as an argument to a scenario, it passes validation just fine, but when the @types decorator tries to resolve it, it blows up
14:38:11 <stpierre> @types.set(), that is
14:38:23 <boris-42> stpierre: I dislike that code overall
14:38:23 <stpierre> and i don't know how to solve this in an elegant way
14:40:24 <boris-42> stpierre: so https://github.com/openstack/rally/blob/master/rally/task/types.py#L56
14:40:27 <boris-42> stpierre: this is the problem
14:40:40 <stpierre> yeah, basically
14:40:41 <boris-42> stpierre: and another one problem is that types are not plugins
14:41:02 <boris-42> stpierre: and this is even bigger problem because it blocks us from removing openstack from Rally framework
14:41:17 <boris-42> stpierre: so typically there are 3 places that binds us to openstack
14:41:22 <stpierre> ooh :/
14:41:32 <boris-42> stpierre: 1) rally deployment 2) rally task types 3) rally task validation
14:41:34 <stpierre> so basically this images bug is just the tip of the iceberg
14:41:41 <boris-42> stpierre: yyeeeep
14:42:12 <boris-42> stpierre: I removed bunch of dependcies between 0.0.4->0.1. switch
14:42:22 <stpierre> it sounds like what we need is a spec laying out a new way to do types, that is both pluggable, and supports types that are resolved once per subtask, or once per iteration. does that sound correct?
14:42:23 <boris-42> stpierre: but these 3 still have to be adrressed
14:42:59 <boris-42> stpierre: types should be resolved always per subtask
14:42:59 <stpierre> 'cause we can resolve flavors, e.g., once per subtask, since a flavor exists globally; but images need to be resolved on every iteration, using the context for that iteration, to avoid this bug
14:43:08 <stpierre> okay, how can we do that with images?
14:43:30 <boris-42> stpierre: so the whole idea of types was to resolve the things before load starts
14:43:43 <stpierre> say the context has created three tenants, and three identically-named images, one per tenant. how can we hand off a single image id to the runner and expect it to work?
14:43:45 <boris-42> stpierre: so you won't get overhead of image list on each iteration where you don't expect it
14:44:03 <stpierre> i understand that we don't want the overhead, but unless we make all images public it just plain won't work
14:44:05 <boris-42> stpierre: so there different ways to resolve this
14:44:15 <boris-42> stpierre: that's not true
14:44:27 <boris-42> stpierre: you can do image list from all users in context and store somewhere
14:44:34 <boris-42> stpierre: for example in context_obj
14:44:48 <boris-42> stpierre: after that use this infromation before u run scenario iteration
14:45:10 <boris-42> stpierre: current implementation sucks but it doesn't mean that there is no better way to handle the stuff
14:45:27 <stpierre> okay, so you end up doing all possible types resolutions before the subtask starts, and just cache it. that makes sense. of course we still need support for an action run before each iteration then, it's just a different action
14:45:53 <boris-42> stpierre: I am talking about different way to handle types
14:45:57 <stpierre> so am i
14:46:09 <boris-42> stpierre: so just implement better mechanism that won't depend on openstack
14:46:32 <stpierre> right, that's the first step, but there's more to it than just that.
14:46:41 <stpierre> anyhow, i'll write up a spec and we can discuss the nitty-gritty details then
14:47:15 <stpierre> ty
14:47:51 <boris-42> stpierre: heh that will be hard one spec
14:48:04 <boris-42> okay let's move to the next topic
14:48:18 <boris-42> #topic [amaretskiy] plans and status for upcoming changes in output charts in HTML report
14:48:41 <amaretskiy> there are plans to improve scenario output charts a lot
14:48:51 <amaretskiy> currently we have single chart
14:49:24 <amaretskiy> but the idea is to have arbitrary number of additive (one value per iteration) charts
14:49:27 <amaretskiy> and also
14:49:39 <amaretskiy> have complete charts from each iteration
14:49:56 <amaretskiy> so there will be 2 tabs
14:50:01 <boris-42> amaretskiy: are you going to propose spec  ?
14:50:05 <amaretskiy> yes
14:50:07 <boris-42> amaretskiy: or you will just work on the code/
14:50:20 <amaretskiy> since this affects scenario results schema
14:50:36 <amaretskiy> the first step is having a spec
14:50:52 <amaretskiy> that is what I'm  working on right now
14:51:04 <amaretskiy> I believe the spec will be proposed tomorrow
14:51:13 <amaretskiy> eom
14:51:45 <boris-42> amaretskiy: okay great
14:51:56 <boris-42> amaretskiy: please make sure that you are aligned with pboldin
14:52:19 <boris-42> #topic  [ikhudoshyn] Distributed load generation - spec  - https://review.openstack.org/#/c/236979/
14:52:34 <ikhudoshyn> hi
14:52:54 <ikhudoshyn> there is ongoning work to design subj
14:53:25 <ikhudoshyn> we want to run rally on several nodes in order to increase amount of load we could generate
14:53:53 <ikhudoshyn> by the link there is a patch (not ready yet) with the spec
14:54:26 <ikhudoshyn> it does not contain any impl details but already describes the main topics and action items
14:54:54 <ikhudoshyn> in the nearest future I'm to add ac ouple diagrams and imp details
14:54:59 <boris-42> шikhudoshyn ok great
14:55:03 <boris-42> stpierre: ^ btw
14:55:22 <boris-42> ikhudoshyn: btw don't forget about part related to the sending context
14:55:32 <boris-42> ikhudoshyn: and making unique iterations number
14:55:40 <ikhudoshyn> boris-42: sure
14:56:16 <ikhudoshyn> any questions anybody?
14:56:46 <amaretskiy> no
14:56:57 <boris-42> not yet=)
14:57:07 <ikhudoshyn> good))
14:58:21 <boris-42> okay let's end meeting
14:58:24 <ikhudoshyn> looks like we r done, just in time
14:58:24 <boris-42> see you guys
14:58:29 <boris-42> #endmeeting