17:03:03 <boris-42> #startmeeting rally 17:03:04 <openstack> Meeting started Tue Aug 26 17:03:03 2014 UTC and is due to finish in 60 minutes. The chair is boris-42. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:03:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:03:07 <openstack> The meeting name has been set to 'rally' 17:03:12 <boris-42> Hi Rally team! 17:04:21 <boris-42> k4n0 RainbowBastion marcoemorais harlowja_away olkonami hi guys 17:04:31 <k4n0> o/ hi all 17:05:45 <rediskin> -_- 17:06:03 <boris-42> rediskin hi there 17:06:09 <rediskin> hi all 17:06:30 <oanufriev> hi 17:07:27 <boris-42> oanufriev hi 17:08:04 <boris-42> okay I'll start 17:08:15 <boris-42> #topic support of benchmarking with pre created users 17:08:51 <boris-42> so the idea is to avoid creation of temporary users and be able to benchmark with existing users 17:09:20 <boris-42> to do this I decided to extend ExistingEngine config to accept admin & users 17:09:26 <boris-42> and do all related change 17:09:49 <boris-42> #link https://review.openstack.org/#/c/116766/ 17:10:10 <boris-42> but patch is not fully ready, as well there will be some hacks and refactoring of context 17:10:48 <boris-42> to remove hardcoded usage of user context 17:11:00 <boris-42> so I hope during this week I'll finish work on this 17:11:04 <boris-42> any questions? 17:11:37 <rediskin> how users will be created? 17:11:56 <boris-42> rediskin they are lady exist 17:12:01 <boris-42> rediskin in OpenStack 17:12:24 <boris-42> rediskin usually in production OpenStack is using existing LDAP 17:12:29 <rediskin> oh 17:12:30 <rediskin> ok 17:12:30 <boris-42> rediskin with read only access 17:12:48 <boris-42> rediskin that's the issue, so people is not able to run benchmarks against their production clouds 17:13:07 <rediskin> ok. got it 17:13:32 <boris-42> ok next topic? 17:13:38 <olkonami> May be it's a stupid question. But why can't we just extend user context to specify existing users there& 17:13:50 <boris-42> openstack so good question 17:14:20 <rediskin> +1 17:14:39 <boris-42> olkonami rediskin so the issue is next 17:15:00 <boris-42> openstack rediskin I want to run 100 benchmarks 17:15:07 <boris-42> olkonami rediskin in one task 17:15:22 <boris-42> I will need to write 100 times the similar users 17:16:10 <boris-42> olkonami rediskin so for end user it will be simpler to describe during creating deployment these users, then specify every time 17:16:39 <boris-42> olkonami rediskin it doesn't mean that we won't have existing-users context 17:17:05 <rediskin> i thought also about shared contexts or named contexts 17:17:21 <boris-42> rediskin yep this will be as well one of the features that we should discuss 17:17:22 <rediskin> one context multiple tasks 17:17:35 <boris-42> rediskin I want to make something like persistance-context 17:17:48 <boris-42> rediskin e.g. running task against context (not deployment) 17:18:03 <boris-42> rediskin as well I am thinking about general section for benchmark config 17:18:41 <olkonami> +1 for general section for benchmark congfig 17:18:54 <boris-42> olkonami we should think a lot about this 17:19:04 <boris-42> olkonami and make proposals cause it's user facing changes 17:19:12 <boris-42> olkonami so they should be done 1 time and forever 17:20:05 <olkonami> boris-42. ok. clear 17:20:10 <boris-42> olkonami rediskin so actually I think having a deployment with users will be better actually 17:20:15 <boris-42> olkonami rediskin in most cases 17:20:32 <boris-42> olkonami rediskin cause you can run different tasks without changing them every time 17:20:37 <boris-42> olkonami rediskin depending on users 17:20:59 <boris-42> okay let's move 17:21:10 <boris-42> #topic msdubov came back from vacation woot 17:21:13 <boris-42> https://wiki.openstack.org/wiki/Rally/Updates 17:21:18 <boris-42> ^ we have finally fresh update 17:21:56 <boris-42> #topic Generic cleanup 17:22:06 <boris-42> rediskin could you share updates ? 17:22:22 <rediskin> im working on reafactoring cleanup mechanism 17:22:48 <rediskin> now it will be done via cleanup classes 17:23:28 <rediskin> with minimum code duplication and rate limiting and retry ability 17:24:16 <rediskin> patch is almost done https://review.openstack.org/#/c/116269/ 17:24:47 <rediskin> boris-42: ^ 17:25:25 <k4n0> boris-42, I am finishing up unit tests coverage blueprint https://review.openstack.org/#/c/116958/ 17:26:04 <boris-42> rediskin oh it's a bit magic=) 17:26:21 <boris-42> rediskin will take a look later 17:26:35 <boris-42> rediskin btw what do you think about part related to deleting resources by pattern-names? 17:27:03 <rediskin> boris-42: it may be separate command 17:27:16 <rediskin> rally cleanup or something similar 17:27:24 <boris-42> rediskin i mean another thing 17:27:47 <boris-42> rediskin would it be simpler to delete users using naming patterns? 17:28:09 <boris-42> rediskin e.g. then it will be similar in case of admin resources and user resources 17:28:34 <rediskin> we can delete all resources in such manner 17:28:57 <boris-42> rediskin nope we can't if we are deleting only by patterns 17:29:02 <boris-42> rediskin e.g. by name of resource 17:29:23 <rediskin> why? 17:29:31 <boris-42> for resource in resources.list() if pass_tempate(resource.name) 17:29:42 <boris-42> rediskin e.g. deleting all resource that are starting with rally_* 17:29:48 <rediskin> delete all rally_* volumes tenants users images etc 17:30:08 <boris-42> rediskin or maybe even better rally_<task_uuid> 17:30:18 <rediskin> +1 17:31:02 <boris-42> rediskin so it will simplify logic a lot ? 17:31:15 <boris-42> rediskin and we will be able to use this stuff in both cases admin/non-admin users 17:31:18 <rediskin> not sure if lot 17:31:34 <boris-42> rediskin but at least it will be similar to "rally deployment cleanup" 17:32:09 <rediskin> i will think about it, ok 17:32:26 <boris-42> rediskin great, I mean keep thing simple=) 17:33:10 <boris-42> #topic introduction to "rally info" 17:33:20 <boris-42> Okay guys we have absolutely new command 17:33:24 <boris-42> "rally info" 17:33:30 <boris-42> it's internal manual for rally =) 17:33:59 <boris-42> e.g. in future you'll be able to retrieve absolutely everything via it 17:34:04 <boris-42> for now you can do something like 17:35:36 <boris-42> rally info find CeilometerAlarms 17:35:41 <boris-42> and it will show pretty output 17:35:50 <boris-42> any questions? 17:36:51 <olkonami> have we already merged this? 17:36:54 <boris-42> olkonami yep 17:36:59 <boris-42> olkonami basic stuff yep 17:37:00 <olkonami> cool ^) 17:37:08 <boris-42> olkonami but there is a lot of work in this area 17:37:11 <boris-42> olkonami =) 17:37:53 <boris-42> #topic Welcome Designate team=) 17:38:00 <boris-42> ekarlso hey there 17:38:32 <ekarlso> boris-42: ello 17:38:42 <ekarlso> i'm just hiding atm 17:38:59 <boris-42> ekarlso =) 17:39:23 <boris-42> ekarlso so I'll need to review some of your patches=) 17:39:31 <boris-42> ekarlso but seems like gates are not in the best fit 17:39:56 <boris-42> rediskin could you help us to create a rally-gate with rally/desingate and probably other incubated projects? 17:42:33 <boris-42> ekarlso okay I hope he will help us =) 17:43:05 <boris-42> #topic Changes in Results json Schema 17:43:25 <boris-42> guys I am going to start work on new versions of json schema for output of results 17:43:34 <boris-42> e.g. currently we are facing few issues 17:43:52 <boris-42> 1) Stress engine can't store in native way results 17:44:28 <boris-42> 2) There is no way to store results if we make a engine/runner that will run multiple scenarios simultaneously 17:44:43 <boris-42> so I am going to extend a bit format to cover these case 17:44:58 <boris-42> this will as well involve change rally task config, graphs and rally detailed function 17:45:09 <boris-42> k4n0 rediskin olkonami ekarlso ^ 17:45:31 <k4n0> boris-42, ok, can you document this somewhere? 17:45:39 <boris-42> k4n0 yep 17:45:46 <k4n0> boris-42, thanks 17:45:50 <boris-42> k4n0 I am going to make google doc with changes 17:45:57 <boris-42> so it will be draft to start dicussion 17:45:57 <k4n0> boris-42, please share with me 17:46:05 <boris-42> I'll share with everybody =) 17:46:20 <olkonami> good good 17:46:31 <boris-42> #topic Stress runner 17:46:55 <boris-42> https://review.openstack.org/#/c/94806/ 17:47:01 <boris-42> this is quite old patch ^ 17:47:04 <boris-42> from olkonami ^ 17:47:12 <boris-42> I think that we should make it in a bit different way 17:47:34 <boris-42> e.g. why not having 1 stress runner 17:47:40 <boris-42> that can use other runners 17:47:49 <boris-42> and run them multiple times 17:48:30 <boris-42> so we can change a bit current runners (to add support of getting next stress arguments) or some stuff like that 17:49:01 <boris-42> but in generally *any* load generator can be used with stress stuff 17:49:21 <boris-42> k4n0 olkonami rediskin thgouths? 17:49:41 <k4n0> boris-42 1 stress runner sounds good 17:50:03 <olkonami> good thought, than may be we can extend BaseRunner for this functionality? 17:50:41 <boris-42> olkonami ya some method should be that allows to iterate "stress" arugments 17:51:11 <boris-42> olkonami e.g. every method should describe own stress notation 17:51:17 <boris-42> olkonami runner* 17:51:36 <boris-42> olkonami but this will be as well related to changing format of task results 17:51:52 <boris-42> olkonami I will propose tomorrow changes 17:51:58 <boris-42> olkonami so we will disucss in more details 17:52:42 <boris-42> ok 17:52:47 <boris-42> #topic free discussion 17:52:59 <boris-42> anybody has any questions/topics to disucss? 17:53:11 <olkonami> why own notation? I prefer general notation for all runner, I think it is possible 17:53:20 <boris-42> olkonami it can't be general 17:53:37 <olkonami> or some general part at least 17:53:40 <boris-42> olkonami cause RPS runner should be iterate in one way, Constant in antoher 17:53:57 <boris-42> olkonami RPS for duration, and constant for duration in third 17:54:16 <boris-42> olkonami I don't think that it's really hard to do 17:54:24 <boris-42> olkonami it's just another JSON schema 17:54:29 <boris-42> olkonami like we already have 17:54:51 <boris-42> olkonami https://github.com/stackforge/rally/blob/master/rally/benchmark/runners/rps.py#L98-L117 17:55:01 <boris-42> olkonami so there will be stress *one* 17:55:13 <olkonami> oh, yes, I understand 17:55:30 <boris-42> olkonami so we will get more control on level of runner 17:55:53 <boris-42> olkonami e.g. general stress runner will just get new values to run new iteration of stress 17:56:02 <boris-42> olkonami so it will have clean logic 17:56:11 <boris-42> olkonami and won't depend on other runners 17:57:29 <boris-42> okay 17:57:33 <boris-42> we have to end meeting 17:57:38 <boris-42> #endmeeting