17:01:21 #startmeeting Rally 17:01:22 Meeting started Tue Feb 11 17:01:21 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:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:26 The meeting name has been set to 'rally' 17:01:31 dkranz 17:01:55 boris-42_: hi 17:02:01 hughsaunders jorisroovers rediskin tzabal akscram stannie miarmak meeting 17:02:06 hi 17:02:23 tnurlygayanov as well meeting time 17:02:27 Hi 17:03:13 yes, I'm here ) 17:03:31 * boris-42_ typing todays topics 17:03:59 hi all 17:04:19 The document with idea was updated: https://docs.google.com/document/d/1bYdiFiIXKOR2OHeGq2fCm1956CTQVCY-BEZc-irmcxw/edit?usp=sharing 17:04:29 tnurlygayanov order pls=) 17:04:50 tnurlygayanov this is weekly meeting about all that happened with Rally and will happen=) 17:05:23 1. Atomic actions 17:05:32 2. Scenarion runner refactoring 17:05:40 3. Rally & Tempest intgeration 17:05:55 4. Multi node deployment & LXC engine 17:06:20 5. Updates about fixing couple of painful bugs 17:06:36 6. Updates in rally.conf 17:06:47 boris-42_: I don't have this wholel hour free so can you tell me when you want to discuss the tempest thing? 17:06:58 dkranz yep I will just ping you=) 17:07:18 boris-42_: But I have to be away part of the time. How about half-past? 17:07:31 okay try to make it happen=) 17:07:44 boris-42_: or just ping me and I'll be back soon 17:07:58 ok 17:08:11 7. VM benchmarks 17:08:16 so let's start 17:08:25 #topic 1. Atomic actions 17:08:33 Just short update that this work was finished 17:08:45 https://github.com/stackforge/rally/commit/b5d24fb3959e9467c4ef8e2924412b37795c6673 17:08:51 by this patch ^ 17:09:11 great patch :) 17:09:23 So now we are able to measure times of atomic actions, e.g. booting VM/deleting VM/snapshoting it and so on 17:09:38 hughsaunders yep great one=) 17:09:46 #topic 2. Scenarion runner refactoring 17:09:49 it not quite atomic =) 17:09:59 rediskin gg 17:10:12 so we done a lot of work around refactoring our scenario runner 17:10:30 First of all we improved generic cleanup and creation of users 17:10:48 now we are using context so cleanup is proceed always 17:11:02 and as well we removed spaghetti from code 17:11:22 Second thing is that now we are able to make plugins 17:11:31 to generate different load 17:11:34 cool 17:11:44 plugins? 17:11:48 do we have example? 17:11:49 rediskin https://github.com/stackforge/rally/tree/master/rally/benchmark/runners 17:11:57 oh 17:12:08 rediskin yep just add new your_load_generator.py 17:12:10 yea, it is easy to write own runner 17:12:23 There are couple of things that should be also refactored 17:12:32 ahh, but not really a plugin, as it has to be in-tree? 17:12:39 hughsaunders nope 17:12:48 hughsaunders Olga is working around plugin 17:12:51 hughsaunders system 17:13:01 hughsaunders for engines/serverprovider/benchmarks/loaders 17:13:11 https://review.openstack.org/#/c/72679/ 17:13:17 ^^ load extra modules 17:13:23 yep that one 17:13:45 could use entrypoints for that? 17:13:57 hughsaunders actually we are going to use rally.conf 17:14:16 hughsaunders I don't like steavedoor.. 17:14:26 ok 17:14:57 but unfortunately Olga chose wrong place 17:15:00 to put initialization 17:15:12 so the idea is that we have some place 17:15:17 in code 17:15:24 that will just load external modules 17:15:42 and our factories approach will fetch them=) 17:16:26 so next thing that we are going to refactor is this place 17:16:27 https://github.com/stackforge/rally/blob/master/rally/benchmark/engine.py#L134-L154 17:16:39 ^ we should put here validation of benchmarks inputs 17:16:50 i mean image_id/flavor_id and so on 17:17:14 And thing that is Mike working now 17:17:22 Support of procreated users 17:17:27 precreated* 17:17:48 Btw should we discuss it?) 17:18:14 maybe 17:18:40 #topic Support of benchmarking with procreated users 17:18:48 how about to create clients-container class 17:19:04 make this object oriented 17:19:27 but it actually endpoint 17:19:27 do not use all this dicrionaries and diffrerent clients laying around 17:20:02 ? 17:20:07 it endpoint, but client = make_client(endpoint['username'], endpoint['password']... 17:20:26 everywhere in the code crap like this ^^ 17:20:33 rediskin actually you are speaking about legacy code 17:20:43 rediskin until we add endpoint object 17:20:56 rediskin so this part is just not refactored 17:21:24 I will share with my thoughs 17:21:48 https://github.com/stackforge/rally/blob/master/rally/osclients.py#L38-L40 this should accept only object endpoint 17:22:03 and here return it https://github.com/stackforge/rally/blob/master/rally/osclients.py#L139 17:22:29 this things should be removed https://github.com/stackforge/rally/blob/master/rally/benchmark/runner.py#L33-L36 17:22:35 ^ they are legacy code =( 17:23:03 we should pass here https://github.com/stackforge/rally/blob/master/rally/benchmark/runner.py#L39 17:23:08 boris-42_: ok. I'm so looking forward for this refactoring =) 17:23:22 rediskin so we will refactor it step by step 17:23:37 rediskin it is hard to make all in one step 17:23:48 rediskin so we are refactoring it step by step 17:24:01 And I think that we made already big success 17:24:12 objects Endpoints and Client might be done first 17:24:32 rediskin I think that it could be done separately 17:24:42 boris-42_: just IMHO 17:24:43 ok 17:24:47 rediskin ok =) 17:24:56 does anybody have something to say?) 17:25:48 #4. Multi node deployment & LXC engine 17:25:56 #topic 4. Multi node deployment & LXC engine 17:26:03 lets discuss this before tempest stuff 17:26:16 hughsaunders rediskin could you share with updates 17:26:20 I thought it's done, but hughsaunders told it is not 17:26:26 lol 17:26:59 still some issues. need more tesing. 17:27:04 actually it all works for me 17:27:15 hughsaunders does it works for you?) 17:28:53 seems like hughsaunders is not here..=0 17:28:59 he showd me traceback, but it it not enough. need -d -v options on 17:29:19 anyway there is not much to do 17:29:21 okay so I hope we will get it soon merged 17:29:41 #topic 3. Rally & Tempest intgeration 17:29:45 dkranz around?) 17:29:53 boris-42_: Yes 17:29:54 miarmak could you share with your updates 17:30:04 yeah 17:30:15 https://review.openstack.org/#/c/70131 17:30:16 boris-42_: I have not been able to get lxc or multinode to work yet 17:30:22 patch is ready to review) 17:30:38 miarmak: all tests done? 17:30:42 miarmak ggg 17:30:45 rediskin: yes 17:30:49 =) 17:30:50 miarmak could you share in more words 17:30:55 miarmak what your patch makes 17:30:56 but I'm pretty much of the problem is me failing to configure correctly 17:30:58 yoday i have finished 17:31:36 it adds 2 cli commands: rally-manage tempest install to install the Tempest 17:31:50 and 'rally verify start' 17:31:59 to start verifiing process 17:32:26 we can use it with specificated deploy-id 17:32:35 or with default deploy id 17:32:59 miarmak so and it works with default deployed cloud with devstack? 17:33:17 yes 17:33:25 boris-42_: on devstack almost all tests passed =) 17:33:25 brilliant :) 17:33:27 but for now it starts smoke tests 17:33:30 haha 17:33:35 to simplifu first steps) 17:33:39 ahah 17:33:41 simplify* 17:33:53 okay 17:34:02 all tests pass very long) 17:34:05 miarmak: So devstack is presumably not the real target for rally 17:34:24 miarmak: I made a comment in the review of how I think this really needs to work 17:34:35 dkranz we agree with you 17:34:36 I gonna test it on cloud deployed bu fuel 17:34:41 dkranz but step by step 17:34:42 tomorrow.. 17:34:45 boris-42_: Of course 17:34:49 dkranz we would like to get now base in 17:35:00 boris-42_: I am not going to -1 :) 17:35:05 dkranz so we will be able to simultaneously work on different steps 17:35:22 dkranz e.g. sets of tests/ storing results/ better config generation 17:35:23 boris-42_: I just thought it would be helpful to understand what is important and missing 17:35:36 dkranz: yeah, thanks) 17:35:41 dkranz so let me try to describe what we are going to do and why=) 17:35:54 boris-42_: Because devstack is doing stuff that really needs to be in the configure tempest part for real cloud 17:36:08 dkranz we would like to use Rally against different cloud 17:36:27 dkranz with fake virtualization, or real big deployments, or private clouds 17:36:33 Sure 17:36:37 dkranz clouds that are deployed for developers with Rally 17:36:45 I get that 17:36:49 dkranz so we need mechanism that will understand 17:36:53 dkranz what we have in cloud 17:37:00 dkranz and what tests we can actually run 17:37:25 dkranz so after we merge this patch one of direction will be this 17:37:35 Great 17:37:43 dkranz when we finish this work 17:37:52 dkranz we will move this stuff to tempest 17:37:56 boris-42_: Please let me know if you disagree with anything in my comment 17:38:08 dkranz I mean smart generation of tempest conf 17:38:25 dkranz even more if you could help us with this work, it will be nice 17:38:47 dkranz because we don't have enough developers to cover all things… It takes a lot of time to make things simple=) 17:38:51 boris-42_: Yes, but what I was saying is that in order to do smart generation of tempest.conf you also have to create stuff that is expected, and is created by devstack 17:39:16 dkranz as a first step pre_creation of things could be done by hand 17:39:20 boris-42_: I know and hope we can help. But it will be easier if the initial version submitted to tempest has the form of what I described 17:39:25 dkranz and passed as extra data 17:39:31 boris-42_: It does not have to be complete. 17:40:38 dkranz so what's my idea is to split this work 17:40:41 boris-42_: Once an initial version is submitted to tempest I am sure other people will contribute 17:41:16 dkranz so you would like to start work inside tempest? 17:41:51 dkranz I am woried a bit the speed of accepting pathces in tempest is less then in Rally… cause it is not top priority 17:41:59 boris-42_: It might be some one else 17:42:09 boris-42_: I can promise this will get high attention 17:42:26 boris-42_: But I do understand your concern 17:42:43 boris-42_: I know there is a lot of interest and this will be reviewed quickly in tempest 17:42:50 dkranz I mean, the biggest problem is that we don't actually now exactly what we would like to get at the end 17:42:58 dkranz and it will be faster to make a lot of POC 17:43:08 dkranz and finial result put to tempest=) 17:43:13 boris-42_: In my comment I tried to describe what this would look like at the end 17:43:35 boris-42_: So it would be fine to push a POC to tempest 17:44:01 dkranz okay let's try 17:44:16 boris-42_: But please take note of my comment as a guideline 17:44:26 dkranz I understand that part 17:44:39 dkranz But it is too high level 17:44:52 boris-42_: And remember that there is already a poc in tempest which you will be replacing so make that clear 17:45:18 dkranz I mean pre_init of cloud is a bit dangerous thing for Rally 17:45:31 dkranz because there cases when you don't have admin access 17:45:39 there are* 17:45:49 so it should be independet 17:46:01 e.g. there are part the could prepare cloud for tempest 17:46:07 and returns some JSON 17:46:17 and there is a part that should accept this json and make config 17:46:28 boris-42_: I agree they are separate steps but users need to cause the right things to be there 17:46:40 boris-42_: WHether they do it themselves or tell some admin 17:46:53 boris-42_: They should be able to point the admin at a script that does the right thing 17:47:11 boris-42_: There could easily be two separate scripts 17:47:25 dkranz I hope that we will use python =) 17:47:41 boris-42_: But they are linked in that the "create tempest.conf" is depending on the other one that is creating stuff in the cloud 17:47:57 boris-42_: Why would we not use python? 17:48:06 boris-42_: The POC script in tempest does 17:48:12 ok nice 17:48:18 could you just give a link?) 17:48:37 boris-42_: tempest/tools/tempest_auto_config.py 17:48:52 boris-42_: It got totally broken when the sample conf format changed 17:48:55 dkranz and I let's continue this discussion in mailing list 17:49:09 boris-42_: That's what I was thinking 17:49:21 dkranz ok I will write some stuff =) 17:49:43 #topic 5. Updates about fixing couple of painful bugs 17:49:46 gust short 17:50:05 There was a bug that freezes Rally if OpenStack doesn't response 17:50:21 so sometimes it was really impossible to benchmark with Rally 17:50:34 We fixed it using timeouts in os-python-clients 17:50:59 And as well I fixed bug around issue gate-26-python that works forever 17:51:08 by refactoring mocks 17:51:25 #topic 6. Updates in rally.conf 17:51:35 hughsaunders could you share pls with updates?) 17:51:56 I removed lots of magic numbers from scenario utils, and replaced them with config options 17:52:19 probably more options than will ever be used, but at least they can be tweaked for different situations - eg short delays for LXC 17:52:59 hughsaunders that makes totally sense ^ 17:53:19 ok next topic 17:53:21 #topic 7. VM benchmarks 17:53:44 tnurlygayanov_ around? 17:53:50 tnurlygayanov_ your turn 17:54:54 Okay I will just say 17:55:13 that there is work around adding benchmarks that will measure CPU/MEM/IO of VMs 17:55:28 I think that they will be based on Hugh approach 17:55:52 but we should just think bit about output 17:55:55 yes 17:55:55 of these scenarios 17:56:03 to make it clean in Rally arch 17:56:16 yeah, at the moment the script is required to ouput json 17:56:28 hughsaunders yep but we should improve it a bit 17:56:29 but we could have some output processor in rally that normalises the json from each script 17:56:45 hughsaunders but not output data=) 17:57:05 and also need to support scenarios when we have several VMs with workload simulation 17:57:05 hughsaunders so we should think how to process CPU/MEM/IO usage in some common way 17:57:35 and run benchmmarks on other VMs 17:57:35 tnurlygayanov_ eg. IPerf?) 17:57:54 it should be interface like deploy engines/providers 17:58:09 rediskin we will use for such thing heat 17:58:18 rediskin to deploy VMs with HPCC 17:58:44 rediskin tnurlygayanov_ I will think about unifying and making some kind of plugable result processing 17:58:51 hm, not only iperf. We want to test performance of cloud under the wrokload 17:59:05 tnurlygayanov_ it will be really hard to implemnt 17:59:05 *workload 17:59:17 tnurlygayanov_ I was already thinking about it 17:59:23 tnurlygayanov_ I have a couple of ideas 17:59:29 tnurlygayanov_ but it won't be simple 17:59:35 tnurlygayanov_ btw are you familiar with Heat?) 17:59:43 yes 17:59:55 tnurlygayanov_ okay then let's make full things 17:59:56 it was the my first idea 18:00:10 tnurlygayanov_ yep but it will be a bit trickily to integrate it 18:00:11 but I think Rully can do it too 18:00:20 boris-42_: should probably wrap whole script execution, not just result processing, like in-instance-scenario 18:00:26 if we will not delte VMs after the script running 18:00:27 let's go to rally chat 18:00:31 howdy marekd 18:00:32 time is out 18:00:36 ok 18:00:37 stevemar: hey! 18:00:38 #endmeeting