| priteau | #startmeeting blazar | 16:00 |
|---|---|---|
| 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'blazar' | 16:00 |
| priteau | #topic Roll call | 16:00 |
| priteau | Hello diurnalist | 16:09 |
| diurnalist | hello! | 16:10 |
| diurnalist | i'm seeing if mark has time to join | 16:11 |
| mppowers | Hello | 16:12 |
| priteau | Hello mppowers | 16:12 |
| priteau | #topic Yoga priorities | 16:13 |
| priteau | I believe I've seen some progress on external plugins implementation? | 16:13 |
| 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 |
| mppowers | The host plugin is working | 16:14 |
| priteau | Nice! | 16:15 |
| mppowers | It would be great to have some feedback on it if possible. I can reformat it and submit to opendev today. | 16:15 |
| mppowers | Right now, it stores resource properties as JSON data, which adds minimal overhead. | 16:15 |
| 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:16 |
| 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 |
| diurnalist | deallocate would be removing the host / deleting the aggregate | 16:19 |
| diurnalist | it's basically the "enact" process, which is different for each type of resource | 16:20 |
| 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 |
| priteau | That's my understanding to, it means doing the aggregate dance | 16:20 |
| priteau | Actually we do the aggregate thing in on_start | 16:21 |
| priteau | diurnalist: Did you have in mind something that runs at lease creation time or start time | 16:21 |
| 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 |
| diurnalist | start time | 16:21 |
| diurnalist | lease create time just creates the entries in the allocations table, so the system knows who has what when | 16:21 |
| priteau | ok, then yes, on_start/on_end is the current implementation | 16:21 |
| priteau | and also any code that reallocates during active leases | 16:22 |
| mppowers | how should the base class call allocate then? I was calling it when an allocation is inserted into the DB | 16:24 |
| 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:25 |
| mppowers | Yes | 16:26 |
| diurnalist | the.allocate() / .deallocate() functions i would expect to be called at on_start | 16:26 |
| 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 |
| diurnalist | similarly when the lease tears down, all the reservations invoke their plugin's deallocate() | 16:26 |
| 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:27 |
| mppowers | It overrides on_end as well, but calls the super class on_end which deletes the allocations | 16:28 |
| priteau | The spec does say that on_start/on_end could be implemented by the plugin | 16:29 |
| priteau | Maybe we can have a generic on_start, which could be replaced by the plugin if needed? | 16:32 |
| 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:32 |
| mppowers | So `allocate` should be used there, and then also when a reservation update adds new resoruces | 16:34 |
| priteau_ | yes | 16:35 |
| diurnalist | exactly | 16:37 |
| *** priteau is now known as Guest7388 | 16:38 | |
| *** priteau_ is now known as priteau | 16:38 | |
| mppowers | Should deallocate be called in the reservation update? In case a future resource type supports this | 16:38 |
| mppowers | Along with being called in `on_end` | 16:38 |
| priteau | A plugin could tell the base class whether it allows deallocate during active leases | 16:39 |
| mppowers | I was thinking deallocate could handle that itself, since the lease is passed in with it | 16:40 |
| priteau | It would avoid calling deallocate once for each resource only to get an exception back | 16:41 |
| mppowers | The spec has all resources passed into allocate/deallocate at once | 16:42 |
| priteau | ah, ok | 16:42 |
| priteau | well, maybe an exception then | 16:43 |
| mppowers | I mentioned this as a comment on the spec, but I also added validate create and validate update parameter functions | 16:44 |
| mppowers | I think actually it's best to hold off on discussing that until I submit the patch | 16:46 |
| priteau | Sounds good | 16:47 |
| 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 |
| diurnalist | :+1: ! | 16:50 |
| 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 |
| diurnalist | \o/ | 16:51 |
| priteau | Nice | 16:51 |
| diurnalist | that's certainly an improvement | 16:51 |
| priteau | Anything else to discuss today? | 16:52 |
| diurnalist | nope, i'm once again revisiting the context patch while we are discussing | 16:53 |
| diurnalist | blazar's policy handling is a bit dated, had to re-learn this | 16:53 |
| priteau | Yeah, I saw john left various comments | 16:54 |
| 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:55 |
| priteau | Thanks. I am nearing the end of various projects, so I'll aim to review some patches this month | 16:56 |
| priteau | Let's wrap up | 16:56 |
| priteau | #endmeeting | 16:56 |
| opendevmeet | Meeting ended Thu Dec 2 16:56:52 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:56 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/blazar/2021/blazar.2021-12-02-16.00.html | 16:56 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/blazar/2021/blazar.2021-12-02-16.00.txt | 16:56 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/blazar/2021/blazar.2021-12-02-16.00.log.html | 16:56 |
| mppowers | Thanks for the help. Talk to you later! | 16:57 |
| opendevreview | Jason Anderson proposed openstack/blazar master: Use built-in oslo context de/serialization https://review.opendev.org/c/openstack/blazar/+/731586 | 17:10 |
| opendevreview | Jason Anderson proposed openstack/blazar master: Use built-in oslo context de/serialization https://review.opendev.org/c/openstack/blazar/+/731586 | 17:52 |
| opendevreview | Mark Powers proposed openstack/blazar master: Add resource properties discovery API https://review.opendev.org/c/openstack/blazar/+/810298 | 19:47 |
| opendevreview | Mark Powers proposed openstack/blazar master: Remove RPC layer from API https://review.opendev.org/c/openstack/blazar/+/820255 | 19:47 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!