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