14:06:09 #startmeeting Rally 14:06:11 Meeting started Mon Dec 12 14:06:09 2016 UTC and is due to finish in 60 minutes. The chair is andreykurilin. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:06:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:06:15 The meeting name has been set to 'rally' 14:06:59 ok 14:07:09 let's start from regular topic 14:07:15 #topic status of gates 14:07:41 last several weeks we had problems with keystone, heat, nova-net and etc 14:08:05 Currently, all failures should be resolved 14:08:35 hi 14:08:49 hi 14:09:18 so, if you see any new problems with gates, please let me know about them 14:09:47 #topic keystone v3 14:10:08 another one great news, we merged latest patch for keystone v3 support 14:10:25 all scenarios are ported to support both keystone v2 and v3 14:10:41 andreykurilin: great to hear 14:11:02 :) 14:12:38 there is only one case is not supported by rally yet - domain-scope. I heard that some guys have problems with it(maybe it is wrong use case). In case of domain-scope they have empty service catalog and we need to switch to project-scope for obtaining it 14:13:09 stevemar: is it valid use case? ^ 14:13:45 andreykurilin: i believe thats valid 14:14:00 ok, so we need to implement this "switch" 14:14:30 But in general, we support domain-scope if service catalog is not empty :) 14:15:00 ok 14:15:06 let's move to the next topic 14:15:23 #topic Nova-Network is dead. Long live Neutron! 14:16:03 all our jobs don't have nova-net at all 14:16:12 it was disabled by nova team 14:16:34 and it will be removed soon 14:16:46 including nova-net to networking service? 14:17:29 In future yes. 14:17:45 got it. 14:17:52 But now we need that our NetworkService( aka NetworkWrapper) suppor tit 14:17:53 *it 14:18:16 since we have a lot of users with old openstack releases 14:18:29 I do not know when we will able to remove support of it :( 14:18:45 ok. my job's process is slowly :( 14:19:05 I heard about guys who uses latest rally to test openstack grizzly 14:19:15 hai_shi: do you need any help? 14:20:45 maybe I clould commit the patch firstly(just little work). you could review my jobs. 14:21:04 and give me some advise:) 14:21:19 ok, feel free to post any "work-in-progress" patches and we will try to help you 14:21:47 ok. thanks a million. 14:21:55 #topic get rid of validation_results field in database 14:22:04 ok. it is a topic to discuss 14:22:06 :) 14:22:57 currently we have special status "validation_failed" with additional data 14:23:30 for this additional data we have separate db field 14:24:04 https://github.com/openstack/rally/blob/master/rally/common/db/sqlalchemy/models.py#L184 14:24:31 it is good information to store 14:24:37 but it is not "unique" 14:25:22 we use sla_results to store some other information - information about aborting, about runtime errors, about failures in contexts 14:25:55 Maybe we should extend validation_results to something bigger? 14:26:09 amaretskiy ^ 14:27:04 also, I prefer to move it to subtask level 14:27:04 andreykurilin no ideas right now 14:27:37 astudenov ^ 14:27:46 Our subtask is available? 14:28:05 I think we need to leave something for validation result in task level 14:29:04 and add something for error messages in subtask level 14:29:44 chenhb__: astudenov is working on its support. he can share his status:) 14:30:03 astudenov: I dislike validation result at task level 14:30:04 hola 14:30:10 hola 14:30:31 Hi 14:30:45 subtask exists in db at least :) I have a path adding some basic usage of subtask https://review.openstack.org/#/c/395554/ 14:31:00 astudenov: I want to have ability to launch all valid subtasks and workloads, even if one workload is invalid 14:31:19 so it makes thanks to store validation results per subtask or even per workload 14:31:43 also, it would be nice to display this validation results(in case of failure) in our html-reports 14:32:35 lets try 14:32:45 nice 14:32:58 ok, let's move to the next topic 14:33:09 #topic get rid of enums in db 14:33:13 Thanks,@astudenov 14:33:21 why we need them at all?) 14:33:40 I don't see any use cases for them 14:34:49 this is just validation at db level 14:35:33 but we do not change them regularly 14:35:37 I mean statuses 14:35:53 so we should miss the change when we add new status 14:36:28 Also, we do not have places where we transmit status strings without usage rally.consts module 14:36:44 so, imo, we do not need that validation at db level 14:37:09 it requires additional migrations each time when we want extend statuses 14:37:59 reasonable 14:38:04 at first sign 14:38:16 :) 14:38:39 ok, let think more about it and make final decision at the next meeting 14:38:56 #topic Open discussion 14:39:30 we finished fixing gates and I switched to reviewing patches... We have a long queue now 14:39:57 Any topics to discuss? 14:40:38 Nope 14:41:58 Nothing from me 14:42:07 ok 14:42:14 bye 14:42:19 #endmeeting