openstack-discuss search results for query "canceled meeting"

openstack-discuss@lists.openstack.org

895 messages

[manila] Summary of the Victoria Cycle Project Technical Gathering

by Goutham Pacha Ravi

Hello Zorillas and other friendly animals of the OpenStack universe, The manila project community met virtually between 1st June and 5th June and discussed project plans for the Victoria cycle. The detailed meeting notes are in [1] and the recordings were published [2]. A short summary of the discussions and the action items is below: *== Ussuri Retrospective ==* - We lauded the work that Vida Haririan and Jason Grosso have put into making bug tracking and triaging a whole lot easier, and systematic. At the beginning of the cycle, we had roughly 250 bugs, and this was brought down to under 130 by the end of the cycle. As a community, we acted upon many multi-release bugs and made backports as appropriate. We've now automated the expiry of invalid and incomplete bugs thereby reducing noise. Vida's our current Bug Czar, and is interested in mentoring anyone that wants to contribute to this role. Please reach out to her if you're interested. - We also had two successful Outreachy internships (Soledad Kuczala/solkz, Maari Tamm/maaritamm) thanks to Outreachy, their sponsors, mentors (Sofia Enriquez/enriquetaso, Victoria Martinez de la Cruz/vkmc) and the OpenStack Foundation; and a successful Google Summer of Code internship (Robert Vasek/gman0) - many thanks to the mentor (Tomas Smetana/tsmetana), Google, Red Hat and other sponsoring organizations. The team learned a lot, and vkmc encouraged all of us to consider submitting a mentorship application for upcoming cycles and increase our involvement. Through the interns' collective efforts in Train and Ussuri development cycles: - manila CSI driver was built [3] - manilaclient now provides a plugin to the OpenStackClient - manila-ui has support for newer microversions of the manila API and, - manila documentation has gotten a whole lot better! - We made good core team improvements and want to continue to mentor new contributors to become maintainers, and folks felt their PTL was doing a good job (:D) - The community loved the idea of PTL docs (thanks Kendall Nelson/diablo_rojo) - a lot of tribal knowledge was documented for the first time! - We felt that "low-hanging-fruit" bugs [4] were lingering too long in some cases, and must have a "resolve-by" date. These are farmed for new contributors, and if they turn out to be annoying issues, the team may set a resolve-by date and close them out. However, we'll continue to make a concerted effort to triage "bugs that are tolerable" with nice-to-have fixes and keep them handy for anyone looking to make an initial contribution. *== Optimize query speed for share snapshots ==* Haixin (haixin) discovered that not all APIs are taking advantage of filtering and pagination via sqlalchemy. There's a list of APIs that he's compiled and would like to work on them; the team agreed that this is a valuable bug fix; and can be made available to Ussuri when the fixes land in this cycle. *== TC Goals for Victoria cycle ==* - We discussed a long list of items that were proposed for inclusion as TC goals [5]. The TC has officially picked two of them for this cycle [6]. - For gating manila project repos, we make heavy use of "legacy" DSVM jobs. We hadn't invested time and effort in converting these jobs in the past cycles; however, we have a plan [7] and have started porting jobs to "native" zuulv3 format already in the manila-tempest-plugin repository. Once these jobs are complete there, we'll switch over to using them on the main branch of manila. Older branches will get opportunistic updates beyond milestone-2. - Luigi Toscano (tosky) joined us for this discussion and asked us for the status of third party CI systems. The team hasn't mandated that third party CI systems move their testing to zuulv3-native in this cycle. However, the OpenStack community may drop support for devstack-gate in the Victoria release, and making things work with it will get harder - so it's strongly encouraged that third party vendor systems that are using the community testing infrastructure projects: zuul, nodepool and devstack-gate move away from devstack-gate in this cycle. An option to adopt Zuulv3 in third party CI systems could be via the Software Factory project [8]. The RDO community runs some third party jobs and votes on OpenStack upstream projects - so they've created a wealth of jobs and documentation that can be of help. Maintainers of this project hang out in #softwarefactory on FreeNode. - All of the new zuulv3 style tempest jobs inherit from devstack-tempest from the tempest repository, and changing the node-set in the parent would affect all our jobs as well - this would make the transition to Ubuntu 20.04 LTS/Focal Fossa easier. *== Secure default policies and granular policies ==* - Raildo Mascena (raildo) joined us and presented an overview this cross-community effort [9] - Manila has many assumptions of what project roles should be - and over time, we seem to have blended the idea of a deployer administrator and a project administrator - so there are inconsistencies when, even to perform project level administration, one needs excessive permissions across the cloud. This is undesirable - so, a precursor to supporting the new scoped policies from Keystone seems to be to: - eliminate hard coded checks in the code requiring an "admin" role and switch to performing policy checks - eliminating empty defaults which allow anyone to execute an API - manila has very few of these - supporting a "reader" role with the APIs - We can then re-calibrate the defaults to ensure a separation between cross-tenant administration (system scope) and per-tenant administration - following the work in oslo.policy and in keystone - gouthamr will be leading this in the Victoria cycle - other contributors are welcome to join this effort! *== Oslo.privsep and other manila TODOs ==* - We discussed another cross-community effort around transitioning all sudo actions from rootwrap to privsep - Currently no one in the manila team has the bandwidth to investigate and commit to this effort, so we're happy to ask for help! - If you are interested, please join us during one of the team meetings or start submitting patches and we can discuss with you via code reviews. - The team also compiled a list of backlog items in an etherpad [10]. These are great areas for new project contributors to help manila, so please get in touch with us if you would like to work on any of these items *== OSC Status/Completion ==* - Victoria Martinez de la Cruz and Maari Tamm compiled the status for the completion of the OSC plugin work in manilaclient [11] - There's still a lot of ground to cover to get complete parity with the manila command line client, and we need contributors - Maari Tamm (maaritamm) will continue to work on this as time permits. Spyros Trigazis (strigazi) and his team at CERN are interested to work on this as well. Thank you, Maari and Spyros! - On Friday, we were joined by Artem Goncharov (gtema) to discuss the issue of "common commands" - quotas, services, availability zones, limits are common concepts that apply to other projects as well - OSC has support to show you these resources for compute, volume and networking - gtema suggested we should approach this via the OpenStackSDK rather than the plugin since plugins are slow as is, and adding anything more to that interface is not desirable at the moment - There's planned work in the OpenStackClient project to work on the plugin loading mechanisms to make things faster *== Graduation of Experimental Features ==* - Last cycle Carlos Eduardo (carloss) committed the work to graduate Share Groups APIs from their "Experimental API" status - We have two more features behind experimental APIs: share replication and share migration - This cycle, carloss will work on graduating the share replication APIs to fully supported - Generic Share Migration still needs some work, but we've fleshed out the API and it has stayed pretty constant in the past few releases - we might consider graduating the API for share migration in the Wallaby release. *== CephFS Updates ==* - Victoria (vkmc) took us through the updates planned for the Victoria cycle (heh) - Currently all dsvm/tempest based testing in OpenStack (cinder, nova, manila) is happening on ceph luminous and older releases (hammer and jewel) - Victoria has a patch up [12] to update the ceph cluster to using Nautilus by default - This patch moves to using the packages built by the ceph community via their shaman build system [13] - shaman does not support building nautilus on CentOS 8, or on Ubuntu Xenial - so if older branches of the projects are tested with Ubuntu Xenial, we'll fall back to testing with Luminous - The Manila CephFS driver wants to take advantage of the "ceph-mgr" daemon in the Nautilus release and beyond - Maintaining support for "ceph-mgr" and "ceph-volume" clients in the driver will make things messy - so, the manila driver will not support Ceph versions prior to Nautilus in the Victoria cycle - If you're using manila with cephfs, please upgrade your ceph clusters to Nautilus or newer - We're not opposed to supporting versions prior to nautilus, but the community members cannot invest in maintaining support for these older releases of ceph for future releases of manila - With the ceph-mgr interface, we intend to support asynchronous create-share-from-snapshot with manila - Ramana Raja (rraja) provided us an update regarding the ceph-mgr and upcoming support for nfs-ganesha interactions via that interface (ceph pacific release) - Currently there's a ganesha interface driver in manila, and that can switch to using the ceph-mgr interface - Manila provides an "ensure_shares" mechanism to migrate share export locations when the NAS host changes - We'll need to work on that if we want to make it easier to switch ganesha hosts. - We also briefly discussed supporting manage and unmanage operations with the ceph drivers - that should greatly assist day 2 operations, and migration of shared file systems from the native cephfs protocol to nfs and vice-versa. *== Add/Delete/Update security services for in-use share networks ==* - Douglas Viroel (dviroel) discussed a change to manila to support share server modifications wrt security services - Security services are project visible and tenant driven - however, share servers are hidden away from project users by virtue of default policy - dviroel's idea is that, If a share network has multiple share servers, the share manager will enumerate and communicate with all share servers on the share network to update a security service - We need to make sure that all conflicting operations (such as creating new shares, changing access rules on existing shares) are fenced off when a share server security service is being updated - dviroel has a spec that he's working on - and would like feedback on his proposal [14] *== Create shares with two (or more) subnets ==* - dviroel proposed a design allowing a share network having multiple subnets in a given AZ (currently you can have utmost 1 subnet in an AZ for a given share network) - Allowing multiple NICs on a share server may be something most drivers can easily support - This change is identical to the one to update security services on existing share networks - in terms of user experience and expectations - The use cases here include dual IP support, share server network maintenance and migration, simultaneous access from disparate subnets - Feedback from this discussion was to treat this as two separate concerns for easier implementation - Supporting multiple subnets per AZ per share network - Supporting adding/removing subnets to/from a share network that is in-use - Currently, there's no way to modify an in-use share server - so adding that would be a precursor to allowing modification of share networks/subnets and security services *== Technical Committee Tags ==* - In the last cycle, the manila team worked with OpenStack VMT to perform a vulnerability disclosure and coordinate a fix across distributions that included manila. - The experience was valuable in gaining control of our own "coresec" team that had gone wayward on launchpad; and learning about VMT - Jeremy Stanley (fungi) and other members of the VMT have been supportive of having manila apply to the "vulnerability-managed" tag. We'll follow up on this soon - While we're on the subject, with Ghanshyam Mann (gmann) in the room, we discussed other potential tags that we can assert as the project team: - "supports-accessible-upgrade" - manila allows control plane upgrade without disrupting the accessibility of shares, snapshots, ACLs, groups, replicas, share servers, networks and all other resources [15] - "supports-api-interoperability" - manila's API is microversioned and we have hard tests that enforce backwards compatibility [16] - We discussed "tc:approved-release" tag a bit, and felt that we needed to bring it up in a TC meeting, and we did that with Ghanshyam's help - The view from the manila team is that we'd like to eliminate any misconception that the project is not mature, or ready for production use or that it isn't a part of a "core OpenStack" - At the TC meeting, Thierry Carrez (ttx), Graham Hayes (mugsie) and the others provided historic context for this tag: the tag was for a section from the OpenStack foundation bylaws that states that the Technical Committee must define what an approved release is (Article 4, section 4.1 (b) i) [17] - The TC's view was that this tag has outlived its purpose and core-vs-non-core discussions have happened a lot of times. Dropping this tag might require speaking with the Foundation and amending the bylaws and exploring what this implies. It's a good effort to get started on though. - For the moment, The TC was not opposed to the manila team requesting this change to include manila in the list of projects in "tc-approved-release". *== Share and share size quotas/limits per share server ==* - carloss shared his design for allowing share server limits being enforced via the quotas system where administrators could define project share server quotas that the share manager would enforce these by provisioning new servers when the quotas are hit - the quotas system is ill suited for this sort of enforcement, specially given that the share manager allows the share drivers to control what share server can be used to provision a share - it's possible to look for a global solution, like the one proposed for the generic driver in [18], or implement this at a backend level agnostic to the rest of manila - another reason not to use quotas is that manila may eventually do away with this home grown quota system in favor of oslo.limit enforced via keystone - another alternative to doing this is via share types, but, this really fits as a per-share-network limit rather than a global one *== Optimize the quota processing logic for 'manage share' ==* - haixin ran into a bug where quota operations are incorrectly applied for during a share import/manage operation such that a failed manage operation would cause incorrect quota deductions - we discussed possible solutions for the bug, but mostly, this can definitely be fixed - he opened a bug for this [19] *== Share server migration ==* - dviroel presented his thoughts around this new feature [20] which would be helpful for day 2 operations - he suggested that we should not provide for a generic mechanism to perform this migration, given that users would not need it especially if it is not 100% reliable - though there is a generic framework for provisioning share servers, it is only being used by the reference driver (Generic driver) and the Windows SMB driver - shooting for a generic solution would require us to solve SPOF issues that we currently have with the reference driver - and there is not much investment in doing so - dviroel's solution involves a multi-step migration, however relying on the share drivers to perform atomic migration of all the shares - you can think of this wrt the Generic driver as multi-attaching all the underlying cinder volumes and deleting the older nova instance. - manila's share migration is multi-step allowing for a data copy and a cutover phase - and is cancelable through the data copy phase and before the cutover phase is invoked - so there were some concerns if that two phased approach is required here, given that the operation may not be cancelable always, generically *== Manila Container Storage Interface ==* - Tom Barron (tbarron) presented a summary and demo of using the Manila CSI driver on OpenShift to provide RWX storage to containerized applications - Robert Vasek (gman0) explained the core design and the reasoning behind the architecture - Mikhail Fedosin (mfedosin) spoke about the OpenShift operator for Manila CSI and the ease of install and day two operations [21] - the CSI driver has support for snapshots, cloning of snapshots (nfs only at the moment) and topology aside from provisioning, access control and deprovisioning - the team's prioritizing supporting cephfs snapshots and creating shares from cephfs snapshots via subvolume clones in the Victoria cycle Thanks for reading this far! Should you have any questions, don't hesitate to pop into #openstack-manila on freenode.net. [1] https://etherpad.opendev.org/p/victoria-ptg-manila (Minutes of the PTG) [2] https://www.youtube.com/playlist?list=PLnpzT0InFrqBKkyIAQdA9RFJnx-geS3lp (YouTube playlist of the PTG recordings) [3] https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/usi… (Manila CSI driver docs) [4] https://bugs.launchpad.net/manila/+bugs?field.tag=low-hanging-fruit (Low hanging fruit bugs in Manila) [5] https://etherpad.opendev.org/p/community-goals (Community goal proposals) [6] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015459.html (Chosen TC Community Goals for Victoria cycle) [7] https://tree.taiga.io/project/gouthampacha-manila-ci-zuul-v3-migration/kanb… (Zuulv3-native CI migrations tracker) [8] https://www.softwarefactory-project.io/ (Software Factory project) [9] https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… (Policy effort across OpenStack) [10] https://etherpad.opendev.org/p/manila-todos (ToDo list for manila) [11] https://etherpad.opendev.org/p/manila-openstackclient-updates (OSC CLI catchup tracker) [12] https://review.opendev.org/#/c/676722/ (devstack-plugin-ceph support for Ceph Nautilus) [13] https://shaman.ceph.com (Shaman build system for Ceph) [14] https://review.opendev.org/#/c/729292/ (Specification to allow security service updates) [15] https://governance.openstack.org/tc/reference/tags/assert_supports-accessib… (TC tag for accessible upgrades) [16] https://governance.openstack.org/tc/reference/tags/assert_supports-api-inte… (TC tag for API interoperability) [17] https://www.openstack.org/legal/bylaws-of-the-openstack-foundation#ARTICLE_… (TC bylaws requiring "approved release") [18] https://review.opendev.org/#/c/510542/ (Limitting the number of shares per Share server) [19] https://bugs.launchpad.net/manila/+bug/1883506 (delete manage_error share will lead to quota error) [20] https://review.opendev.org/#/c/735970/ (specification for share server migration) [21] https://github.com/openshift/csi-driver-manila-operator

5 years, 5 months

[tc][all][ Technical Committee Zed Virtual PTG discussions details

by Ghanshyam Mann

Hello Everyone, I am writing the Technical Committee discussion details from the Zed cycle PTG this week. We had a lot of discussions and that is why it is a long email but I tried to categorize the details per topic so that you can easily spot the discussion you are interested in. TC + Community leader's interaction ============================ We continue the interaction session in this PTG also. The main idea here is to interact with community leaders and ask for their feedback on TC. I am happy to see more attendance this time. Below are the topics we discussed in this feedback session. * Updates from TC: ** Status on previous PTG interaction sessions' Action items/feedback: *** TC to do more technical guides for the project: DONE We have a unified limit as the first technical guide to start in this[1]. *** TC to define a concrete checklist to check goal readiness before we select a goal: DONE We decoupled the community-wide goal from the release cycle[2] and also added the goal readiness checklist[3]. *** Spread the word: DONE We have updated a new page in project-team-guide where projects can spread the word/story[4] ** Do not do ignorant Recheck: Recheck without seeing the failure even those are not related to the proposed change is very costly and end up consuming a lot of infra resources. Checking the failure and adding comments in why you are doing a recheck will give related projects a chance to know the frequent failures happening in upstream CI and so does we can spend more time fixing them. Dan Smith has added detailed documentation on "How to Handle Test Failures"[5], this can be used to educate the contributors on recheck and how to debug the failure reason. *** Action Item: **** PTL to start spreading the word and monitor ignorant recheck in their weekly meeting etc. **** On ignorant recheck, Zuul to add a comment with the link to recheck practice documentation. ** Spread the word/project outreach: This was brought up again in this PTG but I forget to update that we did work on this in the Yoga cycle and updated the project-team-guide to list the places where the project can spread the word/story[4]. It is ready for projects to refer it and know where they can post their stories/updates. * Recognition to the new contributors and encourage/help them to continue contributing to OpenStack: When there is a new contributor who contributes a significant amount of work to any project then we should have some way to appreciate them. It can be an appreciation certificate/badge from the foundation or TC, appreciation on social media, especially on linked-in. In TC, we will check what is the best possible and less costly way to do so. We checked in cross-community session with k8s and they seem to have coupon/badge distribution from CNCF foundation. 2021 user survey analysis =================== Jay has prepared the summary of the 2021 TC survey[6] and we covered it at a high level, especially the big changes from the previous survey. As the next step, we will review the proposed summary and merge it. Also, we talked about updating the upgrade question when we start the tick/tock release. Prepare to migrate for SQLAlchemy 2.0 ============================== sqlalchemy 2.0 is under development and might have many incompatible changes. To prepare OpenStack in advance, Stephen sent the mail on what are changes and project needs to do[7], also gave the project status. oslo.db is all good to use the sqlalchemy 2.0 and the required neutron change is also merged. Thanks to Stephen for driving it and taking care of various project work. Elections Analysis: ============== Project elections are not going well and we end up with a lot of missing nominations. This cycle, we had 17 projects on the leaderless list and out of it, 16 missed the nomination. There are various factors that lead to missing nomination, short notice from the election (1-2 weeks), PTLs are not active on ML, Language, Time Zone etc. By seeing the number of leaderless projects end up having the new PTLs (this cycle it was just 1 project) and having such projects repeating the nomination miss, we thought election in those projects are not actually required. TC agrees to change the leader assignment for such a project and instead of finding PTL, we will propose to move these projects to the DPL model. WIth the DPL model, we do not need to repeat the PTL assignment in every cycle. Please note, moving them to DPL model will not be automatically done instead that will be done when there are required liaisons to take care of DPL responsibility. Community-wide goals Check In & discussion: =================================== * FIPS goal ade_lee gave the current status of this FIPS work progress in various projects[8]. Current FIPS jobs are based on the centos9 stream which is not so stable but we will keep monitoring it. Canonical has suggested a way to set up FIPS jobs on ubuntu and will give the foundation keys to do FIPS testing and periodically rotate them. One challenge is the horizon which has the dependencies on Django fix and that will be present in Django higher version (4.0 or later) and it is difficult for the horizon to upgrade to that, especially the current bandwidth team has. He also proposed the different milestones to finish the FIPS work[9]. The Technical Committee agreed to have this as a 'selected goal' and as the next step ade_lee will propose it in governance with defined milestone and we will review it. Thanks, ade_lee for all your work and energy in this. * RBAC goal I have summarised it in a separate email, please refer to it - http://lists.openstack.org/pipermail/openstack-discuss/2022-April/028103.ht… Release Cadence Adjustment: ======================= In TC and leaders' interaction sessions, Dan presented an overview of the new release cadence and explain the things which will be changed. After that project followed the discussion in their project PTG sessions and then brought the question in the Thursday TC session. There was a question if we can remove the things (which are deprecated in tick release) in tock release and the answer is yes. We discussed the automation of deprecation/upgrade release notes from tock release to tick release and it is fine but we need to make sure we do not make tick release notes so big that people start ignoring those. We will see how it goes in a few of the initial tick release notes. Below are the various other things which need changes: * ACTION: ** Deprecation document in project-team-guide[10]: *** Add the master deployment case as a recommendation *** Intermediate release upgrade case *** Update 4-a paragraph to clarify the 12 months case and things deprecated in tick can be removed in the next tock release. ** Testing runtime *** In tock release, it is ok to add/test the new python version but do not upgrade the distro version. *** In tick release: no change and keep doing the same what we do currently ** Stable branch *** Update release and stable team with what is proposed in https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad… ** tick-tock name: ***gmann to check foundation about trademark check on "tick", "tock" name Remove release naming instead just use the number ======================================= In yoga cycle, we changed the release naming convention to add the number also in <year>.<release count in that year> format[11]. But the release name is less fun nowadays and more of a conflict or objection from the community. Starting from Ussuri, I have seen objections on many release names and the most recent is 'Zed'. Being one of the release name process coordinators for the last couple of releases, I feel that I am doing a good job and have to accept the blame/objection. Also, the process of selecting the release name has its own cost in terms of TC, community time as well as the cost of the legal check by the foundation. Having only the release number will help to understand how old that release is and also in understanding the tick-tock releases. The Drawback of removing the release name is that it requires changes in release tooling and will be less helpful in marketing. The former one is a one-time change and later once can be adjusted with having some tag lines. For example, "'OpenStack 2022.2': The integration of your effort" Considering all the facts, TC agreed to start the release name drop process in Gerrit and the community can add their feedback on that. Gate Health and Checks =================== This is something TC started monitoring and helping on gate health and it is going in a good direction. TC will continue doing it in every weekly meeting. We encourage every project to keep monitoring their rechecks and TC also will keep eye on those when we notice a large number of rechecks without comment. * Infra resource checks: The next thing we checked was if there are enough infra resources we have to have the smooth development of OpenStack in the Zed cycle. Clark and fungi gave updates on those and we are all in a good position at least not in a panic situation. But to monitor the required infra resources correctly, TC will work on listing the required and good-to-have services we need for OpenStack development. That way we will be able to judge the infra resource situation in a better way. * ELK service: The new dashboard for ELK service is ready to use, you can find the dashboard and credential information in this review[12]. We encourage community members to start using it and provide feedback. Accordingly, Clark will plan to stop the older ELK servers in a month or so. Thanks dpawlik for working on it. * nested-virt capable instances for testing We discussed it and they are available and can be requested from the job definition but there is always a risk of a slow job and timing failure and it is preferred to use those in the project gate only and not in the integrated/cross-project gate, Testing strategy: ============= * Direction on the lower constraints As lower constraints are not well tested and always causing issues in upstream CI, we are discussing it again to find some permanent solution. We discussed both cases 1. keeping lower bound in requirements.txt files and 2. lower-constraints.txt file and its testing. We agree to keep the 1st one but drop the 2nd one completely. Below is the agreement and action items: ** AGREE/ACTION ITEM: *** Write up how downstream distro can test their constraint file with OpenStack upstream. *** Keep the lower bound in requirements.txt but add a line saying that they are the best effort but not tested. If they are wrong then file a bug or fix it. *** Drop the lower-constraints.txt file, l-c tox env and its testing on master as well as on all stable branches. TC will add the resolution and communicate that on ML too. * Release specific job template for testing runtime: As brought up in ML[13], release-specific template does not actually work for independent releases model repo where the OpenStack bot does not update the template. Stephen added a new generic template to use in such repo. But if we see these release-specific templates are adding an extra step to update in every repo on a new release. Having a generic template and handling the python version jobs with branch variant[14] will work fine. But the generic template will move all the projects to new testing runtime at the same time from a central place. We agree to do it but with proper communication to all the projects and give some window to test/fix them before we switch to new testing versions. * Performance testing/monitoring Performance testing is good to do but as per our current CI resources, it is very difficult. We discussed few ideas where we can keep eyes on the performance aspect: ** At the start, we can monitor the memory footprint via performance stats in CI jobs ** Before and after DB query counting (how does this patch affect the number of DB queries) ** For API performance, we can monitor all the API requests via a single behind tls proxy gateway and collect the stats. * When to remove the deprecated devstack-gate? We agree to remove it once stable/wallaby is EM and will update the same in README file also with the expected date of stable/wallaby to be EM (2022-10-14). Improvement in project governance (continue from Yoga PTG....) ================================================ This is regarding how we can better keep eyes on the less or no active projects and detect them earlier in the cycle to same the release, infra resources. In the Yoga release, we faced the issue of a few projects being broken during the last date of the final release. We discussed it in the last PTG and agreed to start the 'tech-preview' idea. To define what can be entry and exit criteria for any project to be in 'tech-preview', we need input from the release team on stopping the auto release of projects or so. The release team was busy in their PTG at the same time we had this discussion so I will continue the discussion in TC weekly meetings. Current state of translations in OpenStack ================================ Ianychoi and Seongsoocho attended this session and gave us a detailed picture of the translation work, what is the current state and what all work is required to do including migration from Zanata to weblate. The main issue here is we need more people helping in this work. We also asked who uses those translations and they should come up to help. As the next step, we agreed to add a new question to the user survey ("Do you use i18n translations in your deployments? If yes please tell us which languages you use") and get some stats about translation usage. Meanwhile, Ian and seongsoocho team will continue maintaining. Thanks to Ian and Seongsoocho for their best effort to maintain it. Cross community sessions with the k8s steering committee team: ================================================= k8s steering committee members (Paris, Dims, Bob, and Tim) joined the OpenStack Technical Committee in PTG. We discussed the various topics about Legal support/coverage for contributors, especially in the security disclosure process and export control. We asked if k8s also have the same level of language translation support in code/doc as that we have in OpenStack and they have only for the documentation which is also if anyone proposes to do. Then we discussed the long-term sustainability efforts, especially for the experience contributors who can take higher responsibility as well as train the new contributors. This is an issue in both communities and none of us have any solution to this. In the last, we discussed how k8s recognize the contributor's good work. In k8s along with appreciating on slack, ML, they issue the coupon and badges from the CNCF foundation. TC Zed Activities checks and planning ============================= This is the last hour of the PTG and we started with the yoga cycle retrospective. * Yoga Retrospective We are doing good in gate health monitoring as well doing more technical work. On the improvement side, we need to be faster at making the decision on things that are in discussion for long period instead of keeping them open. * Pop Up Team Check In After checking with the status and need of both active popup teams, we decided to continue with both in Zed cycle. * TC weekly Meeting time check We will keep the current time until daylight saving time changes again. Also, we will continue the video call once a month. * TC liaison continue or drop? As we have improved the interaction with the project with the weekly meetings as well as in PTG sessions (TC+Leaders interaction session), we agreed to drop the TC liaisons completely. * I will prepare the Zed cycle TC Tracker (activities we will do in Zed cycle) * Next week's TC meeting is cancelled and we will resume meeting from 21st April onwards. That is all from PTG, thanks for reading it and stay safe! [1] https://docs.openstack.org/project-team-guide/technical-guides/unified-limi… [2] https://review.opendev.org/c/openstack/governance/+/816387 [3] https://review.opendev.org/c/openstack/governance/+/835102 [4] https://docs.openstack.org/project-team-guide/spread-the-word.html [5] https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-te… [6] https://review.opendev.org/c/openstack/governance/+/836888 [7] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.h… [8] https://etherpad.opendev.org/p/qa-zed-ptg-fips [9] https://etherpad.opendev.org/p/zed-ptg-fips-goal [10] https://docs.openstack.org/project-team-guide/deprecation.html [11] https://review.opendev.org/c/openstack/governance/+/829563 [12] https://review.opendev.org/c/openstack/governance-sigs/+/835838 [13] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027676.ht… [14] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833892

3 years, 7 months

[nova][ptg] 2026.1 Gazpacho PTG summary

by Rene Ribaud

Hello everyone, Last week was the PTG, thank you to all who joined and contributed to the discussions! I hope you enjoyed it and found it productive. Again, this cycle we had a packed agenda with active participation throughout the sessions. For the Nova sessions (Tuesday to Friday), we had an average of 15 to 20 participants per session. Attendance was slightly higher during the cross-project discussions, with an average of 25 to 30 people joining. You can revisit all notes and discussions on the Etherpad here: https://etherpad.opendev.org/p/r.9bac75a686ab0941572757b205c9415c Below is a summary of the topics and outcomes from our PTG discussions. I’ve tried to keep it as concise as possible, though we covered quite a lot during the week. **** Tuesday topics **** #### 2025.2 Flamingo Retrospective #### During the Flamingo cycle, 14 blueprints were accepted and 9 were fully implemented, resulting in a 64% completion rate. This is slightly lower than the 71% achieved during the previous Epoxy cycle. In addition, at least 26 bug fixes were merged during the cycle. Review & Process Feedback Eventlet Transition Plan, the migration continues to work as expected and remains well-coordinated. Release process was smooth with no major issues reported. Recognition to Kamil for his work on the conductor, and to Sean, Dan, and others for their consistent review efforts. ✅ Continue to prioritize the Eventlet removal as a key goal for the G cycle. Branch Opening Policy, some uncertainty remains about what can be merged between RC1 and GA, when master is technically open but still sensitive for late merges. Concerns were raised about backports and release stability. ✅ Allow merges on a case-by-case basis once the new master branch opens. ✅ Bauzas to propose a patch updating Nova contributor process <https://docs.openstack.org/nova/latest/contributor/process.html> <https://docs.openstack.org/nova/latest/contributor/process.html> Bug Triage, the number of untriaged bugs remains high (around 180). Efforts were noted, but time allocation and rotation remain challenging. The end-of-meeting triage format was found ineffective for real-time work, though still useful for discussing specific cases. ✅ Consider reviving a rotating triage roster if enough volunteers join. ✅ Keep triage discussions focused during the weekly meeting rather than doing live triage. Review Load, contributors noted increasing difficulty in finding time for reviews. Maintaining review velocity remains a cross-cycle challenge. ✅ Encourage feature-specific syncs or review sprints for high-priority areas. Feature Momentum, weekly syncs and structured updates help large features maintain progress. The VMware CI topic was cited as useful, though too many topics per meeting could cause overload. ✅ Keep dedicated weekly or bi-weekly syncs for major features (e.g. Eventlet removal). ✅ Limit meeting updates to 2-3 features per session. Review Tracking, the previous Etherpad tracker was not effective. However, having a central list remains important to avoid missing patches and to monitor review health. ✅ Discuss an external or simplified review tracker during the next meeting with more core reviewers. ✅ Keep the tracker short and up to date to maintain visibility. #### 2025.2 Flamingo Planning #### Hard spec freeze: December 4th Milestone 2 (M2): January 8th Feature Freeze (FF): February 26th Release: End of March / early April. The team discussed adjusting the timing of the spec freeze. A soft spec freeze was proposed for November 20th, giving three weeks after the PTG for contributors to submit specs. Two spec review days will be scheduled between the soft and hard freezes. Additionally, two implementation review days are planned: one around M2 for early landings, and another roughly two weeks before M3. ✅ Adopt the proposed plan, while staying flexible on a case-by-case basis. ✅ Soft spec freeze on Nov 20th, followed by two spec review days before Dec 4th. ✅ Two implementation review days: one near M2 and one two weeks before M3. ✅ A +2 on a spec implies reviewers commit to reviewing the corresponding implementation. #### Upstream meeting schedule #### ✅ Move the weekly upstream meeting to Monday at 16:00 UTC. ✅ Keep the slot fixed (no alternating or skipping weeks). ✅ Uggla to update the meeting schedule and cycle accordingly. #### Upstream bug triage follow up #### The team discussed how to better organize bug triage follow-up for the Gazpacho cycle. A proposal was made to create a small group of volunteers who would receive a few bugs to triage each week. Each volunteer would handle up to three bugs, distributed by Uggla. During the weekly upstream meeting, the team will check whether a dedicated Q&A session is needed to discuss specific bugs. If required, such a session will be scheduled every two weeks, ideally right after the upstream meeting. Otherwise, discussions will take place within the regular meeting. ✅ The team agreed to give this approach a try in the next cycle. The overall sentiment seemed favorable, though details will likely need adjustment as we go. #### Eventlet removal #### Significant progress was made since Flamingo. In Flamingo, n-api, n-metadata, and n-sch could already be switched to native threading via an environment variable, and the nova-next job runs those services without Eventlet. n-cond was nearly ready but missed feature freeze due to a late futurist bug, which has since been fixed and released. A py312-threading tox target and a Zuul job already validate a large part of the unit tests without Eventlet. In early Gazpacho, native threading for the conductor has successfully landed. Planned tasks for Gazpacho - Add native threading support for n-novncproxy and other proxies. - Add native threading support for n-compute. - Run all unit and functional tests in both threading and Eventlet modes, keeping small exclude lists where needed. - Conduct scale testing using the fake driver, possibly extended to the libvirt driver. - Switch n-api, n-metadata, and n-sch to native threading by default, keeping Eventlet as fallback. - Introduce a nova-eventlet (legacy) CI job to ensure backward compatibility. - Keep nova-next as the only job testing conductor, novncproxy, and compute with threading until the H cycle. - Fix bugs reported after Eventlet removal. - After Eventlet removal, migrate from PyMySQL to libmysqlclient for better DB performance. ✅ Kamil volunteered to handle the novncproxy migration. ✅ Start with nova-compute migration first to build confidence. ✅ Switch the default to threading as early as possible in Gazpacho. ✅ Add a dedicated Eventlet CI job to continue testing legacy mode. ✅ Use the hybrid plug job to test Eventlet mode even for services switched to threading by default. ✅ Keep the work independent, but document the known issue with long-running RPC calls. #### Long-Running Sync REST API Calls #### The team discussed how long-running synchronous REST API actions (like volume or interface attach) can block nova-api threads once Eventlet is removed. With native threading, the limited number of threads makes blocking calls more costly, unlike Eventlet which could spawn many lightweight greenlets. This work is closely related but independent from the Eventlet removal effort. Dan started a spec on the topic, and it may be split into two (volume and interface attach). Detach operations are already async, and Manila shares follow a similar model. ✅ Introduce a new microversion to keep backward compatibility. ✅ Convert volume and interface attach to async operations under that microversion. ✅ Coordinate with Rajesh’s "show finish_time" ( https://review.opendev.org/q/topic:%22bp/show-instance-action-finish-time%22 ) work to avoid race conditions. ✅ Dan and Johannes to update the spec. ✅ Further investigation is needed to determine if WSGI or API tuning could help mitigate blocking. #### vTPM Live Migration #### The team reviewed how to handle TPM secret security policies during instance operations. Changing the assigned policy during resize is not supported, as it adds complexity and can lead to image/flavor conflicts. Rebuilds are already blocked for vTPM instances, so once a policy is set via resize, it remains locked in. Existing instances from previous releases are unaffected. ✅ Do not allow changing the TPM secret security policy after assignment. ✅ Remove the option to select the policy from the image for simplicity. ✅ Default policy is “user”, but compute nodes support all policies by default. ✅ Document in the spec and release notes that deployers must define flavors with hw:tpm_secret_security if they want to enable this. ✅ Mention that [libvirt]supported_tpm_secret_security = ['user', 'host', 'deployment'] can be adjusted by operators. **** Wednesday topics **** #### CPU Comparison During Live Migration #### The team revisited the CPU compatibility check between source and destination hosts during live migration. If skip_cpu_compare_on_dest is enabled, some migrations may fail due to missing pre-checks; if disabled, the check can sometimes be too strict. The original goal is to avoid migrations to nodes running with QEMU emulation, which would cause serious performance issues. ✅ Include getDomainCapabilities in the Nova pre-check to improve accuracy. ✅ Move the configuration flag from workaround to the libvirt section. ✅ Document potential unsafe edge cases so deployers can choose between the safer (Nova) or more permissive (libvirt-only) approach. ### Start cross session with Cinder ### #### NFS / NetApp NFS Online Volume Extend #### The team discussed adding online volume extend support for NFS and NetApp backends. Instance operations (like shutdown or migration) should be blocked during the extend process, and any new task_state must stay compatible with existing microversions. ✅ Avoid using the event API, as it’s meant for fast operations. ✅ Introduce a dedicated API for this feature to manage versioning and states. ✅ Consider making the Cinder call synchronous for better control. ✅ Konrad will update the spec in this way. #### Hard-Coded io=native Setting for Cinder Backends #### The team revisited the hard-coded io=native driver setting used for Cinder volume backends (NFS, FC, and iSCSI). This code dates back nearly ten years and has recently caused performance issues and guest hangs in some environments. The original reason for enforcing io=native is unclear. ✅ No one seems to know the reason for this original choice ✅ Move the configuration to a standard libvirt configuration option. ### End cross session with Cinder ### #### Preserve NVRAM After Reboots and Migrations #### The team discussed the proposal to preserve NVRAM data across instance reboots and migrations. The feature is ready for review, pending available reviewer bandwidth. ✅ Request a definitive answer from libvirt regarding file permission handling through a bug report. ### Start cross session with Ironic/Cinder ### A more complete summary of this joint session will be provided by the Ironic team, as they can better capture the discussions and decisions made. However, the Nova PTG notes still include a few relevant takeaways and references for those interested. ### End cross session with Ironic/Cinder ### ### Start cross session with Manila ### The teams discussed testing and integration plans between Nova and Manila. Testing through Tempest was considered challenging due to configuration complexity and potential circular dependencies. Support for CephFS and NFS, hot attach, and live migration with newer OS versions was identified as a goal. ✅ Manila will draft initial UX and workflow details to share with Nova for review. ✅ Add a backlog spec in the Nova repository to track cross-team work. ✅ Manila contributors may help with open SDK and client patches as needed. ✅ Hot attach and live migration support are valuable goals but will need explicit demand and prioritization to move forward. ### End cross session with Manila ### ### Start cross session with Neutron ### A more complete summary of this joint session will be provided by the Neutron team, as they can better capture the discussions and decisions made. However, the Nova PTG notes still include a few relevant takeaways and references for those interested. ### End cross session with Neutron ### **** Thursday topics **** #### Correct Firmware Detection for Stateless Firmware and AMD SEV/SEV-ES #### The team discussed improving firmware detection for stateless firmware and AMD SEV/SEV-ES. Recent QEMU and libvirt versions now include firmware descriptor files that expose these capabilities, allowing libvirt to automatically select the right firmware without Nova duplicating that logic. The group agreed that leveraging libvirt’s detection is the better long-term approach. To avoid regressions, Nova should continue to preserve existing firmware for running instances during hard reboots, while new instances will rely on libvirt’s detection from the start. ✅ Use libvirt’s firmware detection instead of maintaining custom logic in Nova. ✅ Preserve the existing firmware for current instances on hard reboot. Let libvirt select firmware for new ones. ✅ Takashi will write a spec describing the approach and detailing the upgrade path. ✅ He will also check UEFI/stateless firmware tests in CI and run local SEV/SEV-ES tests. #### ROM-Type Firmware Support #### The team continued the discussion on firmware selection, focusing on ROM-type firmware used by AMD SEV-SNP, Intel TDX, and future Arm CCA. Since recent libvirt versions can automatically select the appropriate firmware and handle SMM when needed, Nova no longer needs to manage this logic directly. ✅ Skip further work in Nova and rely on libvirt’s firmware auto-selection mechanism. #### AMD SEV-SNP Support #### The team discussed initial plans for SEV-SNP support, which depends on firmware and requires recent QEMU (≥9.2) and libvirt versions. Work may be postponed to the 2026.2 cycle due to these dependencies. For SEV-SNP, there is a need to provide hostData, an immutable and attested field (up to 32 bytes) that can be set by Nova or external tools. Using Nova metadata for this purpose was ruled out. ✅ Do not use Nova metadata to provide SEV-SNP host data. ✅ The instance POST API could be extended to allow providing this information. ✅ Takashi will write an initial spec, keeping the design generic for both SEV-SNP and TDX. #### Generalize SEV / SEV-ES Code #### The team reviewed the proposal to generalize the existing SEV/SEV-ES code in preparation for future Confidential Computing architectures such as Intel TDX and Arm CCA. The work focuses on refactoring internal Nova code to make memory encryption handling more generic, without changing any user-visible behavior or API. ✅ Treat this as a code refactoring only (no external impact). ✅ Ensure it does not conflict with Takashi’s ongoing work. ✅ Implementation can proceed as a specless blueprint. ✅ No Tempest job available. Manual validation is acceptable, ideally with screenshots or logs. ✅ Note: It’s possible to run Tempest manually using a flavor requesting SEV/SEV-ES to verify correctness. #### Arm CCA Support #### The team discussed the roadmap for Arm CCA enablement in Nova. Upstream dependencies include Linux Kernel (Dec 2025), QEMU (Feb 2026), and libvirt (Mar 2026), with full availability expected around Ubuntu 26.04 (Apr 2026). As a result, development and testing in OpenStack are expected to start during the 2026.2 cycle. ✅ Features cannot merge until support is available in official distributions (not custom kernels). ✅ CentOS Stream 10 may serve as an early test platform if it gains CCA support before Ubuntu 26.04. ✅ Specs or PoCs can still be prepared in advance to ease future inclusion. ✅ Once libvirt support lands, the team will review the spec, targeting early in the H (2026.2) cycle. #### Show finish_time in Instance Action Details #### The proposal adds a finish_time field to the instance action show API, along with matching updates in the SDK and client. Some review comments still need to be addressed before re-proposing the patch for the G release. ✅ No objection to re-proposing the patch for Gazpacho (G). ✅ The existing spec remains valid. ✅ Gmaan will review previous comments to help move the implementation forward. ### Start cross session with Glance ### A more complete summary of this joint session will be provided by the Glance team, as they can better capture the discussions and decisions made. However, the Nova PTG notes still include a few relevant takeaways and references for those interested. ### End cross session with Glance ### #### Periodic Scheduler Update as Notification #### The proposal suggests exposing Nova’s periodic resource tracker updates as optional versioned notifications. This would help services like Watcher obtain a more complete and up-to-date view of compute resources, including NUMA topology and devices not yet modeled in Placement. While there are concerns about notification stability and data volume, the team agreed it could be useful for cross-service integrations. ✅ Support the idea in principle. ✅ Be mindful of the volume of data included in notifications. ✅ Sean will prepare a spec proposal detailing the approach. #### Resource Provider Weigher and Preferred/Avoided Traits #### The proposal introduces a resource provider weigher to influence scheduling decisions, with a longer-term goal of supporting preferred and avoided traits. This would allow external services, such as Watcher, to tag compute nodes (e.g., with CPU or memory pressure) and guide the scheduler to favor or avoid specific hosts. ✅ There are concerns about validating the weigher’s behavior at scale, ensuring it works correctly with a large number of instances. ✅ Continue developing this approach. ✅ Improve the test framework, despite existing challenges. ✅ Add Monte Carlo–style functional tests to validate behavior in complex, non-symmetric scenarios. #### Proxying OVH’s Monitoring-Aware Scheduling #### The team discussed OVH’s proposal to enhance scheduling decisions by integrating external monitoring data. The idea is to add a filter or weigher that delegates its logic to an external plugin, allowing operators to plug in custom metrics (e.g., Prometheus, InfluxDB) without modifying Nova directly. While the use case is relevant, existing out-of-tree filters and weighers already allow similar integrations. One of the main challenges identified was how to share and maintain such code consistently across the community. ✅ Current Nova interfaces likely already support this use case. ✅ Proposal to create a dedicated repository on OpenDev for sharing and maintaining custom filters and weighers. **** Friday topics **** #### LY Corp – Graceful Shutdown Proposal #### The team discussed LY Corp’s proposal to implement graceful shutdown handling in Nova. The goal is to stop accepting new RPC requests while allowing in-progress operations, such as instance boots or live migrations to complete safely. Different designs were compared, including stopping RPC listeners or using the upcoming oslo.messaging HTTP driver, which can handle clean shutdowns more reliably. The consensus was that the complete solution must involve oslo.messaging, allowing Nova services to dynamically subscribe or unsubscribe from topics. This approach also implies an upgrade impact, requiring versioned changes to compute and scheduler topics. ✅ The current proposal needs further work, as live migration cases were not yet considered. ✅ Gmaan will continue investigation and refine the approach based on oslo.messaging improvements. ✅ A revised spec will be submitted once ready. ✅ Gmaan confirmed commitment to follow up and lead this feature. #### Offline VM Migration Using HTTP-Based File Server #### The team discussed a proposal to enable offline VM migration using an HTTP-based file server. The preferred approach is to use WebDAV, which provides a standard protocol and existing server implementations. Nova itself will not host the web server and will be restricted to paths under /var/lib/nova. ✅ Use WebDAV as the preferred protocol. ✅ Avoid introducing non-standard protocols in Nova. ✅ Nova will not spawn or host the web server directly. ✅ Define a URL template in configuration for the remote filesystem driver (e.g., remotefs_url = https://%(host)s:9999/path/to/dav). ✅ Add DevStack support to test the feature in CI. #### PCI and VGPU Scheduling Performance in Placement The team revisited the performance issues with PCI and VGPU scheduling in Placement. Two workaround sets have already been implemented to reduce the number of valid and invalid candidates, but the core scalability problem of the GET /allocation_candidates query remains, especially in large, symmetric provider trees. A long-term constraint solver approach is under consideration, and the discussion will continue once more data is available from current deployments. ✅ Keep the current workarounds active and gather feedback over the next six months. ✅ Nova-next may run with these settings enabled to collect early results. ✅ Revisit the topic and defaulting decisions at the next PTG. ✅ Keep the issue open for urgent improvements if needed before the next cycle. #### Multithread and Multiqueue Support for Libvirt #### The team discussed adding multithread and multiqueue support in Nova for libvirt-based instances. While QEMU already enables multiqueue for virtio-blk and virtio-scsi by default, the main focus is now on IOThread support and improving parallelism during I/O and live migrations. ✅ Enable IOThreads with one thread per device by default (handled as a specless blueprint). ✅ virtio-blk and virtio-scsi specs are parked. ✅ Cancel the multiqueue work, since QEMU now manages it natively. ✅ The parallel migration blueprint is approved as specless. ✅ The earlier proposed spec will be abandoned in favor of this simplified path forward. #### AZ-Aware Scheduling (Soft Anti-Affinity) #### The team discussed improving availability zone–aware scheduling by introducing a soft anti-affinity policy for server groups. ✅ The overall direction is good, but the spec still needs more work. ✅ The team is broadly supportive of continuing in this direction. ✅ A spec will be proposed by Dmitriy. #### NUMA-Aware Placement (CloudFerro Proposal) #### The team discussed CloudFerro’s proposal to enable NUMA-aware scheduling in Placement, based on the old Ussuri spec. The goal is to represent NUMA nodes as resource providers to allow better locality handling for CPU and memory resources. However, this raises potential performance concerns, especially when combined with PCI in Placement, as both increase candidate permutations. ✅ Ensure NUMA and PCI in Placement work together correctly before expanding scope. ✅ Do not move PCI devices under NUMA subtrees yet. ✅ Add functional tests to validate the combined behavior. ✅ Consider extending CI to run on hosts with real NUMA topology. ✅ Enable NUMA awareness in nova-next (single NUMA node for now). ✅ Investigate with the infra team the possibility of adding dual-NUMA test nodes. ✅ Improvements to Placement’s group_policy remain out of scope for this work. ✅ The team is happy with the current direction and looks forward to future patches landing in master. #### WSGI Script Removal #### The team discussed removing the legacy wsgi_script support from Nova. No objections were raised, and no spec is required. ✅ Proceed with the removal, the team is aligned and ready to move forward. #### Improving Cyborg Support #### The team discussed reviving Cyborg integration efforts in Nova. Several aspects remain unfinished, including proper mdev GPU XML generation, support for additional device buses (block, NVMe, CXL, USB), and handling ownership overlap between Nova and Cyborg in Placement. The plan is to resume this work gradually, starting with the most mature components. ✅ Restart the Cyborg–Nova integration effort. ✅ Split the work into multiple specs, as each part is complex enough to warrant separate discussion. ✅ Focus first on mdev support, then extend to other buses (block, NVMe, etc.). ✅ Investigate Placement ownership to avoid inventory conflicts between Nova and Cyborg. If you've read this far, thank you! 🙏 If you spot any mistakes or missing points, please don't hesitate to let me know. Best regards. René.

2 weeks

Re: [all][ptg] Pre-PTG discussion: New Keystone Middleware Feature Supporting OAuth2.0 with External Authorization Service

by Dave Wilde

I’m happy to book an additional time slot(s) specifically for this discussion if something other than what we currently have works better for everyone. Please let me know. /Dave On Mar 24, 2023 at 10:49 AM -0500, Hiromu Asahina <hiromu.asahina.az(a)hco.ntt.co.jp>, wrote: > As Keystone canceled Monday 14 UTC timeslot [1], I'd like to hold this > discussion on Monday 15 UTC timeslot. If it doesn't work for Ironic > members, please kindly reply convenient timeslots. > > [1] https://ptg.opendev.org/ptg.html > > Thanks, > > Hiromu Asahina > > On 2023/03/22 20:01, Hiromu Asahina wrote: > > Thanks! > > > > I look forward to your reply. > > > > On 2023/03/22 1:29, Julia Kreger wrote: > > > No worries! > > > > > > I think that time works for me. I'm not sure it will work for > > > everyone, but > > > I can proxy information back to the whole of the ironic project as we > > > also > > > have the question of this functionality listed for our Operator Hour in > > > order to help ironic gauge interest. > > > > > > -Julia > > > > > > On Tue, Mar 21, 2023 at 9:00 AM Hiromu Asahina < > > > hiromu.asahina.az(a)hco.ntt.co.jp> wrote: > > > > > > > I apologize that I couldn't reply before the Ironic meeting on Monday. > > > > > > > > I need one slot to discuss this topic. > > > > > > > > I asked Keystone today and Monday's first Keystone slot (14 UTC Mon, > > > > 27)[1,2] works for them. Does this work for Ironic? I understand not all > > > > Ironic members will join this discussion, so I hope we can arrange a > > > > convenient date for you two at least and, hopefully, for those > > > > interested in this topic. > > > > > > > > [1] > > > > > > > > https://www.timeanddate.com/worldclock/fixedtime.html?iso=2023-03-27T14:00:… > > > > [2] https://ptg.opendev.org/ptg.html > > > > > > > > Thanks, > > > > Hiromu Asahina > > > > > > > > On 2023/03/17 23:29, Julia Kreger wrote: > > > > > I'm not sure how many Ironic contributors would be the ones to attend a > > > > > discussion, in part because this is disjointed from the items they need > > > > to > > > > > focus on. It is much more of a "big picture" item for those of us > > > > > who are > > > > > leaders in the project. > > > > > > > > > > I think it would help to understand how much time you expect the > > > > discussion > > > > > to take to determine a path forward and how we can collaborate. Ironic > > > > has > > > > > a huge number of topics we want to discuss during the PTG, and I > > > > > suspect > > > > > our team meeting on Monday next week should yield more > > > > > interest/awareness > > > > > as well as an amount of time for each topic which will aid us in > > > > scheduling. > > > > > > > > > > If you can let us know how long, then I think we can figure out when > > > > > the > > > > > best day/time will be. > > > > > > > > > > Thanks! > > > > > > > > > > -Julia > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Mar 17, 2023 at 2:57 AM Hiromu Asahina < > > > > > hiromu.asahina.az(a)hco.ntt.co.jp> wrote: > > > > > > > > > > > Thank you for your reply. > > > > > > > > > > > > I'd like to decide the time slot for this topic. > > > > > > I just checked PTG schedule [1]. > > > > > > > > > > > > We have the following time slots. Which one is convenient to gether? > > > > > > (I didn't get reply but I listed Barbican, as its cores are almost the > > > > > > same as Keystone) > > > > > > > > > > > > Mon, 27: > > > > > > > > > > > > - 14 (keystone) > > > > > > - 15 (keystone) > > > > > > > > > > > > Tue, 28 > > > > > > > > > > > > - 13 (barbican) > > > > > > - 14 (keystone, ironic) > > > > > > - 15 (keysonte, ironic) > > > > > > - 16 (ironic) > > > > > > > > > > > > Wed, 29 > > > > > > > > > > > > - 13 (ironic) > > > > > > - 14 (keystone, ironic) > > > > > > - 15 (keystone, ironic) > > > > > > - 21 (ironic) > > > > > > > > > > > > Thanks, > > > > > > > > > > > > [1] https://ptg.opendev.org/ptg.html > > > > > > > > > > > > Hiromu Asahina > > > > > > > > > > > > > > > > > > On 2023/02/11 1:41, Jay Faulkner wrote: > > > > > > > I think it's safe to say the Ironic community would be very > > > > > > > invested in > > > > > > > such an effort. Let's make sure the time chosen for vPTG with this is > > > > > > such > > > > > > > that Ironic contributors can attend as well. > > > > > > > > > > > > > > Thanks, > > > > > > > Jay Faulkner > > > > > > > Ironic PTL > > > > > > > > > > > > > > On Fri, Feb 10, 2023 at 7:40 AM Hiromu Asahina < > > > > > > > hiromu.asahina.az(a)hco.ntt.co.jp> wrote: > > > > > > > > > > > > > > > Hello Everyone, > > > > > > > > > > > > > > > > Recently, Tacker and Keystone have been working together on a new > > > > > > Keystone > > > > > > > > Middleware that can work with external authentication > > > > > > > > services, such as Keycloak. The code has already been submitted [1], > > > > but > > > > > > > > we want to make this middleware a generic plugin that works > > > > > > > > with as many OpenStack services as possible. To that end, we would > > > > like > > > > > > to > > > > > > > > hear from other projects with similar use cases > > > > > > > > (especially Ironic and Barbican, which run as standalone > > > > > > > > services). We > > > > > > > > will make a time slot to discuss this topic at the next vPTG. > > > > > > > > Please contact me if you are interested and available to > > > > > > > > participate. > > > > > > > > > > > > > > > > [1] > > > > https://review.opendev.org/c/openstack/keystonemiddleware/+/868734 > > > > > > > > > > > > > > > > -- > > > > > > > > Hiromu Asahina > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > ◇-------------------------------------◇ > > > > > > NTT Network Innovation Center > > > > > > Hiromu Asahina > > > > > > ------------------------------------- > > > > > > 3-9-11, Midori-cho, Musashino-shi > > > > > > Tokyo 180-8585, Japan > > > > > > Phone: +81-422-59-7008 > > > > > > Email: hiromu.asahina.az(a)hco.ntt.co.jp > > > > > > ◇-------------------------------------◇ > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > ◇-------------------------------------◇ > > > > NTT Network Innovation Center > > > > Hiromu Asahina > > > > ------------------------------------- > > > > 3-9-11, Midori-cho, Musashino-shi > > > > Tokyo 180-8585, Japan > > > > Phone: +81-422-59-7008 > > > > Email: hiromu.asahina.az(a)hco.ntt.co.jp > > > > ◇-------------------------------------◇ > > > > > > > > > > > > > > > -- > ◇-------------------------------------◇ > NTT Network Innovation Center > Hiromu Asahina > ------------------------------------- > 3-9-11, Midori-cho, Musashino-shi > Tokyo 180-8585, Japan > 　 Phone: +81-422-59-7008 > 　 Email: hiromu.asahina.az(a)hco.ntt.co.jp > ◇-------------------------------------◇ > >

2 years, 7 months

Re: [all][ptg] Pre-PTG discussion: New Keystone Middleware Feature Supporting OAuth2.0 with External Authorization Service

by Dave Wilde

Hi Julia, No worries! I see that several of our sessions are overlapping, perhaps we could combine the 15:00 UTC session tomorrow to discuss this topic? /Dave On Mar 27, 2023 at 8:44 AM -0500, Julia Kreger <juliaashleykreger(a)gmail.com>, wrote: > > > > On Fri, Mar 24, 2023 at 9:55 AM Dave Wilde <dwilde(a)redhat.com> wrote: > > > I’m happy to book an additional time slot(s) specifically for this discussion if something other than what we currently have works better for everyone. Please let me know. > > > > > > /Dave > > > On Mar 24, 2023 at 10:49 AM -0500, Hiromu Asahina <hiromu.asahina.az(a)hco.ntt.co.jp>, wrote: > > > > As Keystone canceled Monday 14 UTC timeslot [1], I'd like to hold this > > > > discussion on Monday 15 UTC timeslot. If it doesn't work for Ironic > > > > members, please kindly reply convenient timeslots. > > > > Unfortunately, I took the last few days off and I'm only seeing this now. My morning is booked up aside from the original time slot which was discussed. > > > > Maybe there is a time later in the week which could work? > > > > > > > > > > > > [1] https://ptg.opendev.org/ptg.html > > > > > > > > Thanks, > > > > > > > > Hiromu Asahina > > > > > > > > On 2023/03/22 20:01, Hiromu Asahina wrote: > > > > > Thanks! > > > > > > > > > > I look forward to your reply. > > > > > > > > > > On 2023/03/22 1:29, Julia Kreger wrote: > > > > > > No worries! > > > > > > > > > > > > I think that time works for me. I'm not sure it will work for > > > > > > everyone, but > > > > > > I can proxy information back to the whole of the ironic project as we > > > > > > also > > > > > > have the question of this functionality listed for our Operator Hour in > > > > > > order to help ironic gauge interest. > > > > > > > > > > > > -Julia > > > > > > > > > > > > On Tue, Mar 21, 2023 at 9:00 AM Hiromu Asahina < > > > > > > hiromu.asahina.az(a)hco.ntt.co.jp> wrote: > > > > > > > > > > > > > I apologize that I couldn't reply before the Ironic meeting on Monday. > > > > > > > > > > > > > > I need one slot to discuss this topic. > > > > > > > > > > > > > > I asked Keystone today and Monday's first Keystone slot (14 UTC Mon, > > > > > > > 27)[1,2] works for them. Does this work for Ironic? I understand not all > > > > > > > Ironic members will join this discussion, so I hope we can arrange a > > > > > > > convenient date for you two at least and, hopefully, for those > > > > > > > interested in this topic. > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > https://www.timeanddate.com/worldclock/fixedtime.html?iso=2023-03-27T14:00:… > > > > > > > [2] https://ptg.opendev.org/ptg.html > > > > > > > > > > > > > > Thanks, > > > > > > > Hiromu Asahina > > > > > > > > > > > > > > On 2023/03/17 23:29, Julia Kreger wrote: > > > > > > > > I'm not sure how many Ironic contributors would be the ones to attend a > > > > > > > > discussion, in part because this is disjointed from the items they need > > > > > > > to > > > > > > > > focus on. It is much more of a "big picture" item for those of us > > > > > > > > who are > > > > > > > > leaders in the project. > > > > > > > > > > > > > > > > I think it would help to understand how much time you expect the > > > > > > > discussion > > > > > > > > to take to determine a path forward and how we can collaborate. Ironic > > > > > > > has > > > > > > > > a huge number of topics we want to discuss during the PTG, and I > > > > > > > > suspect > > > > > > > > our team meeting on Monday next week should yield more > > > > > > > > interest/awareness > > > > > > > > as well as an amount of time for each topic which will aid us in > > > > > > > scheduling. > > > > > > > > > > > > > > > > If you can let us know how long, then I think we can figure out when > > > > > > > > the > > > > > > > > best day/time will be. > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > -Julia > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Mar 17, 2023 at 2:57 AM Hiromu Asahina < > > > > > > > > hiromu.asahina.az(a)hco.ntt.co.jp> wrote: > > > > > > > > > > > > > > > > > Thank you for your reply. > > > > > > > > > > > > > > > > > > I'd like to decide the time slot for this topic. > > > > > > > > > I just checked PTG schedule [1]. > > > > > > > > > > > > > > > > > > We have the following time slots. Which one is convenient to gether? > > > > > > > > > (I didn't get reply but I listed Barbican, as its cores are almost the > > > > > > > > > same as Keystone) > > > > > > > > > > > > > > > > > > Mon, 27: > > > > > > > > > > > > > > > > > > - 14 (keystone) > > > > > > > > > - 15 (keystone) > > > > > > > > > > > > > > > > > > Tue, 28 > > > > > > > > > > > > > > > > > > - 13 (barbican) > > > > > > > > > - 14 (keystone, ironic) > > > > > > > > > - 15 (keysonte, ironic) > > > > > > > > > - 16 (ironic) > > > > > > > > > > > > > > > > > > Wed, 29 > > > > > > > > > > > > > > > > > > - 13 (ironic) > > > > > > > > > - 14 (keystone, ironic) > > > > > > > > > - 15 (keystone, ironic) > > > > > > > > > - 21 (ironic) > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > [1] https://ptg.opendev.org/ptg.html > > > > > > > > > > > > > > > > > > Hiromu Asahina > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2023/02/11 1:41, Jay Faulkner wrote: > > > > > > > > > > I think it's safe to say the Ironic community would be very > > > > > > > > > > invested in > > > > > > > > > > such an effort. Let's make sure the time chosen for vPTG with this is > > > > > > > > > such > > > > > > > > > > that Ironic contributors can attend as well. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Jay Faulkner > > > > > > > > > > Ironic PTL > > > > > > > > > > > > > > > > > > > > On Fri, Feb 10, 2023 at 7:40 AM Hiromu Asahina < > > > > > > > > > > hiromu.asahina.az(a)hco.ntt.co.jp> wrote: > > > > > > > > > > > > > > > > > > > > > Hello Everyone, > > > > > > > > > > > > > > > > > > > > > > Recently, Tacker and Keystone have been working together on a new > > > > > > > > > Keystone > > > > > > > > > > > Middleware that can work with external authentication > > > > > > > > > > > services, such as Keycloak. The code has already been submitted [1], > > > > > > > but > > > > > > > > > > > we want to make this middleware a generic plugin that works > > > > > > > > > > > with as many OpenStack services as possible. To that end, we would > > > > > > > like > > > > > > > > > to > > > > > > > > > > > hear from other projects with similar use cases > > > > > > > > > > > (especially Ironic and Barbican, which run as standalone > > > > > > > > > > > services). We > > > > > > > > > > > will make a time slot to discuss this topic at the next vPTG. > > > > > > > > > > > Please contact me if you are interested and available to > > > > > > > > > > > participate. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > https://review.opendev.org/c/openstack/keystonemiddleware/+/868734 > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Hiromu Asahina > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > ◇-------------------------------------◇ > > > > > > > > > NTT Network Innovation Center > > > > > > > > > Hiromu Asahina > > > > > > > > > ------------------------------------- > > > > > > > > > 3-9-11, Midori-cho, Musashino-shi > > > > > > > > > Tokyo 180-8585, Japan > > > > > > > > > Phone: +81-422-59-7008 > > > > > > > > > Email: hiromu.asahina.az(a)hco.ntt.co.jp > > > > > > > > > ◇-------------------------------------◇ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > ◇-------------------------------------◇ > > > > > > > NTT Network Innovation Center > > > > > > > Hiromu Asahina > > > > > > > ------------------------------------- > > > > > > > 3-9-11, Midori-cho, Musashino-shi > > > > > > > Tokyo 180-8585, Japan > > > > > > > Phone: +81-422-59-7008 > > > > > > > Email: hiromu.asahina.az(a)hco.ntt.co.jp > > > > > > > ◇-------------------------------------◇ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > ◇-------------------------------------◇ > > > > NTT Network Innovation Center > > > > Hiromu Asahina > > > > ------------------------------------- > > > > 3-9-11, Midori-cho, Musashino-shi > > > > Tokyo 180-8585, Japan > > > > 　 Phone: +81-422-59-7008 > > > > 　 Email: hiromu.asahina.az(a)hco.ntt.co.jp > > > > ◇-------------------------------------◇ > > > > > > > >

2 years, 7 months

Jump to page: