09:02:06 <masahito> #startmeeting blazar
09:02:08 <openstack> Meeting started Tue Jun 12 09:02:06 2018 UTC and is due to finish in 60 minutes.  The chair is masahito. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:02:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:02:11 <openstack> The meeting name has been set to 'blazar'
09:02:19 <masahito> #topic RollCall
09:02:25 <hiro-kobayashi> o/
09:02:28 <priteau> o/
09:02:40 <tetsuro> o/
09:02:43 <masahito> hiro-kobayashi, priteau: hi
09:02:47 <masahito> tetsuro: hi
09:02:52 <masahito> today's agenda is
09:03:02 <masahito> 1. R-2 milestone
09:03:03 <masahito> 2. AOB
09:03:07 <masahito> anything else?
09:03:10 <masahito> less topics.
09:03:21 <hiro-kobayashi> I’m joining from mobile and will be temporally unavailable today.
09:03:52 <masahito> hiro-kobayashi: got it.
09:04:01 <masahito> #topic R-2 milestone
09:04:45 <masahito> As I mentioned last meeting, I pushed the patch for gate failure and merged it.
09:05:16 <priteau> Thanks!
09:05:24 <masahito> I tagged 2.0.0.0b2 tag later commit the patch merged.
09:05:24 <hiro-kobayashi> thank you for quickly solving the problem!
09:06:00 <masahito> I guess Blazar server of the tag works well.
09:07:03 <masahito> any comments? if nothing, move on to next.
09:07:30 <priteau> I submitted a patch for python-blazarclient which unfortunately didn't make it to the tagged release
09:07:40 <priteau> (for region support)
09:08:06 <priteau> Do you think we could release a new client on PyPI before Rocky?
09:08:39 <masahito> priteau: thanks the patch!
09:09:02 <masahito> yes. I plan to release a new python client 2.0.0 for Rocky.
09:09:55 <masahito> IMO, the tag numbering among blazar, blazar-nova, python-blazarclient, dashboard should be synchronized at major release.
09:10:21 <priteau> Do you think we could backport the patch to Queens and release a minor version?
09:10:49 <priteau> Currently Chameleon users have to install our fork on GitHub, which is not convenient
09:11:53 <masahito> meaning backport to stable/queens branch or backport to 1.x.y?
09:12:17 <priteau> both?
09:12:43 <priteau> Backport to stable/queens branch and tag 1.0.2
09:12:52 <priteau> Is that the correct process?
09:13:36 <masahito> IIRC, backport is only for bug fix or security issue in OpenStack
09:13:50 <priteau> It is a bug fix
09:15:25 <masahito> ah, Does Chameleon's client fork from stable/queens?
09:16:15 <priteau> Just from master. We only forked because the patch is still being reviewed.
09:16:54 <priteau> But this is a bug fix that should be included in the python-blazarclient version that is installed with pip.
09:17:19 <masahito> I see. I understand your situation.
09:18:28 <masahito> I already tagged 1.1.0.  Is 1.1.1 OK?
09:19:13 <priteau> Sure
09:20:16 <masahito> The client freeze is same time at R-3 milestone. Before 2.0.0 release, I'll put the 1.1.1.
09:21:32 <masahito> let't move on to next
09:21:38 <masahito> #topic AOB
09:21:49 <masahito> Does someone have topic to share/discuss?
09:22:05 <priteau> Thanks masahito! Sorry, my question was more AOB than Rocky-related in the end
09:22:45 <priteau> Nothing else from me
09:23:20 <masahito> I have an update
09:23:37 <masahito> I pushed a spec for resource-availability API https://review.openstack.org/#/c/574628/
09:24:05 <hiro-kobayashi> good news! thanks
09:24:15 <masahito> I noticed two points while I was writing the spec.
09:25:20 <masahito> 1. Should the API return or only pending and active reservation or terminated reservation as well?
09:26:40 <masahito> 2. The API response could be huge if there're lots of hosts or reservation.
09:27:16 <hiro-kobayashi> for 1, I think terminated lease info is not useful for users who want to create a lease
09:27:26 <masahito> In general, #2 can be solved once get and list API support paging feature.
09:28:36 <priteau> 1. This could be useful for admins who want to track past usage. Could be an option though?
09:28:46 <priteau> 2. Can we use pagination?
09:29:30 <hiro-kobayashi> current Lease List API and Host List API have the same problems  with #2
09:29:31 <masahito> right. So I could imagine adding query parameter, terminated=True/False, to handle the problem.
09:30:04 <hiro-kobayashi> make sense
09:30:25 <masahito> Blazar API doesn't support pagination mechanism now. If needed, we need to implement it.
09:31:27 <masahito> priteau: In your cloud, does listing all leases have performance issue now?
09:31:33 <priteau> We could probably release this feature without pagination at first
09:32:45 <masahito> Yes, so I wrote the issue in the performance impact section.
09:33:48 <masahito> Thank you for your feedback. I'll update the spec based on the discussion.
09:33:51 <priteau> masahito: Not so much. It takes just a few seconds to list all leases
09:34:02 <priteau> And that's including getting a token
09:34:48 <masahito> priteau: Good to hear. we could start the API without pagination.
09:34:51 <priteau> 2 seconds with a pre-allocated token
09:35:05 <masahito> That's from my side.
09:35:33 <priteau> That is for 1025 leases
09:36:11 <hiro-kobayashi> priteau: better than my expectation :-)
09:36:46 <hiro-kobayashi> my update is that I pushed all patches for policy-in-code.
09:37:18 <hiro-kobayashi> It’s already in review, thanks!
09:38:20 <priteau> Actually what takes more time to list is the hosts, almost 10 seconds for 370 hosts, but we have lots of extra capabilities
09:39:22 <priteau> It's on my TODO list to investigate if there is any unoptimised query to get all hosts
09:40:25 <masahito> That's a nice feedback. I didn't know the query issue.
09:42:31 <priteau> Thanks both for submitting spec and patches
09:42:59 <masahito> anything else? If nothing, let's finish early.a
09:44:32 <masahito> Okay, then thanks all!
09:44:55 <masahito> bye.
09:45:05 <masahito> #endmeeting