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