16:00:19 <priteau> #startmeeting blazar
16:00:19 <opendevmeet> Meeting started Thu Dec  2 16:00:19 2021 UTC and is due to finish in 60 minutes.  The chair is priteau. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:19 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:19 <opendevmeet> The meeting name has been set to 'blazar'
16:00:25 <priteau> #topic Roll call
16:09:18 <priteau> Hello diurnalist
16:10:41 <diurnalist> hello!
16:11:16 <diurnalist> i'm seeing if mark has time to join
16:12:19 <mppowers> Hello
16:12:41 <priteau> Hello mppowers
16:13:21 <priteau> #topic Yoga priorities
16:13:41 <priteau> I believe I've seen some progress on external plugins implementation?
16:14:21 <mppowers> Yes. At the moment I've been writing it against Chameleon's fork, but it shouldn't be coupled much to our version.
16:14:27 <mppowers> The host plugin is working
16:15:02 <priteau> Nice!
16:15:27 <mppowers> It would be great to have some feedback on it if possible. I can reformat it and submit to opendev today.
16:15:55 <mppowers> Right now, it stores resource properties as JSON data, which adds minimal overhead.
16:16:49 <mppowers> Also, the spec outlines allocate() and deallocate() as the main functions needed to be implemented by the plugin, but I found this is boilerplate that wasn't needed for the host plugin. Though maybe I am missing something.
16:19:35 <diurnalist> mppowers: in my mind when writing the spec, 'allocate' means 'allocate to user', in this case meaning, create the aggregate and put the host in it
16:19:42 <diurnalist> deallocate would be removing the host / deleting the aggregate
16:20:01 <diurnalist> it's basically the "enact" process, which is different for each type of resource
16:20:04 <priteau> * ``allocate(resources, lease)``: given a resource selected by Blazar and a target lease, somehow make the resources available to the lease's user or project.
16:20:17 <priteau> That's my understanding to, it means doing the aggregate dance
16:21:07 <priteau> Actually we do the aggregate thing in on_start
16:21:33 <priteau> diurnalist: Did you have in mind something that runs at lease creation time or start time
16:21:34 <diurnalist> i think priteau and i benefit from being involved w/ the chameleon 'allocatable resources' paper when it comes to this terminology ;) -- blazar's db has "allocations" which marks which things should be allocated at start time
16:21:41 <diurnalist> start time
16:21:54 <diurnalist> lease create time just creates the entries in the allocations table, so the system knows who has what when
16:21:56 <priteau> ok, then yes, on_start/on_end is the current implementation
16:22:06 <priteau> and also any code that reallocates during active leases
16:24:24 <mppowers> how should the base class call allocate then? I was calling it when an allocation is inserted into the DB
16:25:41 <diurnalist> i think at lease create, the allocation logic probably is the same for all plugins and could be lifted out. that's the point where the allocations are created in the DB, and i think in the spec that's a single generic table
16:26:04 <mppowers> Yes
16:26:08 <diurnalist> the.allocate() / .deallocate() functions i would expect to be called at on_start
16:26:36 <diurnalist> so the lease manager runs on_start for a lease, and it finds all the plugins involved in the lease and invokes their allocate() function, passing the resources that were reserved
16:26:58 <diurnalist> similarly when the lease tears down, all the reservations invoke their plugin's deallocate()
16:27:51 <mppowers> Right now I implemented it in the host plugin overriding on_start, since there isn't much boilerplate there, and this was part of the interface in the spec
16:28:36 <mppowers> It overrides on_end as well, but calls the super class on_end which deletes the allocations
16:29:02 <priteau> The spec does say that on_start/on_end could be implemented by the plugin
16:32:12 <priteau> Maybe we can have a generic on_start, which could be replaced by the plugin if needed?
16:32:45 <diurnalist> yeah... i think really all on_start should do, likely, is call allocate... but maybe other plugins would for some reason do something else before or after
16:34:11 <mppowers> So `allocate` should be used there, and then also when a reservation update adds new resoruces
16:35:16 <priteau_> yes
16:37:18 <diurnalist> exactly
16:38:46 <mppowers> Should deallocate be called in the reservation update? In case a future resource type supports this
16:38:57 <mppowers> Along with being called in `on_end`
16:39:29 <priteau> A plugin could tell the base class whether it allows deallocate during active leases
16:40:27 <mppowers> I was thinking deallocate could handle that itself, since the lease is passed in with it
16:41:28 <priteau> It would avoid calling deallocate once for each resource only to get an exception back
16:42:46 <mppowers> The spec has all resources passed into allocate/deallocate at once
16:42:52 <priteau> ah, ok
16:43:09 <priteau> well, maybe an exception then
16:44:42 <mppowers> I mentioned this as a comment on the spec, but I also added validate create and validate update parameter functions
16:46:18 <mppowers> I think actually it's best to hold off on discussing that until I submit the patch
16:47:39 <priteau> Sounds good
16:50:21 <mppowers> That is all I have to say on the external plugins at the moment, I'll upload my change, and refactor allocate/deallocate based on our discussion
16:50:34 <diurnalist> :+1: !
16:51:02 <mppowers> Perhaps a metric of interest is the external host plugin is 375 lines, compared to 2000+ lines of code the native host plugin has
16:51:25 <diurnalist> \o/
16:51:51 <priteau> Nice
16:51:54 <diurnalist> that's certainly an improvement
16:52:47 <priteau> Anything else to discuss today?
16:53:07 <diurnalist> nope, i'm once again revisiting the context patch while we are discussing
16:53:29 <diurnalist> blazar's policy handling is a bit dated, had to re-learn this
16:54:23 <priteau> Yeah, I saw john left various comments
16:55:13 <mppowers> nothing else for me. I may get a chance to work on default resource properties, and there are a few open questions on the etherpad, I'll ask if I have any questions regarding it
16:56:13 <priteau> Thanks. I am nearing the end of various projects, so I'll aim to review some patches this month
16:56:46 <priteau> Let's wrap up
16:56:52 <priteau> #endmeeting