16:00:00 <priteau> #startmeeting blazar
16:00:00 <opendevmeet> Meeting started Thu Nov  4 16:00:00 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:00 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:00 <opendevmeet> The meeting name has been set to 'blazar'
16:00:07 <priteau> #topic Roll call
16:00:22 <priteau> Hello mppowers, right on time :)
16:00:31 <mppowers> hello priteau
16:02:08 <priteau> Is it just you today?
16:02:47 <mppowers> I'm expecting Jason to join too
16:04:32 <priteau> Let's wait a few minutes then
16:06:45 <diurnalist> oo7
16:06:51 <diurnalist> two-headed salute
16:06:52 <priteau> Hello diurnalist
16:08:27 <priteau> Before discussing Yoga release I have something about CI
16:08:31 <priteau> #topic CI status
16:09:01 <priteau> You may know that our CI jobs run blazar with devstack
16:09:24 <priteau> There was a change merged yesterday in devstack that broke our devstack jobs
16:09:36 <priteau> I've fixed it at https://review.opendev.org/c/openstack/blazar/+/816627
16:10:00 <priteau> Please review and approve if good
16:10:19 <mppowers> will do
16:10:42 <priteau> On a related topic, I thought someone mentioned in the past updating the blazar config for discovering services in keystone
16:10:58 <priteau> Currently it is done with os_auth_version, os_auth_host, os_auth_port, os_auth_prefix
16:11:05 <priteau> Maybe it was you diurnalist?
16:12:10 <diurnalist> i'm not sure -- what is the alternative to the above?
16:12:34 <diurnalist> just os_auth_url?
16:12:55 <priteau> Just the URL I suppose
16:13:20 <priteau> And making sure we are using modern auth libraries the way they are intended
16:14:24 <diurnalist> that seems to be what all the other services do, at least those that i've seen.
16:14:35 <diurnalist> it seems to be something that should probably be in oslo somewhere, but isn't
16:14:40 <diurnalist> i see this file being copied in several places https://github.com/openstack/ironic/blob/master/ironic/conf/auth.py
16:15:28 <priteau> Good to know
16:16:24 <priteau> I've added it to the etherpad
16:16:26 <diurnalist> other approach: https://opendev.org/openstack/nova/src/branch/master/nova/conf/cinder.py -- only supports *password type
16:16:36 <diurnalist> but yes. i'm sure we can steal something sane :)
16:18:12 <priteau> Let's discuss Yoga priorities now
16:18:16 <priteau> #topic Yoga release
16:19:39 <priteau> We have the following from our Etherpad
16:19:41 <priteau> * Default resource properties
16:19:46 <priteau> * Third-party resource type plugins
16:19:50 <priteau> * Blazar calendar
16:19:54 <priteau> * Remove RPC layer from DB interaction
16:20:14 <priteau> Do you have any update on the above?
16:20:34 <mppowers> I have been working on third-party plugins
16:21:55 <priteau> On updating the spec or the actual implementation?
16:22:00 <mppowers> There are more features that need to be addressed in the spec. I mentioned last time that in the current spec, there is no way to validate parameters to create and update resources.
16:22:32 <mppowers> Additionally, right now plugins use allocation_candidates() before creating allocations, which are then passed to enforcement filters, which the spec doesn't account for.
16:25:24 <mppowers> I've been working on an implementation as well, which brings some more questions. One of which is that both the API and manager agents need access to the plugins. Does it make sense to have a plugin agent? I believe neutron plugins run this way, but I may be misremembering
16:27:22 <priteau> I am not fully sure but I think the agents in Neutron are only used to implement some of the business logic of the plugin when it cannot be done in the main server
16:28:07 <diurnalist> agents are mainly used when some operations need to take place on a host that is NOT the neutron server
16:28:17 <diurnalist> e.g. creating veth pairs or linux bridges or something on a compute node
16:28:20 <priteau> Looking at Kolla images, there is an agent for VPNaaS, but not for FWaaS
16:29:31 <diurnalist> i don't think there is any strong benefit in having a plugin agent for this. the main thing would be if the plugin code is so intensive that it will bog down the manager thread, b/c the manager is involved in executing all the plugin events etc serially
16:29:54 <diurnalist> in the kolla case, both the api and manager containers will simply have the plugin code included, and may call it in different ways
16:30:16 <mppowers> Yes, that makes sense. I was misunderstanding the neutron situation, it seems it is used to implement what can't be done on the main server
16:30:31 <diurnalist> the api layer will invoke the plugin's API endpoints and DB accessors mainly, whilst the manager will invoke the lease lifecycle, allocation/dellocation subroutines
16:30:58 <priteau> Agree with diurnalist
16:31:09 <mppowers> Got it, that clears it up
16:31:15 <priteau> We don't want to have to manage another process if it's not necessary
16:32:21 <priteau> The api and manager code will be extended by importing the plugins from config
16:33:03 <mppowers> Yes
16:33:29 <mppowers> We also discussed using JSON fields in the DB to share tables between plugins.
16:33:55 <mppowers> This seems to work fine, I haven't tested if this is slower though.
16:35:22 <priteau> Just for the *_reservations tables?
16:35:39 <mppowers> It sounded like the thought was to share the *_reservations table at least, but I think we could share the main resources table, and *_allocations as well. This is my preference, as it reduces boilerplate and doesn't require plugins to manage DB migrations.
16:37:38 <priteau> We should check how much complexity this adds if we use it for all tables. I would prefer to have plugins handle migrations if it means simpler code.
16:41:27 <priteau> Do you think you could try converting an existing plugin to see the difference?
16:41:54 <mppowers> Yes, that is a good idea for this comparison
16:43:18 <priteau> I believe you also made progress on the RPC changes, how is that going?
16:43:57 <mppowers> I finished that up for Chameleon, and have yet to refactor it for the upstream change
16:44:42 <mppowers> I can submit that soon, it shouldn't take make to bring it over
16:46:45 <priteau> Great
16:47:14 <priteau> I see we have just over 10 minutes left, anything else we should discuss today?
16:48:28 <mppowers> That's it for me
16:48:58 <diurnalist> same - i was just reviewing the yoga milestones
16:50:07 <diurnalist> main issue i see is that we need to start merging some outstanding things soon b/c more will be incoming i imagine
16:50:22 <diurnalist> but this is not unique
16:51:35 <priteau> If you have merge conflict please update your patche
16:51:40 <priteau> patches
16:51:54 <priteau> Meanwhile I am going to look at CI again
16:51:58 <priteau> I think devstack broke us again
16:52:09 <priteau> Merge "Switch off creating a keystone admin endpoint by default"
16:53:16 <diurnalist> huzzah
16:55:31 <diurnalist> i'll work on my patches this afternoon
16:55:35 <diurnalist> nothing else from me
16:55:35 <priteau> Thank you
16:56:13 <priteau> Last bit of info, I got contacted by someone from IBM in India who wants to use Blazar
16:58:14 <priteau> That's all from me
16:59:13 <opendevreview> Pierre Riteau proposed openstack/blazar master: CI: Fix breakage following devstack changes  https://review.opendev.org/c/openstack/blazar/+/816627
16:59:23 <priteau> Hopefully this fixes CI jobs
16:59:31 <priteau> Thanks both, talk to you soon!
16:59:35 <priteau> #endmeeting