Thursday, 2021-11-04

opendevreviewPierre Riteau proposed openstack/blazar master: Add resource properties discovery API
opendevreviewPierre Riteau proposed openstack/blazar master: Use KEYSTONE_SERVICE_* instead of KEYSTONE_AUTH_*
priteau#startmeeting blazar16:00
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
opendevmeetThe meeting name has been set to 'blazar'16:00
priteau#topic Roll call16:00
priteauHello mppowers, right on time :)16:00
mppowershello priteau16:00
priteauIs it just you today?16:02
mppowersI'm expecting Jason to join too16:02
priteauLet's wait a few minutes then16:04
diurnalisttwo-headed salute16:06
priteauHello diurnalist16:06
priteauBefore discussing Yoga release I have something about CI16:08
priteau#topic CI status16:08
priteauYou may know that our CI jobs run blazar with devstack16:09
priteauThere was a change merged yesterday in devstack that broke our devstack jobs16:09
priteauI've fixed it at
priteauPlease review and approve if good16:10
mppowerswill do16:10
priteauOn a related topic, I thought someone mentioned in the past updating the blazar config for discovering services in keystone16:10
priteauCurrently it is done with os_auth_version, os_auth_host, os_auth_port, os_auth_prefix16:10
priteauMaybe it was you diurnalist?16:11
diurnalisti'm not sure -- what is the alternative to the above?16:12
diurnalistjust os_auth_url?16:12
priteauJust the URL I suppose16:12
priteauAnd making sure we are using modern auth libraries the way they are intended16:13
diurnalistthat seems to be what all the other services do, at least those that i've seen.16:14
diurnalistit seems to be something that should probably be in oslo somewhere, but isn't16:14
diurnalisti see this file being copied in several places
priteauGood to know16:15
priteauI've added it to the etherpad16:16
diurnalistother approach: -- only supports *password type16:16
diurnalistbut yes. i'm sure we can steal something sane :)16:16
priteauLet's discuss Yoga priorities now16:18
priteau#topic Yoga release16:18
priteauWe have the following from our Etherpad16:19
priteau* Default resource properties16:19
priteau* Third-party resource type plugins16:19
priteau* Blazar calendar16:19
priteau* Remove RPC layer from DB interaction16:19
priteauDo you have any update on the above?16:20
mppowersI have been working on third-party plugins16:20
priteauOn updating the spec or the actual implementation?16:21
mppowersThere 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
mppowersAdditionally, right now plugins use allocation_candidates() before creating allocations, which are then passed to enforcement filters, which the spec doesn't account for.16:22
mppowersI'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 misremembering16:25
priteauI 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 server16:27
diurnalistagents are mainly used when some operations need to take place on a host that is NOT the neutron server16:28
diurnaliste.g. creating veth pairs or linux bridges or something on a compute node16:28
priteauLooking at Kolla images, there is an agent for VPNaaS, but not for FWaaS16:28
diurnalisti 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 serially16:29
diurnalistin the kolla case, both the api and manager containers will simply have the plugin code included, and may call it in different ways16:29
mppowersYes, that makes sense. I was misunderstanding the neutron situation, it seems it is used to implement what can't be done on the main server16:30
diurnalistthe api layer will invoke the plugin's API endpoints and DB accessors mainly, whilst the manager will invoke the lease lifecycle, allocation/dellocation subroutines16:30
priteauAgree with diurnalist16:30
mppowersGot it, that clears it up16:31
priteauWe don't want to have to manage another process if it's not necessary16:31
priteauThe api and manager code will be extended by importing the plugins from config16:32
mppowersWe also discussed using JSON fields in the DB to share tables between plugins.16:33
mppowersThis seems to work fine, I haven't tested if this is slower though.16:33
priteauJust for the *_reservations tables?16:35
mppowersIt 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:35
priteauWe 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:37
priteauDo you think you could try converting an existing plugin to see the difference?16:41
mppowersYes, that is a good idea for this comparison16:41
priteauI believe you also made progress on the RPC changes, how is that going?16:43
mppowersI finished that up for Chameleon, and have yet to refactor it for the upstream change16:43
mppowersI can submit that soon, it shouldn't take make to bring it over16:44
priteauI see we have just over 10 minutes left, anything else we should discuss today?16:47
mppowersThat's it for me16:48
diurnalistsame - i was just reviewing the yoga milestones16:48
diurnalistmain issue i see is that we need to start merging some outstanding things soon b/c more will be incoming i imagine16:50
diurnalistbut this is not unique16:50
priteauIf you have merge conflict please update your patche16:51
priteauMeanwhile I am going to look at CI again16:51
priteauI think devstack broke us again16:51
priteauMerge "Switch off creating a keystone admin endpoint by default"16:52
diurnalisti'll work on my patches this afternoon16:55
diurnalistnothing else from me16:55
priteauThank you16:55
priteauLast bit of info, I got contacted by someone from IBM in India who wants to use Blazar16:56
priteauThat's all from me16:58
opendevreviewPierre Riteau proposed openstack/blazar master: CI: Fix breakage following devstack changes
priteauHopefully this fixes CI jobs16:59
priteauThanks both, talk to you soon!16:59
opendevmeetMeeting ended Thu Nov  4 16:59:35 2021 UTC.  Information about MeetBot at . (v 0.1.4)16:59
opendevmeetMinutes (text):
mppowersThank you too!16:59
opendevreviewJason Anderson proposed openstack/blazar master: Use built-in oslo context de/serialization

Generated by 2.17.2 by Marius Gedminas - find it at!