April 2021 - openstack-discuss - lists.openstack.org

cyborg launchpad suppport
by Alex Song (宋文平) 27 Apr '21

27 Apr '21

Hi, We change to use launchpad to track cyborg bugs and features, with this patch merged: https://review.opendev.org/c/openstack/project-config/+/787306. But we cannot count on the website: https://www.stackalytics.io/ Please help us with this problem. Thanks.

3 4

[Interop][PTG] highlights from Interop PTG
by Kanevsky, Arkady 27 Apr '21

27 Apr '21

Fellow stackers, Thank you for successful Xena PTG. The PTG agenda and notes are at https://etherpad.opendev.org/p/april2021-ptg-interop-refstack Highlights: 1. Ghanshayam and Goutham are now co-chair of Interop along with Arkady 2. Superuser article for Interop is in progress highlighting major changes to Interop program including Rfestack transitioning to Python3, support of refstack of add-on projects, and adding share file system as add-on program. 3. Working on updated to Interop processes, and specifically no need for Board to approve new guidelines, only process changes. * See https://review.opendev.org/c/osf/interop/+/787646 * Discuss updates to all wiki pages starting from https://wiki.openstack.org/wiki/Governance/InteropWG - expect changes in Xena cycle 4. Agreed on how we will list add-on Logo to marketplace listing 5. Working on how to handle in automated matter in refstack admin privileges for setting up for tempest user testing, Manila in particular. 6. Starting discussion on how to handle microiservice versions of APIs. 7. Interlocks with all projects under interop guidelines, except Swift and Keystone. 8. Discussed several possible add-on projects Happy to provide more details. Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell Technologies office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

1 0

OS X install openstackclient 10.15.7
by Michael STFC 27 Apr '21

27 Apr '21

Hi I know this is a forum for openstack but I have some issues with OS X and upgrading or reinstalling openstackclient. Any advise welcome. —— Regards, Michael Tint System Administrator

2 2

OS X install openstackclient 10.15.7
by Michael STFC 27 Apr '21

27 Apr '21

Hi I know this is a forum for openstack but I have some issues with OS X and upgrading or reinstalling openstackclient. Any advise welcome. Regards, Michael Tint System Administrator

1 0

[venus][ptg]Venus vPTG Summary April 2021
by Liye Pang(逄立业) 27 Apr '21

27 Apr '21

Hi all, Thanks for all your participation! We've conducted the first meeting of venus last week and it is successful. Here's the summary of the topics we have discussed: *Progress in the past six months: - Develop devstack-based deployment for venus - Add log retrieval of modules such as vitrage - Develop the configuration, based on which you can retrieve the chain log of the call *Next step: - Develop alarm task code to set threshold for the number of error logs of different modules at different times, and provides alarm services and notification services - The configuration, analysis and alarm of Venus will be integrated into horizon in the form of plugin. - Develop a deployment method based on kolla-ansible - (discuss)Summarize the log specifications of some typical scenarios and develop them to venus - Evaluate whether to collect event data (considering usage, pressure, etc.We will continue to discuss with the telemetry project team) *Promblem: - Many projects's log records are not standardized, so they can only support full-text retrieval, not multi-dimensional analysis Full discussion (PTG etherpad): [1] https://etherpad.opendev.org/p/venus-xena-ptg Introduction of venus: [2] https://youtu.be/mE2MoEx3awM

4 4

[Vitrage] Cannot delete old entities on graph
by Adam Tomas 27 Apr '21

27 Apr '21

Hi, I’ve deployed Kolla-Ansible (Victoria) and after using it for some time I have errors from Vitrage service: 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init [-] Got Exception for event {'vitrage_entity_type': 'consistency', 'vitrage_datasource_action': 'update', 'vitrage_sample_date': '2021-03-18T13:30:19Z', 'vitrage_event_type': 'delete_entity', 'vitrage_id': 'a19330f1-49c1-4a97-9787-c80b645f51a6', 'id': '93c1df77-dbb5-4ba7-9b7d-16fad97169f1', 'vitrage_type': 'cinder.volume', 'vitrage_category': 'RESOURCE', 'is_real_vitrage_id': True}: KeyError: 'vitrage_is_placeholder' 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init Traceback (most recent call last): 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init File "/var/lib/kolla/venv/lib/python3.8/site-packages/vitrage/entity_graph/graph_init.py", line 146, in do_work 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init return do_work_func(event) 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init File "/var/lib/kolla/venv/lib/python3.8/site-packages/vitrage/entity_graph/graph_init.py", line 111, in process_event 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init self.processor.process_event(event) 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init File "/var/lib/kolla/venv/lib/python3.8/site-packages/vitrage/entity_graph/processor/processor.py", line 63, in process_event 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init self.actions[entity.action](entity.vertex, entity.neighbors) 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init File "/var/lib/kolla/venv/lib/python3.8/site-packages/vitrage/entity_graph/processor/processor.py", line 149, in delete_entity 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init PUtils.delete_placeholder_vertex(self.entity_graph, vertex) 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init File "/var/lib/kolla/venv/lib/python3.8/site-packages/vitrage/entity_graph/processor/processor_utils.py", line 68, in delete_placeholder_vertex 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init if not vertex[VProps.VITRAGE_IS_PLACEHOLDER]: 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init File "/var/lib/kolla/venv/lib/python3.8/site-packages/vitrage/graph/driver/elements.py", line 24, in __getitem__ 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init return self.properties[key] 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init KeyError: 'vitrage_is_placeholder' 2021-03-18 13:30:19.873 7 ERROR vitrage.entity_graph.graph_init As I can see in Horizon, there are some old volumes , which in Cinder database have proper (DELETED/DETACHED) status, but they’re still visible on Entity Graph, and as in error message above - cannot be deleted by vitrage-graph. How to delete such entities? Best regards, Adam Tomas

2 7

[tacker] IRC meeting cancelled on 4th May
by Yasufumi Ogawa 27 Apr '21

27 Apr '21

Hi tacker team, It's a holiday season next week in Japan, and most of us are not going to join the next IRC meeting. We will cancel the meeting on 4th May. Cheers, Yasufumi

1 0

[Multi-arch SIG][sig][PTG] PTG Summary. Next meeting: May, 11.
by Rico Lin 27 Apr '21

27 Apr '21

Dear all Before we starts, just like to notify that we're not running meeting this week, but will run meeting at May, 11. So please join and provide topics if you got any: https://etherpad.opendev.org/p/Multi-Arch-agenda As we just have our PTG meeting last week, and I thank everyone who joins our PTG session. Here are some summaries from PTG: - Success to run full tempest tests on Arm64 env. What's next? - ML: http://lists.openstack.org/pipermail/openstack-discuss/2021-April/021600.ht… - Job patch: https://review.opendev.org/c/openstack/devstack/+/708317 - Job status: https://zuul.openstack.org/builds?job_name=devstack-platform-arm64+ - actions: - propose to add swift arm64 UT job: Swift is one of services directly touch file system or basic storage services. - pushing forward for integrating Ceph with current CI job to test more similar to user's environment - tunning volume backup/restore on the current job: - we might try to use POSIX as volume backup backend to testing performance issue. - ricolin and kevinz will take action to run tests locally for debugging - Also will try to switch to OSUOSL environment to check what kind of result we will face. - propose a periodic task for current CI job (once landed): as current job performance is not suitable for gating every patch set, I believe it will make sense to at least have a periodic job running. After performance issue is fixed, we can consider adding gating job or post-merge job. - We should also consider having multi-node job to test cross node. - SIG report (https://www.openstack.org/multi-arch-sig-report) - As general agreement that we definitely will generate report out to keep update the community with works related to multi-arch supports. Also hope to get use cases for share around. - We found some error in SIG report, but they are fixed now. - SIG video meeting - We discuss about the chances to run a video meeting. Once we have more material collected or topics ready. - Check libvirt 7 and cpu stuff - as libvirt 7 released this year, we should check if behavior changes: - There was code added for CPU features on migration - Need to check does 'cpu_mode' different than host-passthrough work now Please reference our PTG etherpad for more detailed discussion: https://etherpad.opendev.org/p/xena-ptg-multi-arch-sig *Rico Lin* OIF Board director, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack

1 0

Masakari meeting on 2021-05-04 *cancelled*
by Radosław Piliszek 27 Apr '21

27 Apr '21

Dears, We are cancelling the Masakari meeting on 2021-05-04 as there are holidays in China. We will meet again on 2021-05-11. -yoctozepto

1 0

[neutron]Really need some help in network aspect
by Rey 26 Apr '21

26 Apr '21

Hello, I'm not sure this is the right place, but I want to try whether if can I get any useful help. I stuck in some network problem for couple of days, and the problem I listed in https://github.com/projectcalico/calico/issues/4563 In short, the environment is kubernetes over openstack vm, and calico is kubernetes network componenet. However, the container to container network is very very slowly than host to host. So, I confused in questions: 1. Does kernel support double virturalization network? Like container network in vm 2. Is there any way to dig more? Sincerely, Yuan

1 0

[cyborg][ptg]Cyborg vPTG Summary April 2021
by Wang, Xin-ran 26 Apr '21

26 Apr '21

Hi all, Please ignore my previous message, it is sent to wrong person. Sorry about this. Thanks for all your participation! We've conducted a successful meeting last week. Here is the aggregated summary from Cyborg vPTG discussion. Please check it out and feel free to feedback any concerns you might have. We did a retrospective of Wallaby release, including: * We supports more operations supported for a VM with accelerator attached. * We introduced new drivers for Intel x710 NIC and Inspur's NVMe SSD Card. * We implemented a new configuration file allowing more flexible device configuration. Topic discussion: Here's some major discussion and conclusion of Cyborg vPTG. For more details, please refer to the etherpad[1]. * More nova operation supporting: - We prioritized the tasks: 1. suspend/resume. 2. cold migration. 3. live migration. * vGPU support: - We reached an internal agreement on whole workflow which can be apply as a generic framework for mdev device. * API enhancement: Some of the following items requires a new micro-version. - Add refresh policy check for all APIs. - Add device profile update API. - Add ARQ query by multiple instances API. - Add disable/enable device API, this one requires a spec first. - Enhance device profile show API with more information. * Cleanup issue: - This issue comes from the case where one compute node shutdown accidently, and the accelerator records in placement and cyborg DB remains as the orphaned resources. We agreed to implement a mechanism to clean up the orphaned resources, this one also need a spec. [1] https://etherpad.opendev.org/p/cyborg-xena-ptg Thanks, Xin-Ran Wang

2 2

[sdk]: compute service create_server method, how to create multiple servers
by dmeng 26 Apr '21

26 Apr '21

Hello there, Hope this email finds you well. We are currently using the openstacksdk for developing our product, and have a question about the openstacksdk compute service create_server() method. We are wondering if the "max_count" and "min_count" are supported by openstackskd for creating multiple servers at once. I tried both the max_count and the min_count, and they both only create one server for me, but I'd like to create multiple servers at once. The code I'm using is like the following: conn = connection.Connection( session=sess, region_name=None, compute_api_version='2') nova = conn.compute nova.create_server( name='sdk-test-create', image_id=image_id, flavor_id=flavor_id, key_name=my_key_name, networks=[{"uuid": network_id}], security_groups=[{'name':security_group_name}], min_count=3, ) The above code will create one server "sdk-test-create", but I'm assuming it should create three. Wondering did I miss anything, or if we have any other option to archive this? Thanks for your help and have a great day! Catherine

2 1

[Watcher] Datasource plugins?
by Jing Geng (BLOOMBERG/ 120 PARK) 26 Apr '21

26 Apr '21

Hi There, Currently Watcher supports many kinds of plugins, including actions, cluster data model collector, goals... In fact, it seems everything has plugins except for datasources (metrics). I wonder if there is any reason that so far Watcher doesn't provide plugins for datasources? Another question is, if I'd like to build plugin infrastructure for datasources, which means changing this DataSourceBase class so it extends loadable.Loadable and abc.ABCMeta, like other base classes for plugins, will this be supported by the community? I hope this idea will be supported, especially when there have already been several projects that tried to make datasources more flexible (Formal Datasource Interface, File based Metric Map, Grafana proxy datasource...). It seems to me that we should just provide plugins for datasources so Watcher can work with any metric system that has been deployed. If I missed something and it isn't a good idea, please also let me know why. Looking forward to contributing to the community! Regards, Jing Geng

1 0

[telemetry][ptg] Summary of the discussed topics
by Matthias Runge 26 Apr '21

26 Apr '21

Hi there, last week, we had two days of PTG sessions for telemetry. There were a couple of topics discussed, and here's the summary. - the CI situation for telemetry is not very satisfying. There are a couple of repositories interacting with each other. telemetry gates have been blocked for over a month on the external dependency gnocchi. - We talked about the use (or not using) storyboard for the case of tracking bugs etc. for telemetry. It is/was not very user friendly to report bugs. - for the future, we'll go back and use launchpad for tracking bugs etc. - We had a collab session with the folks from venus, talked about what they are doing, and if there is a room for collaboration. - we also decided to drop panko from OpenStack. A separate mail will follow. Best, Matthias

1 0

RE: [kolla] VM build fails after Train-Ussuri upgrade
by Braden, Albert 26 Apr '21

26 Apr '21

Can anyone help with this upgrade issue? From: Braden, Albert Sent: Monday, April 19, 2021 8:20 AM To: openstack-discuss(a)lists.openstack.org Subject: [kolla] VM build fails after Train-Ussuri upgrade I upgraded my Train test cluster to Ussuri following these instructions: OpenStack Docs: Operating Kolla<https://docs.openstack.org/kolla-ansible/latest/user/operating-kolla.html#u…> The upgrade completed successfully with no failures, and the existing VMs are fine, but new VM build fails with rados.Rados.connect\nrados.PermissionDeniedError: Ubuntu Pastebin<https://paste.ubuntu.com/p/MJhzgjYbW8/> I'm running external ceph so I looked at this document: OpenStack Docs: External Ceph<https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-…> It says that I need the following in /etc/kolla/config/glance/ceph.conf: auth_cluster_required = cephx auth_service_required = cephx auth_client_required = cephx I didn't have that, so I added it and then redeployed, but still can't build VMs. I tried adding the same to all copies of ceph.conf and redeployed again, but that didn't help. Does anything else need to change in my ceph config when upgrading from Train to Ussuri? I see some cryptic talk about ceph in the release notes but it's not obvious what I'm being asked to change: OpenStack Docs: Ussuri Series Release Notes<https://docs.openstack.org/releasenotes/kolla-ansible/ussuri.html#relnotes-…> I read the bug that it refers to: Bug #1904062 "external ceph cinder volume config breaks volumes ..." : Bugs : kolla-ansible (launchpad.net)<https://bugs.launchpad.net/kolla-ansible/+bug/1904062> But I already have "backend_host=rbd:volumes" so I don't think I'm hitting that. Also I read these sections but I don't see anything obvious here that needs to be changed: * For cinder (cinder-volume and cinder-backup), glance-api and manila keyrings behavior has changed and Kolla Ansible deployment will not copy those keys using wildcards (ceph.*), instead will use newly introduced variables. Your environment may render unusable after an upgrade if your keys in /etc/kolla/config do not match default values for introduced variables. * The default behavior for generating the cinder.conf template has changed. An rbd-1 section will be generated when external Ceph functionality is used, i.e. cinder_backend_ceph is set to true. Previously it was only included when Kolla Ansible internal Ceph deployment mechanism was used. * The rbd section of nova.conf for nova-compute is now generated when nova_backend is set to "rbd". Previously it was only generated when both enable_ceph was "yes" and nova_backend was set to "rbd". My ceph keys have the default name and are in the default locations. I have cinder_backend_ceph: "yes". I don't have a nova_backend setting but I have nova_backend_ceph: "yes" I added nova_backend: "rbd" and redeployed and now I get a different error: rados.Rados.connect\nrados.ObjectNotFound Ubuntu Pastebin<https://paste.ubuntu.com/p/2kdKCW7npw/> I apologize for the nonsense below. I have not been able to stop it from being attached to my external emails. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

2 2

[TripleO] Xena PTG session summaries
by Marios Andreou 26 Apr '21

26 Apr '21

Hello folks, I sent out some stats and links on our PTG meetup with http://lists.openstack.org/pipermail/openstack-discuss/2021-April/021999.ht… already, but, as a couple of different people asked me about it, I took the time to write a summary for each session today. Of course you can find all etherpad links and recordings via https://etherpad.opendev.org/p/tripleo-ptg-xena (which seems to be down right now but I have backups if it isn't resolved by tomorrow I can try sharing that content somewhere else). Below is a (very) concise summary of the main points in each session and I hope that is useful to someone (especially since it took far longer than I expected ;)). Please reply here (or ping privately if you prefer) for any glaring omissions or obvious issues that should be revised (I originally intended to put this in an etherpad for easier collaboration but as I wrote above, etherpad.opendev.org seems down right now at least for me). regards, marios MON: * https://etherpad.opendev.org/p/tripleo-ptg-retrospective Retrospective of the Wallaby cycle - there are some community and team level 'headlines' on the main items worked on during this cycle on the etherpad. Some identified ideas for improvement include targeting another older branch for end-of-life likely Queens, improving upstream documentation especially removal of stale content, and creating a tag in Launchpad for teams so we can more easily identify which squad is currently assigned. * Topic: Plan/Swift removal update Presentation link: https://drive.google.com/file/d/1igOW4XuAbU55Tat73DwLqO4UGZu8MiNi/view?usp=… An update of the work completed in the W allay cycle to remove the Swift service and the deployment plan (which is no longer used as part of our deployments) from the undercloud. From wallaby onward by default there is no undercloud Swift. There may be a revision of the spec https://opendev.org/openstack/tripleo-specs/commit/e83d8aba3a950da83a33c23b… as the original plan didn't explicitly consider removal of the deployment plan. * https://etherpad.opendev.org/p/tripleo-ephemeral-heat Update on the ephemeral heat work (i.e. no permanent heat process on the undercloud). There has been very strong progress made in this cycle and there are still some outstanding patches https://review.opendev.org/q/topic:%22ephemeral-heat%22+(status:open) to be merged. Goal is to make this the default in Xena deployments and backport to Wallaby as optional. Besides the main feature, some related planned work includes consolidation of the python-tripleoclient "overcloud deploy" and "tripleo deploy" (eg standalone) commands. Note that this work depends on the tripleo-network-v2 work (next session below). * https://etherpad.opendev.org/p/tripleo-network-v2 Update on the network ports v2 work (moving network port creation out of the heat stack) https://opendev.org/openstack/tripleo-specs/src/branch/master/specs/wallaby… - again good progress on this during Wallaby but there is still some ongoing work there https://review.opendev.org/q/topic:%2522network-data-v2%2522+(status:open) . The goal for Xena is to make this the default (i.e. no node/networking config in deploy-steps-playbook.yaml). One main area of work for X in this topic is integration of the baremetal network config in the overcloud deployment (i.e. allow a single command). * https://etherpad.opendev.org/p/tripleo-ceph-xena Update from the ceph team about the main work items completed in Wallaby including the tripleo-ceph-client and tripleo-ceph in place of ceph-ansible for RBD ( https://specs.openstack.org/openstack/tripleo-specs/specs/wallaby/tripleo-c… and https://specs.openstack.org/openstack/tripleo-specs/specs/wallaby/tripleo-c… ). The main work planned for Xena is to continue trying to achieve feature parity with ceph-ansible - including resolving cephadm blockers, , Ganesha & https://specs.openstack.org/openstack/tripleo-specs/specs/wallaby/tripleo-c… . One major consideration is how to move ceph creation/config outside of the heat stack - some parts such as pools, keyrings and haproxy config will have to remain as part of the tripleo deployment. Note that this work depends on the network ports v2 (previous session above). TUE: * https://etherpad.opendev.org/p/tripleo-xena-whole-disk-images A proposal to move to whole disk images instead of the current overcloud-full.qcow+overcloud-full.initrd+overcloud-full.vmlinuz. There were many compelling arguments made for the proposal including: with the overcloud-full.qcow2 partition image, as of centos 8.4 grub2 no longer supports UEFI boot, there will be much less for ironic-python-agent to do during deployment with a single disk image, there will be just one file to distribute (vs 3), we will no longer need to define and build a separate 'hardened' image (and also remove the related CI jobs). One of the main technical issues that needs to be addressed first is the grow partition for /var which is where we are storing containers and config for deployment. * https://etherpad.opendev.org/p/tripleo-xena-drop-healthchecks Proposal to drop the container health check since are using deployment resources but aren't providing value. There was no push back against this proposal and the details are being discussed in the newly posted spec @ https://review.opendev.org/c/openstack/tripleo-specs/+/787535. * https://etherpad.opendev.org/p/ci-tripleo-repos Proposal to consolidate the various ways and places that tripleo-ci is using to configure the repos in the CI jobs. There is a spec proposed @ https://review.opendev.org/c/openstack/tripleo-specs/+/772442 - some of the work here is split into sub items which are ongoing (tripleo-get-hash there https://review.opendev.org/c/openstack/tripleo-ci/+/784392) The main outstanding blocking item here is to agree on the common data format for the various personas upstream downstream and product that we need to support eg https://github.com/mwhahaha/rhos-bootstrap/blob/main/versions/centos.yaml vs https://review.opendev.org/c/openstack/tripleo-repos/+/785593/1/tripleo_rep… * openstack tempest skiplist https://docs.google.com/presentation/d/1aCiV35IYNhPV7SRmi4_A9vkIjZ89pwfC4Vv… Update on the tempest skiplist effort during Wallaby to consolidate the skipped Tempest tests in a central location with the ability to specify particular jobs and or branches for which specific skips will apply. * https://etherpad.opendev.org/p/tripleo-next One of the main items discussed here was the 'first principles' proposal at https://review.opendev.org/c/openstack/tripleo-specs/+/786980 - these are meant to guide us when discussing changes to our deployment tooling and architecture. The proposal will merge in Xena specs once we've reached consensus on the review. Another topic discussed in this session was an update on exploratory work to replace "heat & ansible" in our deployment tooling with 'something else' - some ongoing work here is at https://github.com/cloudnull/director & https://github.com/mwhahaha/task-core. More info and pointers (also discussed Kube/OCP with an operator to deploy tripleo) on the etherpad. WED: * https://etherpad.opendev.org/p/tripleo-xena-inventory-script This was a proposal to remove the "tripleo-ansible-inventory script" @ https://github.com/openstack/tripleo-common/blob/ccd990b58b6583dda3a0e0f341… and instead generate it from the deployment data (e.g. metalsmith or user data from deployed-server deployments). The consensus reached was that instead of removing it we should instead use it in a better way, for example make sure static inventories are generated and exported to known locations (especially for the ephemeral heat case) and re-used. * https://etherpad.opendev.org/p/vf-ui-output This was an update from the validations squad about the main items worked on during Wallaby (integrated the validation framework into the component CI pipelines, enabled the standalone job in upstream check/gate and increased adoption especially by the upgrades squad). Followed by discussions for planned Xena work, including changes in the UI/CLI (eg jq queries can be handled better and various other UI improvements more on the etherpad). Some of the other topics raised here were to make the validations themselves component aware (run all validations related to a given component) and discussion around the requirement for a molecule test on all validation additions (especially the example of mocking out OpenStack services like keystone); the compromise could be to instead use a standalone job for such cases. * https://etherpad.opendev.org/p/Validation-Framework-Next-Generation In this session the validations squad introduced ideas for the future direction of the validation framework. Some of the main proposals are to remove the validations repos - validations-common and validations-libs out of tripleo governance but still within openstack and establishing a new validations project (discussion but no clear consensus on this point), to re-merge the two repos into one consolidated validations repo and fixup the CLI (see previous session) - more items and other considerations on the etherpad. * https://etherpad.opendev.org/p/tripleo-frr-integration Update on Wallaby progress from the cross-squad team looking at FRR/BGP integration in the tripleo deployment (https://opendev.org/openstack/tripleo-specs/src/branch/master/specs/wallaby…) Some of the main items discussed for Xena work included how we might approximate some part of this feature in upstream CI (high resource requirements - downstream CI has 9 nodes) and backport considerations (no backport to upstream/train). * https://etherpad.opendev.org/p/update-upgrade-consolidation In this session the upgrades squad outlined their proposal for consolidation of the minor update and major upgrade workflows - without any blockers or objections coming out of the discussion. One of the main considerations was around how we can decouple the operating system updates/upgrades from the tripleo container upgrade - one action item is to de-containerize those containers that are tied to the kernel version (ABI) such as libvirt and openvswitch. THU: * https://etherpad.opendev.org/p/policy-popup-xena-ptg In this session the security squad gave an update on progress during Wallaby on the Role Based Access Control (RBAC) - many services have completed implementation (Keystone, Nova, Ironic - more on the etherpad). Then there was a discussion around potential integration points during the tripleo deployment, for example https://review.opendev.org/c/openstack/tripleo-heat-templates/+/781571/7/en… . One of the considerations was around how we can test this in CI (possibly the standalone job is a good fit) as well as the use of multiple clouds.yaml for project specific operations during the deployment (with the root clouds yaml having the system-admin profile). * https://etherpad.opendev.org/p/centos-stream-9-upstream In this session the CI squad lead a discussion around centos9 stream (possibly coming Apr/May) and what we should consider/prepare for with respect to upstream CI. Some of the main changes and discussion items included NetworkManager and firewalld replacing iptables, ansible version (2.11/2.12?/?). Mainly this effort is blocked on the actual 9-stream release and getting the relevant nodepool node. Another main discussion point here was whether we would support both stream-8 and stream-9 on particular branches - consensus here is that wallaby has both 8/9 and for X can have only 9 - but this is all dependent on when 9 becomes available with respect to when Xena is released. * https://etherpad.opendev.org/p/os-migrate This session was an update from the upgrades squad around the os-migrate tool ( https://github.com/os-migrate/os-migrate ) - which aims to 'copy' your openstack deployment and in particular the end-user workloads (i.e. user data, vms etc, but not the controlplane) onto new hardware, as an alternative to the in-place upgrade. More information and slides @ https://docs.google.com/presentation/d/1UYGOI89MBLHLpS89mPp0VK1yvTYtb2BamUL…

1 1

[TripleO] next irc meeting Tuesday Apr 27 @ 1400 UTC in #tripleo
by Marios Andreou 26 Apr '21

26 Apr '21

Reminder that the next TripleO irc meeting is: ** Tuesday 27 April at 1400 UTC in #tripleo ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to highlight at https://etherpad.opendev.org/p/tripleo-meeting-items This can be recently completed things, ongoing review requests, blocking issues, or anything else tripleo you want to share. Our last meeting was on Mar 13 - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-04-13-14.… Hope you can make it on Tuesday, regards, marios

1 0

[Interop]: Interop Working Group Meeting
by Kanevsky, Arkady 26 Apr '21

26 Apr '21

1 0

RE: [Interop] Proposal to move weekly meeting 1 hour earlier
by Kanevsky, Arkady 26 Apr '21

26 Apr '21

Thanks Dmitry. You are correct it is for Interop WG not Ironic. Thanks for catching it. That is for Friday weekly Interop Meeting. Arkady From: Dmitry Tantsur <dtantsur(a)redhat.com> Sent: Friday, April 23, 2021 9:12 AM To: Kanevsky, Arkady Cc: openstack-discuss(a)lists.openstack.org Subject: Re: [Ironic] Proposal to move weekly meeting 1 hour earlier [EXTERNAL EMAIL] I suspect you wanted to use [interop] tag, not [ironic] :) On Fri, Apr 23, 2021 at 4:10 PM Kanevsky, Arkady <Arkady.Kanevsky(a)dell.com<mailto:Arkady.Kanevsky@dell.com>> wrote: Team, On today’s PTG Interop meeting we proposed to move weekly Friday meeting 1 hour earlier to 16:00 UTC. Please, respond if the proposed time will or not will work for you. Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell Technologies office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955 -- Red Hat GmbH, https://de.redhat.com/ [de.redhat.com]<https://urldefense.com/v3/__https:/de.redhat.com/__;!!LpKI!wCVrafnGLyCBhmrC…> , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

4 4

[TripleO] overcloud node introspect failed
by Vinesh N 26 Apr '21

26 Apr '21

hi, i am facing an issue while introspect the bare metal nodes, *error message* "*4bdd55bd-c4d9-4af0-b619-2e0b7b0107cf | 2021-04-22T01:41:32 | 2021-04-22T01:41:35 | Failed to set boot device to PXE: Failed to set boot device for node 4bdd55bd-c4d9-4af0-b619-2e0b7b0107cf: Client Error for url: http://10.0.1.202:6385/v1/nodes/4bdd55bd-c4d9-4af0-b619-2e0b7b0107cf/manage… <http://10.0.1.202:6385/v1/nodes/4bdd55bd-c4d9-4af0-b619-2e0b7b0107cf/manage…>, Node 4bdd55bd-c4d9-4af0-b619-2e0b7b0107cf is locked by host undercloud.localdomain, please retry after the current operation is completed*" *(undercloud) [stack@undercloud ~]$ cat /etc/*release* CentOS Linux release 8.3.2011 *ussuri version* *(undercloud) [stack@undercloud ~]$ openstack image list* /usr/lib/python3.6/site-packages/requests/__init__.py:91: RequestsDependencyWarning: urllib3 (1.26.4) or chardet (3.0.4) doesn't match a supported version! RequestsDependencyWarning) +--------------------------------------+------------------------+--------+ | ID | Name | Status | +--------------------------------------+------------------------+--------+ | 8ddcd168-cc18-4ce2-97c5-c3502ac471a4 | overcloud-full | active | | 8d9cfac9-400b-4570-b0b1-baeb175b16c4 | overcloud-full-initrd | active | | c561f1d5-41ae-4599-81ea-de2c1e74eae7 | overcloud-full-vmlinuz | active | +--------------------------------------+------------------------+--------+ *Using the command to introspect the node, it was able to discover the node and I could provision the node boot via pxe, and load the image on the node. I could see the login prompt on the server, after some time of provision shut the node down.* *openstack overcloud node discover --range 10.0.40.5 --credentials admin:XXXX --introspect --provide* /usr/lib/python3.6/site-packages/requests/__init__.py:91: RequestsDependencyWarning: urllib3 (1.26.4) or chardet (3.0.4) doesn't match a supported version! RequestsDependencyWarning) Successfully probed node IP 10.0.40.5 Successfully registered node UUID 4bdd55bd-c4d9-4af0-b619-2e0b7b0107cf /usr/lib/python3.6/site-packages/requests/__init__.py:91: RequestsDependencyWarning: urllib3 (1.26.4) or chardet (3.0.4) doesn't match a supported version! RequestsDependencyWarning) PLAY [Baremetal Introspection for multiple Ironic Nodes] *********************** 2021-04-22 07:04:28.978299 | 002590fe-0d22-76eb-1a70-000000000008 | TASK | Check for required inputs 2021-04-22 07:04:29.002729 | 002590fe-0d22-76eb-1a70-000000000008 | SKIPPED | Check for required inputs | localhost | item=node_uuids 2021-04-22 07:04:29.004468 | 002590fe-0d22-76eb-1a70-000000000008 | TIMING | Check for required inputs | localhost | 0:00:00.069134 | 0.0 .... .... .... 2021-04-22 07:11:43.261714 | 002590fe-0d22-76eb-1a70-000000000016 | TASK | Nodes that failed introspection 2021-04-22 07:11:43.296417 | 002590fe-0d22-76eb-1a70-000000000016 | FATAL | Nodes that failed introspection | localhost | error={ "msg": " 4bdd55bd-c4d9-4af0-b619-2e0b7b0107cf" } 2021-04-22 07:11:43.297359 | 002590fe-0d22-76eb-1a70-000000000016 | TIMING | Nodes that failed introspection | localhost | 0:07:14.362025 | 0.03s NO MORE HOSTS LEFT ************************************************************* PLAY RECAP ********************************************************************* localhost : ok=4 changed=1 unreachable=0 failed=1 skipped=5 rescued=0 ignored=0 2021-04-22 07:11:43.301553 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2021-04-22 07:11:43.302101 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Total Tasks: 10 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2021-04-22 07:11:43.302609 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Elapsed Time: 0:07:14.367265 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2021-04-22 07:11:43.303162 | UUID | Info | Host | Task Name | Run Time 2021-04-22 07:11:43.303740 | 002590fe-0d22-76eb-1a70-000000000014 | SUMMARY | localhost | Start baremetal introspection | 434.03s 2021-04-22 07:11:43.304248 | 002590fe-0d22-76eb-1a70-000000000015 | SUMMARY | localhost | Nodes that passed introspection | 0.04s 2021-04-22 07:11:43.304814 | 002590fe-0d22-76eb-1a70-000000000016 | SUMMARY | localhost | Nodes that failed introspection | 0.03s 2021-04-22 07:11:43.305341 | 002590fe-0d22-76eb-1a70-000000000008 | SUMMARY | localhost | Check for required inputs | 0.03s 2021-04-22 07:11:43.305854 | 002590fe-0d22-76eb-1a70-00000000000a | SUMMARY | localhost | Set node_uuids_intro fact | 0.02s 2021-04-22 07:11:43.306397 | 002590fe-0d22-76eb-1a70-000000000010 | SUMMARY | localhost | Check if validation enabled | 0.02s 2021-04-22 07:11:43.306904 | 002590fe-0d22-76eb-1a70-000000000012 | SUMMARY | localhost | Fail if validations are disabled | 0.02s 2021-04-22 07:11:43.307379 | 002590fe-0d22-76eb-1a70-00000000000e | SUMMARY | localhost | Set concurrency fact | 0.02s 2021-04-22 07:11:43.307913 | 002590fe-0d22-76eb-1a70-00000000000c | SUMMARY | localhost | Notice | 0.02s 2021-04-22 07:11:43.308417 | 002590fe-0d22-76eb-1a70-000000000011 | SUMMARY | localhost | Run Validations | 0.02s 2021-04-22 07:11:43.308926 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ End Summary Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2021-04-22 07:11:43.309423 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ State Information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2021-04-22 07:11:43.310021 | ~~~~~~~~~~~~~~~~~~ Number of nodes which did not deploy successfully: 1 ~~~~~~~~~~~~~~~~~ 2021-04-22 07:11:43.310545 | The following node(s) had failures: localhost 2021-04-22 07:11:43.311080 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ansible execution failed. playbook: /usr/share/ansible/tripleo-playbooks/cli-baremetal-introspect.yaml, Run Status: failed, Return Code: 2 Exception occured while running the command Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/tripleoclient/command.py", line 34, in run super(Command, self).run(parsed_args) File "/usr/lib/python3.6/site-packages/osc_lib/command/command.py", line 41, in run return super(Command, self).run(parsed_args) File "/usr/lib/python3.6/site-packages/cliff/command.py", line 187, in run return_code = self.take_action(parsed_args) or 0 File "/usr/lib/python3.6/site-packages/tripleoclient/v1/overcloud_node.py", line 462, in take_action retry_timeout=parsed_args.retry_timeout, File "/usr/lib/python3.6/site-packages/tripleoclient/workflows/baremetal.py", line 193, in introspect "retry_timeout": retry_timeout, File "/usr/lib/python3.6/site-packages/tripleoclient/utils.py", line 728, in run_ansible_playbook raise RuntimeError(err_msg) RuntimeError: Ansible execution failed. playbook: /usr/share/ansible/tripleo-playbooks/cli-baremetal-introspect.yaml, Run Status: failed, Return Code: 2 Ansible execution failed. playbook: /usr/share/ansible/tripleo-playbooks/cli-baremetal-introspect.yaml, Run Status: failed, Return Code: 2 *(undercloud) [stack@undercloud ~]$ openstack baremetal introspection list* /usr/lib/python3.6/site-packages/requests/__init__.py:91: RequestsDependencyWarning: urllib3 (1.26.4) or chardet (3.0.4) doesn't match a supported version! RequestsDependencyWarning) +--------------------------------------+---------------------+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | UUID | Started at | Finished at | Error | +--------------------------------------+---------------------+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | 4bdd55bd-c4d9-4af0-b619-2e0b7b0107cf | 2021-04-22T01:41:32 | 2021-04-22T01:41:35 | Failed to set boot device to PXE: Failed to set boot device for node 4bdd55bd-c4d9-4af0-b619-2e0b7b0107cf: Client Error for url: http://10.0.1.202:6385/v1/nodes/4bdd55bd-c4d9-4af0-b619-2e0b7b0107cf/manage…, Node 4bdd55bd-c4d9-4af0-b619-2e0b7b0107cf is locked by host undercloud.localdomain, please retry after the current operation is completed. | | 3d091348-e9c7-4e99-80e3-df72d332d935 | 2021-04-21T12:36:30 | 2021-04-21T12:36:32 | Failed to set boot device to PXE: Failed to set boot device for node 3d091348-e9c7-4e99-80e3-df72d332d935: Client Error for url: http://10.0.1.202:6385/v1/nodes/3d091348-e9c7-4e99-80e3-df72d332d935/manage…, Node 3d091348-e9c7-4e99-80e3-df72d332d935 is locked by host undercloud.localdomain, please retry after the current operation is completed. | +--------------------------------------+---------------------+---------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

2 2

[neutron] April 2021 - PTG Summary
by Slawek Kaplonski 26 Apr '21

26 Apr '21

Hi, Below is my summary of the Neutron sessions during the PTG last week. Etherpad with agenda and all notes from the sessions is available at https:// etherpad.opendev.org/p/neutron-xena-ptg If You want to discuss some topic in more details, please start new thread for it to keep this one clean. ## Day 1 (Monday) ### Retrospective of the Wallaby cycle Good things: * we accomplished our community goals this cycle, like e.g. rootwrap to privsep migration, * migration to the secure RBAC, * many performance improvements, * CI improvements and the job simplification/reducing, * stable team, and a lot of small patches from all around the world, * OVN feature gap with OVS is shrinking, * team support to implement address groups, including RBAC support. In the list of not so good things we mentioned: * During the previous PTG we were talking about some OVN related guides/sessions but we didn't made any, * networking-midonet - (yet another) stadium project deprecated due to lack of maintainers, but it's better to have them clearly marked as out of stadium, than false expectations - we can bring such projects back when needed anyway, * still unstable CI, mainly tempest and tempest-plugin jobs, also during this release functional tests. As for action items for the _Xena_ cycle, we listed couple of things: * Miguel wants to do the ovn knowledge share internally in his company and later share the material, * we will keep working on the improvements for our CI, list of all opened, CI related bugs can be found at https://tinyurl.com/neutron-gate-failures and we will work on reducing that list in next months. * Rodolfo and Miguel will follow up on Nova's plans to drop eventlet and move to the threading and will investigate if we can try to do something similar in the Neutron, * Akihiro raised good point about ML2/OVN and stadium projects. We should clarify the support plan for OVN in all of our stadium projects. Lajos and Lucas volunteered to work on that. ### Secure RBAC - testing - discussion with QA team As next session in the first day, we attended QA team's session about testing new secure RBAC policies. Summary of that discussion can be found in the etherpad: https://etherpad.opendev.org/p/qa-xena-ptg. QA team wants to switch each project to enforce new defaults and the system scope tokens in the Devstack. We will have to monitor that and check what needs to be fixed on our side to accomplish that. ### Deprecated hybrid plug and the iptables_hybrid firewall driver Bence proposed discussion about potential deprecation of the iptables_hybrid firewall driver as we have now native openvswitch driver too. After discussion we decided that we are not going to deprecate it, at least for now. There are known differences between those two drivers and there is still many usecases where people wants to use iptables_hybrid driver. ### Future of the Linuxbridge backend As the last topic of the first day we discussed future of the Linuxbridge backend and ML2 driver. The same topic was discussed in the http://kaplonski.pl/ blog/shanghai_ptg_summary/ and then, based on the feedback from operators we decided that we are not going to deprecate this backend anytime soon as many people are still using it. But now we are couple of cycle later and things didn't change a lot. We still don't have anyone who would like to maintain it. In most cases it works fine but there are also pretty many bugs reported for that backend, which don't have owners - see https://tinyurl.com/linuxbridge-bugs. But things may change in the future and e.g. removal of the legacy iptables from the main distributions may makes things harder to work. We again had feedback, e.g. from Jon that NASA is using that driver and want's to keep using it. But from the other hand in the core Neutron we don't have anyone interested in maintaining it currently. The outcome of the discussion is that we will again raise that topic and ask operators about: - who is using it and what are the use cases addressed by that driver - maybe we can help with proposing another solution, - who is willing to help with maintenance of that backend. If You are using Linuxbridge backend, please give us such feedback. For Xena status is that we still do our best to keep Linuxbridge backend to be running and fully supported but we will also revisit its status again in the next PTG. ## Day 2 (Tuesday) ### Continuation of "L3 feature improvements" During the second day of the PTG we had very interesting discussions about L3 improvements. We discussed bunch of the RFEs proposed by Bence, Lajos and Manu: * [RFE] Add BFD support for Neutron https://bugs.launchpad.net/neutron/+bug/ 1907089 and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/767337 * [RFE] Allow explicit management of default routes: https://bugs.launchpad.net/ neutron/+bug/1921126) and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/781475 * Allow multiple external gateways on a router: https://bugs.launchpad.net/neutron/ +bug/1905295 and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/779511 * [RFE] Enhancement to Neutron BGPaaS to directly support Neutron Routers & bgp-peering from such routers over internal & external Neutron Networks https:// bugs.launchpad.net/neutron/+bug/1921461 and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/783791 * [RFE] BFD for BGP Dynamic Routing: https://bugs.launchpad.net/neutron/+bug/ 1922716 and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/785349. That one still needs to be discussed and approved during the drivers meeting. General outcome from the discussion is that during the Xena cycle we at least wants to have all those specs merged to have agreement about implementation details. When that will be done, Bence, Lajos and others from Ericsson will work on the implementation of those RFEs. ### Tap-as-a-service (taas) project Next topic which we discussed during Tuesday's session was about Tap-as-a-service: https://opendev.org/x/tap-as-a-service project. Few cycle back we were thinking about including it in the Neutron stadium but finally that

1 0

[keystone] Token
by Adam Tomas 26 Apr '21

26 Apr '21

Hi Which CLI setting sets domain_id field in a token? I tried openstack —os-domain-id SOME_OS_COMMAND, openstack —os-default-domain SOME_OS_COMMAND, openstack —os-default-domain_id SOME_OS_COMMAND but none of them sets this field and policies checking domain_id:%(domain_id) don’t work because of that. Interesting thing is that horizon somehow generates token with domain_id set and everything works with the same policies, I have a problem only with CLI. Can user_domain_id (which is inside of every token is see for particular user) be used instead of domain_id? Example token from CLI: 2021-04-23 12:16:38.090 700 DEBUG keystone.server.flask.request_processing.middleware.auth_context [req-117bc600-490e-46ae-a857-0c8d09dc1dbc 9adbxxxxb02ef 61d4xxxx9c0f - 3a08xxxx82c1 3a08xxxx82c1] RBAC: auth_context: {'token': <TokenModel (audit_id=BLWXSpdbTvqc0YS9WzStjQ, audit_chain_id=['BLWXSpdbTvqc0YS9WzStjQ']) at 0x7f8c390aaca0>, 'domain_id': None, 'trust_id': None, 'trustor_id': None, 'trustee_id': None, 'domain_name': None, 'group_ids': [], 'user_id': '9adbxxxx02ef', 'user_domain_id': '3a08xxxx82c1', 'system_scope': None, 'project_id': '61d4xxxx9c0f', 'project_domain_id': '3a08xxxx82c1', 'roles': ['member', 'project_admin', 'reader', 'domain_admin'], 'is_admin_project': True, 'service_user_id': None, 'service_user_domain_id': None, 'service_project_id': None, 'service_project_domain_id': None, 'service_roles': []} fill_context /var/lib/kolla/venv/lib/python3.8/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py:478 Example token from Horizon: 2021-04-23 12:48:21.009 704 DEBUG keystone.server.flask.request_processing.middleware.auth_context [req-d6d89d3e-c3c1-48c0-b3ed-b3dcedb54db3 9adbxxxx02ef - 3a08xxxx82c1 3a08xxxx82c1 -] RBAC: auth_context: {'token': <TokenModel (audit_id=ZHltw2esTJyTRnFlgHetog, audit_chain_id=['ZHltw2esTJyTRnFlgHetog', 'iJGq-E9fQKKXdZaZq72MQw']) at 0x7f8c3a1b4460>, 'domain_id': '3a08xxx82c1', 'trust_id': None, 'trustor_id': None, 'trustee_id': None, 'domain_name': ‚xxxx', 'group_ids': [], 'user_id': '9adbxxxx02ef', 'user_domain_id': '3a08xxxx82c1', 'system_scope': None, 'project_id': None, 'project_domain_id': None, 'roles': ['project_admin', 'member', 'reader', 'domain_admin'], 'is_admin_project': False, 'service_user_id': None, 'service_user_domain_id': None, 'service_project_id': None, 'service_project_domain_id': None, 'service_roles': []} fill_context /var/lib/kolla/venv/lib/python3.8/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py:478 Best regards Adam

1 1

[cinder] festival of mypy reviews 30 April 2021
by Brian Rosmaita 26 Apr '21

26 Apr '21

Hello Cinder community members, As discussed at last week's PTG, we will be holding a special Cinder Festival of mypy Reviews at the end of this week on Friday 30 April. what: Cinder Festival of mypy Reviews when: Friday 30 April 2021 from 1400-1600 UTC where: https://meetpad.opendev.org/cinder-festival-of-reviews See you there! brian

1 0

[cinder] reminder: this week's meeting in video+IRC
by Brian Rosmaita 26 Apr '21

26 Apr '21

Quick reminder that this week's Cinder team meeting on Wednesday 28 April, being the final meeting of the month, will be held in both videoconference and IRC at the regularly scheduled time of 1400 UTC. These are the video meeting rules we've agreed to: * Everyone will keep IRC open during the meeting. * We'll take notes in IRC to leave a record similar to what we have for our regular IRC meetings. * Some people are more comfortable communicating in written English. So at any point, any attendee may request that the discussion of the current topic be conducted entirely in IRC. * The meeting will be recorded. connection info: https://bluejeans.com/3228528973 meeting agenda: https://etherpad.opendev.org/p/cinder-xena-meetings cheers, brian

1 0

[neutron] bug deputy report for week of 2021-04-19
by Rodolfo Alonso Hernandez 26 Apr '21

26 Apr '21

Hello Neutrinos: This is the list of bugs opened during the last week. I would like to remark the two critical bugs and the high one, that are not assigned. Critical: - https://bugs.launchpad.net/neutron/+bug/1925451: “[stable/rocky] grenade job is broken”. Unassigned. - https://bugs.launchpad.net/neutron/+bug/1926109: “SSH timeout (wait timeout) due to potential paramiko issue“. Unassigned. High: - https://bugs.launchpad.net/neutron/+bug/1925498: “SNAT is not working“. Unassigned. - NOTE: I didn't have time to test if this issue is legit. IMO that's something that should have been detected years ago but I'm until this bug is triaged, I'll set it as "high". Medium: - https://bugs.launchpad.net/neutron/+bug/1925406: “[functional] run dsvm-functional locally will need ovn no matter the running cases are”. Unassigned. - https://bugs.launchpad.net/neutron/+bug/1916428: “dibbler tool for dhcpv6 is concluded“. Unassigned. - NOTE: I’m adding this bug into this list because this week a duplicate of this bug was filled. Worth mentioning it again. - https://bugs.launchpad.net/neutron/+bug/1925836: “[OVN] OVN metadata should not need to monitor the enterily Chassis table”. Assigned to Lucas. - https://review.opendev.org/c/openstack/neutron/+/787780 Low: - https://bugs.launchpad.net/neutron/+bug/1925218: “[OVN] BW limit QoS rules assigned to networks with SR-IOV ports are created on NBDB”. Assigned to Rodolfo. - https://review.opendev.org/c/openstack/neutron/+/787351 - https://bugs.launchpad.net/neutron/+bug/1925368: “[L3] Router GW can be removed with routes defined”. Unassigned. - NOTE: I would like to know if this is a valid issue or not. - https://bugs.launchpad.net/neutron/+bug/1925433: “[doc] SR-IOV config documentation has not been updated when SRIOV attach got implemented”. Assigned to Balazs. - https://review.opendev.org/c/openstack/neutron/+/787500 - https://bugs.launchpad.net/neutron/+bug/1925841: “"backref" warnings for "QosNetworkPolicyBinding.port" and "StandardAttribute.tags"“. Assigned to Rodolfo. - https://review.opendev.org/c/openstack/neutron/+/787782 Whishlist: - https://bugs.launchpad.net/neutron/+bug/1925528: “Improve "NeutronDbObject.objects_exist" performance“. Assigned to Rodolfo. - https://review.opendev.org/c/openstack/neutron/+/787681 Incomplete: - https://bugs.launchpad.net/neutron/+bug/1925213: “o-api seems to leak memory when ovn-octavia-provider is used” - https://bugs.launchpad.net/neutron/+bug/1926045: “Restrictions on FIP binding” - https://bugs.launchpad.net/neutron/+bug/1926049: “check_changed_vlans failed“ Undecided/unconfirmed: - https://bugs.launchpad.net/neutron/+bug/1925789: “neutron fwaas2 l3 - inconsistent order of jump rules“. FWaaS bug in Train. Regards.

1 0