14:01:34 #startmeeting Rally 14:01:35 Meeting started Mon Apr 18 14:01:34 2016 UTC and is due to finish in 60 minutes. The chair is andreykurilin__. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:39 The meeting name has been set to 'rally' 14:01:56 0/ 14:02:02 hi 14:02:47 hello 14:03:29 \o 14:03:36 let's wait a bit 14:03:57 boris-42 stpierre: ping 14:04:09 * stpierre is here 14:05:08 good 14:05:15 ok, let's start 14:05:39 good news - we have an agenda for today:) 14:05:42 #link https://wiki.openstack.org/wiki/Meetings/Rally 14:05:54 #topic [andreykurilin] Release 0.4.0 14:06:21 This topic was planned as happy news :) 14:06:53 but we have problems with cutting release 14:06:58 the process was changed 14:07:12 and now we unable to cut release easier 14:07:20 we need to do it via openstack/releases repo 14:08:00 we're under big tent, so bi bro's watching 14:08:04 ) 14:08:17 I push a change for new release, but gates queue is too big (250+ changes) 14:08:19 #link https://review.openstack.org/#/c/307139/ 14:08:19 andreykurilin__: patch 307139 - releases - Release Rally 0.4.0 14:08:48 andreykurilin__, gate is almost broken now... 14:08:54 yeah:( 14:09:12 so cores please do not merge anything before new release come 14:09:15 andreykurilin__: hi 14:09:21 boris-42: hi 14:09:40 PS: release notes were merged 14:09:55 andreykurilin__: so now we should make that patch? 14:10:05 andreykurilin__: instead pushing tag by hands? 14:10:11 boris-42: yes 14:10:21 andreykurilin__: heh=( no freedome 14:10:27 yeah 14:10:50 release notes for new release 14:10:51 #ling http://rally.readthedocs.org/en/latest/release_notes/archive/v0.4.0.html 14:11:37 ok, let move to the next topic) 14:11:49 [andreykurilin] Planning for next release 14:11:52 #topic [andreykurilin] Planning for next release 14:12:04 hi 14:12:22 as we discussed several meeting ago, next release should implement wrappers/utils refactoring spec 14:12:52 #link https://github.com/openstack/rally/blob/master/doc/specs/in-progress/refactor_scenario_utils.rst 14:13:27 lets discuss our steps 14:13:30 and policy 14:14:01 proposal - let's include trends report (https://review.openstack.org/#/c/276721/) to plans for next release 14:14:01 amaretskiy: patch 276721 - rally - [Reports][CLI][CI] Introduce Trends report 14:14:20 I propose to not stop merging fix to partial wrappers/utils until work for this partial service is not started 14:14:51 amaretskiy: I believe andreykurilin__ was askin' bout wrappers stuff policy )) 14:14:57 When we will start implement services and who will do this? 14:15:07 ikhudoshyn: +1 :) 14:15:23 rvasilets: I think boris-42 wanted to implement the base stuff:) 14:16:17 Ok boris-42 will implement base and who will move glance, nova, murano... etc to service base?) 14:16:28 i can do this work but boris-42 told me that there are some tasks waiting for me (I do not know what exact tasks) 14:16:46 Will we split this work to the whole team? 14:16:48 I'm pretty busy as well 14:16:56 andreykurilin__: +2 14:17:07 Or this will be done by one person7 14:17:07 iirc we had discussed boris-42 doing the base and keystone, and just getting that into the next release 14:17:11 andreykurilin__: I want to stop merging those things as well and just start working on the base 14:17:23 stpierre: that's like minial goal 14:17:24 and waiting for the subsequent release to try to get other services done 14:17:53 stpierre: nope I was talking about having at least keystone done in next release 14:18:01 ok boris will move keystone I can help with some other part 14:18:15 boris-42: why we can't merge small fixes to glance wrapper for example if we don't start work on it? 14:18:49 andreykurilin__++ 14:19:09 let's block patches only for keystone stuff now 14:19:11 because they are unneeded 14:19:18 rvasilets: why? 14:19:25 stpierre: andreykurilin__ is it so hard to do the services base? 14:19:35 it makes sense to declare each wrapper deprecated once we have an actual WIP to replace it, but given how busy everyone has just declared themselves i think it's awfully optimistic to pretend that we'll get this all done quickly enough 14:19:50 andreykurilin__, because we will rewrite then in the nearest month 14:19:55 boris-42: i dunno, the spec took well over 6 months to get merged, i don't expect anything else to be any quicker 14:20:09 rvasilets: and in the mean time there are real actual bugs that people are dealing with 14:20:15 stpierre: the spec wasn't not on priority 14:20:16 rvasilets: we will use existing code as a base for new services 14:20:27 stpierre: and nobody reviewed it 14:20:33 rvasilets: so we can improve it and fix issues 14:20:45 we have a lot of bugs and they are not critical as others 14:21:03 we can't just declare the wrappers dead code and ignore any issues with them without having a replacement 14:21:12 stpierre: +1 14:21:52 why not?) 14:21:54 once we even have a replacement WIP i absolutely think we should block changes to the wrapper, but we haven't even started work on the base class, let alone the individual services 14:22:05 because there are real actual bugs that currently exist and are affecting people 14:22:07 stpierre: agree on this 14:22:09 there are scenarios that we can't run 14:22:27 that's not an abstract "we", that's us, cisco -- we have important internal work that is blocked on actual rally bugs 14:22:39 that we have a fix in review for 14:23:05 ok, it looks like we have an agreement 14:23:08 :) 14:23:16 andreykurilin__: stpierre ok let's merge small fixes 14:23:21 let's be sure to communicate well when work on a new service starts 14:23:23 nice 14:23:28 so we can block further changes to that wrapper 14:23:32 andreykurilin__: stpierre however what I don't like is porting old scenarios to wrapper and adding more work on this 14:24:22 honestly, i think that should serve as a motivator to get us to write the services faster 14:24:31 :) 14:25:24 but in general i concur, let's keep any fixes as small as is practical 14:26:22 Can we move to the next topic? 14:26:32 since we have an agreement 14:26:54 ok 14:26:59 #topic [amaretskiy] Let's revive DB refactoring spec and give it high priority, since we can not effectively switch to new task format without this spec 14:27:08 #link https://review.openstack.org/#/c/167060/ 14:27:08 andreykurilin__: patch 167060 - rally - [spec] Making DB scalable and flexible enough 14:28:21 we have to do a lot of changes in database schema - adopt it for new task results format, add extra data about workloads and cloud and so on 14:28:34 #link https://github.com/openstack/rally/blob/master/doc/specs/in-progress/new_rally_input_task_format.rst 14:28:50 it's time to revive spec https://review.openstack.org/#/c/167060/ 14:28:50 amaretskiy: patch 167060 - rally - [spec] Making DB scalable and flexible enough 14:29:05 we can do all these changes well without spec 14:29:07 I'm working on it 14:29:19 I propose to plan this patch for next rlease 14:29:33 ikhudoshyn: great! 14:29:41 new patchset would be available in a next couple days 14:30:50 yet i'd like to warn that it's implementation may take pretty much long 14:31:15 It is sad 14:31:34 since predicted schema change gonna be huge I plan to implement it piece by piece 14:31:46 let's add a high priority to this patch and review new patch sets without delay 14:32:14 any comments? 14:32:14 at least let's set hi prio to the spec)) 14:32:26 sure :) 14:32:51 amaretskiy: ikhudoshyn seems like that we have more priority tasks than people 14:32:52 ok 14:33:00 boris-42: heh 14:33:09 what about trying to push this release services bases and just pause everything else 14:33:19 hm... 14:33:41 agree 14:33:45 big agree 14:33:46 I don't think that trends or new db are rising problem (it's like constant amount of work to it now or in one release) 14:33:49 ok I'm fine with that 14:33:56 perfect 14:34:00 however we are getting every day new plugins and using more and more wrappers 14:34:05 stpierre: you should be happy:) 14:34:31 heh 14:34:43 boris-42: ok, I can work on nova service 14:35:01 me on glance for example 14:35:23 stpierre: do you want to take some service to yourself? :) 14:35:31 I'll try to finish the spec and would probably need some time off in the nearest future 14:35:46 amaretskiy: and you? 14:35:55 stpierre, you can take glance if you like) 14:35:57 seems like we should prioritize glance, cinder, keystone, and nova-net/neutron, since those are the wrappers we have 14:35:59 i'll do glance 14:36:09 i can take network service 14:36:17 i'll take cinder then... 14:36:20 amaretskiy: Could you take neutone/n-net ? 14:36:44 since you was an author of old wrapper:) 14:37:04 andreykurilin__: network service? sure 14:37:58 thanks 14:38:03 and could handle heat also 14:38:24 i'll try to use help of heat core 14:38:32 rvasilets: I think redixin could do it 14:38:38 but he is not here now 14:39:04 there is vm 14:39:14 maybe redixin will do vm?) 14:39:18 ok, boris-42: we are waiting for base classes ;) 14:39:24 andreykurilin__: ok 14:39:27 year) 14:39:35 andreykurilin__: I will try to manage to get this soon 14:39:38 *yeah 14:39:47 boris-42: thanks 14:40:05 anything else for this topic? 14:40:28 I think no) 14:41:15 zuul queue contains 355 patches... 14:41:16 ;( 14:41:25 #topic [yanyanhu] Basic support for Senlin service in Rally: 14:41:35 #link https://review.openstack.org/298109 14:41:38 hello, everyone :) 14:41:44 o/ 14:41:46 #link https://review.openstack.org/307170 14:41:54 hi, I'm from Senlin team 14:41:59 #link https://review.openstack.org/307050 14:42:05 we hope to use Rally to benchmark Senlin service 14:42:11 \o/ 14:42:22 so we proposed a patch to add basic support for senlin into rally 14:42:33 https://review.openstack.org/298109 14:42:50 this one 14:43:14 and I just proposed patch to infra to add gate job 14:43:30 here: https://review.openstack.org/298109 14:43:54 and local plugins and jobs in Senlin repo: https://review.openstack.org/307170 14:44:37 but I think the following two ones rely on the basic senlin support patch to work :) 14:44:54 Yanyanhu: why do you want to store all your plugin at the local repo? 14:45:13 we hope to contribute them to rally's repo 14:45:24 nice 14:45:36 but not sure whether we should do that :) so I temporarily keep them in senlin's reop 14:45:38 repo 14:45:49 so I'm ok with mergin support of senlinclient to our repo now 14:46:32 thanks andreykurilin__, with that patch being merged, more code for senlin plugin can be added :) 14:46:35 and also jobs 14:46:59 Yanyanhu: btw, clients entity in rally is a pluggable too, so you able to store it in local repo too ;) 14:47:04 andreykurilin__: yep I don't think that we should block this 14:47:16 andreykurilin__: I think that we need just to help to get CI job done for this 14:47:25 I see. 14:47:30 Yanyanhu: can you add your experimental job to our project too? 14:47:36 will we create experimental job at Rally7 14:47:37 sure 14:47:39 I will 14:47:44 nice 14:47:51 nice 14:48:02 =) 14:48:10 thanks you guys :) 14:48:16 so as soon as we got new release we will be able to merge your base patch 14:48:26 got it 14:48:37 I think it will done in a day(zuul is dead) 14:48:56 yes... the gate is broken I think 14:49:03 anything else? 14:49:16 for this topic?) 14:49:20 yes 14:49:25 тщ 14:49:26 no 14:49:29 ok 14:49:36 #topic [andreykurilin] Make Glance V2 the default version 14:49:54 as far as I know, Glance V1 will deprecated soon 14:50:23 I think we should switch to use V2 by default 14:51:16 Last week we merged several patches for compatibility with it (thanks to stpierre ylobankov) 14:51:50 i'd like some extra eyes on the image creation code in rally for glance v2 14:52:17 AFAICT glance v2 is really and truly horrible and the code is correct, but before we make it the default i'd just like to double- or triple-check that we aren't doing anything stupid 14:52:24 or at least, no more stupid than we need to be to deal with glance v2 14:52:29 :) 14:52:39 ok 14:52:57 #link https://github.com/openstack/rally/blob/master/rally/plugins/openstack/wrappers/glance.py#L151-L196 14:53:25 if that checks out, then +1 to making glance v2 the default 14:53:27 a bit of magic 14:53:28 lol 14:53:29 I could ask in glance chat will we do everything correct 14:53:44 ok, let's switch to glance v2 as soon as stpierre propose patch for it :D 14:53:51 )) 14:54:20 andreykurilin__: sounds good :) 14:54:29 perfect 14:54:59 Do we have more topics? 14:55:14 yes I want to ask review to https://review.openstack.org/#/c/283180/ 14:55:14 rvasilets: patch 283180 - rally - [Spec] Rally Task Validation refactoring 14:55:24 nop 14:55:28 :D 14:55:35 =((( 14:55:40 crying 14:55:47 rvasilets: please, no... 14:55:58 I'll try to review it this week 14:56:12 anything else? 14:56:19 So please review it. And after services we will be able to refactor validators 14:56:34 nothing else 14:56:55 https://review.openstack.org/#/c/242329/ actually is waiting for boris-42 eyes 14:56:55 ikhudoshyn: patch 242329 - rally - Transform DB layer to return dicts, not SQLAlchemy... 14:57:09 boris-42: ^ 14:57:12 we need you 14:57:14 others are welcome as well 14:57:26 andreykurilin__: ok 14:57:44 ok, let's finish 14:57:47 thank you all 14:57:54 #endmeeting