17:01:06 #startmeeting Rally 17:01:07 Meeting started Tue Feb 25 17:01:06 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:01:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:11 The meeting name has been set to 'rally' 17:01:12 boris-42_: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 17:02:59 hughsaunders ping 17:03:02 msdubov ping 17:04:26 hey boris-42_ 17:04:31 boris-42 hi 17:07:11 рш фдд 17:07:15 miarmak hey=) 17:07:15 hi all* 17:07:21 okay guys let's strat 17:07:23 boris-42_: hi:) 17:07:33 1) Verification stuff 17:07:38 2) Benchmark stuff 17:07:41 3) Deploy stuff 17:07:50 #topic 1) Verification stuff 17:08:00 miarmak I have a couple of questions 17:08:07 boris-42_: yep 17:08:26 miarmak it actually is really hard to use 17:08:46 boris-42_: why? 17:08:58 miarmak I mean probably we should move all tempest files to ~/.rally/tempest/* 17:09:14 miarmak cause it requires "sudo" to use it or even to run 17:09:19 ~/.rally/deploy-id/tempest 17:09:25 hughsaunders +1 17:09:43 and rally install will make git clone 17:09:55 I was trying to figure out where tempest is installed, gets complicated with venvs 17:09:58 and rally run will copy paste this local repo to /rally/deploy-id 17:10:05 hughsaunders +1 17:10:14 hughsaunders it doesn't work.. with venv.. 17:10:15 added a debug statement just to show where config is as I wanted to check whats in it 17:10:31 miarmak are you agree with these chagnes? 17:10:54 boris-42_: hm, in such case of course 17:11:54 marcoemorais ping 17:12:00 marcoemorais we have meeting=) 17:12:22 miarmak ok let move this 17:12:34 miarmak as I know you are not able to do this? 17:12:48 miarmak so probably Olga could continue work around it 17:13:14 boris-42_: yeah( 17:13:30 miarmak another area that I would like is to create by hand virtual env 17:13:33 miarmak inside rally 17:14:05 miarmak and then use tempest with testr that will allow us to get full results (without processing of run_tempest) 17:14:17 miarmak so we will be able to parse them and store 17:15:03 boris-42_: aha, clear 17:15:11 miarmak so okay=) 17:15:19 #topic benchmark 17:15:37 Okay I would just to discuss our future steps 17:15:39 hughsaunders ^ 17:16:03 erm 17:16:08 future of verification? 17:16:17 #topic benchmark 17:16:21 oh sorry :( 17:16:42 I think it makes sense to put here the link to https://docs.google.com/a/mirantis.com/document/d/1LYUAHkZQD8W7dtlj2I3PDA6x67TiD3AMnSWG6ljsups/edit#heading=h.ae5lk415py0q 17:16:52 as a guidance 17:16:52 msdubov yep 17:17:02 msdubov but we should start working around all these steps 17:17:17 I've started today with point 1 17:17:20 boris-42_: here now 17:17:23 msdubov and point 2 17:17:27 ("Improving scenario input args validation") 17:17:34 marcoemorais hey happy to see you=) 17:17:40 boris-42_ Yep they are to follow 17:17:50 I would like to work on stress execution, but won't be able to for a while 17:17:52 They are currently on review.openstack.org but WIP 17:17:53 marcoemorais you're just in right moment=) 17:17:55 and will be rebased 17:18:12 hughsaunders I've actually started it some time ago 17:18:17 :) 17:18:21 even before we've made all this refactoring 17:18:22 msdubov you started in wrong direction=) 17:18:30 So I'll probably continue the work in another direction 17:18:39 in the right one 17:18:41 msdubov probably we could let hugh?) 17:19:03 boris-42_: no 17:19:04 boris-42_ Well, it depends on when hughsaunders can start it, I think 17:19:06 msdubov there is a lot of other work that should be done before stress exectuion=) 17:19:13 boris-42_ agree 17:19:23 somebody have to do it as well.. 17:19:35 hughsaunders serious?) 17:19:46 boris-42_: just time starved at the mo :( 17:20:39 hughsaunders okay I think ww will see who will be able to do all parts 17:20:54 msdubov hughsaunders but before doing it we should change input config 17:20:59 boris-42_: yeah 17:21:33 hughsaunders so load_generator or run_configuration or run_config? 17:21:38 msdubov marcoemorais ^ 17:21:59 boris-42_ I personally like "load generator" 17:22:14 because it's logical for everybody not familiar with the inner structure of Rally 17:23:19 boris-42_: what is the difference btwn run_configuration and run_config? 17:23:34 msdubov length=) 17:23:40 I would vote for run_config 17:23:40 marcoemorais length * 17:24:15 run_config 17:24:57 boris-42_ what's your opinion? 17:25:48 msdubov i don't know as form one side I like load_generator (cause it clear that inside will be configuration of it) 17:26:16 msdubov from other side run_config is clean as well... 17:26:30 amaretskiy hi 17:26:37 hello! 17:26:46 amaretskiy https://docs.google.com/a/mirantis.com/document/d/1LYUAHkZQD8W7dtlj2I3PDA6x67TiD3AMnSWG6ljsups/edit# open this document at point 3.1 17:26:56 amaretskiy we are voting for new config schema 17:27:11 amaretskiy load_generator or run_config 17:27:18 amaretskiy your oponion? 17:27:37 sorry, I'm novice to this, I have no idea at that time 17:27:52 amaretskiy you are super useful for this task 17:27:59 I'm just a spectator for a while :) 17:28:00 amaretskiy cause you don't know anything about Rally 17:28:28 ok, I will think about that for a minute... 17:28:30 amaretskiy what is more clear for you, it specify load that will be generated 17:28:34 an argument for "load_generator" would be IMHO the fact that we are speaking about continuous/periodic LOADS on the cloud, not about continuous/periodic configurations 17:28:46 boris-42_ " it specify load that will be generated" lol 17:28:52 boris-42_ That's unfair :) 17:29:13 msdubov: but its also parameters for how the scenario will be run 17:30:01 btw tenants and user_per_tenant as well specify run configuration 17:30:09 probably it will be a bit misleading ? 17:30:37 boris-42_ Nope, they specify what happens inside the cloud, so it's ok I think... 17:30:57 msdubov nope they specify actually run specifycation 17:31:08 boris-42_ I mean that scenarios are on the Rally side but users/tenants exist in the cloud 17:31:16 hughsaunders so run_conifg should contains for 2 parts config of resources 17:31:21 hughsaunders and config of load 17:31:28 how about something even more generic like test_config or benchmark_config ? 17:31:41 marcoemorais as I said 17:31:59 scenario_args is benchmark configuration? 17:32:02 marcoemorais part with "cloud_config" is as well part of benchmark config 17:32:24 msdubov hughsaunders marcoemorais what about load_config ? 17:32:58 because actually it is configuration of load 17:33:01 and nothing else 17:34:35 scenario_run_config? 17:34:48 boris-42_: usu. what is nice is when names in the configuration match names in the code (that is why scenario_args is nice), if we call this load_config, we should prolly rename the code to use word load 17:35:13 marcoemorais now they are called scneario_runners 17:35:39 boris-42_: then runner_config? 17:36:12 marcoemorais actually probably yes 17:36:21 hughsaunders msdubov thoughts ? 17:36:35 I like runner_config 17:36:45 cause it will be absolutely clear what means "type" field 17:36:54 it's just runner type 17:37:09 boris-42_ Also perfectly ok 17:37:13 #agreed 17:37:13 okay 17:37:14 nice 17:37:27 marcoemorais Also true. In any case, the code should follow the API (= the config format), but never vice cersa 17:37:40 what about cloud_config? 17:37:52 * boris-42_ Holy wars meeting 17:38:06 haha 17:38:27 I think actually such things are very important 17:38:37 cause it is thing that is used by end users.. 17:38:43 so it should be ideal 17:39:10 so variants are next 17:39:16 boris-42_: so things specified in cloud_config are setup before the scenario is run? In this case creating users.. 17:39:30 hughsaunders yep but there will be much more 17:39:32 hughsaunders in future 17:39:54 so in general it specifies resources to be created that will be used by the scenario? 17:40:00 hughsaunders yep 17:40:08 so resource_config ? 17:40:42 hughsaunders: that sounds pretty good 17:40:44 marcoemorais msdubov miarmak amaretskiy ^ 17:41:02 upload images, configure access lists, configure network. imo better is cloud_config 17:41:10 it not only resources 17:41:15 hmm ok 17:42:03 tzabal hi 17:42:13 hello 17:42:16 tzabal we have holy wars meeting at the moment 17:42:21 tzabal https://docs.google.com/a/mirantis.com/document/d/1LYUAHkZQD8W7dtlj2I3PDA6x67TiD3AMnSWG6ljsups/edit# 17:42:32 tzabal point 3.1. 17:42:32 so it specifies any action that needs to be done to the cloud before rally is run. cloud_preparation? 17:42:38 cloud_prep? 17:42:53 hughsaunders yep any actions not only creation of resources 17:42:53 hughsaunders: one thing abt the items in this section is that they are ephemeral (eg cleaned up at end of test) 17:43:08 marcoemorais ? 17:43:19 marcoemorais ah yes 17:43:30 marcoemorais they should return cloud in state 17:43:37 marcoemorais before benchmarking 17:43:41 boris-42_: they will all get cleaned up by ResourceCleaner 17:43:46 marcoemorais yep 17:44:16 boris-42_: like setUp and tearDown in a unit test 17:44:26 marcoemorais yep 17:44:27 https://blueprints.launchpad.net/rally/+spec/pre-benchmark 17:44:31 2013-11-26 17:44:49 rediskin bad config=) 17:45:01 rediskin but word "pre_benchmark" 17:45:18 is interesting 17:45:19 benchmark_prep 17:45:24 scenario_prep? 17:45:30 scenario_prep 17:45:34 hughsaunders: benchmark_setup? 17:45:47 benchmark_setup +1 17:46:12 benchmark setup is similar to scenario_args, we need something that implies action before the benchmark is run 17:47:35 so?) 17:48:07 so something with pre/prep/before/etc ? 17:49:01 what about bare words "setup", "benchmark", "cloud" ? 17:49:41 scenario, runner, prep? 17:50:10 args 17:50:16 args/runner/prep 17:50:17 ? 17:50:37 I like that 17:51:30 marcoemorais rediskin amaretskiy msdubov miarmak 17:51:36 args/runner/prep 17:51:38 ^ 17:51:47 without any complicated constructions 17:51:51 sounds good 17:52:07 I like prep 17:53:20 marcoemorais ? 17:53:43 boris-42_: args/runner/prep without additional complications is good 17:53:44 marcoemorais so we will use this set? 17:53:49 okay nice 17:53:53 renaming in doc 17:55:15 * boris-42_ nice 17:55:29 it looks perfect and clear 17:55:46 agree, much better than the current format 17:55:55 who will rename it? 17:56:11 marcoemorais would you like to refactor it? 17:56:19 boris-42_: yes 17:56:29 boris-42_: is there a trello card for this yet? 17:56:30 marcoemorais could you make task at trello? 17:56:33 marcoemorais nope 17:56:46 marcoemorais goal of this document is to collect all togehter 17:56:52 whats uppp 17:56:54 ha 17:56:54 marcoemorais to simplify splitting job to trello tasks 17:56:57 harlowja ha=) 17:57:07 harlowja we are just speaking about refactoring configuration file 17:57:15 keep up the good work! 17:57:15 lol 17:57:28 harlowja already disucssed 17:57:34 marcoemorais will implement 17:57:35 -=) 17:57:37 nice 17:57:39 +2 17:58:01 a question that i was having with marco, why have the json files at all? why not just let people program in say python 17:58:17 harlowja there is a strong reason 17:58:26 whats that 17:58:47 harlowja for 99% of people it is hard 17:59:02 :-/ 17:59:02 harlowja for 80% of people it is hard even to fill right this simple jso 17:59:03 thats sad 17:59:04 json 17:59:08 double sad 17:59:12 so =( 17:59:22 they just would like to have 1 red button 17:59:29 hmmm 17:59:30 "benchmark it" 17:59:33 ha 17:59:38 that will do all work and make a report 17:59:47 soo 18:00:01 JSON simplify UI of rally a lot 18:00:21 exccept its json :( 18:00:25 and can't have comments in it :( 18:00:27 that sux 18:00:37 harlowja so it should be super clean=) 18:00:40 lol 18:00:40 json allows users to tailor benchmarks to their needs without hacking on code 18:00:54 hughsaunders yep 18:00:59 but could use yaml, wouldn't make much difference 18:01:16 hughsaunders actually yes 18:01:18 hmmm, ok, i'm just not sure, to me hacking on json is the same level of difficulty as hacking on code 18:01:19 o/ 18:01:20 could use support both, its the structure not the format that is important 18:01:21 but up to u guys 18:01:27 * ayoung slips into meeting room 18:01:29 for the users of "red button", we may create a web UI as a frontend to the configuration with the required fields, it could be more "user friendly" 18:01:36 guys we need to end meeting 18:01:41 bye 18:01:43 lata 18:01:45 let's go to Rally 18:01:50 #endmeeting