16:01:00 <priteau> #startmeeting blazar
16:01:00 <openstack> Meeting started Thu Jun 20 16:01:00 2019 UTC and is due to finish in 60 minutes.  The chair is priteau. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:03 <openstack> The meeting name has been set to 'blazar'
16:01:13 <priteau> #topic Roll call
16:05:33 <priteau> Hi jakecoll
16:05:45 <jakecoll> Hello
16:06:18 <priteau> Hi diurnalist
16:06:41 <diurnalist> hello
16:06:55 <priteau> I am afraid I wasn't very creative and set the same agenda as last time
16:07:00 <priteau> 1. Reservation usage policy enforcement
16:07:06 <priteau> 2. Upstream contributions
16:07:10 <priteau> 3. AOB
16:07:24 <priteau> Unless there is something else you would like to discuss?
16:08:03 <priteau> #topic Reservation usage policy enforcement
16:08:34 <priteau> #link https://review.opendev.org/#/c/663394/
16:09:15 <priteau> I haven't worked more on this in the past weeks, been busy elsewhere. Did anyone had the chance to look at the early draft?
16:09:33 <diurnalist> i admit i also didn't look, i will leave some comments now though
16:10:11 <priteau> Thanks diurnalist
16:10:20 <jakecoll> same
16:13:15 <priteau> diurnalist: did you mean now as in right now, or later today after this call
16:13:33 <diurnalist> i'm looking at it now in another tab :)
16:13:39 <diurnalist> but some comments likely won't make it until after the call
16:14:17 <priteau> There's not much to discuss on the agenda so you can take a few minutes to read the spec
16:15:46 <diurnalist> the draft looks good and fits my understanding of the solution we've discussed
16:15:59 <diurnalist> the obvious questions (already identified as work items) are what kind of interface it should have
16:16:51 <priteau> Indeed, that's the next task
16:17:19 <diurnalist> there are a few approaches i guess. do you have preferences currently?
16:18:17 <priteau> We could start with something modelled after the function calls that Chameleon's fork makes to the usage enforcement module
16:18:50 <priteau> But really I would like to keep it as simple as possible, even if limited, and iterate
16:20:57 <priteau> For protocol transport, HTTP and JSON based
16:21:18 <diurnalist> in chameleon we just have `check_lease_duration` and `check_usage_against_allocation`
16:22:06 <diurnalist> so i believe the total bits of information are: lease start/end date, user/project id for lease, and then the ids of all the resources tied to the lease
16:22:38 <priteau> Actually there is also calls specifically for lease updates: check_usage_against_allocation_pre_update & check_usage_against_allocation_post_update
16:23:25 <diurnalist> why is it 2 functions?
16:24:11 <priteau> I knew that at one point :-)
16:24:49 <priteau> IIRC, pre_update does a check just based on new values provided by the user
16:25:32 <priteau> post_update also gets the newly allocated resources, does a check based on that too, and updates the enforcement DB
16:26:21 <priteau> It could probably be the same function with optional parameters
16:26:36 <priteau> I think that's what is done with check_usage_against_allocation
16:27:44 <priteau> It might be useful to have the old lease values during lease-update, unless we expect the external service to query back Blazar to get them
16:28:04 <diurnalist> yes, it looks like pre_update sort of looks more at extending a lease, whereas post-update is aware of allocation changes.
16:28:52 <diurnalist> the question of how much context the external service needs is interesting. is it enough to just have the 'new' lease representation?
16:29:18 <diurnalist> so, either a new lease, or a proposed updated version of a lease
16:29:44 <priteau> If you want to do something like allow prolongation only in the last 48 hours, you need to know the old lease values as well
16:30:11 <diurnalist> ah, yes
16:30:16 <diurnalist> then perhaps old_lease, new_lease
16:30:23 <diurnalist> where old_lease could be null
16:31:03 <priteau> same with allocations, you might need the old ones and the new to compute how much more/less resources was requested
16:31:15 <priteau> which is why we have both in check_usage_against_allocation_post_update
16:31:22 <diurnalist> yes, i guess when i said "lease" i meant "lease and all reservation/allocations"
16:31:43 <diurnalist> what this doesn't allow: policies based on # of current leases. whether this is important in practice to support is debatable IMO
16:32:09 <priteau> The external service could still query Blazar before making its decision
16:32:27 * diurnalist puts hands over ears
16:32:39 <diurnalist> yes, the implementor has that option :)
16:33:02 <priteau> As long as Blazar isn't blocking waiting for the external service to reply...
16:33:34 <diurnalist> priteau: probably we do want to call out to this thing on lease terminate as well. a policy service wouldn't really care about stopping this but it might be important to know.
16:33:46 <priteau> Right
16:34:12 <diurnalist> the other way to handle this would be for the policy service to also listen for notifications
16:34:38 <diurnalist> it's a tricky line to draw
16:35:10 <priteau> It is more elegant, but does it make sense to set this up for just one operation?
16:35:13 <diurnalist> those are my initial thoughts. i do think pushing this out to another service is really the right thing to do, given all of the above special cases
16:36:14 <priteau> Thanks, that's helpful
16:36:34 <priteau> Let's move on?
16:37:36 <priteau> #topic Upstream contributions
16:39:00 <priteau> Anything new with upstream Blazar patches?
16:40:14 <jakecoll> There still isn't an update reservation implementation for floating ips. I'm working on that now.
16:40:34 <priteau> Masahito said on Tuesday that he had started working on it
16:40:52 <priteau> You may want to check with him?
16:41:57 <jakecoll> Is the best place to reach him on IRC?
16:42:30 <priteau> Yes, if you live on the other side of the earth :)
16:42:35 <priteau> He's in Japan
16:42:44 <priteau> I'll share his email with you
16:43:26 <jakecoll> thanks
16:45:02 <priteau> Nothing happened on your heat patch?
16:45:38 <jakecoll> Nope. Zane suggested the whole advanced reservation be implemented in blazar itself.
16:46:00 <jakecoll> Two of them are your patches, but there hasn't been any movement.
16:47:16 <priteau> Thanks for the update.
16:47:44 <priteau> I sent you and masahito an email
16:48:03 <priteau> #topic AOB
16:48:09 <priteau> Anything else to discuss?
16:49:25 <priteau> If not we can end early for today. Thanks for joining guys!
16:49:25 <jakecoll> :+1
16:49:50 <priteau> #endmeeting