17:03:52 #startmeeting Rally 17:03:53 Meeting started Tue Jul 29 17:03:52 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:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:03:56 The meeting name has been set to 'rally' 17:05:05 Hi o/ 17:05:11 k4n0 Hi there 17:05:18 k4n0 let's wait for others 17:06:33 tbarron hi there 17:06:40 tbarron sorry* 17:06:44 tzabal hi there 17:06:54 boris-42 hi 17:08:46 okay let's start 17:09:33 k4n0 could you please update 17:09:42 share updates 17:09:53 k4n0 I saw you got merged tempest related patch 17:10:08 boris-42, I am working on adding unit test coverage and adding context setup timing data 17:10:59 k4n0 so how's that go? 17:11:15 k4n0 btw are you working on --json stuff? 17:11:22 boris-42, I have no blockers, will finish task in a day or two. 17:11:27 boris-42, --json patch is under review 17:11:40 k4n0 but it doesn't add to all command --json 17:11:57 boris-42, which command are left? 17:12:20 k4n0 all 17:12:41 k4n0 all commands should accept --json 17:12:53 boris-42, ok, i have this patch https://review.openstack.org/#/c/106813/ 17:12:57 boris-42, i will add to it 17:14:07 k4n0 in your patch you are adding only to "deploy config" and "task results" 17:14:12 k4n0 but we have much more commands 17:14:22 k4n0 btw you don't need to add everything in single patch 17:14:31 k4n0 it can be chain of patches, so it will be simpler to review it 17:14:36 boris-42, other commands dont have output which can be shown in json, but i will check 17:15:01 k4n0 all list commands 17:15:08 k4n0 all run commands 17:15:17 boris-42, ok, i will check 17:15:36 k4n0 all commands that have output should have a way to be displayed in json 17:15:43 boris-42, got it 17:16:09 k4n0 as well I think that it makes sense to do alias 17:16:23 boris-42, alias? 17:16:24 k4n0 "rally task show" instead of "rally task details" 17:16:29 oh no 17:16:31 no details 17:16:37 but "resutls" 17:16:52 e.g. rally task show and rally task results will be similar 17:17:05 and we will deprecate "results" 17:17:08 k4n0 ^ 17:17:33 boris-42, ok 17:17:43 rediskin around?? 17:17:50 yep 17:17:55 #action deprecate rally task results for rally task show 17:18:04 k4n0 #action deprecate rally task results for rally task show 17:18:16 k4n0 #action add to all commands --json 17:18:24 #action add to all commands --json 17:18:28 boris-42, got it 17:18:38 heh there is no irc bot message 17:18:42 for actions 17:18:53 so as well what we need is --show-uuid 17:19:07 k4n0 today with andreykuriling and rediskin we discussed 17:19:17 k4n0 that it's quite hard to use in bash scripts rally 17:19:30 k4n0 cause we don't know UUID of created resources 17:19:59 k4n0 so it will be nice to add to all commands that are creating argument 17:20:20 k4n0 --show-uuid that will display only one line of output that contains uuid of created resource 17:20:37 k4n0: to be able to write something like this http://paste.openstack.org/show/88961/ 17:20:46 boris-42, ok, so all create commands will show uuid if --show-uuid is used 17:21:33 k4n0 yep like rediskin ^ showed 17:22:08 okay let some 17:22:11 let's move** 17:22:18 ok got it 17:22:23 #topic RPS load generator 17:22:30 #action http://paste.openstack.org/show/88961/ 17:22:36 Oaky finally we merged patch 17:22:41 that fixes periodic runner 17:22:54 and actually change it's name to something more clear 17:23:24 so we have some kind of "Scenario per seconds" runner 17:23:26 know 17:23:28 woot 17:23:52 https://review.openstack.org/#/c/102363/ 17:23:54 there is already some changes in rps on review 17:23:55 #link https://review.openstack.org/#/c/102363/ 17:24:03 rediskin yep could you share about them 17:24:27 https://review.openstack.org/#/c/110007/ 17:24:33 just some improvements 17:24:57 rediskin --verobse share about what is changed there 17:25:00 ^_^ 17:25:26 most significant change is joinig completed threads once they completed 17:25:40 current prs runner statrs all threads 17:25:44 and then join all threads 17:26:05 if we specify "100000" times in config 17:26:12 we got 100000 alive threads 17:26:25 rediskin ohhh 17:26:39 rediskin so that won't work=) 17:26:56 rediskin is your patch ready? 17:27:06 it will work with 64 bit PID identifiers %) 17:27:10 yes, it is ready 17:27:24 rediskin okay so we will need to review it=) 17:27:27 k4n0 ^ 17:27:44 boris-42, yes, ill review it 17:27:48 tbarron ping* 17:28:13 #topic Production ready cleanups 17:28:22 sooo guys it's quite large stuff 17:28:26 first of all we should 17:28:33 1) Split admin and user cleanups 17:29:21 2) Make cleanup more offline ready 17:29:36 e.g. we should be able to kill rally process 17:29:44 and restore process of cleanuping 17:30:09 3) Make a cleanup specific per task / so we will be able to cleanup resources related to only one task 17:30:35 4) Add functional job that will check that cleanup works in any case (even if rally process fails in the middle) 17:30:46 rediskin ^ are you ready for this?) 17:30:57 ohh 17:31:33 rediskin yep it's quite largeeee task 17:31:38 i just trying to split admin and user cleanup 17:32:02 rediskin yep when you finish that I will help you with explaining next steps=) 17:32:19 rediskin btw we should have next submethods 17:32:31 rediskin cleanup_tenant_resources, cleanupt_user_resources 17:32:42 rediskin in both admin and user cleanup context 17:33:07 rediskin cause quotas, images are per tenant, and instances are more per user 17:33:54 rediskin thoughts? 17:34:12 i can tell you more after splitting admin and users cleanups 17:35:21 i missing a lot in cleanup stuff 17:35:35 rediskin yep this is quite large topis 17:35:37 topic 17:35:52 rediskin probably I should create big blueprint with link to the google doc 17:36:26 #action make a big doc about cleanup stuff 17:36:35 #topic Rally & Specs 17:36:52 I think that we should make in doc/ new directory doc/specs 17:37:06 maybe we should write docs about cleanup mechanism in dos/sources/cleanup.rst 17:37:16 rediskin +1 17:37:24 rediskin did you take a look at doc jobs? 17:37:30 no 17:37:39 which jobs? 17:37:53 rediskin gate--docs 17:38:26 rediskin actually we have already one 17:38:26 but there is a gate-rally-docs job already in rally 17:38:42 rediskin but it won't check rally/docs/specs 17:39:11 it should be different job? 17:39:25 one more repo on rtfd.org? 17:39:34 separate rally and rally-specs? 17:40:05 i thought rally-specs will be just another section of rally-docs 17:40:24 rediskin then they should be in rally/doc/source 17:40:41 yes 17:41:26 rediskin https://github.com/openstack/oslo-specs/blob/master/tox.ini#L17-L18 17:41:57 we have something similar in rally 17:41:59 rediskin https://github.com/stackforge/rally/blob/master/tox.ini#L32-L35 17:42:09 rediskin ^ it's different a bit 17:42:47 rediskin in any case maybe we should just refactor current docs 17:42:59 rediskin e.g. everything that is in source move to the top 17:43:07 i believe there is "make html" in setup.py %) 17:43:09 rediskin and have in rtfm everything 17:43:36 rediskin so we will have Samples, user_stoires and other in rtfm 17:44:08 yes, it would be nice 17:45:10 rediskin okay I will make some small patch 17:45:15 rediskin to refactor this 17:45:22 rediskin its not to much work 17:45:30 #action refactor rtfm 17:45:40 #topic open discussion 17:45:52 anybody would like to discuss anything? 17:45:56 a quick question: Would somebody want help into improving the installation method for CentOS? 17:46:19 lordd as far as I know you tried to install it on Fuel controller? 17:47:05 well.. yeah, not as smooth as I wanted it to be, so I tried again on an empty CentOS machine 17:47:16 lordd it's problem of fuel controller image 17:47:45 lordd Centos that is used for Fuel controller is very custom 17:47:59 lordd as well you shouldn't install rally on Fuel controllers 17:48:05 ok, got it, makes sense 17:48:22 lordd actually we have functional testing, that is run on every patch in rally 17:48:32 lordd that checks that that script works in centos and ubuntu 17:48:47 lordd and installas rally successfully 17:48:51 so, rally is also funcional with 6.5, ok 17:49:17 lordd I hope so=) 17:49:41 rediskin what Centos image is in gates? 17:50:13 lordd i have tested it against CentOS 6.5 and it installed rally successfully 17:50:15 boris-42: 6.5 afair 17:50:26 rediskin okay good=) 17:50:36 ok, we're good then, sorry for the fuzz 17:50:51 lordd no worries and don't install rally on Fuel controllers=) 17:51:41 tzabal as you are here 17:51:43 haha, sorry it was for quick testing 17:51:59 lordd it's better to use VMs even in such case=) 17:52:02 lordd or your laptop=) 17:52:05 eventually, though where should cloud admins have rally installed? 17:52:16 when rally is a service 17:52:19 lordd at some day it will be horizon plugin 17:52:31 lordd and it will be installed probably on controllers 17:53:06 ok, for the moment I learnt my lesson and I have my vm with it 17:53:28 lordd yep it's definitely better=) but we are working on getting this as a horizon plugin 17:53:47 lordd so fuel will install it (like murano and so on) 17:54:04 when you need help with the UI, ring a bell :) 17:54:05 tzabal wanna discuss your work? 17:54:13 lordd hm you are UI guy/ 17:54:14 ? 17:54:26 depends of the UI, but I can do things with it 17:54:36 lordd and write a code?) 17:54:56 my Python is a sysadmin python 17:55:02 lordd and js?) 17:55:07 yep, the same 17:55:19 can do it, but will be ugly 17:55:28 lordd =) 17:55:47 boris-42 well i hope that we will have a functional vm benchmarking in some days :) 17:56:05 tzabal ya it takes sometimes a lot of time to get done stuff=) 17:56:20 boris-42 yeap 17:56:32 tzabal okay hope to see your patches=) 17:56:38 boris-42 right now the context works without the extra utils module that i have created 17:56:53 tzabal nize 17:56:55 nice* 17:57:22 boris-42 the "bad" thing is that i have 3 patches under review, and in order to see that vm benchmarking actually works, you need to have all of them merged 17:57:36 tzabal nope you don't need 17:57:42 boris-42 how come? 17:57:45 tzabal just do next thing 17:57:51 tzabal put all patches in one branch 17:57:58 tzabal e.g. create one branch 17:58:14 tzabal and cherry-pick them with keeping proper order 17:58:21 tzabal and run git review -R 17:58:31 tzabal gerrit will set automactially dependencies 17:58:39 tzabal and everything will work=) 17:58:46 boris-42 hm ok i will check it 17:59:58 okay thank you guys for joining meeting 17:59:59 see you 18:00:02 #endmeeting