09:00:00 #startmeeting blazar 09:00:00 Meeting started Tue May 21 09:00:00 2019 UTC and is due to finish in 60 minutes. The chair is priteau. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:00:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:00:03 The meeting name has been set to 'blazar' 09:00:06 #topic Roll call 09:02:00 Hi tetsuro 09:02:10 Hi 09:03:07 I think masahito is at Kubecon today 09:03:10 Hi bertys_ 09:03:15 hi 09:03:30 o/ 09:04:01 Agenda for today: 09:04:06 JSON validation 09:04:08 Lease duration parameter 09:04:10 AOB 09:04:31 #topic JSON validation 09:06:09 Asmita Singh reached out to me asking if we supported adding a JSON schema validation layer, rather than manual validation scattered through the code 09:06:12 #link https://blueprints.launchpad.net/blazar/+spec/json-schema-validation 09:06:32 This seems like a good idea to me. I believe Keystone does it, maybe other services as well. 09:06:46 ++ good idea 09:06:52 +1 09:07:05 In particular she wants to fix https://bugs.launchpad.net/blazar/+bug/1803147 using JSON schema validation 09:07:07 Launchpad bug 1803147 in Blazar "Requirements containing non-ascii characters causes internal error" [Undecided,New] - Assigned to Asmita Singh (asmita2018) 09:08:17 For this particular bug, an alternative approach would be to supported non-ascii in requirements (extra capabilities, but also things like hypervisor_hostname gathered from Nova) 09:09:01 tetsuro: Do you know if operators in Japan like/want to use non-ascii characters for things like hostnames? 09:10:07 My feeling about this is that we should first fix the bug by restricting to ascii characters, and later we can relax the rule 09:10:25 restricting to ascii characters seems good to me 09:11:04 Great 09:11:35 Any other comments about this? 09:12:29 * tetsuro waves to asmita_ 09:12:38 Hi asmita_ 09:12:48 We were just discussing JSON schema validation 09:13:58 We support the plan of using JSON schema validation and restricting requirements to ascii characters 09:16:41 We can follow nova's restriction like https://github.com/openstack/nova/blob/fb14f24cc38a546f96adfc0446879716ca4c883e/nova/api/validation/parameter_types.py#L260-L268 09:17:16 +1 09:17:38 Related reading: Karbor API validation spec 09:17:41 #link https://review.opendev.org/#/c/523831/4/doc/source/specs/api-json-schema-validation.rst 09:18:56 asmita_: Do you feel comfortable writing a spec? You could base it on the Karbor spec and adapt it to Blazar 09:21:37 asmita_ may not be reading IRC. Let's continue with the agenda. 09:21:51 #topic Lease duration parameter 09:22:13 Something else that asmita_ is working on: create leases with lease duration instead of end date 09:22:16 https://bugs.launchpad.net/blazar/+bug/1717290 09:22:17 Launchpad bug 1717290 in Blazar "Create leases with lease duration instead of end date" [Wishlist,Confirmed] - Assigned to Pierre Riteau (priteau) 09:22:52 Originally I thought this would purely be a client-side fix 09:23:19 Add new parameter --duration which could be used instead of --end-date 09:23:52 Have the client calculate the end date internally and use it in the create lease request to the service 09:24:39 asmita_ pointed out an issue if start_date="now": https://bugs.launchpad.net/blazar/+bug/1717290/comments/2 09:24:40 Launchpad bug 1717290 in Blazar "Create leases with lease duration instead of end date" [Wishlist,Confirmed] - Assigned to Pierre Riteau (priteau) 09:25:56 In a perfect world this would only have a minor impact, making leases just a few seconds shorter than requested 09:26:13 However, consider the scenario where a client's clock is not synchronized 09:27:10 Because start_date=now would be computed by the server, but end_date would be computed by the client, we could end up with a lease that doesn't match at all the request duration 09:27:46 What asmita_ proposes is to add a lease duration parameter directly in the API, leveraging microversion support to add it without breaking compatibility 09:27:49 Any thoughts? 09:28:09 At a first look doing that in server side seems sane 09:28:57 doing that in client side is a bit weird assuming that now is calculated in the server side 09:29:44 I agree. I think it's a good change for Blazar. 09:30:16 More generally micro version would be useful to extend the API without breaking compatibility 09:31:40 Any other comments about this? 09:34:50 Moving on to AOB 09:34:52 #topic AOB 09:35:54 I've sent my summary of the discussion during the American IRC meeting 09:35:58 #link http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006392.html 09:36:42 I'd like to investigate this topic more during the Train cycle. 09:38:01 Any comment or other AOB items? 09:41:44 If not let's end the meeting here for this week. 09:42:42 Thanks for joining! 09:42:45 #endmeeting