14:05:17 <andreykurilin> #startmeeting Rally 14:05:17 <openstack> Meeting started Mon Apr 10 14:05:17 2017 UTC and is due to finish in 60 minutes. The chair is andreykurilin. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:05:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:05:20 <openstack> The meeting name has been set to 'rally' 14:05:37 <rallydev-bot2> [From Gitter] andreykurilin : @tohin @astarove @shihai1991 14:05:47 <andreykurilin> hi all! 14:05:50 <hai_shi> Hi 14:05:52 <rallydev-bot2> [From Gitter] astarove : рш 14:05:55 <rallydev-bot2> [From Gitter] astarove : hi 14:05:59 <tovin07> hi 14:06:44 <andreykurilin> chenhb are you here?) 14:07:06 <andreykurilin> ok, let's start 14:07:17 <andreykurilin> #topic Status of Rally 0.9.1 14:07:35 <andreykurilin> Last week we decided to make a release of 0.9.1 14:07:50 <andreykurilin> which includes a bunch of bug-fixes 14:08:06 <andreykurilin> BUT, setuptools-scm release before that :) 14:08:12 <andreykurilin> it broke our CI 14:08:24 <andreykurilin> and we were blocked with that 14:08:57 <andreykurilin> I pushed a change to rally master with a workaround and our master branch is unblocked now 14:09:20 <andreykurilin> as for stable/0.9 branch, we need to wait for https://review.openstack.org/#/c/455234/ 14:10:19 <andreykurilin> After that we will be able to deliver 0.9.1 14:10:20 <chenhb> hi 14:10:25 <andreykurilin> hi 14:10:53 <andreykurilin> Also, today one more bug-fix was proposed to rally master - https://review.openstack.org/#/c/455173/ 14:10:57 <chenhb> i am late again 14:11:12 <andreykurilin> chenhb: np 14:12:01 <andreykurilin> If comments will be addressed and 455173 change will be merged before 0.9.1, I'm for backporting it to 0.9 branch too 14:12:26 <andreykurilin> but it is not so critical bug-fix to block releasing 0.9.1 14:12:43 <andreykurilin> that is all about 0.9.1 release 14:12:48 <andreykurilin> Any questions? 14:13:28 <chenhb> nothing from me 14:13:41 <hai_shi> no question from my side 14:13:56 <andreykurilin> ok 14:14:16 <andreykurilin> # topic Free discussion 14:14:26 <andreykurilin> Actually I do not have other topic to discuss 14:14:37 <andreykurilin> so "free-discussion" section is open 14:14:38 <andreykurilin> :) 14:15:49 <hai_shi> pls help review this patch https://review.openstack.org/#/c/431624/ ;) 14:16:20 <tovin07> andreykurilin: hi 14:17:31 <tovin07> recently, rcherrueau from inria asked you about Rally + OSprofiler 14:17:39 <tovin07> Do you remember that? :D 14:17:47 <andreykurilin> hai_shi: yeah... I remember about it. It is in my opened tabs. Actually, I dislike how is validation in embedded in CLI and not sure that we should save in database errors like "unable to open file". Today I want to experiment with validation and then will return to you patch 14:17:57 <andreykurilin> tovin07: yes, I remember about it 14:17:58 <andreykurilin> :) 14:18:36 <tovin07> so, do you guys have any plan to make it work? 14:19:20 <andreykurilin> tovin07, my reply to inria folks maybe was not accurate, so they thought that it will take too much human-resources which they do not have :( 14:19:27 <andreykurilin> actually, it should not be a hard task 14:20:01 <tovin07> currently, I see that there is no way to benchmark OpenStack with OSprofiler enabled for services with current initialization of OpenStack clients in Rally 14:20:21 <andreykurilin> it is true 14:20:42 <andreykurilin> but as I said, it should not be hard to implement it 14:20:51 <tovin07> for example, we init nova client with something like this: nova.Client(something but **kwargs) 14:20:58 <tovin07> yup 14:22:04 <tovin07> so, I think it’s good to do that soon ==> we can measure overhead of using OSprofiler all-the-time in production 14:23:16 <tovin07> I agree that it is not a hard to implement :D 14:23:53 <andreykurilin> tovin07: [implementation details] as far as I understand how osprofiler works, while osprofiler initialization it uses global variable, so initialization of one openstack client means initialzation fro all clients. That is why there is no need to transmit profiler_enable to nova client itself. 14:24:22 <andreykurilin> If you are interested in implementation, I'm ok to extend rally with osprofiler feauture 14:24:25 <andreykurilin> we can start from the spec 14:25:04 <tovin07> oh yes 14:25:10 <tovin07> I will follow it if I can 14:25:50 <tovin07> thank you andreykurilin 14:25:57 <tovin07> that’s all from me 14:26:33 <andreykurilin> Ok, I'll start a spec about it. Can you share your email(you can do it in direct messages to avoid logging)? I'll add you to thread with inrea folks when the spec will ready. 14:27:05 <tovin07> okay, I’ll send a dirrect message 14:27:09 <andreykurilin> Anything else to discuss? 14:28:14 <hai_shi> https://review.openstack.org/#/c/432138/6/rally/plugins/openstack/services/storage/block.py 14:28:21 <hai_shi> a small question 14:29:11 <hai_shi> if cinder_v1 have not update_volumes() function, it looks we can not add this update_volues() in BlockStorage 14:29:11 <chenhb> we call osprofile.trace while calling client? 14:30:18 <chenhb> update_volume_type? 14:30:26 <hai_shi> yep 14:31:18 <andreykurilin> If update_volume_type is a specific for Cinder V2, only Cinder V2 should include that method and scenario should have proper validator that checks that that cinder v2 is enabled. 14:32:13 <andreykurilin> chenhb: no we will just initialize osprofiler before each iteration and save trace id into iteration result then it will be displayed in reports as text area. 14:32:20 <andreykurilin> it is a first step for integration 14:32:47 <andreykurilin> then, it will be possible to embed osprofiler report into rally's report 14:33:10 <chenhb> got it 14:33:34 <hai_shi> fine 14:33:53 <tovin07> andreykurilin: (y) 14:34:00 <chenhb> so we can get a unify report 14:34:14 <andreykurilin> *we will able to get 14:34:19 <andreykurilin> now we cannot do it :) 14:36:18 <andreykurilin> anything else? 14:36:46 <hai_shi> no question 14:37:03 <chenhb> nothing from me 14:38:15 <andreykurilin> ok, let's finish 14:38:27 <andreykurilin> #endmeeting