| opendevreview | Pierre Riteau proposed openstack/blazar master: Add resource properties discovery API https://review.opendev.org/c/openstack/blazar/+/810298 | 07:57 |
|---|---|---|
| opendevreview | Pierre Riteau proposed openstack/blazar master: Use KEYSTONE_SERVICE_* instead of KEYSTONE_AUTH_* https://review.opendev.org/c/openstack/blazar/+/816627 | 09:38 |
| priteau | #startmeeting blazar | 16: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 |
| 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 mppowers, right on time :) | 16:00 |
| mppowers | hello priteau | 16:00 |
| priteau | Is it just you today? | 16:02 |
| mppowers | I'm expecting Jason to join too | 16:02 |
| priteau | Let's wait a few minutes then | 16:04 |
| diurnalist | oo7 | 16:06 |
| diurnalist | two-headed salute | 16:06 |
| priteau | Hello diurnalist | 16:06 |
| priteau | Before discussing Yoga release I have something about CI | 16:08 |
| priteau | #topic CI status | 16:08 |
| priteau | You may know that our CI jobs run blazar with devstack | 16:09 |
| priteau | There was a change merged yesterday in devstack that broke our devstack jobs | 16:09 |
| priteau | I've fixed it at https://review.opendev.org/c/openstack/blazar/+/816627 | 16:09 |
| priteau | Please review and approve if good | 16:10 |
| mppowers | will do | 16:10 |
| priteau | On a related topic, I thought someone mentioned in the past updating the blazar config for discovering services in keystone | 16:10 |
| priteau | Currently it is done with os_auth_version, os_auth_host, os_auth_port, os_auth_prefix | 16:10 |
| priteau | Maybe it was you diurnalist? | 16:11 |
| diurnalist | i'm not sure -- what is the alternative to the above? | 16:12 |
| diurnalist | just os_auth_url? | 16:12 |
| priteau | Just the URL I suppose | 16:12 |
| priteau | And making sure we are using modern auth libraries the way they are intended | 16:13 |
| diurnalist | that seems to be what all the other services do, at least those that i've seen. | 16:14 |
| diurnalist | it seems to be something that should probably be in oslo somewhere, but isn't | 16:14 |
| diurnalist | i see this file being copied in several places https://github.com/openstack/ironic/blob/master/ironic/conf/auth.py | 16:14 |
| priteau | Good to know | 16:15 |
| priteau | I've added it to the etherpad | 16:16 |
| diurnalist | other approach: https://opendev.org/openstack/nova/src/branch/master/nova/conf/cinder.py -- only supports *password type | 16:16 |
| diurnalist | but yes. i'm sure we can steal something sane :) | 16:16 |
| priteau | Let's discuss Yoga priorities now | 16:18 |
| priteau | #topic Yoga release | 16:18 |
| priteau | We have the following from our Etherpad | 16:19 |
| priteau | * Default resource properties | 16:19 |
| priteau | * Third-party resource type plugins | 16:19 |
| priteau | * Blazar calendar | 16:19 |
| priteau | * Remove RPC layer from DB interaction | 16:19 |
| priteau | Do you have any update on the above? | 16:20 |
| mppowers | I have been working on third-party plugins | 16:20 |
| priteau | On updating the spec or the actual implementation? | 16:21 |
| 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 |
| 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:22 |
| 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:25 |
| 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:27 |
| diurnalist | agents are mainly used when some operations need to take place on a host that is NOT the neutron server | 16:28 |
| diurnalist | e.g. creating veth pairs or linux bridges or something on a compute node | 16:28 |
| priteau | Looking at Kolla images, there is an agent for VPNaaS, but not for FWaaS | 16:28 |
| 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 |
| 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:29 |
| 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 |
| 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 |
| priteau | Agree with diurnalist | 16:30 |
| mppowers | Got it, that clears it up | 16:31 |
| priteau | We don't want to have to manage another process if it's not necessary | 16:31 |
| priteau | The api and manager code will be extended by importing the plugins from config | 16:32 |
| mppowers | Yes | 16:33 |
| mppowers | We also discussed using JSON fields in the DB to share tables between plugins. | 16:33 |
| mppowers | This seems to work fine, I haven't tested if this is slower though. | 16:33 |
| priteau | Just for the *_reservations tables? | 16:35 |
| 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:35 |
| 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:37 |
| priteau | Do you think you could try converting an existing plugin to see the difference? | 16:41 |
| mppowers | Yes, that is a good idea for this comparison | 16:41 |
| priteau | I believe you also made progress on the RPC changes, how is that going? | 16:43 |
| mppowers | I finished that up for Chameleon, and have yet to refactor it for the upstream change | 16:43 |
| mppowers | I can submit that soon, it shouldn't take make to bring it over | 16:44 |
| priteau | Great | 16:46 |
| priteau | I see we have just over 10 minutes left, anything else we should discuss today? | 16:47 |
| mppowers | That's it for me | 16:48 |
| diurnalist | same - i was just reviewing the yoga milestones | 16:48 |
| 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 |
| diurnalist | but this is not unique | 16:50 |
| priteau | If you have merge conflict please update your patche | 16:51 |
| priteau | patches | 16:51 |
| priteau | Meanwhile I am going to look at CI again | 16:51 |
| priteau | I think devstack broke us again | 16:51 |
| priteau | Merge "Switch off creating a keystone admin endpoint by default" | 16:52 |
| diurnalist | huzzah | 16:53 |
| diurnalist | i'll work on my patches this afternoon | 16:55 |
| diurnalist | nothing else from me | 16:55 |
| priteau | Thank you | 16:55 |
| priteau | Last bit of info, I got contacted by someone from IBM in India who wants to use Blazar | 16:56 |
| priteau | That's all from me | 16:58 |
| opendevreview | Pierre Riteau proposed openstack/blazar master: CI: Fix breakage following devstack changes https://review.opendev.org/c/openstack/blazar/+/816627 | 16:59 |
| priteau | Hopefully this fixes CI jobs | 16:59 |
| priteau | Thanks both, talk to you soon! | 16:59 |
| priteau | #endmeeting | 16:59 |
| opendevmeet | Meeting ended Thu Nov 4 16:59:35 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/blazar/2021/blazar.2021-11-04-16.00.html | 16:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/blazar/2021/blazar.2021-11-04-16.00.txt | 16:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/blazar/2021/blazar.2021-11-04-16.00.log.html | 16:59 |
| mppowers | Thank you too! | 16:59 |
| opendevreview | Jason Anderson proposed openstack/blazar master: Use built-in oslo context de/serialization https://review.opendev.org/c/openstack/blazar/+/731586 | 17:13 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!