- openstack-discuss - lists.openstack.org

OVN with SSL
by nabeel.tariq＠rapidcompute.com 10 Nov '21

10 Nov '21

Hi, We have configured OVN with SSL which is working while using SSL from third party. When we implement self-signed certificate, it shows certificate verification failed in logs. ERROR LOG: 2021-11-10 10:11:14.703 88854 ERROR neutron.service OpenSSL.SSL.Error: [('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')] By using openssl verify command selfsigned server is showing verified. openssl verify -verbose -CAfile <self-signed-cacertificate>.pem <main>.crt

1 0

[sdk]: Get server fault message
by dmeng 10 Nov '21

10 Nov '21

Hello there, Hope everything is going well. I'm wondering if there is any method that could show the error message of a server whose status is "ERROR"? Like from openstack cli, "openstack server show server_name", if the server is in "ERROR" status, this will return a field "fault" with a message shows the error. I tried the compute service get_server and find_server, but neither of them show the error messages. Thanks and have a great day! Catherine

2 1

[puppet] Propose retiring puppet-senlin
by Takashi Kajinami 09 Nov '21

09 Nov '21

Hello, I remember I raised a similar discussion recently[1] but we need the same for a different module. puppet-selin was introduced back in 2018, but the module has had only the portion made by cookiecutter and has no capability to manage fundamental resources yet. Because we haven't seen any interest in creating implementations to support even basic usage, I'll propose retiring this module. I'll be open for any feedback for a while, and will propose a series of patches for retirement if no concern is raised here for one week. Thank you, Takashi [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-September/02468… [2] https://opendev.org/openstack/puppet-senlin

2 2

[keystone] failed auth takes a while
by Tony Liu 09 Nov '21

09 Nov '21

Hi, I am using Keystone 17.0.0 with Ussuri. When issue a request by openstack cli (eg. network list) with wrong password, it takes 1+ minute to get auth failure 401 back. After correct the password, for the first request, it still takes 1+ minute to return success. After that, all following request is as fast as usual, around 1s. "openstack user password set" also takes that much time to return success. Any clues? Thanks! Tony

1 0

[qa] Moving office hour one hour later
by Martin Kopec 09 Nov '21

09 Nov '21

Hi everyone, we have decided to move the weekly office hour (held on Tuesdays) one later to 15:00 UTC effective November 16th [1]. It was discussed during our last office hour [2]. [1] https://review.opendev.org/c/opendev/irc-meetings/+/817224 [2] https://meetings.opendev.org/meetings/qa/2021/qa.2021-11-09-14.00.log.html#… Regards, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

1 0

[openstack-helm] No meeting tomorrow
by Gage Hugo 08 Nov '21

08 Nov '21

Hey team, Since there are no agenda items [0] for the IRC meeting tomorrow, the meeting is cancelled. Our next meeting will be November 16th. Thanks [0] https://etherpad.opendev.org/p/openstack-helm-weekly-meeting

1 0

Opendaylight integration Openstack
by Hojii GZNI 08 Nov '21

08 Nov '21

Hi everyone I am trying to use Opendaylight as an Openstack SDN controller but have this error for "mechanism_dirver". Xena Ubuntu 20.04 Opendaylight 8 /etc/neutron/plugins/ml2/ml2_conf.ini mechanism_drivers = opendaylight Neutron server log: CRITICAL neutron.plugins.ml2.managers [-] The following mechanism drivers were not found: {'opendaylight'} All configuration is in my Github[1] Regards, Hojat. [1]: https://github.com/hojat-gazestani/openstack

2 1

OpenInfra Live - November 11 at 9am CT
by Ashlee Ferguson 08 Nov '21

08 Nov '21

Hi everyone, This week’s OpenInfra Live episode is brought to you by the OpenStack Community. The 2021 User Survey shows that the footprint of OpenStack clouds grew by 66% over the last year, totaling over 25 million cores in production. This increase has been contributed by organizations of all sizes around the world. During this episode of OpenInfra Live, we are going to talk to operators from Kakao, LINE, Schwarz IT, NeCTAR and T-Systems about what’s causing this OpenStack growth at their organization. Episode: OpenStack Is Alive: Explosive Growth Among Production Deployments Date and time: November 11 at 9am CT (1500 UTC) You can watch us live on: YouTube: https://www.youtube.com/watch?v=RhMJO82lDxc <https://www.youtube.com/watch?v=RhMJO82lDxc> LinkedIn: https://www.linkedin.com/feed/update/urn:li:ugcPost:6862068514526756864 <https://www.linkedin.com/feed/update/urn:li:ugcPost:6862068514526756864> Facebook: https://www.facebook.com/104139126308032/posts/4493822407339660/ <https://www.facebook.com/104139126308032/posts/4493822407339660/> WeChat: recording will be posted on OpenStack WeChat after the live stream Speakers: Paul Coddington (ARDC Nectar) Reedip Banerjee (LINE) Yushiro Furukawa (LINE) Andrew Kong (Kakao) Nils Magnus (T-Systems) Adrian Seiffert (Schwarz) Marvin Titus (Schwarz) Carmel Walsh (ARDC Nectar) Have an idea for a future episode? Share it now at ideas.openinfra.live <https://openinfrafoundation.formstack.com/forms/openinfralive>. Register now for OpenInfra Live: Keynotes, a special edition of OpenInfra Live on November 17-18th starting at 1500 UTC: https://openinfralivekeynotes.eventbrite.com/ Thanks, Ashlee OpenInfra Foundation Community & Events ashlee(a)openinfra.dev

1 0

[ironic] Proposing Aija Jauntēva for sushy-core
by Iury Gregory 08 Nov '21

08 Nov '21

Hello everyone! I would like to propose Aija Jauntēva (irc: ajya) to be added to the sushy-core group. Aija has been in the ironic community for a long time, she has a lot of knowledge about redfish and is always providing good reviews. ironic-cores please vote with +/- 1. -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the ironic-core and puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

8 8

[neutron] Neutron drivers Meeting - vote on time of the meeting
by Lajos Katona 08 Nov '21

08 Nov '21

Hi Neutrinos, As we discussed during the PTG, let's start a poll to see which time fits best the need of the team for the Neutron drivers meeting. I prepared a doodle, please check which time slot would be best for you: https://doodle.com/poll/6vdugxp7g54smdv6?utm_source=poll&utm_medium=link The dates for the doodle now for next week, but please ignore that. Lajos Katona (lajoskatona)

1 0

[kuryr] Using kuryr-kubernetes CNI without neutron agent(s)?
by Jason Anderson 08 Nov '21

08 Nov '21

Hello all, I’m interested in letting Neutron provide the network configuration frontend for networks realized on k8s kubelets. I have been reading a lot about kuryr-kubernetes and it looks like it fits the bill, but some of the older architecture diagrams I’ve seen indicate that OVS and the neutron-openvswitch-agent (or similar) must also run on the kubelet node. Is this still accurate? I am hoping to avoid this because my understanding is that running the OVS agent means giving the kubelet node access to RabbitMQ and potentially storing admin keystone creds on the node as well. Can kuryr-kubernetes work without such an agent co-located? Thanks! Jason Anderson --- Chameleon DevOps Lead Department of Computer Science, University of Chicago Mathematics and Computer Science, Argonne National Laboratory

2 5

[neutron] Bug deputy report (week starting on 2021-11-01)
by Bernard Cafarelli 08 Nov '21

08 Nov '21

Hey neutrinos, Now that we are past the biannual DST calendar mess, it is also time for a new bug deputy rotation! Here is the list of bugs reported for last week, kudos to Rodolfo for both reporting most of them and also having a fix for them! All bugs have assignees, almost have patches and some are just waiting for CI Critical * "neutron-tempest-plugin-scenario-ovn" job timing out frequently - https://bugs.launchpad.net/neutron/+bug/1949557 Change merged increasing timeout by ralonsoh: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/816438 * "openstack-tox-py38" CI job is timing out frequently in gate - https://bugs.launchpad.net/neutron/+bug/1949704 Timeout change by ralonsoh in https://review.opendev.org/c/openstack/neutron/+/816631 * [CI] "neutron-ovs-rally-task" job failing due to an authentication problem - https://bugs.launchpad.net/neutron/+bug/1949945 Change to create keystone endpoint merged by ralonsoh: https://review.opendev.org/c/openstack/neutron/+/816792 High * [OVN] Stateless SG Extension Support - https://bugs.launchpad.net/neutron/+bug/1949451 Extension missing in the OVN supported extensions list, fix by Ihar https://review.opendev.org/c/openstack/neutron/+/816612 * "openstack-tox-py39" is timing out frequently - https://bugs.launchpad.net/neutron/+bug/1949476 Similar fix as py38 in https://review.opendev.org/c/openstack/neutron/+/816631 Medium * [OVS][QoS] Dataplane enforcement is limited to minimum bandwidth egress rule - https://bugs.launchpad.net/neutron/+bug/1949607 Patch in progress by ralonsoh: https://review.opendev.org/c/openstack/neutron/+/816530 * FIP ports count into quota as they get a project_id set - https://bugs.launchpad.net/neutron/+bug/1949767 Change in train bulk port binding, suggested fix https://review.opendev.org/c/openstack/neutron/+/816722 * [OVN] OVN mech driver does not map new segments - https://bugs.launchpad.net/neutron/+bug/1949967 WIP patch by ralonsoh https://review.opendev.org/c/openstack/neutron/+/816856 Low * [OVN] Check OVN support for stateless NAT - https://bugs.launchpad.net/neutron/+bug/1949494 Patch in progress by ralonsoh: https://review.opendev.org/c/openstack/neutron/+/816376 * [OVN] Check OVN support virtual port type - https://bugs.launchpad.net/neutron/+bug/1949496 Patch in progress by ralonsoh: https://review.opendev.org/c/openstack/neutron/+/816383 * direct-physical port creation fails with QoS minimum bandwidth rule - https://bugs.launchpad.net/neutron/+bug/1949877 Assigned to gibi -- Bernard Cafarelli

1 0

[neutron] Neutron Team meeting - vote on time of the meeting
by Lajos Katona 08 Nov '21

08 Nov '21

Hi Neutrinos As we discussed during the PTG, let's start a poll to see which time fits best the need of the team for the Neutron Team meeting. I prepared a doodle, please check which time slot would be best for you: https://doodle.com/poll/m973q9eyag8k385w?utm_source=poll&utm_medium=link The dates for the doodle now for next week, but please ignore that. Lajos Katona (lajoskatona)

1 0

[all][tc] What's happening in Technical Committee: summary 5th Nov, 21: Reading: 10 min
by Ghanshyam Mann 05 Nov '21

05 Nov '21

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * TC this week IRC meeting held on Nov 5th Thursday. * Most of the meeting discussions are summarized below (Completed or in-progress activities section). Meeting full recording are available @ - https://www.youtube.com/watch?v=4bt6iNaR3oI - IRC chat summary (topics and links): https://meetings.opendev.org/meetings/tc/2021/tc.2021-11-04-15.02.log.html * Next week's meeting will be on IRC on Nov 11th, Thursday 15:00 UTC, feel free the topic on agenda[1] by Nov 10th. 2. What we completed this week: ========================= * Retired kolla-cli [2] * Removed oslo independent deliverables from stable policy[3] * Magnum PTL is changed from Feilong Wang to Spryos[4] 3. Activities In progress: ================== TC Tracker for Yoga cycle ------------------------------ * I have started the etherpad to collect the Yoga cycle targets for TC[5]. Open Reviews ----------------- * Eleven open reviews for ongoing activities[6]. RBAC discussion: continuing from PTG ---------------------------------------------- We had a discussion on Wed and sort out the many points especially on get-all-project resources or system and project scoped isolation. Complete notes are in this etherpad[7]. Lance is re-working on the goal and new implementation/details, feel free to review it for more feedback[8]. We will continue the discussion on next Wed Nov 10th same time[9], feel free to join for any additional query related to your project specific and we will also discuss about what all bits we can do in Yoga cycle and what all to move as next targets. Decouple the community-wide goals from cycle release ----------------------------------------------------------------- * As discussed in PTG, we are de-coupling the community-wide goals from release cycle so that we can improve the community-wide goal selection and its completion workflow where goals are multi-cycle like RBAC etc. * Proposal is up, please review and add your feedback[10]. Yoga release community-wide goal ----------------------------------------- * With the continuing the discussion on RBAC, we are re-working on the RBAC goal, please wait until we finalize the implementation[11] * There is one more goal proposal for 'FIPS compatibility and compliance'[12]. Adjutant need maintainers and PTLs ------------------------------------------- You might have seen the email[13] from Adrian to call the maintainer for Adjutant project, please reply to that email or here or on openstack-tc channel if you are interested to maintain this project. We will wait for next week also and if no-one shows up for help then we will start the retirement process. New project 'Skyline' proposal ------------------------------------ * We discussed it in TC PTG and there are few open points about python packaging, repos, and plugins plan which we are discussion on ML. * Still waiting from skyline team to work on the above points[14]. Updating the Yoga testing runtime ---------------------------------------- * As centos stream 9 is released, I have updated the Yoga testing runtime[15] with: 1. Add Debian 11 as tested distro 2. Change centos stream 8 -> centos stream 9 3. Bump lowest python version to test to 3.8 and highest to python 3.9 Stable Core team process change --------------------------------------- * Current proposal is under review[16]. Feel free to provide early feedback if you have any. * This is ready to merge and I will do that week early, feel free to add feedback if any. Merging 'Technical Writing' SIG Chair/Maintainers to TC ------------------------------------------------------------------ * Work to merge this SIG to TC is up for review[17]. * No response on usage and maintaining help for openstack/training-labs repo[18] and in TC meeting we decided to retire it next week. If you use or would like to maintain this, this is last chance to raise hand. TC tags analysis ------------------- * TC agreed to remove the framework and it is communicated in ML[19]. Project updates ------------------- * Retiring js-openstack-lib [20] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[21]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [22] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [23] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://review.opendev.org/c/openstack/governance/+/814603 [3] https://review.opendev.org/c/openstack/governance/+/816828 [4] https://review.opendev.org/c/openstack/governance/+/816431 [5] https://etherpad.opendev.org/p/tc-yoga-tracker [6] https://review.opendev.org/q/projects:openstack/governance+status:open [7] https://etherpad.opendev.org/p/policy-popup-yoga-ptg [8] https://review.opendev.org/c/openstack/governance/+/815158 [9] http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025666… [10] https://review.opendev.org/c/openstack/governance/+/816387 [11] https://review.opendev.org/c/openstack/governance/+/815158 [12] https://review.opendev.org/c/openstack/governance/+/816587 [13] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025555.… [14] https://review.opendev.org/c/openstack/governance/+/814037 [15] https://review.opendev.org/c/openstack/governance/+/815851 [16] https://review.opendev.org/c/openstack/governance/+/810721 [17] https://review.opendev.org/c/openstack/governance/+/815869 [18] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025586.… [19] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025571.… [20] https://review.opendev.org/c/openstack/governance/+/807163 [21] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [22] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [23] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

[docs] Double headings on every page
by Peter Matulis 04 Nov '21

04 Nov '21

Hi, I'm hitting an oddity in one of my projects where the titles of all pages show up twice. Example: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/wall… Source file is here: https://opendev.org/openstack/charm-deployment-guide/src/branch/master/depl… Does anyone see what can be causing this? It appears to happen only for the current stable release ('wallaby') and 'latest'. Thanks, Peter

5 6

[neutron] Drivers meeting - Friday 5.11.2021 - cancelled
by Lajos Katona 04 Nov '21

04 Nov '21

Hi Neutron Drivers! Due to the lack of agenda, let's cancel tomorrow's drivers meeting. See You on the meeting next week. Lajos Katona (lajoskatona)

1 0

[baremetal-sig][ironic] Tue Nov 9, 2021, 2pm UTC: Hardware burn-in
by Arne Wiebalck 04 Nov '21

04 Nov '21

Dear all, The Bare Metal SIG will meet next week on Tue Nov 9, 2021, at 2pm UTC on zoom. The meeting will feature a "topic-of-the-day" presentation by Emmanouil Bagakis (CERN) on "Hardware Burn-in with Ironic" As usual, all details on https://etherpad.opendev.org/p/bare-metal-sig Everyone is welcome! Cheers, Arne

1 0

[barbican] Simple Crypto Plugin kek issue
by Ammad Syed 03 Nov '21

03 Nov '21

Hi, I have installed barbican and using it with openstack magnum. When I am using the default kek describe in document below, works fine and magnum cluster creation goes successful. https://docs.openstack.org/barbican/latest/install/barbican-backend.html But when I generate a new kek with below command. python3 -c "from cryptography.fernet import Fernet ; key = Fernet.generate_key(); print(key)" and put it in barbican.conf, the magnum cluster failed to create and I see below logs in barbican. 2021-10-29 12:53:28.932 568554 INFO barbican.plugin.crypto.simple_crypto [req-aaac01e9-82af-421b-b85a-ff998d904972 ad702ac807f44c73a32a9b7a795b693c d782069f335041138f0cb141fde9933f - default default] Software Only Crypto initialized 2021-10-29 12:53:28.932 568554 DEBUG barbican.model.repositories [req-aaac01e9-82af-421b-b85a-ff998d904972 ad702ac807f44c73a32a9b7a795b693c d782069f335041138f0cb141fde9933f - default default] Getting session... get_session /usr/lib/python3/dist-packages/barbican/model/repositories.py:364 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers [req-aaac01e9-82af-421b-b85a-ff998d904972 ad702ac807f44c73a32a9b7a795b693c d782069f335041138f0cb141fde9933f - default default] Secret creation failure seen - please contact site administrator.: cryptography.fernet.InvalidToken 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers Traceback (most recent call last): 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/cryptography/fernet.py", line 113, in _verify_signature 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers h.verify(data[-32:]) 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/hmac.py", line 70, in verify 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers ctx.verify(signature) 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/cryptography/hazmat/backends/openssl/hmac.py", line 76, in verify 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers raise InvalidSignature("Signature did not match digest.") 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers cryptography.exceptions.InvalidSignature: Signature did not match digest. 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers During handling of the above exception, another exception occurred: 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers Traceback (most recent call last): 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/barbican/api/controllers/__init__.py", line 102, in handler 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers return fn(inst, *args, **kwargs) 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/barbican/api/controllers/__init__.py", line 88, in enforcer 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers return fn(inst, *args, **kwargs) 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/barbican/api/controllers/__init__.py", line 150, in content_types_enforcer 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers return fn(inst, *args, **kwargs) 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/barbican/api/controllers/secrets.py", line 456, in on_post 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers new_secret, transport_key_model = plugin.store_secret( 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/barbican/plugin/resources.py", line 108, in store_secret 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers secret_metadata = _store_secret_using_plugin(store_plugin, secret_dto, 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/barbican/plugin/resources.py", line 279, in _store_secret_using_plugin 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers secret_metadata = store_plugin.store_secret(secret_dto, context) 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/barbican/plugin/store_crypto.py", line 96, in store_secret 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers response_dto = encrypting_plugin.encrypt( 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/barbican/plugin/crypto/simple_crypto.py", line 76, in encrypt 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers kek = self._get_kek(kek_meta_dto) 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/barbican/plugin/crypto/simple_crypto.py", line 73, in _get_kek 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers return encryptor.decrypt(kek_meta_dto.plugin_meta) 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/cryptography/fernet.py", line 76, in decrypt 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers return self._decrypt_data(data, timestamp, ttl, int(time.time())) 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/cryptography/fernet.py", line 125, in _decrypt_data 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers self._verify_signature(data) 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers File "/usr/lib/python3/dist-packages/cryptography/fernet.py", line 115, in _verify_signature 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers raise InvalidToken 2021-10-29 12:53:28.991 568554 ERROR barbican.api.controllers cryptography.fernet.InvalidToken Any advise how to fix it ? - Ammad

2 1

[all][tc] Technical Committee next weekly meeting on Nov 4th at 1500 UTC
by Ghanshyam Mann 03 Nov '21

03 Nov '21

Hello Everyone, Technical Committee's next weekly meeting is scheduled for Nov 4th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Nov 3rd, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[TripleO] Branching our documentation
by James Slagle 03 Nov '21

03 Nov '21

Hello TripleO Owls, Our documentation, particularly the deploy guide, has become overly complex with all the branches that TripleO has supported over the years. I see notes that document functionality specific to releases all the way back to Mitaka! In ancient history, we made the decision to not branch our documentation because the work to maintain multiple branches outweighed the effort to just document all releases at once in the same branch. I think the scale has now tipped in the other direction. I propose that we create a stable/wallaby in tripleo-docs, and begin making the master branch specific to Yoga. This would also mean we could clean up all the old notes and admonitions about previous releases on the master branch. Going forward, if you make a change to the docs that applies to Yoga and Wallaby, you would need to backport that change to stable/wallaby. If you needed to make a change that applied only to Wallaby (or a prior release), you would make that change only on stable/wallaby. I'm not sure of all the plumbing required to make it so that the OpenStack Wallaby deploy guide builds from stable/wallaby, etc, but I wanted to get the idea out there first for feedback. Please let me know your thoughts. Thank you! -- -- James Slagle --

4 4

[ptl][release][stable][EM] Extended Maintenance - Ussuri
by Előd Illés 03 Nov '21

03 Nov '21

Hi, As Xena was released last week and we are in a less busy period, now it is a good time to call your attention to the following: In a month Ussuri is planned to transition to Extended Maintenance phase [1] (planned date: 2021-11-12). I have generated the list of the current *open* and *unreleased* changes in stable/ussuri for the follows-policy tagged repositories [2] (where there are such patches). These lists could help the teams who are planning to do a *final* release on Ussuri before moving stable/ussuri branches to Extended Maintenance. Feel free to edit and extend these lists to track your progress! * At the transition date the Release Team will tag the *latest* Ussuri releases of repositories with *ussuri-em* tag. * After the transition stable/ussuri will be still open for bug fixes, but there won't be official releases anymore. *NOTE*: teams, please focus on wrapping up your libraries first if there is any concern about the changes, in order to avoid broken (final!) releases! Thanks, Előd [1] https://releases.openstack.org/ [2] https://etherpad.opendev.org/p/ussuri-final-release-before-em

1 1

Attach Nvidia Jetson as compute node to openstack (aarch64)
by Pavlos Basaras 03 Nov '21

03 Nov '21

Hello everyone, I am relatively new to the community, thanks in advance for your time and help. I have an openstack cluster ready, working with several compute nodes based on x86 architecture. My current installation is based on Ussuri. I have recently acquired a couple of nvidia Jetson devices ( https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-ag…) which I want to connect to the cluster. The arm cpu model name is ARMv8 Processor rev 0 (v8l). CPU flags on the arm architecture are different and hence egrep -c '(vmx|svm)' /proc/cpuinfo is empty to the best of my knowledge. However, i re-build the custom linux kernel (i.e, Tegra) of the Jetson device, enabling the KVM module. So once i used: *sudo kvm-ok* INFO: /dev/kvm exists KVM acceleration can be used *dmesg | grep -i kvm* [ 1.372478] kvm [1]: 16-bit VMID [ 1.372489] kvm [1]: IDMAP page: 80fa1000 [ 1.372498] kvm [1]: HYP VA range: 4000000000:7fffffffff [ 1.374185] kvm [1]: Hyp mode initialized successfully [ 1.374299] kvm [1]: vgic-v2@3884000 [ 1.374763] kvm [1]: vgic interrupt IRQ1 [ 1.374790] kvm [1]: virtual timer IRQ4 *dmesg | grep -i 'CPU features'* [ 0.687366] CPU features: detected feature: Privileged Access Never [ 0.687372] CPU features: detected feature: LSE atomic instructions [ 0.687378] CPU features: detected feature: User Access Override [ 0.687385] CPU features: detected feature: 32-bit EL0 Support Does this suffice to say that I can use KVM with libvirt for the nova openstack? The version of libvirt is 6.0.0. >From the nova logs i see the following with *virt_type = qemu* WARNING nova.virt.libvirt.driver [-] The libvirt driver is not tested on qemu/aarch64 by the OpenStack project and thus its quality can not be ensured. For more information, see: https://docs.openstack.org/nova/latest/user/support-matrix.html And as it detects the aarch64 device: CPU mode "host-passthrough" was chosen If i try to launch an instance i get the following error with qemu libvirt.libvirtError: unsupported configuration: CPU mode 'host-passthrough' for aarch64 qemu domain on aarch64 host is not supported by hypervisor where as i i use *virt_type= kvm* the error after trying to launch an instance is libvirt.libvirtError: unsupported configuration: Emulator '/usr/bin/qemu-system-aarch64' does not support virt type 'kvm' Any advice on how to proceed? all the best Pavlos.

1 0

[cinder] Bug deputy report for week of 11-03-2021
by Sofia Enriquez 03 Nov '21

03 Nov '21

This is a bug report from 10-27-2021-15-09 to 11-03-2021. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/cinder/+bug/1949313 'Cinder backup tries to restore to the wrong host'. Assigned to Sam Morrison. - https://bugs.launchpad.net/cinder/+bug/1949189 'NfsDriver' object has no attribute 'manage_existing_get_size'. Unassigned. - https://bugs.launchpad.net/cinder/+bug/1946483 'Error when deleting encrypted volume backup from another project'. Assigned to Pavlo Shchelokovskyy. - https://bugs.launchpad.net/cinder/+bug/1948962 'Quotas: Some operations fail with a 255 volume type name'. Assigned to Gorka. - https://bugs.launchpad.net/cinder/+bug/1949061 '[Storwize] Retype of a non-rep mirror volume to mirror- volume-type with different mirror_pool is failing'. Assigned to Mounika Sreeram. Low - https://bugs.launchpad.net/cinder/+bug/1798589 'No available space check for image_conversion_dir in cinder-volume on upload-to-image'. Unassigned. Cheers -- Sofía Enriquez she/her Software Engineer Red Hat PnT <https://www.redhat.com> IRC: @enriquetaso @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

1 0

[monasca][kolla-ansible] HTTPUnprocessableEntity: Dimension value must be 255 characters or less
by Adam Tomas 03 Nov '21

03 Nov '21

Hi, in my test deployment I get following error messages for each metric at each metric collection (every 60s in my case). Of course whole URL (i.e. /v2.0/metrics/statistics?name=transfer.region2.size&merge_metrics=True&dimensions=project_id%3Afcfaxxxxx&start_time=2021-10-31+02%3A55%3A00%2B02%3A00&end_time=2021-10-31+02%3A00%3A00%2B01%3A00&period=-3300&statistics=avg&group_by=project_id&group_by=resource_id) is longer than 255 characters, but shouldn’t this URL be processed in smaller chunks? As I see the validation is done by monasca_api, so in case it fails no data is processed by monasca_log_transformer, right? Limiting metric name lenght won’t change this situation (in this example metric name is 22 characters long, while the whole URL is 285 characters long, so 285-22 is still > 255). How can I avoid this error? Best regards Adam Tomas 2021-11-02 14:19:44.935 693 ERROR monasca_api.v2.common.bulk_processor [req-a251xxxx 60bexxxx 27bexxxxx - default default] Log transformation failed, rejecting log: monasca_api.api.core.log.exceptions.HTTPUnprocessableEntity: Dimension value /v2.0/metrics/statistics?name=transfer.region2.size&merge_metrics=True&dimensions=project_id%3Afcfaxxxxx&start_time=2021-10-31+02%3A55%3A00%2B02%3A00&end_time=2021-10-31+02%3A00%3A00%2B01%3A00&period=-3300&statistics=avg&group_by=project_id&group_by=resource_id must be 255 characters or less 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor [req-a251xxxx 60bexxxx 27bexxxx - default default] Dimension value /v2.0/metrics/statistics?name=transfer.region2.size&merge_metrics=True&dimensions=project_id%3Afcfaxxx&start_time=2021-10-31+02%3A55%3A00%2B02%3A00&end_time=2021-10-31+02%3A00%3A00%2B01%3A00&period=-3300&statistics=avg&group_by=project_id&group_by=resource_id must be 255 characters or less: monasca_api.api.core.log.exceptions.HTTPUnprocessableEntity: Dimension value /v2.0/metrics/statistics?name=transfer.region2.size&merge_metrics=True&dimensions=project_id%3Afcfaxxxx&start_time=2021-10-31+02%3A55%3A00%2B02%3A00&end_time=2021-10-31+02%3A00%3A00%2B01%3A00&period=-3300&statistics=avg&group_by=project_id&group_by=resource_id must be 255 characters or less 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor Traceback (most recent call last): 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor File "/var/lib/kolla/venv/lib/python3.8/site-packages/monasca_api/v2/common/bulk_processor.py", line 81, in _transform_message 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor dimensions=self._get_dimensions(log_element, 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor File "/var/lib/kolla/venv/lib/python3.8/site-packages/monasca_api/v2/common/bulk_processor.py", line 129, in _get_dimensions 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor validation.validate_dimensions(local_dims) 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor File "/var/lib/kolla/venv/lib/python3.8/site-packages/monasca_api/api/core/log/validation.py", line 138, in validate_dimensions 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor _validate_dimension_value(dim_value) 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor File "/var/lib/kolla/venv/lib/python3.8/site-packages/monasca_api/api/core/log/validation.py", line 114, in _validate_dimension_value 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor raise exceptions.HTTPUnprocessableEntity( 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor monasca_api.api.core.log.exceptions.HTTPUnprocessableEntity: Dimension value /v2.0/metrics/statistics?name=transfer.region2.size&merge_metrics=True&dimensions=project_id%3Afcfaxxxx&start_time=2021-10-31+02%3A55%3A00%2B02%3A00&end_time=2021-10-31+02%3A00%3A00%2B01%3A00&period=-3300&statistics=avg&group_by=project_id&group_by=resource_id must be 255 characters or less 2021-11-02 14:19:44.936 693 ERROR monasca_api.v2.common.bulk_processor

1 1

[neutron][ovs] Different Cookie with Remote Security group
by Mohan Kumar 03 Nov '21

03 Nov '21

Team, I've created a security group with a remote security group attached to it. openstack security group rule create --ethertype=IPv4 --protocol tcp > --remote-group server-grp --ingress --dst-port=22 application-grp when I create VM with server-grp , I can see two cookies in br-int ovs bridge, one with default cookie and another new cookie with conjunction flows, is it expected behavior? ubuntu@req-generic-65-d012-mn:~$ sudo ovs-ofctl dump-flows br-int | awk '{print $1}' | sort -n | uniq cookie=0x12b7adbe73614620, cookie=0x207d02d6bbcf499e, NXST_FLOW ubuntu@req-generic-65-d012-mn:~$ sudo ovs-ofctl dump-flows br-int | grep "0x207d02d6bbcf499e" cookie=0x207d02d6bbcf499e, duration=335.421s, table=82, n_packets=0, n_bytes=0, idle_age=335, priority=70,ct_state=+est-rel-rpl,ipv6,reg6=0x1,ipv6_src=fdd8:a3ce:31ae:0:f816:3eff:fe8a:f751 actions=conjunction(8,1/2) cookie=0x207d02d6bbcf499e, duration=335.420s, table=82, n_packets=0, n_bytes=0, idle_age=335, priority=70,ct_state=+new-est,ipv6,reg6=0x1,ipv6_src=fdd8:a3ce:31ae:0:f816:3eff:fe8a:f751 actions=conjunction(9,1/2) cookie=0x207d02d6bbcf499e, duration=335.420s, table=82, n_packets=0, n_bytes=0, idle_age=335, priority=70,ct_state=+est-rel-rpl,ip,reg6=0x1,nw_src=10.0.0.38 actions=conjunction(16,1/2) cookie=0x207d02d6bbcf499e, duration=335.420s, table=82, n_packets=0, n_bytes=0, idle_age=335, priority=70,ct_state=+new-est,ip,reg6=0x1,nw_src=10.0.0.38 actions=conjunction(17,1/2)

2 2

[Openstack-victoria] [Openstack-queens] migration of VM from openstack queens to victoria
by Swogat Pradhan 02 Nov '21

02 Nov '21

Hi, I have 2 openstack setups Setup1. Openstack queens + ceph nautilaus Setup2. Openstack victoria + ceph octopus So, I am trying to migrate some VM's (windows and linux) from Setup1 to Setup2. For migrating the VM's i am using rbd export on setup1 and then rbd import on setup2. I have successfully migrated 21 VM's. i am now facing an issue in the 22nd vm which, after migrating the VM the vm is stuck in the windows logo screen and not moving forward, and i can't seem to understand how to approach it. Attached the instance.xml files of both queens and victoria setup's of the same VM. With regards, Swogat pradhan

2 3

Accessing Openstack using v3 API
by open infra 02 Nov '21

02 Nov '21

Hi, I was trying to use the openstack environment using the v3 client API as mentioned in [2] documentation but ended up with an error as mentioned in [1]. I can access the same environment v3 API using curl. Am I missing something? [1] https://paste.opendev.org/show/810336/ [2] https://docs.openstack.org/python-keystoneclient/latest/using-api-v3.html Regards, Danishka

2 2

[neutron][ovn] Stateless Security Group
by Ammad Syed 02 Nov '21

02 Nov '21

Hi, I have upgraded my lab to latest xena release and ovn 21.09 and ovs 2.16. I am trying to create stateless security group. But its getting failed with below error message. # openstack security group create --stateless sec02-stateless Error while executing command: BadRequestException: 400, Unrecognized attribute(s) 'stateful' I see below logs in neutron server logs. 2021-11-02 12:47:41.921 1346 DEBUG neutron.wsgi [-] (1346) accepted ('172.16.40.45', 41272) server /usr/lib/python3/dist-packages/eventlet/wsgi.py:992 2021-11-02 12:47:42.166 1346 DEBUG neutron.api.v2.base [req-b6a37fff-090f-4754-9df7-6e4314ed9481 19844bf62a7b498eb443508ef150e9b8 98687873a146418eaeeb54a01693669f - default default] Request body: {'security_group': {'name': 'sec02-stateless', 'stateful': False, 'description': 'sec02-stateless'}} prepare_request_body /usr/lib/python3/dist-packages/neutron/api/v2/base.py:729 2021-11-02 12:47:42.167 1346 WARNING neutron.api.v2.base [req-b6a37fff-090f-4754-9df7-6e4314ed9481 19844bf62a7b498eb443508ef150e9b8 98687873a146418eaeeb54a01693669f - default default] An exception happened while processing the request body. The exception message is [Unrecognized attribute(s) 'stateful'].: webob.exc.HTTPBadRequest: Unrecognized attribute(s) 'stateful' 2021-11-02 12:47:42.167 1346 INFO neutron.api.v2.resource [req-b6a37fff-090f-4754-9df7-6e4314ed9481 19844bf62a7b498eb443508ef150e9b8 98687873a146418eaeeb54a01693669f - default default] create failed (client error): Unrecognized attribute(s) 'stateful' 2021-11-02 12:47:42.168 1346 INFO neutron.wsgi [req-b6a37fff-090f-4754-9df7-6e4314ed9481 19844bf62a7b498eb443508ef150e9b8 98687873a146418eaeeb54a01693669f - default default] 172.16.40.45 "POST /v2.0/security-groups HTTP/1.1" status: 400 len: 317 time: 0.2455938 Any advice on how to fix it ? Ammad

3 10

[neutron] CI meeting - Tuesday 02.11.2021
by Slawek Kaplonski 02 Nov '21

02 Nov '21

Hi, As we discussed during the PTG and in the last week's CI meeting, this week's meeting will be a video call. Please join https://meetpad.opendev.org/neutron-ci-meetings at 300pm UTC if You are interested in the Neutron CI. We will also keep meeting opened in the #openstack-neutron irc channel in case if anyone would like to participate that way. Agenda for the meeting is at https://etherpad.opendev.org/p/neutron-ci-meetings -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[neutron] Bug Deputy Report Oct 25 - 31
by Oleg Bondarev 02 Nov '21

02 Nov '21

Hi everyone, Please find Bug Deputy report for the week Oct 25 - 31st below. 1 Critical bug in stable/train already in progress; 1 High bug looks for an assignee. Several OVN bug needs some triage from OVN folks + assignees. Critical - https://bugs.launchpad.net/neutron/+bug/1948804 - [stable/train] neutron-tempest-plugin scenario jobs fail "sudo: guestmount: command not found" o In Progress: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/815518 o Assigned to bcafarel High - https://bugs.launchpad.net/neutron/+bug/1948832 - "_disable_ipv6_addressing_on_interface" can't find the interface o Confirmed o Unassigned Medium - https://bugs.launchpad.net/neutron/+bug/1948676 - rpc response timeout for agent report_state is not possible Edit o Fix released: https://review.opendev.org/c/openstack/neutron/+/815310 o Fixed by Tobias Urdin - https://bugs.launchpad.net/bugs/1948642 - Configuration of the ovs controller by neutron-ovs-agent isn't idempotent Edit o In progress: https://review.opendev.org/c/openstack/neutron/+/815255 o Assigned to slaweq - https://bugs.launchpad.net/neutron/+bug/1948891 - [ovn] Using ovsdb-client for MAC_Binding could theoretically block indefinitely o Confirmed o Unassigned - https://bugs.launchpad.net/neutron/+bug/1949059 - ovn-octavia-provider: incorrect router association in NB when network is linked to more than 1 router o Confirmed o Unassigned - https://bugs.launchpad.net/neutron/+bug/1949081 - [OVN] check_for_mcast_flood_reports maintenance task not accounting for localnet "mcast_flood" changes o Confirmed o Assigned to lucasgomes Undecided - https://bugs.launchpad.net/neutron/+bug/1949097 - Cloud-Init cannot contact Meta-Data-Service on Xena with OVN o New o Unassigned - https://bugs.launchpad.net/neutron/+bug/1949202 - ovn-controllers are listed as agents but cannot be disabled o New o Unassigned - https://bugs.launchpad.net/neutron/+bug/1949230 - OVN Octavia provider driver should implement allowed_cidrs to enforce security groups on LB ports o New o Unassigned Invalid - https://bugs.launchpad.net/neutron/+bug/1948656 - toggling explicitly_egress_direct from true to false does not clean flows Thanks, Oleg --- Advanced Software Technology Lab Huawei

1 0

[horizon] Skip tomorrow Weekly IRC Meeting
by vishal manchanda 01 Nov '21

01 Nov '21

Hi all, As discussed, during the last weekly meeting[1], there will be no horizon weekly meeting tomorrow. See you next week! Thanks & regards, Vishal Manchanda [1] https://meetings.opendev.org/meetings/horizon/2021/horizon.2021-10-27-15.00…

1 0

[tacker][ptg] Yoga PTG summary
by yasufum 01 Nov '21

01 Nov '21

Hi everyone, Thank you for participating in the Yoga PTG sessions. We discussed 17 items totally, including 13 specs, and agreed all to implement the proposed features. We also decided to set the spec freeze on 31th Dec. The etherpad of our PTG is at https://etherpad.opendev.org/p/tacker-yoga-ptg Here is a summary of the PTG sessions. *Day 1 1. Introduce for Tacker installer * To reduce uinteresting steps of setting up tacker, we introduce a dedicated installer for developers. * For beginners, we should minimize difficulties of deploying and make them focusing on their usecases. 2. Prometheus monitoring and AutoHeal support for Kubernetes Cluster VNF via FM Interface * Add fault management interface support applied with ETSI SOL003 standards including polling mode and notify mode. * Polling mode responds to resources that is named "Alarms" and "Individual alarm". On the other hand, notify mode responds to resources that is named "Subscriptions" and "Notification endpoint" 3. Support VNF update operations reflecting changes to VNF instances using MgmtDriver * Add update APIs for container VNF instances by using ConfigMap and Secret of k8s. 4. Support CentOS stream * Revise our current incomplete CentOS support for the latest 'stream'. * We will provide some functional tests for the update, but non-voting for a while. 5. Add VNF Package sample for practical use cases * Provide more practical examples of usecase of tacker for users because current usecases in documentation are simple and not enough so much for actual cases. * There are three examples supposed in the proposal, "use multiple deployment flavours", "deploy VNF connected to external network" and "deploy VNF as HA cluster". *Day 2 6. Support handling large query results by ETSI NFV * Introduce an extended feature for reducing a large amount of result for some queries defined in ETSI standards. * The idea is simply dividing the results in several pieces with paging. 7. Support FT of Multi tenant * There are two problems in multi-tenancy case, (1) No restriction in assigning a tenant,(2) Notifying events on different tenants. * The policy of assigning a tenant should be clarified and also Notification process under multi-tenancy should be changed. * We need to clear the policy of RBAC (Is it allowed to make admin user can access all resources?) 8. Sample Ansible Driver * There are no management drivers enable VNF Configuration using Ansible. So, add the scripts as samples and docs. * Revise the name of directories for considering conventioins in takcer repo is necessary. * This can be used for 'Add VNF Package sample for practical use cases' proposal. We wii support the sample development. 9. Support Robot Framework API * Currently Tacker functional tests mainly focus on checking various VNF patterns such as a simple VNF, multi VDU, volume attach and affinity set. Tacker community is advancing ETSI NFV standard compliance, and coverage of compliant API testing becomes important. * The proposal is to use Robot Framework to achieve automated API testing and in the first step, we adopt API test code released by ETSI NFV-TST010. 10. Add Tacker-horizon Unit Test Cases * `tacker-horizon` which provides very limited features, such as showing a list of registered VIMs, VNFDs or so. We don't use this feature so much without checking instances of Tacker quickly via intuitive Web GUI way. So, we have not maintained tacker-horizon so actively * One of the reasons why bugs in tacker-horizon have not fixed is that we have no unittests in. Although we can find a bug coincidentally while using the features, but should implement unittests because bugs in horizon are some contextual and not so easy to find by hand. *Day 3 11. Report for ETSI NFV API Conformance Test Results * Share the result of Remote NFV&MEC API Plugtest 2021, Totally 136 API Conformance test sessions were executed for [NFV-SOL003] were executed as well as for NFV-SOL005. * https://hackmd.io/q4DzQ6_2Q0e-TdmtBikVlQ?view 12. Reduce code clone from sol-kubernetes job of FT * There are much similar files can be reduced for functional tests. It makes maintenance more complicated and difficult. The goal is to reduce it to less than 20%. * In particular, since sol_kubernetes's code clone rate is up to 40% , we think it will be better to refactor to make future maintenance easier. * other details: https://hackmd.io/Wo8cBIH_RPe6ll1hNwmx1w?view 13. Reduce unnecessary test codes * It's similar as above item. We have very similar YAML files for definitions and useless template files for tests can be reduced. 14. Enhance NFV SOL_v3 LCM operation * Introduce the latest V2 APIs for LCM operation as below. * Scale VNF (POST /vnf_instances/{vnfInstanceId}/scale) * Heal VNF (POST /vnf_instances/{vnfInstanceId}/heal) * Modify VNF Information (PATCH /vnf_instances/{vnfInstanceId}) * Change External VNF Connectivity (POST /vnf_instances/{vnfInstanceId}/change_ext_conn) 15. Support ETSI NFV-SOL_v3 based error-handling operation * Introduce the latest V2 APIs for error handling operation as below. * Retry operation (POST /vnf_lcm_op_occs/{vnfLcmOpOccId}/retry) * Fail operation (POST /vnf_lcm_op_occs/{vnfLcmOpOccId}/fail) * Rollback operation (POST /vnf_lcm_op_occs/{vnfLcmOpOccId}/rollback) * Test scenario needs to include raising an error, becoming FAILD_TEMP, and executing the ErrorHandling API. * Timer adjusting and using inapporpriate vnf package can cause error. 16. Support ChangeCurrentVNFPackage * Add API for ChangeCurrentVNFPackage by which blue-green deployment and rolling update are supported. * Both of VIMs, OpenStack and Kubernetes, are covered. 17. Support heal and scale method in lcm_user_data * Enable to customize stack parameters for heal and scale operations in user script, `user_lcm_data.py` more specifically. * Call the proposed methods if it's existing in the script for the operations. Thanks, Yasufumi

1 0

[horizon][dev]Handle multiple login sessions from same user in Horizon
by Luz de Avila, Arthur 01 Nov '21

01 Nov '21

Hi everyone, In order to improve the system my colleagues and I would like to bring up a new feature to Horizon. We found out that an user is able to login in Horizon with the same credentials in multiple devices or/and browsers. This may be not very secure as the user can login in many different devices or/and browsers with the same credential. Thinking on that, we would like bring up more control to the admin of the system in a way that the admin can enable or disable the multiple login sessions according to the needs of the system. For a better follow up of this propose, a blueprint has been opened with more details about the idea and concepts of this and we would like the onion of the community whether this feature make sense to implement or not. The blueprint opened on launchpad: https://blueprints.launchpad.net/horizon/+spec/handle-multiple-login-sessio… Kind regards, Arthur Avila

2 1

[charms] Yoga PTG Summary
by Alex Kavanagh 01 Nov '21

01 Nov '21

Hi All Thanks to all who participated in the PTG discussions. We had some good sessions where we tackled thorny issues in the charms deployments of OpenStack. A brief set of highlights is: - The store holding all the charms (https://jaas.ai/) just happens to be migrating to a new home (https://charmhub.io/) within the timescales of the Yoga cycle and some of the changes in behaviour provide some challenges and also opportunities to both simplify the charms and provide a better operator experience. The discussions highlighted the pain points and the general direction that the migration could take around: - Charm upgrades - OpenStack upgrades - Series upgrades of the underlying operating system. - The charms deployment of OpenStack supports versions back to mitaka (pre yoga) and queens (yoga cycle onwards). This has recently presented challenges around Python 3 support, particularly with py35 being EOL September 2020, and with py36 (bionic LTS) EOL 23rd December 2021. We discussed various strategies and approaches around maintenance, security and support of queens onwards in terms of support and upgrades. - The charms team also maintains a CI infrastructure based on Jenkins and (more recently) self-hosted Zuul to test installation and upgrade of OpenStack solutions. We discussed the further migrations of services from Jenkins to Zuul and issues associated with it. - Discussions around building new charms and refreshing old charms for the new components and features in the previous xena cycle and oncoming yoga cycle. Our raw notes are here: https://etherpad.opendev.org/p/charms-yoga-ptg Thank you again for all the participation in setting the direction and priorities for the yoga cycle. -- Alex Kavanagh - PTL Yoga

1 0

Openstack ansible VS kolla ansible
by A Monster 01 Nov '21

01 Nov '21

Openstack-ansible uses LXC containers to deploy openstack services , while Kolla uses docker containers instead, which of these two deployment tools should I use for an Openstack deployment, and what are the differences between them.

3 2

is OVS+DPDK useful for general purpose workload
by Satish Patel 01 Nov '21

01 Nov '21

Folks, I have deployed openstack and configured OVS-DPDK on compute nodes for high performance networking. My workload is general purpose workload like running haproxy, mysql, apache and XMPP etc. When I did load testing I found performance was average and after 200kpps packet rate I noticed packet drops. I heard and read that DPDK can handle millions of packets but in my case its not true. I am using virtio-net in guest vm which processes packets in the kernel so I believe my bottleneck is my guest VM. I don't have any guest based DPDK applications like testpmd etc. does that mean OVS+DPDK isn't useful for my cloud? How do I take advantage of OVS+DPDK with general purpose workload? Maybe I have the wrong understanding about DPDK so please help me :) Thanks ~S

2 2

Re: Using ceph for openstack storage
by A Monster 01 Nov '21

01 Nov '21

Thank you for your response. Sadly, I'm talking about actual production, but I'm very limited in terms of hardware. I was thinking about using RAID for controller node as data redundancy, because I had the idea of maximizing the number of nova compute nodes, So basically i thought off using a controller with the following services ( Nova, Neutron, Keystone, Horizon, Glance, Cinder and Swift). Following the configuration you suggested, I would have : - 3 Controllers that are also Ceph Monitors - 9 Nova compute nodes and Ceph OSDs My questions are : - having multiple Ceph monitors is for the sake of redundancy or does it have a performance goal ? - Combining Ceph OSD and Nova compute wouldn't have performance drawbacks or damage the integrity of data stored in each node. wouldn't it be better is this case to use two separate servers for swift and glance and use RAID for data redundancy instead of using Ceph SDS. Thank you very much for you time.

3 2

Re: Router interfaces are down
by Slawek Kaplonski 01 Nov '21

01 Nov '21

Hi, Please don't drop ML from the thread. You have to go to the node where Your router is hosted and investigate there in the agent's logs. If ports are DOWN, I would start with checking in the L2 agent logs (neutron-ovs-agent or linuxbridge-agent, idk what You are using exactly). If there is no any errors there, You can also check neutron-server logs, why ports aren't set to be UP as well as checking neutron-l3-agent logs on the node where router is hosted. On czwartek, 28 października 2021 18:41:29 CET Jibsan Joel Rosa Toirac wrote: > Here I let you some screenshots of my Network Topology: > > > > El jue, 28 oct 2021 a las 7:43, Jibsan Joel Rosa Toirac (<jibsan94(a)gmail.com>) > escribió: > > Yes it’s neutron router. Well the router is centralized. It is located > > between the subnets and the node, all the subnets will pass through the > > router to internet, but I don’t know what else check to set it up for. I’m > > using a friend’s Openstack instance on a server to check out if I’m missing > > something and both nodes are the same. I will send you a screenshot of my > > network Topology. > > > > Greetings > > > > On Thu, Oct 28, 2021 at 2:33 AM Slawek Kaplonski <skaplons(a)redhat.com> > > > > wrote: > >> Hi, > >> > >> On środa, 27 października 2021 21:39:55 CEST Jibsan Joel Rosa Toirac > >> > >> wrote: > >> > Hello, I'm trying to route all the requests from a private vlan to > >> > internet. I have a private network and all the Virtual Machines inside > >> > >> the > >> > >> > subnet config can do everything between they, but if I ping to > >> > >> Internet, it > >> > >> > doesn't work. > >> > > >> > When I see the router_external it says all the interfaces are DOWN. > >> > >> By router_external, You mean neutron router, right? > >> If so, what kind of router it is, centralized HA or non-HA, or maybe DVR? > >> Is router scheduled properly to some node? You can check that with > >> command > >> like "neutron l3-agent-list-hosting-router <router_id>". > >> > >> > I have search in everywhere but I can't find a solution for this. > >> > > >> > Thank you for your time > >> > >> -- > >> Slawek Kaplonski > >> Principal Software Engineer > >> Red Hat -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[Diversity] Diversity and Inclusion Meeting Reminder
by Amy Marrich 31 Oct '21

31 Oct '21

The Diversity & Inclusion WG invites members of all OIF projects to attend our next meeting Monday November 1st, at 17:00 UTC in the #openinfra- diversity channel on OFTC. The agenda can be found at https://etherpad.openstack.org/p/diversity-wg-agenda. Please feel free to add any topics you wish to discuss at the meeting. Thanks, Amy (apotz)

1 0

Using ceph for openstack storage
by A Monster 31 Oct '21

31 Oct '21

I'm in the process of deploying an Openstack cloud and I've been aiming at maximize the number of computing node and in order to do that I've thought of using Ceph distributed storage and use an All in one openstack deployment, so that swift objects and glance's blocks are stored through Ceph. I have a total of 12 servers, so I'll end up with 1 Controller node for openstack services and use the remaining nodes for ceph cluster and computing. Is it worth it to use a ceph storage system , and what would be the minimum number of nodes required to deploy it.

2 1

Re: kolla-ansible wallaby manila ceph pacific
by wodel youchi 30 Oct '21

30 Oct '21

Hi, To *Buddhika Godakuru* I took a look into the manila-share docker deployed on my platforme and it contains the patch you mentioned in [1]. The Manila code does integrate the ceph test for version. [1] https://review.opendev.org/c/openstack/manila/+/797955 Regards. Le mar. 26 oct. 2021 à 09:06, wodel youchi <wodel.youchi(a)gmail.com> a écrit : > Hi, > My deployment is from source, and I have little experience on how to > rebuild docker images, I can perhaps pull new images (built recently I > mean). > I took a look into docker hub and there are new manila images pushed 2 > days ago. > > Regards. > > Le lun. 25 oct. 2021 à 19:23, Buddhika Godakuru <bsanjeewa(a)kln.ac.lk> a > écrit : > >> Is your deployment type is source or binary? >> If it is binay, I wonder if this patch [1] is built into the repos. >> If source, could you try rebuilding the manila docker images? >> >> [1] https://review.opendev.org/c/openstack/manila/+/797955 >> >> On Mon, 25 Oct 2021 at 20:21, wodel youchi <wodel.youchi(a)gmail.com> >> wrote: >> >>> Hi, >>> >>> I tried with pacific then with octopus, the same problem. >>> The patch was applied to kolla-ansible. >>> >>> Regards. >>> >>> Le ven. 22 oct. 2021 00:34, Goutham Pacha Ravi <gouthampravi(a)gmail.com> >>> a écrit : >>> >>>> >>>> >>>> On Thu, Oct 21, 2021 at 1:56 AM wodel youchi <wodel.youchi(a)gmail.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I did that already, I changed the keyring to "*ceph auth >>>>> get-or-create client.manila -o manila.keyring mgr 'allow rw' mon 'allow r'* >>>>> " it didn't work, then I tried with ceph octopus, same error. >>>>> I applied the patch, then I recreated the keyring for manila as >>>>> wallaby documentation, I get the error "*Bad target type 'mon-mgr'*" >>>>> >>>> >>>> Thanks, the error seems similar to this issue: >>>> https://tracker.ceph.com/issues/51039 >>>> >>>> Can you confirm the ceph version installed? On the ceph side, some >>>> changes land after GA and get back ported; >>>> >>>> >>>> >>>>> >>>>> Regards. >>>>> >>>>> Le jeu. 21 oct. 2021 à 05:29, Buddhika Godakuru <bsanjeewa(a)kln.ac.lk> >>>>> a écrit : >>>>> >>>>>> Dear Wodel, >>>>>> I think this is because manila has changed the way how to set/create >>>>>> auth ID in Wallaby for native CephFS driver. >>>>>> For the patch to work, you should change the command >>>>>> *ceph auth get-or-create client.manila mon 'allow r' mds 'allow r, >>>>>> allow rw path=/' osd 'allow rw pool=cephfs_data' mgr 'allow rw'* >>>>>> to something like, >>>>>> ceph auth get-or-create client.manila -o manila.keyring mgr 'allow >>>>>> rw' mon 'allow r' >>>>>> >>>>>> Please see Manila Wallaby CephFS Driver document [1] >>>>>> >>>>>> Hope this helps. >>>>>> >>>>>> Thank you >>>>>> [1] >>>>>> https://docs.openstack.org/manila/wallaby/admin/cephfs_driver.html#authoriz… >>>>>> >>>>>> On Wed, 20 Oct 2021 at 23:19, wodel youchi <wodel.youchi(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hi, and thanks >>>>>>> >>>>>>> I tried to apply the patch, but it didn't work, this is the >>>>>>> manila-share.log. >>>>>>> By the way, I did change to caps for the manila client to what is >>>>>>> said in wallaby documentation, that is : >>>>>>> [client.manila] >>>>>>> key = keyyyyyyyy..... >>>>>>> >>>>>>> * caps mgr = "allow rw" caps mon = "allow r"* >>>>>>> >>>>>>> [root@ControllerA manila]# cat manila-share.log >>>>>>> 2021-10-20 10:03:22.286 7 INFO oslo_service.periodic_task [-] >>>>>>> Skipping periodic task update_share_usage_size because it is disabled >>>>>>> 2021-10-20 10:03:22.310 7 INFO oslo_service.service >>>>>>> [req-5b253656-4fe2-4087-b4ab-9ba2a8a0443f - - - - -] Starting 1 workers >>>>>>> 2021-10-20 10:03:22.315 30 INFO manila.service [-] Starting >>>>>>> manila-share node (version 12.0.1) >>>>>>> 2021-10-20 10:03:22.320 30 INFO manila.share.drivers.cephfs.driver >>>>>>> [req-9e549670-d131-4572-b57e-761b513abc75 - - - - -] [CEPHFS1] Cep >>>>>>> h client found, connecting... >>>>>>> 2021-10-20 10:03:22.368 30 INFO manila.share.drivers.cephfs.driver >>>>>>> [req-9e549670-d131-4572-b57e-761b513abc75 - - - - -] [CEPHFS1] Cep >>>>>>> h client connection complete. >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager >>>>>>> [req-9e549670-d131-4572-b57e-761b513abc75 - - - - -] Error encountered >>>>>>> during i >>>>>>> n*itialization* >>>>>>> >>>>>>> * of driver CephFSDriver@ControllerA@cephfsnative1: >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix=fs >>>>>>> volume ls, argdict={'format': 'json'} - exception message: Bad target type >>>>>>> 'mon-mgr'. 2021-10-20 10:03:22.372 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): * >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 191, in rados_command >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager >>>>>>> timeout=RADOS_TIMEOUT) >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1460, in json_ >>>>>>> command >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager inbuf, >>>>>>> timeout, verbose) >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1330, in send_ >>>>>>> command_retry >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager return >>>>>>> send_command(*args, **kwargs) >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1412, in send_ >>>>>>> command >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager raise >>>>>>> ArgumentValid("Bad target type '{0}'".format(target[0])) >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager >>>>>>> ceph_argparse.ArgumentValid: Bad target type 'mon-mgr' >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager During >>>>>>> handling of the above exception, another exception occurred: >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py >>>>>>> ", line 346, in _driver_setup >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager >>>>>>> self.driver.do_setup(ctxt) >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 251, in do_setup >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager >>>>>>> volname=self.volname) >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 401, in volname >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager >>>>>>> self.rados_client, "fs volume ls", json_obj=True) >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 205, in rados_command >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager raise >>>>>>> exception.ShareBackendException(msg) >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix=fs >>>>>>> volume >>>>>>> ls, argdict={'format': 'json'} - exception message: Bad target type >>>>>>> 'mon-mgr'. >>>>>>> 2021-10-20 10:03:22.372 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager >>>>>>> [req-9e549670-d131-4572-b57e-761b513abc75 - - - - -] Error encountered >>>>>>> during i >>>>>>> nitialization of driver CephFSDriver@ControllerA@cephfsnative1: >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix= >>>>>>> fs volume ls, argdict={'format': 'json'} - exception message: Bad >>>>>>> target type 'mon-mgr'. >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 191, in rados_command >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager >>>>>>> timeout=RADOS_TIMEOUT) >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1460, in json_ >>>>>>> command >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager inbuf, >>>>>>> timeout, verbose) >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1330, in send_ >>>>>>> command_retry >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager return >>>>>>> send_command(*args, **kwargs) >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1412, in send_ >>>>>>> command >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager raise >>>>>>> ArgumentValid("Bad target type '{0}'".format(target[0])) >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager >>>>>>> ceph_argparse.ArgumentValid: Bad target type 'mon-mgr' >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager During >>>>>>> handling of the above exception, another exception occurred: >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py >>>>>>> ", line 346, in _driver_setup >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager >>>>>>> self.driver.do_setup(ctxt) >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 251, in do_setup >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager >>>>>>> volname=self.volname) >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 401, in volname >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager >>>>>>> self.rados_client, "fs volume ls", json_obj=True) >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 205, in rados_command >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager raise >>>>>>> exception.ShareBackendException(msg) >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix=fs >>>>>>> volume >>>>>>> ls, argdict={'format': 'json'} - exception message: Bad target type >>>>>>> 'mon-mgr'. >>>>>>> 2021-10-20 10:03:26.379 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager >>>>>>> [req-9e549670-d131-4572-b57e-761b513abc75 - - - - -] Error encountered >>>>>>> during i >>>>>>> nitialization of driver CephFSDriver@ControllerA@cephfsnative1: >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix= >>>>>>> fs volume ls, argdict={'format': 'json'} - exception message: Bad >>>>>>> target type 'mon-mgr'. >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 191, in rados_command >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager >>>>>>> timeout=RADOS_TIMEOUT) >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1460, in json_ >>>>>>> command >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager inbuf, >>>>>>> timeout, verbose) >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1330, in send_ >>>>>>> command_retry >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager return >>>>>>> send_command(*args, **kwargs) >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1412, in send_ >>>>>>> command >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager raise >>>>>>> ArgumentValid("Bad target type '{0}'".format(target[0])) >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager >>>>>>> ceph_argparse.ArgumentValid: Bad target type 'mon-mgr' >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager During >>>>>>> handling of the above exception, another exception occurred: >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py >>>>>>> ", line 346, in _driver_setup >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager >>>>>>> self.driver.do_setup(ctxt) >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 251, in do_setup >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager >>>>>>> volname=self.volname) >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 401, in volname >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager >>>>>>> self.rados_client, "fs volume ls", json_obj=True) >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 205, in rados_command >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager raise >>>>>>> exception.ShareBackendException(msg) >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix=fs >>>>>>> volume >>>>>>> ls, argdict={'format': 'json'} - exception message: Bad target type >>>>>>> 'mon-mgr'. >>>>>>> 2021-10-20 10:03:34.387 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager >>>>>>> [req-9e549670-d131-4572-b57e-761b513abc75 - - - - -] Error encountered >>>>>>> during i >>>>>>> nitialization of driver CephFSDriver@ControllerA@cephfsnative1: >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix= >>>>>>> fs volume ls, argdict={'format': 'json'} - exception message: Bad >>>>>>> target type 'mon-mgr'. >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 191, in rados_command >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager >>>>>>> timeout=RADOS_TIMEOUT) >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1460, in json_ >>>>>>> command >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager inbuf, >>>>>>> timeout, verbose) >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1330, in send_ >>>>>>> command_retry >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager return >>>>>>> send_command(*args, **kwargs) >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1412, in send_ >>>>>>> command >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager raise >>>>>>> ArgumentValid("Bad target type '{0}'".format(target[0])) >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager >>>>>>> ceph_argparse.ArgumentValid: Bad target type 'mon-mgr' >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager During >>>>>>> handling of the above exception, another exception occurred: >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py >>>>>>> ", line 346, in _driver_setup >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager >>>>>>> self.driver.do_setup(ctxt) >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 251, in do_setup >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager >>>>>>> volname=self.volname) >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 401, in volname >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager >>>>>>> self.rados_client, "fs volume ls", json_obj=True) >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 205, in rados_command >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager raise >>>>>>> exception.ShareBackendException(msg) >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix=fs >>>>>>> volume >>>>>>> ls, argdict={'format': 'json'} - exception message: Bad target type >>>>>>> 'mon-mgr'. >>>>>>> 2021-10-20 10:03:50.404 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager >>>>>>> [req-9e549670-d131-4572-b57e-761b513abc75 - - - - -] Error encountered >>>>>>> during i >>>>>>> nitialization of driver CephFSDriver@ControllerA@cephfsnative1: >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix= >>>>>>> fs volume ls, argdict={'format': 'json'} - exception message: Bad >>>>>>> target type 'mon-mgr'. >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 191, in rados_command >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager >>>>>>> timeout=RADOS_TIMEOUT) >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1460, in json_ >>>>>>> command >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager inbuf, >>>>>>> timeout, verbose) >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1330, in send_ >>>>>>> command_retry >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager return >>>>>>> send_command(*args, **kwargs) >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1412, in send_ >>>>>>> command >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager raise >>>>>>> ArgumentValid("Bad target type '{0}'".format(target[0])) >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager >>>>>>> ceph_argparse.ArgumentValid: Bad target type 'mon-mgr' >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager During >>>>>>> handling of the above exception, another exception occurred: >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py >>>>>>> ", line 346, in _driver_setup >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager >>>>>>> self.driver.do_setup(ctxt) >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 251, in do_setup >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager >>>>>>> volname=self.volname) >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 401, in volname >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager >>>>>>> self.rados_client, "fs volume ls", json_obj=True) >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 205, in rados_command >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager raise >>>>>>> exception.ShareBackendException(msg) >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix=fs >>>>>>> volume >>>>>>> ls, argdict={'format': 'json'} - exception message: Bad target type >>>>>>> 'mon-mgr'. >>>>>>> 2021-10-20 10:04:22.436 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager >>>>>>> [req-9e549670-d131-4572-b57e-761b513abc75 - - - - -] Error encountered >>>>>>> during i >>>>>>> nitialization of driver CephFSDriver@ControllerA@cephfsnative1: >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix= >>>>>>> fs volume ls, argdict={'format': 'json'} - exception message: Bad >>>>>>> target type 'mon-mgr'. >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 191, in rados_command >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager >>>>>>> timeout=RADOS_TIMEOUT) >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1460, in json_ >>>>>>> command >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager inbuf, >>>>>>> timeout, verbose) >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1330, in send_ >>>>>>> command_retry >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager return >>>>>>> send_command(*args, **kwargs) >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1412, in send_ >>>>>>> command >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager raise >>>>>>> ArgumentValid("Bad target type '{0}'".format(target[0])) >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager >>>>>>> ceph_argparse.ArgumentValid: Bad target type 'mon-mgr' >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager During >>>>>>> handling of the above exception, another exception occurred: >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py >>>>>>> ", line 346, in _driver_setup >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager >>>>>>> self.driver.do_setup(ctxt) >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 251, in do_setup >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager >>>>>>> volname=self.volname) >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 401, in volname >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager >>>>>>> self.rados_client, "fs volume ls", json_obj=True) >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 205, in rados_command >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager raise >>>>>>> exception.ShareBackendException(msg) >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix=fs >>>>>>> volume >>>>>>> ls, argdict={'format': 'json'} - exception message: Bad target type >>>>>>> 'mon-mgr'. >>>>>>> 2021-10-20 10:05:26.438 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager >>>>>>> [req-9e549670-d131-4572-b57e-761b513abc75 - - - - -] Error encountered >>>>>>> during i >>>>>>> nitialization of driver CephFSDriver@ControllerA@cephfsnative1: >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix= >>>>>>> fs volume ls, argdict={'format': 'json'} - exception message: Bad >>>>>>> target type 'mon-mgr'. >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 191, in rados_command >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager >>>>>>> timeout=RADOS_TIMEOUT) >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1460, in json_ >>>>>>> command >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager inbuf, >>>>>>> timeout, verbose) >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1330, in send_ >>>>>>> command_retry >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager return >>>>>>> send_command(*args, **kwargs) >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1412, in send_ >>>>>>> command >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager raise >>>>>>> ArgumentValid("Bad target type '{0}'".format(target[0])) >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager >>>>>>> ceph_argparse.ArgumentValid: Bad target type 'mon-mgr' >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager During >>>>>>> handling of the above exception, another exception occurred: >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py >>>>>>> ", line 346, in _driver_setup >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager >>>>>>> self.driver.do_setup(ctxt) >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 251, in do_setup >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager >>>>>>> volname=self.volname) >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 401, in volname >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager >>>>>>> self.rados_client, "fs volume ls", json_obj=True) >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 205, in rados_command >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager raise >>>>>>> exception.ShareBackendException(msg) >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix=fs >>>>>>> volume >>>>>>> ls, argdict={'format': 'json'} - exception message: Bad target type >>>>>>> 'mon-mgr'. >>>>>>> 2021-10-20 10:07:34.539 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager >>>>>>> [req-9e549670-d131-4572-b57e-761b513abc75 - - - - -] Error encountered >>>>>>> during i >>>>>>> nitialization of driver CephFSDriver@ControllerA@cephfsnative1: >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix= >>>>>>> fs volume ls, argdict={'format': 'json'} - exception message: Bad >>>>>>> target type 'mon-mgr'. >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 191, in rados_command >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager >>>>>>> timeout=RADOS_TIMEOUT) >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1460, in json_ >>>>>>> command >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager inbuf, >>>>>>> timeout, verbose) >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1330, in send_ >>>>>>> command_retry >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager return >>>>>>> send_command(*args, **kwargs) >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager File >>>>>>> "/usr/lib/python3.6/site-packages/ceph_argparse.py", line 1412, in send_ >>>>>>> command >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager raise >>>>>>> ArgumentValid("Bad target type '{0}'".format(target[0])) >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager >>>>>>> ceph_argparse.ArgumentValid: Bad target type 'mon-mgr' >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager During >>>>>>> handling of the above exception, another exception occurred: >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager Traceback >>>>>>> (most recent call last): >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/manager.py >>>>>>> ", line 346, in _driver_setup >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager >>>>>>> self.driver.do_setup(ctxt) >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 251, in do_setup >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager >>>>>>> volname=self.volname) >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 401, in volname >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager >>>>>>> self.rados_client, "fs volume ls", json_obj=True) >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager File >>>>>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/manila/share/drivers/ce >>>>>>> phfs/driver.py", line 205, in rados_command >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager raise >>>>>>> exception.ShareBackendException(msg) >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager >>>>>>> manila.exception.ShareBackendException: json_command failed - prefix=fs >>>>>>> volume >>>>>>> ls, argdict={'format': 'json'} - exception message: Bad target type >>>>>>> 'mon-mgr'. >>>>>>> 2021-10-20 10:11:50.596 30 ERROR manila.share.manager >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Le mer. 20 oct. 2021 à 00:14, Goutham Pacha Ravi < >>>>>>> gouthampravi(a)gmail.com> a écrit : >>>>>>> >>>>>>>> >>>>>>>> On Tue, Oct 19, 2021 at 2:35 PM wodel youchi < >>>>>>>> wodel.youchi(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> Has anyone been successful in deploying Manila wallaby using >>>>>>>>> kolla-ansible with ceph pacific as a backend? >>>>>>>>> >>>>>>>>> I have created the manila client in ceph pacific like this : >>>>>>>>> >>>>>>>>> *ceph auth get-or-create client.manila mon 'allow r' mds 'allow r, >>>>>>>>> allow rw path=/' osd 'allow rw pool=cephfs_data' mgr 'allow rw'* >>>>>>>>> >>>>>>>>> When I deploy, I get this error in manila's log file : >>>>>>>>> Bad target type 'mon-mgr' >>>>>>>>> Any ideas? >>>>>>>>> >>>>>>>> >>>>>>>> Could you share the full log from the manila-share service? >>>>>>>> There's an open bug related to manila/cephfs deployment: >>>>>>>> https://bugs.launchpad.net/kolla-ansible/+bug/1935784 >>>>>>>> Proposed fix: >>>>>>>> https://review.opendev.org/c/openstack/kolla-ansible/+/802743 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Regards. >>>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> බුද්ධික සංජීව ගොඩාකුරු >>>>>> Buddhika Sanjeewa Godakuru >>>>>> >>>>>> Systems Analyst/Programmer >>>>>> Deputy Webmaster / University of Kelaniya >>>>>> >>>>>> Information and Communication Technology Centre (ICTC) >>>>>> University of Kelaniya, Sri Lanka, >>>>>> Kelaniya, >>>>>> Sri Lanka. >>>>>> >>>>>> Mobile : (+94) 071 5696981 >>>>>> Office : (+94) 011 2903420 / 2903424 >>>>>> >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>> University of Kelaniya Sri Lanka, accepts no liability for the >>>>>> content of this email, or for the consequences of any actions taken on the >>>>>> basis of the information provided, unless that information is subsequently >>>>>> confirmed in writing. If you are not the intended recipient, this email >>>>>> and/or any information it contains should not be copied, disclosed, >>>>>> retained or used by you or any other party and the email and all its >>>>>> contents should be promptly deleted fully from our system and the sender >>>>>> informed. >>>>>> >>>>>> E-mail transmission cannot be guaranteed to be secure or error-free >>>>>> as information could be intercepted, corrupted, lost, destroyed, arrive >>>>>> late or incomplete. >>>>>> >>>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>> >>>>> >> >> -- >> >> බුද්ධික සංජීව ගොඩාකුරු >> Buddhika Sanjeewa Godakuru >> >> Systems Analyst/Programmer >> Deputy Webmaster / University of Kelaniya >> >> Information and Communication Technology Centre (ICTC) >> University of Kelaniya, Sri Lanka, >> Kelaniya, >> Sri Lanka. >> >> Mobile : (+94) 071 5696981 >> Office : (+94) 011 2903420 / 2903424 >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> University of Kelaniya Sri Lanka, accepts no liability for the content of >> this email, or for the consequences of any actions taken on the basis of >> the information provided, unless that information is subsequently confirmed >> in writing. If you are not the intended recipient, this email and/or any >> information it contains should not be copied, disclosed, retained or used >> by you or any other party and the email and all its contents should be >> promptly deleted fully from our system and the sender informed. >> >> E-mail transmission cannot be guaranteed to be secure or error-free as >> information could be intercepted, corrupted, lost, destroyed, arrive late >> or incomplete. >> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >

3 3

[kuryr][ptg] Yoga cycle PTG summary
by Maysa De Macedo Souza 30 Oct '21

30 Oct '21

Hello, I would like to thank you for the great discussion and engagement during the PTG sessions. It was a really productive week. Here follows the summary of the Kuryr sessions during the PTG: *Day 1 - Tuesday* Etherpad: https://etherpad.opendev.org/p/kuryr-yoga-ptg - Xena retrospective: - We celebrated the contributions from many Outreachy applicants and the interns. - The addition of new features, such as: - The Reconciliation mechanisms that enforces the matching of a Kubernetes Service with a load-balancer. - The setting of Octavia Listener timeout based on annotation of the Kubernetes Service. - Improvements on the logs to facilitate debuggability and troubleshooting. - Usage of Kubeadm to facilitate configuration of Kubernetes cluster with Devstack. - Many documentation improvements. - Stable branches: - We have many stable branches which are not highly maintained anymore - action items: EOL the branches till Stein - As we currently release with OpenStack, it was proposed that we release with Kubernetes - action items: Keep following the OpenStack release, but make sure that when there is a Kubernetes release it's updated in Kuryr. - Future of the CI: - action items: - Move all the gates to use CRI-O and have one with Docker. - Attempt to remove the Amphora dependency for the API load-balancer when OVN Octavia driver is available. - Move the jobs that use OVN to voting. - Rate limit requests: - Possibility to limit the requests to Octavia during the reconciliation between load-balancers and Kubernetes Service . - Possibility to limit the amount of requests sent to Neutron *Day 2 - Wednesday* Etherpad: https://etherpad.opendev.org/p/kuryr-yoga-ptg - Merge of Kuryr lib into Kuryr-kubernetes: - action items: analyze the feasibility of moving the needed pieces into Kuryr-kubernetes and sync with other projects that use it. - Different log levels: - action items: - clean up some unnecessary debugging messages and move the level of some to warning or info. - Feasibility of reducing the current approach of one Network per Namespace, to one Network per cluster to reduce resource usage: - action items: - check if there is a plan to implement Network cascade delete with the Neutron team - attempt to create a PoC with one Pod Network per Cluster - Possibility of creating external reachable services without Amphora. - Discussion about the open Kubernetes proposal of notifying the user when a Network Policy is actually enforced. - Drop the liveness checks for certain scenarios: - The controller and CNI restarts has helped with certain cornes cases, but it can decrease the availability of Kuryr if restarted many times - action items: - drop restarts on unavailability of Neutron/k8s API - enforce restarts when all the Kuryr watches, handlers and drivers are not running - Drop usage of Flask debug servers - Currently many servers created by Kuryr like Health, Prometheus exporter and Kuryr daemon are based on flask and could likely be moved to another type of server. - action item: Move the kuryr-cni to kuryr-daemon communication to use gRPC Don't exitate to contact us either on IRC or email if you have any questions. Cheers, Maysa Macedo.

1 0

[all][tc] What's happening in Technical Committee: summary 29th Oct, 21: Reading: 5 min
by Ghanshyam Mann 29 Oct '21

29 Oct '21

Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * TC this week IRC meeting held on Oct 28th Thursday. * Most of the meeting discussions are summarized below (Completed or in-progress activities section). Meeting full logs are available @ - https://meetings.opendev.org/meetings/tc/2021/tc.2021-10-28-15.00.log.html * Next week's meeting will be video call on google meet on Oct 28th, Thursday 15:00 UTC, feel free the topic on agenda[1] by Oct 27th. 2. What we completed this week: ========================= * Add openstack/ci-log-processing project into TaCT[2] * PTG and Summary: I have summarized the TC summary along with the TC+community leaders interaction sessions. Recordings: Day1: https://www.youtube.com/watch?v=uQRKYummsHM Day2: https://www.youtube.com/watch?v=IHj7cpBlbYo Day3: https://www.youtube.com/watch?v=RT492bi6Xto Summary: http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025554.… Two topics 1. RBAC and 2. Pain points will be continue to discuss in post-PTG call or TC weekly meeting. 3. Activities In progress: ================== TC Tracker for Yoga cycle ------------------------------ * I have started the etherpad to collect the Yoga cycle targets for TC[3]. Open Reviews ----------------- * Nine open reviews for ongoing activities[4]. RBAC discussion: continuing from PTG ---------------------------------------------- We are continuing the RBAC discussion we left in PTG. I have sent the doodle poll to select the appropriate time, feel free to add your vote if you are interested to be part of it[5]. Yoga release community-wide goal ----------------------------------------- * With the continuing the discussion on RBAC, we are re-working on the RBAC goal, please wait until we finalize the implementation[6] Adjutant need maintainers and PTLs ------------------------------------------- You might have seen the email[7] from Adrian to call the maintainer for Adjutant project, please reply to that email or here or on openstack-tc channel if you are interested to maintain this project. New project 'Skyline' proposal ------------------------------------ * We discussed it in TC PTG and there are few open points about python packaging, repos, and plugins plan which we are discussion on ML. Updating the Yoga testing runtime ---------------------------------------- * We agreed to update the below things in the Yoga testing runtime: 1. Add Debian 11 as tested distro 2. Bump highest python version to test to 3.9 Patch is up for the review[8], once that is merged I will update the job template. Stable Core team process change --------------------------------------- * Current proposal is under review[9]. Feel free to provide early feedback if you have any. Merging 'Technical Writing' SIG Chair/Maintainers to TC ------------------------------------------------------------------ * Work to merge this SIG to TC is up for review[10]. One repo of this SIG openstack/training-labs is called for maintainers[11] and rest other are moved under TC & FC SIG. TC tags analysis ------------------- * TC agreed to remove the framework and it is communicated in ML[12]. Project updates ------------------- * Retiring js-openstack-lib [13] * Retiring kolla-cli [14] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[15]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [16] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [17] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://review.opendev.org/c/openstack/governance/+/815318 [3] https://etherpad.opendev.org/p/tc-yoga-tracker [4] https://review.opendev.org/q/projects:openstack/governance+status:open [5] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025569.… [6] https://review.opendev.org/c/openstack/governance/+/815158 [7] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025555.… [8] https://review.opendev.org/c/openstack/governance/+/815851 [9] https://review.opendev.org/c/openstack/governance/+/810721 [10] https://review.opendev.org/c/openstack/governance/+/815869 [11] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025586.… [12] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025571.… [13] https://review.opendev.org/c/openstack/governance/+/807163 [14] https://review.opendev.org/c/openstack/governance/+/814603 [15] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [16] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [17] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

[PTL] PTG Summaries Blog
by helena＠openstack.org 29 Oct '21

29 Oct '21

Hi PTLs, I have loved seeing all the PTG summaries that have been rolling in! I am working to gather all of them and create a blog post for [ openstack.org/blog ]( http://openstack.org/blog ). If you would like for your summary to be included in the blog please post it to the mailing list and send me the link to the archived email by Tuesday, November 2nd. Thank you all for your involvement in PTG and I look forward to seeing all the summaries! Cheers, Helena

2 1

[TC][First Contact][Skyline][OpenDev][Release][OpenStackSDK] Oct 2021 PTG Summaries
by Kendall Nelson 29 Oct '21

29 Oct '21

Hello! I tried to summarize some of the discussions I was in throughout the week for those that could not join! Hopefully some of it is helpful :) Technical Committee[1] Monday- 25 people Monday we focused on the relationship between the Project Team Leads (PTLs) and the Technical Committee (TC). We discussed the role of the TC, and what PTLs look to us for, what we should be doing that we are not, what we are doing that we shouldn’t be. Things we do that maybe might not be the best use of everyone’s time, etc. Some of the main things that came out of discussions were: - Creating a repo (possibly) to house documents about how certain things should be implemented if a project is going to implement them, for example quotas. These technical guidelines will hopefully give more direction to new projects entering the OpenStack space and help unify and standardize the implementations of features across already established OpenStack projects. These documents will not have accompanying deadlines like community goals, but will instead be used as resources and reference documents to further enhance OpenStack. - How to engage with OpenStack Operators and get them to be more vocal about feedback and encouraging interaction with the project specific communities with regards to bugs and project direction. Ideas included making sure to use the [ops] tag on emails to the openstack-discuss list and ensuring that users and operators know the mailing list is for them just as much as it is for developers. Also, making sure to communicate topics to the twitter handle for wider engagement to those that might not be watching the mailing list closely. Thursday- 18 people Another full day of discussions. We covered the Docs SIG state of affairs, Yoga testing runtime, TC tags, a project adoption ladder, and release name process changes (yes, again). The tldrs; of all of that: - Some of the Docs SIG repos are being retired, some are going to live with the First Contact SIG. - Python 3.9 is now a voting test and 3.10 will be added as non voting. Python 3.6 will be kept until CentOS Stream 8 is replaced by Stream 9. - There is a proposal to drop the tag framework altogether[1.1]. - We do NOT want to add a whole process for incubating new projects; simply keep the process we have and apply a ‘tech preview’ note to their first release where applicable. - We are going to change back to having the community vote for the names which will also be proposed by the community, but also pre-vetted by the community before voting begins. The final vetting will be the Open Infra Foundation’s legal team as it always has been. Friday- 28 people Another nother full day of discussions! We covered operator pain point targeting, Skyline project proposal, RBAC, Community Goals, Xena Wrap up, and were also joined at the very end by several members of the Kubernetes Steering Committee (YAY cross community collaboration!). Those tldrs; - We want to make sure all the pain points are being actively tracked and if there are things that are common across many projects those get more attention as potential community goals down the road. - Skyline is largely ready to be proposed as a project. There are a few things that might need to get rearranged and changed so that it can be released as a part of OpenStack but that shouldn’t stop them from being approved. They could be included in the Yoga release as a ‘tech preview’. - I don’t even know how to summarize the RBAC stuff lol. That one I can’t tldr for you. Go check out those notes in the etherpad[1]. - The main thing we discussed wrt community goals is that things like RBAC that we want as a community goal cannot be scoped to a single release and we are fine with that. - In the Xena wrap up, we did a retrospective of the things we accomplished and also agreed to keep monthly video meetings in the upcoming cycle. - We again loved having members of the k8s steering committee join us! We chatted about how the CNCF project ladder works, how the OpenStack’s ‘Upstream Investment Opportunities' works, and CI/CD resourcing struggles for both communities. OpenStackSDK / OpenStackClient[2] - 10 people First we kicked off with Artem giving us an update on the r1 branch which is nearing the point that we can merge it! There is only one part missing- compute has not been completely reconfigured to use proxy; there are still a number of sections of the code that rely on the cloud layer and directly touch the APIs. Once that is completed however; we will be able to merge r1 into master and celebrate! We legitimately discussed having a party and publicizing it, so if you have opinions about any of that (or want to help wrap things up), please reach out to us in #openstack-sdks. We talked a little bit about the exceptional cases where we might consider deprecating OSC commands. Basically we concluded that we still don’t want to do it except in very specific circumstances. We are generally okay with doing it for removed APIs such that they are actually being completely removed from the API and not just removed in a microversion and are essentially still reachable in older microversions. Lastly, we chatted with the Korea user group about their mentoring program that is in the process of wrapping up. It sounds like it will be a yearly thing for them and we (the SDK team) want to try to help support those efforts more going forward if the organizers of the mentoring program can give us heads up like they did this last time. We look forward to working with them more in the future! First Contact SIG[3] - 2 people Discussions were pretty brief as not many people attended, but we did follow up on a discussion earlier in the day that the Technical Committee had about having the First Contact SIG become the new owners of a couple of repositories formerly owned by the Docs SIG (a reaction to a general lack of spoons on that team and moving in the direction of moving the status of that SIG inactive). The First Contact SIG agreed to take ownership of the contributor-guide repo and the training-guides repo. Work on that migration/reconfiguration of ACLs will begin soon. If you have any questions or are interested in getting involved, please contact the First Contact SIG or the Technical Committee OpenDev[4] - 4 people The session was mostly just a working one, but we also had a little time to catch up and chat and stay connected as a team :) Not much to say here really. Skyline[5]- 4 people I attended their sessions on Tuesday and while it was largely quiet when I was there we did chat a little bit about the upcoming TC discussions about the project and I invited them to join in those- spoiler; they came! Release Management [6] - 6 People The largest topic we discussed in the release management ptg session was everyone’s favorite topic- release cadence! We talked about how it might finally be time to move to 12 month cadence. Things have slowed down sufficiently with regards to feature development (and this has been consistent throughout the last couple releases). It would reduce the frequent upgrades that distros have to work through, and the process we currently maintain can be easily stretched to accommodate a year. All in all, the release team supports the idea and think that if we are to make the transition, when we finish the ‘Z’ release and start over at the beginning of the alphabet again, that would be a natural time to also switch to a one year release cycle rather than the 6th month cadence we have been keeping up with for quite some time. The decision is ultimately up to the Technical Committee, but the release team supports the idea. -Kendall Nelson (diablo_rojo) [1] https://etherpad.opendev.org/p/tc-yoga-ptg [1.1] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025571.… [2] https://etherpad.opendev.org/p/oct2021-ptg-sdk-cli [3] https://etherpad.opendev.org/p/oct2021-ptg-first-contact [4] https://etherpad.opendev.org/p/oct2021-ptg-opendev [5] https://etherpad.opendev.org/p/oct2021-ptg-skyline [6] https://etherpad.opendev.org/p/relmgmt-yoga-ptg

1 0

[tc][operators][all] TC tags framework to be dropped
by Radosław Piliszek 29 Oct '21

29 Oct '21

Dear OpenStack Operators, Due to no response to the original query about usefulness of the TC tags framework [1] (which was repeated in each and every following TC newsletter), the TC has decided to drop the tags framework entirely. [2] [3] [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-September/02480… [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025554.… [3] https://etherpad.opendev.org/p/tc-yoga-ptg Kind regards, -yoctozepto

2 2

[OpenStack-Ansible] LXC containers apt upgrade
by Taltavull Jean-Francois 29 Oct '21

29 Oct '21

Hi All, Following the recent Let's Encrypt certificates expiration, I was wondering what was the best policy to apt upgrade the operating system used by LXC containers running on controller nodes. Has anyone ever defined such a policy ? Is there an OSA tool to do this ? Regards, Jean-François

2 2

[masakari] Yoga PTG summary
by Radosław Piliszek 29 Oct '21

29 Oct '21

Hi! This is a quick summary of Masakari's Yoga PTG. Quick as the PTG itself was quite quick. :-) We have summarised the progress made in Xena and decided to continue the efforts related to supporting monitoring with Consul and tracking issued evacuations. We have also discussed one new topic regarding circuit breaking in case of a mass failure of instances (e.g., due to a storage network failing in one location). To this end, the proposal is to introduce a protection mechanism (circuit breaking) based on a static time window (static at least in the first iteration) per segment. suzhengwei is to write the spec for this. Raw notes are available at https://etherpad.opendev.org/p/masakari-yoga-ptg Kind regards, -yoctozepto

1 0

[sahara][ptg] Yoga PTG Summary
by Juntingqiu Qiujunting (邱军婷) 28 Oct '21

28 Oct '21

Hi all: Thank everyone for taking time and attending session. The discussion content of the PTG meeting is as follows: https://etherpad.opendev.org/p/sahara-yoga-ptg 1、Sahara has supported boot virtual machine from volume. https://specs.openstack.org/openstack/sahara-specs/specs/backlog/boot-from-… 2、Sahara deploys a dedicated clusters need the network to be a flat one for instances. Could set up a "jumphost" which can be reached by the controllers, and that can reach the instances, need not the network to be a flat one for instance. https://docs.openstack.org/sahara/latest/admin/advanced-configuration-guide… 3、Discuss about which Plugins should be kept and updated and which ones should be dropped? The conclusion is that such as HDP、CDH、MapR Storm and Spark can be deleted in Yoga. 4、Improve the unit testing and documentation of Sahara project. Currently, the activity of the Sahara project is relatively low. We can discover its potential and expand its usage scenarios. Thank you Fossen --------------------------------- Fossen Qiu | 邱军婷 CBRD | 云计算与大数据研发部 T: 18249256272 E: qiujunting(a)inspur.com<mailto:qiujunting@inspur.com> 浪潮云海

1 0

[ptg][cinder] yoga virtual PTG summary
by Brian Rosmaita 28 Oct '21

28 Oct '21

Sorry for the delay, it's posted here: https://wiki.openstack.org/wiki/CinderYogaPTGSummary The wiki page contains links to all the recordings. It's a wiki page, so feel free to make clarifications or corrections. Action items are noted in the "conclusions" sections of most of the summaries, so please look to remind yourself what you have committed yourself to. cheers, brian

1 0