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