16:58:26 #startmeeting Designate 16:58:26 Meeting started Wed May 24 16:58:26 2017 UTC and is due to finish in 60 minutes. The chair is mugsie|alt. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:58:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:58:29 The meeting name has been set to 'designate' 16:58:34 #topic Roll Call 16:58:53 o/ 16:58:56 whos here for the designate meeting? 16:59:06 trungnv_: o/ 16:59:16 yep. 16:59:24 I think it is just us 16:59:47 just you and me today? 16:59:48 timsim is away today, so we will people a minute or two more 17:00:28 sure. 17:01:08 #topic Open Discussion 17:01:22 Nothing really on the agenda - trungnv_ do you have anything 17:01:40 Yep. I have 17:01:44 great 17:02:20 we have update somethings in our PS about our solution for OVO https://review.openstack.org/#/c/464971/ 17:02:31 i saw 17:02:36 now, we can validate most of fields in OVO 17:02:59 just for zones, right? 17:03:04 yep. 17:03:34 but we meet some issue with currently code. such as tenant_id 17:03:56 OK - what is the issue? 17:04:33 https://bugs.launchpad.net/designate/+bug/1693286 this launchpad mention about validate for tenant_id field 17:04:34 Launchpad bug 1693286 in Designate "Schema Validator don't validate with "tenant_id" in Zone object " [Undecided,In progress] - Assigned to Nguyen Van Trung (trungnv) 17:05:00 currently code assign tenant_id is string 17:05:31 that mean we can put everything under string and most of them passed schema validator 17:05:53 yes - this is an old issue - we have always had it as a string 17:06:17 (due to hp public cloud using ints for tenant id's in the old days) 17:06:32 I thinks It should be int or uuid 17:06:47 maybe, but that would be a separate change 17:07:04 it could also be considered an API change 17:07:27 yep. I am understand. 17:08:02 I saw a lot of functional test doesn't validate via Schema validator. 17:08:22 no 17:08:23 such as my PS: https://review.openstack.org/#/c/467649/ 17:09:18 we want to get to a point where storage calls .validate() on all objects 17:09:28 but, ouir unit tests use invalid data 17:10:00 yes. I saw that on UT. 17:10:27 so, what we should do, is add a .validate() to storage and see what breaks 17:10:34 but I do not have time right now 17:12:32 How do you think my suggestion to change into validate inside functional test? 17:12:53 before storage. 17:13:37 its a good start 17:13:47 and it will find issues alright 17:13:57 It will help us validate at fields in OVO fields before going to storage. 17:14:08 that patch is not to functional testing - it is a unit test of sorts 17:14:47 my PS? 17:15:11 yeah 17:15:26 yep. 17:16:00 did you review my PS? How do you think about this PS? 17:16:09 I still think that OVO is going to hit issues - recordsets are going to be an interesting challenge 17:16:37 https://review.openstack.org/#/c/467649 ? 17:16:59 it is the wrong place to be relying on validation - we should be doing this by default 17:17:31 yeah. my co-worker working on recordset issue and you just meger his PS. 17:18:08 (we should be addig validation to the Zone.from_dict() method 17:18:42 yep. agree with your advice. 17:19:48 OK - is there anything else to discuss ? 17:20:12 with tenant_id, in OVO we can validate via uuid and accept to int and uuid. 17:20:34 no - it needs to stay as a string 17:21:04 thus we will separate our solution against currently code. 17:21:17 yep. sure. 17:21:41 type = string and format = uuid 17:22:26 no format 17:22:29 we can put 'int' or 'uuid' with type string. 17:22:34 it should be a free form string 17:22:53 https://github.com/openstack/designate/blob/master/designate/objects/zone.py#L32-L35 17:23:06 I see. 17:23:35 if it's string then we cannot validate for them. 17:23:46 the migration to OVO should only be OVO, and things like this should be discussed later. I don't think it makes a difference really - that info is provided by keystone, so we have to trust it 17:24:16 sure - its the same as descriptions - we cannot validate them 17:24:25 yep. thanks. 17:24:53 Agree. thanks. 17:25:03 Anything else? 17:25:17 no. thanks 17:25:21 cool 17:25:28 #endmeeting