October 2021 - openstack-discuss - lists.openstack.org

Live migration fails
by Szabo, Istvan (Agoda) 07 Aug '24

07 Aug '24

Hi, I have couple of compute nodes where the live migration fails with existing vms. When I quickly spawn a vm and try live migration it works so I assume shouldn't be a big problem with the compute node. However I have many existing vms where it fails with a servername not found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 ERROR nova.conductor.tasks.migrate [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] [instance: 1517a2ac-3b51-4d8d-80b3-89a5614d1ae0] Unable to find record for source node servername on servername: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 WARNING nova.scheduler.utils [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] Failed to compute_task_migrate_server: Compute host servername could not be found.: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 WARNING nova.scheduler.utils [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] [instance: 1517a2ac-3b51-4d8d-80b3-89a5614d1ae0] Setting instance to ACTIVE state.: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.672 227612 ERROR oslo_messaging.rpc.server [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] Exception during message handling: ComputeHostNotFound: Compute host am-osfecn-4025 Tried with this command: nova live-migration --block-migrate id. Any idea? Thank you. ________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses.

5 16

[all] Dynamic Zuul results table in Gerrit 3
by Radosław Piliszek 04 Aug '22

04 Aug '22

Hello Fellow OpenStack and OpenDev Folks! TL;DR click on [3] and enjoy. I am starting this thread to not hijack the discussion happening on [1]. First of all, I would like to thank gibi (Balazs Gibizer) for hacking a way to get the place to render the table in the first place (pun intended). I have been a long-time-now user of [2]. I have improved and customised it for myself but never really got to share back the changes I made. The new Gerrit obviously broke the whole script so it was of no use to share at that particular state. However, inspired by gibi's work, I decided to finally sit down and fix it to work with Gerrit 3 and here it comes: [3]. Works well on Chrome with Tampermonkey. Not tested others. I hope you will enjoy this little helper (I do). I know the script looks super fugly but it generally boils down to a mix of styles of 3 people and Gerrit having funky UI rendering. Finally, I'd also like to thank hrw (Marcin Juszkiewicz) for linking me to the original Michel's script in 2019. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/019051… [2] https://opendev.org/x/coats/src/commit/444c95738677593dcfed0cfd9667d4c4f0d5… [3] https://gist.github.com/yoctozepto/7ea1271c299d143388b7c1b1802ee75e Kind regards, -yoctozepto

5 7

[all] PyCharm Licenses Renewed till July 2021
by Swapnil Kulkarni 13 Jul '22

13 Jul '22

Hello, Happy to inform you the open source developer license for Pycharm has been renewed for 1 additional year till July 2021. Best Regards, Swapnil Kulkarni coolsvap at gmail dot com

8 13

Nova not updating to new size of an extended in-use / attached cinder volume (Ceph RBD) to guest
by Christian Rohmann 28 Jun '22

28 Jun '22

Hello Openstack-Discuss, after some digging I found out that cinder learned to resize attached (in-use) volumes quite a while ago with the introduction of the initial "extend 'in-use' volume" feature: https://review.opendev.org/c/openstack/cinder/+/454287/ The support was then extended to also cover Ceph RBD backed volumes with: https://review.opendev.org/c/openstack/nova/+/613039/ Since this is only about the cinder part, I was wondering if nova would ever find out and would actively rescan the device / volume and quintessentially present an increased new size to the guest. Apparently this is where a certain volume-extended event comes into play: https://review.opendev.org/c/openstack/nova/+/454322/ that is to be emitted by cinder when a volume had been extened. I then went head and tried this with the openstack cli (as Horizon does not seem to support / offer to resize in-use volumes. I run Openstack Train with Ceph RBD as storage. First I ran into an issue with the openstack cli (https://bugs.launchpad.net/cinder/+bug/1871759/comments/2 <https://bugs.launchpad.net/cinder/+bug/1871759/comments/2>) but using cinder extend $volumeid $newsize I was able to resize in-use volumes just fine. The only thing missing was the propagation to the guest. I played around with SCSI rescans, but that did not work, reboots also failed to do anyting in this regards. Stopping and starting the VM did work, but why having the capability to online-resize an attached volume when not being able to resize the guest volume as well? Apparently there seems to be an old and somewhat similar observation / bug with https://bugs.launchpad.net/nova/+bug/1369465 So I was simply wondering if this is expected to be working? Are there any special settings / options I need to set to enable this feature? Thanks and with kind regards Christian

4 9

[oslo] Propose to EOL stable/queens, stable/rocky on all the oslo scope
by Herve Beraud 24 Jun '22

24 Jun '22

Hi, On our last meeting of the oslo team we discussed the problem with broken stable branches (rocky and older) in oslo's projects [1]. Indeed, almost all these branches are broken. Előd Illés kindly generated a list of periodic-stable errors on Oslo's stable branches [2]. Given the lack of active maintainers on Oslo and given the current status of the CI in those branches, I propose to make them End Of Life. I will wait until the end of month for anyone who would like to maybe step up as maintainer of those branches and who would at least try to fix CI of them. If no one will volunteer for that, I'll EOLing those branches for all the projects under the oslo umbrella. Let us know your thoughts. Thank you for your attention. [1] https://meetings.opendev.org/meetings/oslo/2021/oslo.2021-10-04-15.00.log.t… [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023939.html -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud

5 5

[ops][nova][victoria] Power State = Suspended?
by DHilsbos＠performair.com 24 Jan '22

24 Jan '22

All; I had something unusual happen this morning; one of my VMs was showing "Suspended" under the Power State in the Horizon dashboard. I've never seen that. What does it mean? Any search that I do points me to a bunch of resources for Status Suspended. Thank you, Dominic L. Hilsbos, MBA Vice President - Information Technology Perform Air International Inc. DHilsbos(a)PerformAir.com www.PerformAir.com

4 8

[nova][dev] Revisiting qemu emulation where guest arch != host arch
by Apsey, Christopher 05 Jan '22

05 Jan '22

All, A few years ago I asked a question[1] about why nova, when given a hw_architecture property from glance for an image, would not end up using the correct qemu-system-xx binary when starting the guest process on a compute node if that compute nodes architecture did not match the proposed guest architecture. As an example, if we had all x86 hosts, but wanted to run an emulated ppc guest, we should be able to do that given that at least one compute node had qemu-system-ppc already installed and libvirt was successfully reporting that as a supported architecture to nova. It seemed like a heavy lift at the time, so it was put on the back burner. I am now in a position to fund a contract developer to make this happen, so the question is: would this be a useful blueprint that would potentially be accepted? Most of the time when people want to run an emulated guest they would just nest it inside of an already running guest of the native architecture, but that severely limits observability and the task of managing any more than a handful of instances in this manner quickly becomes a tangled nightmare of networking, etc. I see real benefit in allowing this scenario to run natively so all of the tooling that exists for fleet management 'just works'. This would also be a significant differentiator for OpenStack as a whole. Thoughts? [1] http://lists.openstack.org/pipermail/openstack-operators/2018-August/015653… Chris Apsey Director | Georgia Cyber Range GEORGIA CYBER CENTER 100 Grace Hopper Lane | Augusta, Georgia | 30901 https://www.gacybercenter.org

2 2

[stable][requirements][zuul] unpinned setuptools dependency on stable
by Balazs Gibizer 15 Dec '21

15 Dec '21

Hi, The latest setuptools (58.0) removed support for "use_2to3" [1] (deprecated since 46.2). Many OpenStack modules defines decorator==3.4.0 as lower constraints[2]. However, decorator 3.4.0 cannot be installed anymore with the latest setuptool as it depends on "use_2to3". On master, this can be solved easily by bumping the dependency to decorator 4.0.0. On stable/xena we can still solve it the same way with a new RC. But on older stable branches such solution might be against the stable policy as it would require a major bump on our dependencies. This issue is not limited to lower-constraints testing it just hit us there first. A similar break could happen in our upper constraints as well on old stable branches. The root of the problem is that we always use the latest setuptools in our CI testing even on old stable branches. Zuul's ensure-tox task[4] installs tox which installs the virtualenv package which bundles the latest setuptools package. This happens without applying any constraints. Then tox is used to install the project's dependencies under lower or upper constraints with the unconstrained setuptools available. During and after yesterday's nova meeting [3] we discussed possible solutions. Option 1: Bump the major version of the decorator dependency on stable. Pros: * easy to implement Cons: * might against the policy / breaks downstream packagers * needs to be done in each affected project[3] separately * not future proof. After a future setuptools release we can see a similar break with another of our dependencies. @Stable Cores: how do you feel about such bump? Option 2: Pin the setuptools version during tox installation Pros: * single solution for all affected projects * future proof against breaks introduced by future setuptools releases Cons: * complex change as it probably requires to extend the base task in zuul itself Option 3: turn off lower-constraints testing Pros: * easy to implement * some of us want to get rid of lower constraints anyhow Cons: * needs per project changes * not future proof against similar break affecting our upper constraints on old stable branches. Option 4: utilize pyproject.toml[6] to specify build-time requirements Unfortunately, I'm not sure if it is possible to restrict the maximum setuptools version with it As a side note I tried applying [tox]requires in tox.ini to restrict setuptools version[7] but It does not seem to take effect in our case[8]. @Stable Cores: what do you think what could be the way forward? Cheers, gibi [1] https://setuptools.pypa.io/en/latest/history.html#v58-0-2 [2] https://codesearch.openstack.org/?q=decorator%3D%3D3.4.0&i=nope&literal=nop… [3] https://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.20… [4] https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/ensure-tox/tasks… [5] https://tox.readthedocs.io/en/latest/config.html#conf-requires [6] https://www.python.org/dev/peps/pep-0518/ [7] https://review.opendev.org/c/openstack/placement/+/810293/1/tox.ini [8] https://zuul.opendev.org/t/openstack/build/f78a0300c8734e7c8475309af1d2e1a4…

11 28

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

10 Dec '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 14th 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-14-15.00.log.html * Next week's meeting is cancelled as we are meeting in PTG. We will have the next IRC meeting on Oct 28th, Thursday 15:00 UTC, feel free the topic on agenda[1] by Oct 27th. 2. What we completed this week: ========================= * None in this week. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ * TC is using the etherpad[2] for Xena cycle working item. We will be checking it in PTG * Current status is: 9 completed, 3 to-be-discussed in PTG, 1 in-progress Open Reviews ----------------- * Six open reviews for ongoing activities[3]. New project 'Skyline' proposal ------------------------------------ * You might be aware of this new dashboard proposal in the previous month's discussion. * A new project 'Skyline: an OpenStack dashboard optimized by UI and UE' is now proposed in governance to be an official OpenStack project[4]. * Skyline team is planning to meet in PTG on Tue, Wed and Thu at 5UTC, please ask your queries or have feedback/discussion with the team next week. Place to maintain the external hosted ELK, E-R, O-H services ------------------------------------------------------------------------- * We had a final discussion or I will say just a status update on this which was mentioned in last week's email summary[5]. * Now onwards, discussion and migration work will be done in TACT SIG (#openstack-infra IRC channel). Add project health check tool ----------------------------------- * No updates on this, we will continue discussing it in PTG for the next steps on this and what to do with TC liaison things. * Meanwhile, we are reviewing Rico proposal on collecting stats tools [6]. Stable Core team process change --------------------------------------- * Current proposal is under review[7]. Feel free to provide early feedback if you have any. Call for 'Technical Writing' SIG Chair/Maintainers ---------------------------------------------------------- * As agreed in last week's TC meeting, we will be moving this SIG work towards TC. * TC members have been added to the core members list in the SIG repos. * We will be discussing where to move the training repos/work in PTG. TC tags analysis ------------------- * Operator feedback is asked on open infra newsletter too, and we will continue the discussion in PTG and will take the final decision based on feedback we receive, if any[9]. Complete the policy pop up team ---------------------------------------- * Policy pop team has served its purpose and we have new RBAC as one of the the community-wide goal for the Yoga cycle. * We are marking this popup team as completed[10]. Project updates ------------------- * Retiring js-openstack-lib [11] Yoga release community-wide goal ----------------------------------------- * Please add the possible candidates in this etherpad [12]. * Current status: "Secure RBAC" is selected for Yoga cycle[13]. PTG planning ---------------- * We will be meeting in PTG next week, please check the details in this etherpad [14] * Do not forget to join the TC+community leaders sessions on Monday, Oct 18 15 UTC - 17 UTC. Test support for TLS default: ---------------------------------- * Rico has started a separate email thread over testing with tls-proxy enabled[15], we encourage projects to participate in that testing and help to enable the tls-proxy in gate testing. 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[16]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [17] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [18] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://etherpad.opendev.org/p/tc-xena-tracke [3] https://review.opendev.org/q/projects:openstack/governance+status:open [4] https://review.opendev.org/c/openstack/governance/+/814037 [5]http://lists.openstack.org/pipermail/openstack-discuss/2021-October/02525… [6] https://review.opendev.org/c/openstack/governance/+/810037 [7] https://review.opendev.org/c/openstack/governance/+/810721 [9] https://governance.openstack.org/tc/reference/tags/index.html [10] https://review.opendev.org/c/openstack/governance/+/814186 [11] https://review.opendev.org/c/openstack/governance/+/798540 [12] https://review.opendev.org/c/openstack/governance/+/807163 [13] https://etherpad.opendev.org/p/y-series-goals [14] https://etherpad.opendev.org/p/tc-yoga-ptg [15] http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023000.html [16] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [17] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [18] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

9 25

[puppet] Propose retiring old stable branches(Stein, Rocky and Queens)
by Takashi Kajinami 26 Nov '21

26 Nov '21

Hello, In puppet repos we have plenty of stable branches still open, and the oldest is now stable/queens. However recently we haven't seen many backports proposed to stein, rocky and queens [1], so I'll propose retiring these three old branches now. Please let me know if anybody is interested in keeping any of these three. Note that currently CI jobs are broken in these three branches and it is likely we need to investigate the required additional pinning of dependent packages. If somebody is still interested in maintaining these old branches then these jobs should be fixed. [1] https://review.opendev.org/q/(project:%255Eopenstack/puppet-.*)AND(NOT+proj… Thank you, Takashi Kajinami

2 2

[all][sphinx] "rST localisation for language "foo" not found" error
by Stephen Finucane 24 Nov '21

24 Nov '21

We've seen issues in some projects, whereby attempting to build translations as part of the 'openstack-tox-docs' zuul job [1] can result in the following warning: Warning, treated as error: ../doc/source/contributor/contributing.rst::rST localisation for language "id" not found. Based on [2], this issue appears to have been introduced by a recent version bump of docutils, which was in turn introduced by the introduction of Sphinx 4.x. We don't have a resolution for this bug yet but we'll update when we do. Hopefully this email will improve the "Google'ability" of this bug. Stephen [1] https://opendev.org/openstack/openstackdocstheme/src/commit/08461c5311aa692… [2] https://lists.freebsd.org/pipermail/freebsd-ports/2021-April/120848.html

2 2

[ Tacker ] Passing a shell script/parameters as a file in cloud config
by Lokendra Rathour 16 Nov '21

16 Nov '21

Hi, *In Tacker, while deploying VNFD can we pass a file ( parameter file) and keep it at a defined path using cloud-config way?* Like in *generic hot template*s, we have the below-mentioned way to pass a file directly as below: parameters: foo: default: bar resources: the_server: type: OS::Nova::Server properties: # flavor, image etc user_data: str_replace: template: {get_file: the_server_boot.sh} params: $FOO: {get_param: foo} *but when using this approach in Tacker BaseHOT it gives an error saying * "nstantiation wait failed for vnf 77693e61-c80e-41e0-af9a-a0f702f3a9a7, error: VNF Create Resource CREATE failed: resources.obsvrnnu62mb: resources.CAS_0_group.Property error: resources.soft_script.properties.config: No content found in the "files" section for get_file path: Files/scripts/install.py 2021-10-28 00:46:35.677 3853831 ERROR oslo_messaging.rpc.server " do we have a defined way to use the hot capability in TACKER? Defined Folder Structure for CSAR: . ├── BaseHOT │ └── default │ ├── RIN_vnf_hot.yaml │ └── nested │ ├── RIN_0.yaml │ └── RIN_1.yaml ├── Definitions │ ├── RIN_df_default.yaml │ ├── RIN_top_vnfd.yaml │ ├── RIN_types.yaml │ ├── etsi_nfv_sol001_common_types.yaml │ └── etsi_nfv_sol001_vnfd_types.yaml ├── Files │ ├── images │ └── scripts │ └── install.py ├── Scripts ├── TOSCA-Metadata │ └── TOSCA.meta ├── UserData │ ├── __init__.py │ └── lcm_user_data.py *Objective: * To pass a file at a defined path on the VDU after the VDU is instantiated/launched. -- ~ Lokendra skype: lokendrarathour

2 3

Adjutant needs contributors (and a PTL) to survive!
by Adrian Turjak 15 Nov '21

15 Nov '21

Hello fellow OpenStackers! I'm moving on to a different opportunity and my new role will not involve OpenStack, and there sadly isn't anyone at Catalystcloud who will be able to take over project responsibilities for Adjutant any time soon (not that I've been very onto it lately). As such Adjutant needs people to take over, and lead it going forward. I believe the codebase is in a reasonably good position for others to pick up, and I plan to go through and document a few more of my ideas for where it should go in storyboard so some of those plans exist somewhere should people want to pick up from where I left off before going fairly silent upstream. Plus if people want/need to they can reach out to me or add me to code review and chances are I'll comment/review because I do care about the project. Or I may contract some time to it. There are a few clouds running Adjutant, and people who have previously expressed interest in using it, so if you still are, the project isn't in a bad place at all. The code is stable, and the last few major refactors have cleaned up much of my biggest pain points with it. Best of luck! - adriant

5 6

[neutron] CI meeting time slot
by Slawek Kaplonski 15 Nov '21

15 Nov '21

Hi, As per PTG discussion, I prepared doodle to check what would be the best time slot for most of the people. Doodle is at [1]. Please fill it in if You are interested attending the weekly Neutron CI meeting. Meeting is on the #openstack-neutron irc channel, but we are also planning to do it on video from time to time. The timeslots in doodle have dates for next week, but please ignore them. It's just to pick the best time slot for the meeting to use it weekly. Next week meeting will be for sure still in the current time slot, which is Tuesday 1500 UTC. [1] https://doodle.com/poll/3n2im4ebyxhs45ne?utm_source=poll&utm_medium=link -- Slawek Kaplonski Principal Software Engineer Red Hat

1 1

[neutron] openflow rules tools
by Arnaud Morin 12 Nov '21

12 Nov '21

Hello, When using native ovs in neutron, we endup with a lot of openflow rules on ovs side. Debugging it with regular ovs-ofctl --color dump-flows is kind of painful. Is there any tool that the community is using to manage that? Thanks in advance! Arnaud.

5 5

[all] Anyone use or would like to maintain openstack/training-labs repo
by Ghanshyam Mann 11 Nov '21

11 Nov '21

Hello Everyone, During the TC weekly meeting and PTG discussion to merge the 'Technical Writing' SIG into TC, we found that openstack/training-labs is no maintained now a days. Even we do not know who use this repo for training. I have checked that upstream institute training or CoA are not using this repo in their training. If you are using it for your training please reply to this email pr ping us on #openstack-tc IRC OFTC channel otherwise we will start the retirement process. - https://opendev.org/openstack/training-labs -gmann

1 1

[all][tc] Continuing the RBAC PTG discussion
by Ghanshyam Mann 10 Nov '21

10 Nov '21

Hello Everyone, As decided in PTG, we will continue the RBAC discussion from where we left in PTG. We will have a video call next week based on the availability of most of the interested members. Please vote your available time in below doodle vote by Thursday (or Friday morning central time). - https://doodle.com/poll/6xicntb9tu657nz7 NOTE: this is not specific to TC or people working in RBAC work but more to wider community to get feedback and finalize the direction (like what we did in PTG session). Meanwhile, feel free to review the lance's updated proposal for community-wide goal - https://review.opendev.org/c/openstack/governance/+/815158 -gmann

1 3

[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

[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

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

04 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

[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

[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

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

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

01 Nov '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 (邱军婷) 29 Oct '21

29 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

Problems with Openstack internal:external router
by Jibsan Joel Rosa Toirac 28 Oct '21

28 Oct '21

Hello I finished to set up a brand new Openstack server, I had already other up and running without any problems, yet on mine the router wich allows the external connection has all the interfaces down and I don't know what else to do. I've tried everything but it still not working. Please any help with this? I let you here a couple of screenshots of my network topology

1 0

[manila] FIPS compliance (Notice: third party drivers)
by Carlos Silva 28 Oct '21

28 Oct '21

Hello Zorillas and interested stackers! During the PTG week, we had a session where we discussed FIPS compatibility and compliance. In this PTG recording [1] you can see the discussion around this topic and our motivations to achieve such things for Manila. We're writing to follow up on the PTG discussion we had, and to update you on our move towards FIPS compatibility and compliance. We're aiming for manila FIPS compatibility with the Yoga cycle, meaning our CI jobs should be passing. FIPS compliance is a Z(orilla) cycle goal. For third party maintainers, to test if your code is FIPS compatible, use an image with fips enabled as discussed in [3]. In the etherpad we used in our previous discussion [2], there's a mention for some drivers that are using non-FIPS compliant libraries, and some examples of libraries that shouldn't be used. If FIPS is enabled in the controller where the driver is, and the driver is using one of the non permitted libraries, it will possibly lead the driver to malfunctioning. If you have any questions, please feel free to reach out to us (carloss and ashrod98) in #openstack-manila. We're always here to support our community. [1] https://youtu.be/mlTx71GIp1w?t=4864 [2] https://etherpad.opendev.org/p/yoga-manila-FIPS [3] https://etherpad.opendev.org/p/state-of-fips-in-openstack-ci-yoga Thanks! ---- Carlos da Silva (carloss) Ashley Rodriguez (ashrod98)

1 0

[kolla] Yoga PTG summary
by Michał Nasiadka 28 Oct '21

28 Oct '21

Hi everyone, Thank you all who participated in the PTG discussions and shared their thoughts and opinions. Here is the summary of the topics we have discussed: # General ## We agreed to stop using Launchpad’s Blueprints functionality (which was inconsistently used by us). ## We’ve discussed recently proposed services to Kolla: Adjutant has a complicated status now (vacant PTL seat and looking for contributors) Skyline Venus We agreed that a project can be added to Kolla/Kolla-Ansible once it fulfills following the criteria of being in OpenStack governance for 1 cycle and having 1 release. An exception to this criteria is when the patch content is in good quality and there are core reviewers interested in making this functionality merged (but still the project needs to be in OpenStack governance). ## We also discussed adding OSISM collection of Grafana dashboards and Prometheus Alertmgr rules in order to improve the “default deployment” experience for Kolla-Ansible users. ## There was a decision taken to finally retire kolla-cli (since it has been deprecated long time ago). # Kolla ## We have discussed deprecating and dropping of binary type of Kolla images: Pros: * less CI load, less maintenance burden (for a limited Kolla team), users would be running more tested images (since Kolla/Kolla-Ansible CI runs source images CI jobs as voting) Cons: * User survey showed that a considerable amount of users is using them - unclear if because that’s a default - or they have chosen to do so. * Overriding package versions in source variant can be more troublesome than it is in binary Action plan: * Improve documentation for source images, especially focusing on its advantages and what might change for current users of binary (when they make the transition) * Mark binary images as deprecated in Yoga cycle (add a note about deprecation in kolla-build CLI output) * Improve override options for source images (upper-constraints, etc) ## The next discussion item was to use a common base (single Linux distribution) for Kolla images Action plan (to make it possible): * Fix Bifrost and OVN builds for Debian (which are broken now) * Create CI jobs for mixed host-os/in-container-image-os (including upgrade jobs) * Deprecate binary images after those two actions are done * Provide a decent plan with justification and operator feedback in https://etherpad.opendev.org/p/kolla-only-on-debian <https://etherpad.opendev.org/p/kolla-only-on-debian> * Deprecate CentOS only images (like qdrouterd) At the same time we agreed on not pursuing CentOS Stream 9 or Ubuntu 22.04 LTS image builds, when those will show up/be required. ## Migration from ElasticSearch to AWS OpenSearch (Elasticsearch fork after ES changed license) Action items: * Deprecate Elasticsearch in Yoga * Build OpenSearch in Yoga # Kolla-Ansible ## Podman support We agreed to implement it with as minimum Ansible playbooks/roles changes as possible (mainly rework kolla_docker.py) Action plan: * Reduce scope of existing patch to deploy a single service (e.g. MariaDB) * Write up a rough implementation plan in https://etherpad.opendev.org/p/kolla-docker-systemd-podman <https://etherpad.opendev.org/p/kolla-docker-systemd-podman> * Add systemd units support for existing Docker implementation * Add podman installation in Kolla-Ansible’s baremetal role * Add podman support upon systemd support for Docker ## Change default deployment to use ML2/OVN (instead of ML2/OVS) We agreed on the criteria to do so: * Debian OVN packages in Yoga * Working and reliable migration path * A way to prevent accidental migration to OVN for existing deployments And until that is resolved - we’re not going to pursue that decision. ## Keystone system scope continued Action plan: * Proposed to split into 3 parts ** use system scope for keystone admin user (done in Xena) ** assign admin role to service users with system scope ** provide flags to enable scope enforcement and new defaults ## Let’s Encrypt Resume efforts to implement it (since we upgraded to HaProxy 2.2 which enables seamless TLS key/cert replacement) ## More HA settings by default Action plan: * Add a docs HA page that describes typical Kolla-Ansible deployment (haproxy, galera cluster, etc) with references to other projects HA configurations (e.g. neutron, octavia) ## Rocky Linux Host OS support Proposal: Replace CentOS Stream support to Rocky Linux in the longer run Action plan: * Add support for Rocky Linux as Host OS (no Kolla container images) # Kayobe ## Multiple environments part 3 Proposed improvements: * merge OpenStack custom configs * merge Kolla Ansible group_vars * dependencies between environments * CI testing ## Support RAID with Bifrost via cleaning steps and deploy steps Action plan: * Add support to baremetal_node_action Ansible module for manual cleaning and passing deploy steps * Option: Enable automated cleaning to erase metadata * Add support for using this functionality to Bifrost * Add passing of deploy_steps and cleaning_steps from Kayobe to Bifrost ## Create collection(s) for external Ansible roles that Kayobe depends on (those from StackHPC namespace) * Group Kayobe external roles to collections (the whole ,,ecosystem’’ of stackhpc.* roles) * Encourage Kayobe role users to move to collections * Add/improve CI testing for the collection For details please check the Kolla Yoga PTG etherpad: https://etherpad.opendev.org/p/kolla-yoga-ptg <https://etherpad.opendev.org/p/kolla-yoga-ptg> And see you on the weekly meetings: https://meetings.opendev.org/#Kolla_Team_Meeting <https://meetings.opendev.org/#Kolla_Team_Meeting> Best Regards, Michal Nasiadka

1 0

答复: [cyborg][ptg] Yoga PTG Summary
by Brin Zhang(张百林) 28 Oct '21

28 Oct '21

More details on etherpad: https://etherpad.opendev.org/p/cyborg-yoga-ptg brinzhang 发件人: Brin Zhang(张百林) 发送时间: 2021年10月28日 19:37 收件人: 'openstack-discuss(a)lists.openstack.org' <openstack-discuss(a)lists.openstack.org> 抄送: 'xin-ran.wang(a)intel.com' <xin-ran.wang(a)intel.com>; Alex Song (宋文平) <songwenping(a)inspur.com>; Jorhson Deng (邓兆森) <dengzhaosen(a)inspur.com>; Juntingqiu Qiujunting (邱军婷) <qiujunting(a)inspur.com>; 'eric_xiett(a)163.com' <eric_xiett(a)163.com> 主题: [cyborg][ptg] Yoga PTG Summary Hi everyone! First of all I would like to thank everyone for taking time and attending session. I think we had pretty productive time and discussions. You may find discussion summaries below: * With nova-cyborg interaction ** Cyborg vGPU support, we write a spec that adds the prefilter and the traits against every Nova RP and then cyborg contributors to provide a subsequent spec for Cyborg using their own trait ** Continue to work on resume/suspend feature, add the unit tests and update the PoC codes ** Works on PMEM instance cold migration in Nova, the spec is already merged in Xena release, and it need to re-propose it in Yoga release * Introducing some new accelerators driver ** xilin FPGA Driver ** PMEM Driver ** Optimization the exist device function, such as FPGA program interface, GPU/vGPU support * New feature will be support in Yoga release ** Get device profile get by name. It’s need to add a microversion, because of the request path_url changed, proposed the spec but need to update *** SPEC URL: https://review.opendev.org/c/openstack/cyborg-specs/+/813183 ** Add disable/enable device status to mark the device whether can be use or not ***SPEC URL: https://review.opendev.org/c/openstack/cyborg-specs/+/815460 ** We would like to improve the parameter validation, consider checking the api parameters with schema ** Add batch query ARQs for more than one instance support in Get *One* Accelerator Request API * Docs improving, such as nova-cyborg interaction manual and API ref docs * Improve the exception mechanism, improve the efficiency of abnormal judgment in unit testing * Improve the abnormal instance handling scenarios, for example, when the host is disconnected and the device is damaged, how should we set the device status and the accelerator instance state at this time. brinzhang

1 0

[cyborg][ptg] Yoga PTG Summary
by Brin Zhang(张百林) 28 Oct '21

28 Oct '21

Hi everyone! First of all I would like to thank everyone for taking time and attending session. I think we had pretty productive time and discussions. You may find discussion summaries below: * With nova-cyborg interaction ** Cyborg vGPU support, we write a spec that adds the prefilter and the traits against every Nova RP and then cyborg contributors to provide a subsequent spec for Cyborg using their own trait ** Continue to work on resume/suspend feature, add the unit tests and update the PoC codes ** Works on PMEM instance cold migration in Nova, the spec is already merged in Xena release, and it need to re-propose it in Yoga release * Introducing some new accelerators driver ** xilin FPGA Driver ** PMEM Driver ** Optimization the exist device function, such as FPGA program interface, GPU/vGPU support * New feature will be support in Yoga release ** Get device profile get by name. It’s need to add a microversion, because of the request path_url changed, proposed the spec but need to update *** SPEC URL: https://review.opendev.org/c/openstack/cyborg-specs/+/813183 ** Add disable/enable device status to mark the device whether can be use or not ***SPEC URL: https://review.opendev.org/c/openstack/cyborg-specs/+/815460 ** We would like to improve the parameter validation, consider checking the api parameters with schema ** Add batch query ARQs for more than one instance support in Get *One* Accelerator Request API * Docs improving, such as nova-cyborg interaction manual and API ref docs * Improve the exception mechanism, improve the efficiency of abnormal judgment in unit testing * Improve the abnormal instance handling scenarios, for example, when the host is disconnected and the device is damaged, how should we set the device status and the accelerator instance state at this time. brinzhang

1 0

[manila][ptg] Yoga cycle PTG summary
by Goutham Pacha Ravi 28 Oct '21

28 Oct '21

Hello Zorillas and other awesome Stackers, Thank you for participating in the Yoga cycle Project Teams Gathering. A special thanks to the folks at the OpenInfra Foundation who provided the platform for this event! We brainstormed on numerous topics. You'll find the unabridged notes and links in the main etherpad [1]. Video recordings from the event are posted on our Youtube channel [2]. The following is my summary of the proceedings. Please feel free to follow up here, or on OFTC's #openstack-manila if you have any questions. == Xena cycle retrospective == Etherpad: https://etherpad.opendev.org/p/manila-xena-retrospective * We celebrated successful Outreachy internships (Kafilat Adeleke and Archana Kumari), completion of the senior design project of students from Boston University (Ashley Rodriguez, Nicole Chen and Mark Tony) and two Open Source Day mentoring events at the Grace Hopper Celebration. * We have long term contributors in kafilat and archanaserver, along the lines of ashrod98 (who is now a Red Hatter!), disap (at Microsoft!), kiwi_36 (continuing his unified limits work), maaritamm (at city network, is manila core!) and many others. Very proud of the effort the team puts in to attract and retain such talent in the community. * We also discussed the mentoring efforts coinciding with the Yoga release (Northeastern University Cloud Computing course project, Outreachy internships, others). * We anticipate more changes to the maintainers team in the Yoga cycle in our continued effort to build domain expertise around the team, and avoid reviewer burn out. * Thanks to the enthusiastic participation, and to a well groomed bug backlog (kudos, vhari) we had two successful bugsquash weeks and a hack-a-thon during the Xena cycle. We're pruning down the list of stale issues collaboratively. The team liked the frequency of these events. * We discussed the responses for the 2021 User Survey and key takeaways (need for active/active HA, unified limits, unified cli, virtiofs) * Action Items: ** Plan a hack-a-thon in Yoga (topics welcome) ** Update questions for the 2022 user survey ** Plan periodic collaborative code review events alongside the bug squash events to prevent languishing patches. == Share transfers == * haixin highlighted the need for APIs to safely transfer shares across project namespaces and discussed some caveats, and a rough workflow for the feature * To ensure secure multi-tenancy, many back end share drivers use the project_id metadata in their provisioning paths - so transferring resources must send appropriate notifications * For DHSS=True, transfering the share alone makes little sense without first transfering the share network onto which the share is exported - however, multiple shares can be associated with one share network, so this could need a multi-phase transfer needing an ability to rollback. * Action Items: * Propose a spec and discuss the multi-stage implementation of this feature == Project testing and Interoperability improvements == * vhari shared plans for the improvement of the interop guidelines associated with manila * We touched upon the work lkuchlan and vhari are doing to align optional feature testing with tempest's best practices * Third party CI maintainers were reminded that they must be running scenario tests * Action Items: * Team looks at the possible tests to add as advisory to the 2021.11 guideline: https://etherpad.opendev.org/p/refstack-test-analysis == CephFS driver and integration changes == Etherpad: https://etherpad.opendev.org/p/yoga-ptg-manila-cephfsnfs-cephadm * vkmc highlighted the changes intended in the Manila CephFS driver to adopt the ceph mgr nfs APIs instead of the DBUS interactions that the Ganesha interace is coded to perform. The ceph mgr NFS APIs would only work on cephadm-deployed ceph nfs (nfs-ganesha) clusters. * Ceph nfs can be deployed like any other ceph daemon in an active/active HA cluster. One concern was the backwards incompatible changes to default nfs-ganesha configuration - this is being worked out. * TripleO developers joined us to discuss deployment changes, and the upgrade concerns including the eventual change in the NFS VIP. * Action Items: * Share notes about the deployment and upgrade changes necessary to get manila's CephFS driver to work with an active/active NFS HA cluster for the benefit of operators as well as deployment tools like tripleo, kolla-ansible, juju charms, etc. == Manila deployment at the Edge == Etherpad: https://etherpad.opendev.org/p/yoga-ptg-manila-at-the-edge * I quizzed fultonj about the use cases and architecture of the Distributed Compute Node edge deployments that tripleo is capable of orchestrating. * DCN now supports persistent block storage, and enables setting up the service in a multi-backend configuration with local-to-compute backends associated with availability zones that represent the edge sites. * We captured work items to similarly support manila-share at edge sites in this architecture to enable RWX storage at edge sites, and brainstormed future possibilities around the feature (cross site share replication) * Action Items: - A spec to support manila-share in an active/active HA configuration - Testing template for A/A with vendor share drivers == Metadata APIs for all user facing resources == Etherpad: https://etherpad.opendev.org/p/yoga-manila-metadata * ashrod98 discussed the ongoing work to generalize user defined metadata to all end-user facing resources. Currently users can attach metadata to shares and access rules, and the service provides metadata to export locations. * There are changes to the initial design that were brainstormed wrt RBAC and service/operator metadata. * The new APIs are going to be supported in the openstackclient shell implementation * Action Items: * Reviewer attention needed for the changes to the metadata spec, and for new RBAC guarding operator metadata. == Manila UI updates == * vkmc, carloss and haixin presented the plan to update the UI's feature parity * We have two outreachy internship proposals around implementing new UX around share networks and for enhancing integration testing for manila-ui * Action items: * Outreachy contributor period is open, lookout for applicants seeking reviews * Identify trivial API features that can be supported with little effort for the Yoga cycle hack-a-thon == VirtIOFS == Etherpad: https://etherpad.opendev.org/p/nova-manila-virtio-fs-support-yptg-october-2… * tbarron presented updates regarding the ongoing prototyping for nova's support of virtiofs. * There's a demo of how the feature's expected to work: https://asciinema.org/a/IZ7UrhwspxBN63XsOl9JrTcUX?speed=1.5 * The nova discussion (https://etherpad.opendev.org/p/nova-yoga-ptg) included mechanics of supporting read-only attachments, os-share library, mount tags and use cases for baremetal nodes. The specification will be refined to answer some of these questions. * This continues to be a multi-release effort as changes in libvirt, qemu, kvm were needed for live virtiofs attachments. * Action Items: * Review/Refine nova spec: https://review.opendev.org/c/openstack/nova-specs/+/813180 == Multiple share network subnets in an AZ == Etherpad: https://etherpad.opendev.org/p/ptg-multiple-subnet * nahimsouza and felipe_rodrigues presented the use case for share networks to allow multiple subnets per availability zone. * This proposal would make dual stack ipv4/ipv6 networking possible for DHSS=True * Users would also have the ability to modify share networks that were in use - new network allocations will be possible for existing share servers, however, network allocations cannot be deleted. * Concerns were raised regarding the user experience and error signalling when port allocations cannot be made from all relevant subnets. * Action items: * Determine what needs to happen when a subnet has run out of allocations * Propose a specification discussing the API and driver interface impact to accommodate this change == FIPS compatibility and compliance == Etherpad: https://etherpad.opendev.org/p/yoga-manila-FIPS * carloss, ashrod98 and ade_lee spoke of the cross project effort to get FIPS compatibility and compliance testing * We discussed manila's direct/indirect use of cryptographic libraries and FIPS compliant alternatives (md5 in code, and paramiko's use of non-fips compliant digests); manila-tempest-plugin needs fixes along the same lines since it relies on paramiko. * Currently, the team's writing new CI jobs to test compatibility - these should merge by the end of the Yoga release cycle; the goal for compliance would be the Zorilla release (yes, i said it). * Action items: * Work on FIPS compatibility jobs in the Yoga release cycle == Secure RBAC changes in Yoga == Etherpad: https://etherpad.opendev.org/p/yoga-ptg-manila-srbac * vhari and I rounded up the work done so far to update the default RBAC policies across manila APIs and highlighted known issues, and pending work items * Cross service arbitrations on behalf of a user are ongoing discussions elsewhere - examples of these include manila's generic driver where the user's namespace and quota are consumed to create the nas server, backing volume and networking * We are continuing to implement tempest tests and anticipate a large portion to be completed during the Yoga cycle. * We don't plan to support cloud profiles with the manilaclient shell. Users are encouraged to switch to the openstackclient shell to use cloud profiles. * Action items: * Close on known issues in manila code * Complete protection and tempest test coverage == Paying down some technical debt in Yoga == * python-manilaclient still uses keystoneclient instead of keystoneauth1 - vkmc and gouthamr will work on this early in the Yoga release cycle * sqlalchemy2.0 changes - ack'ing SADeprecationWarnings and switching to using the new db engine facade exposed by oslo.db - felipe_rodrigues and gouthamr will work on this during the Yoga cycle * these are wishlist items that need volunteers to drive them to completion: * the generic driver doesn't yet support online extensions - * the generic driver can support more than 26 volumes per share server - this is a wishlist item that needs a volunteer to drive it * we need to publish the container driver image to a container registry from its development within the manila-image-elements project == Backing up shares == Etherpad: https://etherpad.opendev.org/p/ptg-backup-manila * We were joined by operators and storage experts from SAP, CSI Piemonte, NetApp, Red Hat and CERN to discuss current use cases and methods to backing up manila shares * Existing data protection and disaster recovery tools within manila (creating and mounting snapshots, cloning snapshots to new shares, reverting snapshots in-place, replicating shares and snapshots) were compared against the need for scheduling, efficient, incremental, durable/ex-situ/non-homogenous backup destinations, whole container vs selective file backup and recovery. * Available DIY external tooling (restic, borg, urbackup, other) and wrappers were discussed * Creating a backup solution based off-of the manila-data service was considered in the past, the spec was abandoned. It could be revived; however, we could benefit from presenting the need, a state of affairs as they are before exploring solutions. * Action Items: * We'll write up a doc on data protection for manila shares and invite operators to review them and propose future plans; anyone interested in collaborating in this space can get in touch with felipe_rodrigues == OpenStackCLI updates == Etherpad: https://etherpad.opendev.org/p/manila-osc-yoga * Thanks to maaritamm's awesome work, and the enthusiastic hack-a-thon participation from the community, we're very close to parity between OSC and the manilaclient shell. So, the team decided to stop adding new features in the manilaclient shell as a way to gradually wean users off of it. * When using the manilaclient shell from the Yoga release, users will be shown a deprecation warning suggesting an eventual removal (looking at the "A" release for this one, thoughts are welcome). * maaritamm proposed a hack-a-thon for completing the functional testing around manilaclient's osc plugin. * The osc plugin also needs the api microversion negotiation bits that the manilaclient shell currently has. * Action items: * We assigned owners to pending reviews, and missing osc commands * Deprecate the native manilaclient shell. == Manila CSI updates == Etherpad: https://etherpad.opendev.org/p/yoga-ptg-manila-csi * gman0 and tbarron presented the state of the kitchen for manila-csi since the Xena PTG and shared future plans * share backup is now a focus area for pvs serviced by manila-csi - the design involves being able to mount manila snapshots as read only PVs on backup pods and extracting relevant files. * we discussed e2e testing that's being added to the cloud-provider-openstack repository and the results of the perf/scale testing with manila-csi on openshift == OpenStackSDK updates == Etherpad: https://etherpad.opendev.org/p/yoga-manila-openstacksdk-update * we've had several interns working on exposing manila APIs within the openstacksdk since the wallaby release * kafilat has numerous open changes, wrapped up a successful outreachy internship recently * megharth, Jiabo, tutkuna and rishabhdutta from Northeastern University picked up the implementation of the remaining API resources for the Yoga cycle * this continues to be a multi-cycle effort and the plan is to eventually use manila APIs via the openstacksdk within manila-ui, ansible-collections-openstack and manila's OSC plugin. * Action Items: * team will review open changes against the openstacksdk repository pertaining to manila Thanks for reading thus far. It's possible a lot can get lost in translation :) As a reminder, do check out the complete recordings on our Youtube channel! [2] -- Goutham Pacha Ravi PTL, OpenStack Manila [1] https://etherpad.opendev.org/p/yoga-ptg-manila [2] https://www.youtube.com/watch?v=wVAClI82Ths&list=PLnpzT0InFrqDhp1A3lBi_guLA…

1 0

Router interfaces are down
by Jibsan Joel Rosa Toirac 28 Oct '21

28 Oct '21

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. I have search in everywhere but I can't find a solution for this. Thank you for your time

2 1

[all][tc] Technical Committee next weekly meeting on Oct 28th at 1500 UTC
by Ghanshyam Mann 28 Oct '21

28 Oct '21

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

1 1

SSSE3 CPU flag not available
by tarun singhal 27 Oct '21

27 Oct '21

Hello, I have an Openstack cluster which was created using devstack. And recently I was involved in project in which there is a dependency on SSSE3 cpu flag in an Openstack VM instance, to accomplish certain tasks. I searched many posts but couldn't find a definitive solution. The suggestion mentioned didn't worked for me either. I have added below in /etc/nova/nova.conf and restarted devstack(a)n-cpu.service cpu_mode = host-model cpu_model_extra_flags = ssse3 Please let me know a possible way to enable SSSE3 cpu flag in a vm instance. Thanks, Tarun

1 0

[tripleo] x509 certificate Issue in Overcloud Deployment
by Anirudh Gupta 27 Oct '21

27 Oct '21

Hi Team, I am trying to install the Tripleo setup on the Openstack Train. While deploying the overcloud, I am getting an x509 certificate error in downloading the images from quay.io This is because of a proxy certificate in the LAB. Before installing Undercloud, I manually placed the certificate in order to avoid this issue. How can I take care of placing such certificates in case of an overcloud. Regards Anirudh Gupta

2 1

Xena RDO Release Announcement
by Amy Marrich 27 Oct '21

27 Oct '21

If you're having trouble with the formatting, this release announcement is available online at https://blogs.rdoproject.org/2021/10/rdo-xena-released/ ---- *RDO Xena Released* The RDO community is pleased to announce the general availability of the RDO build for OpenStack Xena for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Xena is the 24th release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available on the CentOS mirror network at http://mirror.centos.org/centos/8-stream/cloud/x86_64/openstack-xena/. The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Stream and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. PLEASE NOTE: RDO Xena provides packages for CentOS Stream 8 only. Please use the Victoria release for CentOS Linux 8 which will reach End Of Life (EOL) on December 31st, 2021 (https://www.centos.org/centos-linux-eol/) *Interesting things in the Xena release include:* - The python-oslo-limit package has been added to RDO. This is the limit enforcement library which assists with quota calculation. Its aim is to provide support for quota enforcement across all OpenStack services. - The glance-tempest-plugin package has been added to RDO. This package provides a set of functional tests to validate Glance using the Tempest framework. - TripleO has been moved to an independend release model (see section TripleO in the RDO Xena release) The highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/xena/highlights.html *TripleO in the RDO Xena release:* - In the Xena development cycle, TripleO has moved to an Independent release model( https://specs.openstack.org/openstack/tripleo-specs/specs/xena/tripleo-inde… ) and will only maintain branches for selected OpenStack releases. In the case of Xena, TripleO will not support the Xena release. For TripleO users in RDO, this means that: - RDO Xena will include packages for TripleO tested at OpenStack Xena GA time. - Those packages will not be updated during the entire Xena maintenance cycle. - RDO will not be able to included patches required to fix bugs in TripleO on RDO Xena. - The lifecycle for the non-TripleO packages will follow the code merged and tested in upstream stable/xena branches. - There will not be any tripleoxena container images built/pushed, so interested users will have to do their own container builds when deploying xena. You can find details about this [in RDO webpage](https://www.rdoproject.org/documentation/tripleo-in-xena/) *Contributors* During the Xena cycle, we saw the following new RDO contributors: - Chris Sibbitt - Gregory Thiemonge - Julia Kreger - Leif Madsen Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 41 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and redhat-website repositories: - Alan Bishop - Alan Pevec - Alex Schultz - Alfredo Moralejo - Amy Marrich (spotz) - Bogdan Dobrelya - Chandan Kumar - Chris Sibbitt - Damien Ciabrini - Dmitry Tantsur - Eric Harney - Gaël Chamoulaud - Giulio Fidente - Goutham Pacha Ravi - Gregory Thiemonge - Grzegorz Grasza - Harald Jensas - James Slagle - Javier Peña - Jiri Podivin - Joel Capitao - Jon Schlueter - Julia Kreger - Lee Yarwood - Leif Madsen - Luigi Toscano - Marios Andreou - Mark McClain - Martin Kopec - Mathieu Bultel - Matthias Runge - Michele Baldessari - Pranali Deore - Rabi Mishra - Riccardo Pittau - Sagi Shnaidman - Sławek Kapłoński - Steve Baker - Takashi Kajinami - Wes Hayutin - Yatin Karel *The Next Release Cycle* At the end of one release, focus shifts immediately to the next release i.e Yoga. *Get Started* To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. Finally, for those that don’t have any hardware or physical resources, there’s the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. *Get Help* The RDO Project has our users(a)lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://mail.rdoproject.org. You can also find extensive documentation on RDOproject.org. The #rdo channel on OFTC IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS and TripleO IRC channels (#centos, #centos-devel in Libera.Chat network, and #tripleo on OFTC), however we have a more focused audience within the RDO venues. *Get Involved* To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Join us in #rdo and #tripleo on the OFTC IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube.

1 0

[largescale-sig] Next meeting: Oct 27th, 15utc
by Thierry Carrez 27 Oct '21

27 Oct '21

Hi everyone, The Large Scale SIG meeting is back this Wednesday in #openstack-operators on OFTC IRC, at 15UTC. You can doublecheck how that time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211027T15 A number of topics have already been added to the agenda, including discussing the topic of our next OpenInfra.Live show! Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

How to control data write into a multiattach volume
by open infra 27 Oct '21

27 Oct '21

Hi, I have created a multiattach volume and attached it to several Windows VMs/Instances. Is there away in OpenStack to drop all data written by each VM/instances? I am supposed to periodically detach and attach the multiattach volume. Regards, Danishka

2 1

[cinder] Bug deputy report for week of 10-27-2021
by Sofia Enriquez 27 Oct '21

27 Oct '21

This is a bug report from 10-13-2021-15-09 to 10-27-2021. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/cinder/+bug/1948916 'Inconsistency for resource column between quota_usages and reservations table'. Unassigned. - https://bugs.launchpad.net/cinder/+bug/1947518 '[RBD] Cinder started requiring write access to glance images of RBD pool'. Unassigned. - https://bugs.launchpad.net/cinder/+bug/1947123 '[IBM GPFS] NFS driver throws an error while volume creation in copy-on-write mode'. Assigned to Digvijay Ukirde. - https://bugs.launchpad.net/cinder/+bug/1947134 '[IBM GPFS] NFS driver does the same filesystem check locally and fails initializing the driver in copy-on-write mode'. Assigned to Digvijay Ukirde. - https://bugs.launchpad.net/cinder/+bug/1946262 'NetApp ONTAP is losing QoS with assisted storage migration'. Assigned to Felipe Rodrigues. - https://bugs.launchpad.net/cinder/+bug/1948934 '[Victoria] Backported test requires newer ddt than included in test-requirements.txt'. Unassigned. Incomplete - https://bugs.launchpad.net/cinder/+bug/1947066 'snapshot status hang in backing-up'. Unassigned. Low - https://bugs.launchpad.net/cinder/+bug/1948507 'TypeError when computing QOS feature name'. Unassigned. - https://bugs.launchpad.net/cinder/+bug/1947834 'wrong href returned in volume detail'. Unassigned. -- 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

[qa][ptg] PTG Summary
by Martin Kopec 27 Oct '21

27 Oct '21

Hi everyone, thank you all who participated in the PTG discussions and shared their thoughts and opinions. It's very much appreciated! Here is the summary of the topics we have discussed [1]: * Migration of devstack and Tempest tests to new secure RBAC ** Tempest side appear to be ready, further work is required on Devstack's side. * Xena retrospective ** Among good things belong: *** a few long term unfinished effort got completed *** a participation in an open source contest, which also helped in the above point *** a great response time in devstack patches *** quite prompt fixing devstack gate issues - thank you all who are active in Devstack, great job! ** Bad things to mention: *** not enough active contributors in Tempest and especially in Patrole project *** long review time in Tempest and Patrole * Cleanup of duplicated scenario.manager ** we will start with removing duplicated scenario.manager (Tempest's stable interface) methods from plugins ** this follows the 'making tempest.scenario.manager interface stable' effort done ~2 cycles ago * Test inheritance conventions, are there any ** we discussed usage of DDT library - it has turned out it complicates things when the test names are generated dynamically (it's hard to track the tests then) and because in DDT case the tests are not associated with any UUID ** * FIPS support ** current issues with FIPS at [3] - raised by Ade Lee ** the plan here from high level point of view is we'll use new jobs (with FIPS enabled) in Tempest so that we can identify and fix the tests that don't comply with FIPS * Patrole stable release updates and discussion ** A big question has been raised, do we have someone who can drive the patrole's migration to new RBAC? That's important because as mentioned before, there aren't many contributors in Patrole. ** There was an idea raised to retire the project - mainly because it's hard to maintain it (not enough contributors) and because the gates were broken for several months during the Xena cycle and mostly none had noticed - which raises another question - is the project needed/used by anyone? The discussed topics are transformed into priority items [2] we will be focusing on this cycle. [1] https://etherpad.opendev.org/p/qa-yoga-ptg [2] https://etherpad.opendev.org/p/qa-yoga-priority [3] https://etherpad.opendev.org/p/state-of-fips-in-openstack-ci-yoga Regards, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

1 0

[kolla-ansible][neutron]BGP Problems
by Franck VEDEL 27 Oct '21

27 Oct '21

Hello, I'm trying to get BGP / BGP speaker / DRAgent to work with Neutron on one side and a Cisco router on the other. I work under Centos / Kolla-ansible / Wallaby. I adapt this technical documentation (https://docs.openstack.org/neutron/latest/admin/config-bgp-dynamic-routing.…) to my configuration but I am having difficulties (the cisco router sends a TCP SYN frame to the router in Openstack, TCP port 179, but the router sends back an RST. I don't understand why, no security on the router port). Do you have any links to help, tutorials, that would be of great help to me. Thanks in advance. Franck

2 2

[openstack-ansible][osa][ptg] Yoga PTG summary
by Dmitriy Rabotyagov 27 Oct '21

27 Oct '21

1 0

Devstack stack run issue
by Venkata Krishna Reddy 27 Oct '21

27 Oct '21

3 3

[tc][all][ Yoga Virtual PTG Summary
by Ghanshyam Mann 27 Oct '21

27 Oct '21

Hello Everyone, I am summarizing the Technical Committee discussion that happened in the Yoga cycle PTG last week. 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 TC + Community leaders interaction ------------------------------------------ This is our first session in PTG to interact with community leaders and ask for feedback on TC. Below are the topics we discussed in this feedback session * What is TC responsibility: This is the first feedback we started this session, to discuss what is the role of TC other than accepting/ removing the projects and community-wide goals. does TC need to have a strong vision and start working on that? Why not TC do more technical work than spend time on composing resolutions or so? All those were valid points and we all agreed that TC should be doing more technical work and providing more guidance to the community on the cross-project works for example RBAC, Unified limit (more of similar way API SIG is doing on API side). * Improving community-wide goal process: Another feedback was on the effectiveness of community-wide goals. A few of the community-wide goals were not ready when they were selected. Even a few like pdf goal changed the implementation in milestone-2 and projects have to update the previous implementation. Or sometimes we try too much to do instead of small steps like IPV6 testing. With all feedback, we agreed to have a more concrete checklist when we select any goal and also check project bandwidth to complete the work. * Fewer contributors: Fewer contributors issue is from many projects, to solve that at some extent, TC will encourage projects to apply in outreachy/mentorship programs where few projects have received a good amount of help. * Improving CI: Improving CI is the next topic which we discussed in TC slots on Thursday. One key topic in this was "Request to be able to recheck on a single test instead of the whole check test" as many projects like Ironic gate has more often neutron failure and they have to recheck the complete set of jobs. The issue can be from DHCP, memory etc. We do not think allowing job-specific recheck is the right direction here and instead, we should encourage projects to solve the failures we get in the gate which can improve the code stability. Also, we should encourage projects to monitor the gate failures. >From the above discussion, we are taking below two action items for TC: 1. TC to start composing the technical guidelines on various topics like 'unified limit' etc similar way API SIG has done. 2. TC to add a more specific checklist for community-wide goal readiness and make them more successful as they are currently. TC interop sync on guidelines ----------------------------------- We discussed interop tests requirements. One of the points brought that if starter kits impact interop guidelines to consider but it does not. Can cinder be separated from "OpenStack Powered Compute" if it can be used as standalone? The Interop team need to check if there are cloud without cinder and how they apply for interop certification. On tests requirement by interop, our current process stays same that if interop defined the capabilities in new guidelines then the test writing can be requested or even an interop group can propose the test in Tempest or Tempest plugins. Technical Writing (doc) SIG need a chair and more maintainers ----------------------------------------------------------------------- We are merging this SIG repo into TC responsibility. There are not many activities nowadays on this SIG or repo it own so it should not impact the TC work as such. We agreed to distribute this SIG repo in * TC: api-site, constellations, and openstack-manuals repos under * FC SIG: contributor-guide, training-guides, and upstream-institute-virtual-environment * For training-labs which is for COA, I will check with Foundation on ownership or it. Thanks, Stephen for serving as chair for this SIG. Yoga testing runtime: Review & Update if needed ---------------------------------------------------------- We discussed/iterate over the Yoga testing runtime on new distro and python versions to tests. Distro to tests: * We agreed on including "Debian Bullseye" as a distro in the testing runtime. * centos9-stream release time is not clear so we are keeping centos8-stream for now. * centos8 is planned to be EOL at end of 2021, If you see failure on or stable branch testing, then you can update it to centos8-stream (devstack support is already there) But we do not need to change the testing runtime for stable branches as such. Python Versions to test: * py3.8 as voting (no change from currently tested) * py3.9 as voting * py3.10 as non voting. * keep py3.6 until we move from centos8-stream to centos9-stream I will update the testing runtime doc and job template for that. TC tags review ------------------ You might have seen the email from yoctozepto about a query on TC tag usage[1]. As we did not get any response in the email, we did final checks in PTG. We agreed to start the tag framework removal proposal on ML and if there is no objection for a week or so then we will remove it. Improvement in project governance ------------------------------------------ In the past couple of cycles, we have seen few projects that are not so active or not getting more attention from users. This discussion was to brainstorm the process to keep monitoring such projects and especially when there is a new project application how we can monitor those in initial time to check if they have all the required things working to stay as official OpenStack project. The first thing we discussed introducing the different levels of the project something similar to CNCF (sandbox, incubated, graduated) or OpenStack used to have (incubation -> incubated projects). But it is not known if these levels will work well in our governance. With the low cost to maintain projects in OpenStack governance (as long as they are active). Being an OpenStack official project is one way to give that project more visibility in the market and attract users/contributors. With all these points, we agreed not to introduce the different levels in the project hierarchy but we will introduce a new process of 'Tech Pre-review' for new project applications so that we can monitor the new projects if they are doing good and all minimum required things are working smoothly. As the next step, we will be working to define the "Tech Pre-review" checklist and timeline etc. Release name process change ----------------------------------- We want to discuss two points 1. allow community members to vote on release name 2. some pre-trademark (non-paid) checks, in this topic but due to time limit we discussed first only. As you might know, we changed the electorate on release naming from community to TC which has been objected to in the past when we changed it and during the naming voting also in the past couple of cycles. We have simplified the name proposal criteria in the past which solved the issue that occurred in past on TC removing the name. We agreed on: * The community can propose names that meet the convention. * The TC will ensure that the name is not offensive based on community feedback. * Allow community members to vote on the proposed names. * After Z cycle, go back to 'A' and go through the alphabet (obviously don't re-use names). Pain Point targeting ----------------------- Two key pain points we collected during TC weekly meetings were 1. Rabbitmq 2. OpenStackClient support. But the etherpad has a lot more pain points not only from projects but also from operator or project has collected those from operators. We need to iterate the list again which we will continue doing in TC weekly meetings. TC members will encourage projects to fix or have a look into those pain points if the operator has added them. TC also can help a few of the pain points to solve consistently by defining the technical guidelines for such common pain points. As the next step, we will continue reviewing the list in etherpad[2]. 'Skyline' application to become an official OpenStack Project ------------------------------------------------------------------------ We discussed the new project application Skyline which is a dashboard project for OpenStack. One of the key points raised is about non-integrated projects UI-plugins (like every project has horizon plugins for their UI). How and who is going to implement the new UI plugins on the project's side? Also, there is more work needed on repos and python packaging side for which discussion is going in separate mailing thread[3]. Overall, we are ok to proceed with the proposal once the python package/repos things are set up correctly. Discussion on new RBAC ------------------------------ There were a lot of discussions on the new RBAC on various project sessions. it was clear from the discussion or points raised in those sessions that we are not using the system scope in the way it should be used. We should keep system-level operation only for system scoped and project level for the project. If any system users want to perform the project level operation then they can request the project token and then request. Also, 'admin' term at all levels domain, system, and the project is the most confusing term and we would like to change that to 'manager' or so. The discussion is not yet over and due to the time limit, we wanted to continue it after PTG too. As a summary, we selected this (current way) as Yoga cycle goal which we will re-iterate. I will set up the call to continue the discussion and send on openstack-discuss mailing list. For a detailed summary, please refer to L122 in policy popup etherpad[4]. Community-wide goals ---------------------------- Based on the feedback received in TC+community leaders sessions, we would like to make sure we have the proper checklist to know this goal is ready to start (in terms of implementation details as well as projects bandwidth). Rico and I had worked on such a checklist in the past but did not push for review which we should do now. We are also restructuring the community-wide goal timeline by decoupling them from the release cycle. At a time we will select one or more goals to start with one or more milestones. They can be multi-cycle goals or single based on the goal nature and work it needs. This way we will make sure that we complete the work needed to be done for that goal irrespective of the current cycle release. Xena Retrospective ----------------------- What went well? * Xena cycle tracker status: Completed the 9 items out of 13, others in progress. * Think having the weekly meetings went well instead of just office hours. * Got good feedback from the community about what they expect from the TC. * We have been good at keeping our open reviews low. What to change or any other feedback? * Be more technical, provide more technical guidance. * Get a feedback loop from the community and work on that feedback. Pop Up Team Check In ---------------------------- * Secure RBAC / Policy As discussed in RBAC discussion, there are a lot of work still needed along with community-wide goal. We decided to continue this pop-up team for the Yoga cycle at least. * Encryption Slow progress but still more work to do (waiting on changes in Barbican). The Team is hoping for more progress in the coming cycle. We will continue this pop-up team. Meeting check ----------------- We will continue the weekly meeting at the same time they are currently and also continue the monthly video call. We will continue using google meet until we figure out the recording things in meetpad or so. We did not discuss or check on office hours whether to continue those or not which we will continue in weekly meetings. User Survey Feedback Responses --------------------------------------- We will start working on analyzing the feedback from the user survey. Jay will summarize the feedback and then we will start composing the action items accordingly. k8s Steering Committee Cross community Discussions ----------------------------------------------------------------- This is our last hour of the PTG. This is cross-community sessions we continue organizing in PTG. From Kubernetes steering committee, we had Dims, Bob, Christoph joined along with OpenStack TC and a few non-tc members. The first topic we talked about is the different levels in the CNCF ladder and project confirmation process. This area is mostly taken care of by CNCF and Kubernetes community more concentrate on the technical part. Like OpenStack, Kubernetes is also seeing a slow down in project/SIG activities especially on community leaders. Kubernetes is trying mentor/cohort and more distributed roles by documenting the responsibility of that role that will help contributors to discuss it with their employer. OpenStack Upstream investment opportunity is one of the things we discussed and how successful that is. One of the benefits of this is we can communicate the help-needed things on various platforms/forums. ELK is one (the only as of now) example of success. Like OpenStack, Kubernetes also lacks in CI/CD resourcing and funding. This seems like a common problem in many OSS communities. Yoga cycle tracker ---------------------- Like we did in Xena cycle, TC is defining the cycle-wise tracker to complete the set of things TC would like to work on. For the Yoga cycle also we will continue with the tracker. Based on the PTG discussion, we have collected 9 items for the Yoga cycle to complete. I have captured those in the below etherpad which will be using it for progress tracking also. - https://etherpad.opendev.org/p/tc-yoga-tracker [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-September/02480… [2] https://etherpad.opendev.org/p/pain-point-elimination [3] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025397.… [4] https://etherpad.opendev.org/p/policy-popup-yoga-ptg [5] https://etherpad.opendev.org/p/tc-xena-tracker -gmann

1 0

[TripleO] PTG Summary
by James Slagle 26 Oct '21

26 Oct '21

TripleO had PTG sessions on Monday, Tuesday, and Wednesday, followed by a Directord+Task-Core hackfest on Thursday. The main etherpad for the PTG is at https://etherpad.opendev.org/p/tripleo-yoga-topics (includes links to recordings) Overall Summary =============== Our sessions were well attended with good cross collaboration from external stakeholders (storage, network, compute, etc). We had a good mix of topics, which I felt helped maintain interest and engagement. Topics ranged from future proposals, integrations, CI, and infrastructure. Our attendance was between 30-40 for most sessions. The underlying theme of the week was about the proposed migration from Ansible to Directord+task-core. Overall, I felt we accomplished clarifying the scope of the proposed change and articulating the reasons why the change is necessary, as well as understanding the benefits. With the heavy current investment in Ansible specific components, we emphasized the need for migration tooling wherever possible. No significant objections were raised about the approach. However, we settled on the next steps being agreement in the spec, and agreement around the end to end integration in TripleO. We continued to tie most other topics we discussed back to this topic to make sure we were considering the future impacts. The hackfest on Thursday further helped to understand the proposal and illustrated several key concepts that are presently missing in TripleO. Namely, those of dynamic service dependency management, job result caching and fingerprinting, and the messaging architecture. We had around 30 participants during the hackfest. We took a team photo on Thursday which we can be seen at https://slagle.fedorapeople.org/TripleO-Yoga-PTG-Team-Photo.png Thanks for the participation everyone! Sessions ======== Monday ------ 1310-1350 Directord/task-core introduction and overview https://etherpad.opendev.org/p/tripleo-directord-task-core The overview of Directord and task-core was presented, and we clarified the scope of the change, which is primarily about replacing Ansible in TripleO. As part of the change, we will need to migrate from all Ansible specific implementations (playbooks, roles, tasks, modules, actions, etc) to pure Python or Directord orchestrations and components. We emphasized the need for migration tooling wherever possible. No major objections were raised, and I felt the team understood the proposed benefits. Next steps are to finish the spec and continue on the TripleO integration. 1405-1445 task-core task graphs and execution concepts https://etherpad.opendev.org/p/tripleo-task-core-execution Further illustrated the benefits and functionality gained with task-core, particularly around the dynamic dependency ordering for tasks. Explained the benefits for services with a lot of external deployment tasks, such as Octavia. 1500-1540 (CI) Tripleo Health https://etherpad.opendev.org/p/tripleo-ptg-tripleo-health Really great work by the CI team on http://ci-health.tripleo.org/ and https://opendev.org/openstack/tripleo-ci-health-queries. We need to get the whole team committed to maintaining the queries for the most benefit. 1540-1620 OS Migrate update/feedback session https://etherpad.opendev.org/p/yoga-os-migrate Update on new features added to os-migrate, and version/compatibility testing. Tuesday ------- 1310-1350 ceph integration https://etherpad.opendev.org/p/tripleo-ceph-yoga Plan to remove support for ceph-ansible, and add cephadm ingress with haproxy+keepalived. Upgrade challenges around migrating from PCS to ingress. We also need to keep ceph integration as a priority and proving ground for migration to Directord+task-core. 1405-1445 healthchecks https://etherpad.opendev.org/p/tripleo-healthchecks-yoga Participation from Sean Mooney from the Nova team to present the proposed solution in Nova. Agreement this would work well for TripleO. We need to continue the collaboration and participate in the pending Nova spec to help drive the healthcheck model. 1500-1540 (HA) Pacemaker brainstorming https://etherpad.opendev.org/p/tripleo-yoga-pacemaker General consensus is that we still need pacemaker for some tasks. But, we need to evaluate each usage on a case by case basis and migrate services out of pacemaker where there is opportunity. 1540-1620 FIPS Updates & Secret Management https://etherpad.opendev.org/p/yoga-tripleo-fips Plan to go forward with the spec for secret management in TripleO. Wednesday --------- 1310-1350 (CI) tripleo-repos updates https://etherpad.opendev.org/p/ci-tripleo-repos Update on tripleo-repos and new functionality (yum config, tripleo-get-hash). Covered ansible integration (for CI). 1405-1445 (CI) Update on CI and centos9 prep work https://etherpad.opendev.org/p/centos-stream-9-upstream Discussed needed CI jobs and CentOS 9 timeline. 1500-1540 Dependency clashes installing branched and non-branches repos in Zuul jobs https://etherpad.opendev.org/p/branched-unbranched-dependency-clashes Discussed limiting the usage of upper constraints as the overall approach. 1540-1620 RDO Releases Agreed that providing the list of last tested hashes to RDO for releases that TripleO doesn't support is sufficient. We reviewed the RDO/TripleO support statement around intermediary releases that TripleO doesn't plan to maintain. https://review.rdoproject.org/r/c/rdo-website/+/36342 Hackfest ======== The team participated in the hackfest by following through the etherpad at https://etherpad.opendev.org/p/tripleo-directord-hackfest. Several participants were able to get the environment up. We were able to work through various issues as they arose. Good discussion around UX improvements that are needed, and the apparent benefits for different services due to the dynamic dependencies, job caching, execution time, etc. Also shared the POC of the end to end integration within TripleO. -- -- James Slagle --

1 0

Guest's secondary/virtual IP
by lejeczek 26 Oct '21

26 Oct '21

Hi guys. What I expected turns out not to be enough, must be something trivial - what am I missing? I set a port with --allowed-address and on the instance/guest using the port I did: -> $ ip add add 10.0.1.99/24 dev eth1 yet that IP other guest cannot reach. many thanks, L.

2 2

[skyline][tc] October 2021 - PTG Summary
by Boxiang Zhu 26 Oct '21

26 Oct '21

Hi, Well, it's Skyline Team's first time to attend the PTG : ) Thank you for your attention and discussion of Skyline. And welcome more friends to join us! You can see all the notes in a read-only etherpad here: - skyline etherpad: https://etherpad.opendev.org/p/r.b44d07e6504a4b38514b2717f01aca62 - tc etherpad: https://etherpad.opendev.org/p/r.a07136b01df95515f32c4cb779faa45c#L395 ## reorganize to one Python package per Git repository Now skyline-apiserver has divided the source code into six sections: - skyline-apiserver: core source code of skyline apiserver - skyline-config: config library with yaml to parse config file - skyline-console: git submodule of skyline-console - skyline-log: log library with loguru - skyline-nginx: generate the nginx.conf file with openstack environment - skyline-policy-manager: generate policy yaml file Generally, we just focus on skyline-apiserver. ## stop using Git's submodule feature Is there any reason why we should stop using git's submodule? ## use Python package configuration and tooling consistent with existing OpenStack projects Now skyline-apiserver use yaml to parse config and poetry to manage dependency. ## call Python entrypoints directly from tox instead of using tox as a wrapper around make Scripts[0] get converted to console_scripts entry points, plugins[1] would allow for arbitrary entry points. https://python-poetry.org/docs/pyproject/#scripts https://python-poetry.org/docs/pyproject/#plugins ## constrain Python dependencies and test dependencies in tox configuration (pip -c) Yet, there is no constraints like pip -c in poetry. Find some discussion about this in poetry. But all are closed, not merged. https://github.com/python-poetry/poetry/pull/4005 https://github.com/python-poetry/poetry-core/pull/172 ## track Python dependencies and test dependencies in requirements files Now we track python depentdencies and test dependencies in poetry's tool.poetry.dependencies and tool.poetry.dev-dependencies ## get Python package versions from Git tags rather than hard-coded in configuration files Sure, but hard-coded package version is not serious problem. ## rely more on Oslo libraries (currently only oslo.policy is used) Reuse wherever possible. oslo.policy is used to generate the policy yaml for skyline to use. ## Horizon has plugin support so that projects like Manila can add dashboard support. Skyline's architecture and technology stacks are different from horizon. So we will continue to explore how to gracefully add non-core module functionality via plug-ins. At the same time, we will also improve core component functions. Best Regards Boxiang Zhu

2 1

[nova][placement] Yoga PTG summary
by Sylvain Bauza 26 Oct '21

26 Oct '21

Well, it's a try given we discussed for 4 days and it could be a large summary ;) You can see all the notes in a read-only etherpad here : https://etherpad.opendev.org/p/r.e70aa851abf8644c29c8abe4bce32b81 ### Cross-project discussions # Cyborg cross-project discussion with Nova We agreed on adding a OWNED_BY_NOVA trait for all Resource Providers creating by Nova so Cyborg would provide their own OWNED_BY_CYBORG trait for knowing which inventories are used by either Nova or Cyborg. Cyborg contributors need to modify https://review.opendev.org/c/openstack/nova-specs/+/780452 We also agreed on the fact that https://blueprints.launchpad.net/nova/+spec/cyborg-suspend-and-resume is a specless blueprint. # Oslo cross-project discussion with Nova gmann agreed on providing a new flag for oslopolicy-sample-generator for adding deprecated rules in the generated policy file. # RBAC popup team discussion with Nova Eventually, we found no consensus for this topic as there were some left open questions about system-scope. FWIW, the popup team then discussed on Friday with the TC about this, so please look at the TC etherpad if you want to know more. A side impact is about https://review.opendev.org/c/openstack/nova-specs/+/793011 which is now punted until we figure out a good path. # Neutron cross-project discussion with Nova Again, about RBAC for external events api interaction, we discussed about the scopes and eventually punted the discussion. About specific events related to Neutron backends, ralonso accepted to provide a documentation explaining what backends sends which events, and we accepted to merge https://review.opendev.org/c/openstack/nova/+/813419 as a short-term solution while we would like to get a long-term solution by having Neutron providing the event information by the port binding information. About testing move operations, we agreed on continuing to have a ML2/OVS multinode job. During another Nova session, we also agreed on changing libvirt to directly unplug (not unbind) ports during VM shutdown. # Interop cross-project disussion with Nova We agreed on reviewing https://review.opendev.org/c/openinfra/interop/+/811049/3/guidelines/2021.1… # Cinder cross-project discussion with Nova We discussed about https://blueprints.launchpad.net/nova/+spec/volume-backed-server-rebuild and we said the workflow should be something like user > nova > cinder > nova. We also discussed about some upgrade questions for this one, but we eventually agreed on it. We also discussed about devstack-plugin-nfs gate issues and how to contact the nova events API for resize. # Manila integration with libvirt driver The first spec looks promising https://review.opendev.org/c/openstack/nova-specs/+/813180 There were discussions about cloud-init and the Ironic case, but we agree on the smaller scope for the Yoga release that's proposed in the spec. ### Nova specific topics ### # Xena retrospective We agreed on stopping to have an Asian-friendly meeting timeslot once per month as unfortunately, no contributors went to meetings when we had them. We also agreed on modifying the review-priority label for abling contributors to use it too, but we first need to provide a documentation explaining it before we change Gerrit. # Continuing to use Storyboard for Placement or not ? We eventually said we would look at how create a script for moving Storyboard (SB) stories to Launchpad (as either features or bugs) but we still want to continue verifying whether contributors use Storyboard for Placement bugs or feature requests and bauzas accepted to provide visibility on Placement SB stories during the weekly meeting. gmann also agreed on asking contributors to move off the #openstack-placement IRC channel to #openstack-nova so we would delete this IRC channel eventually during this cycle. # Yoga release deadlines for Nova No real change in deadlines compared to the Xena timeframe. We agreed on having two spec review days, one around mid-Nov (before yoga-1) and one around mid-Dec (before Christmas period) in order to prioritize implementation reviews after Jan 1st even if we can continue to review specs until yoga-2. # python version pinning with tox We agreed on the fact this is a pain for developers. We then had a consensus on modifying tox to accept multiple python versions automatically with https://review.opendev.org/c/openstack/nova/+/804292 so it would fix the issue. # Nova DB issues with DB coalation We agreed on the fact it's a problem, so we'll document the fact that Nova APIs are case-insensitive at the moment even if Python is case-sensitive, which creates problems. What we propose in order to fix this is to provide a nova-manage db upgrade command that would modify the DB tables to use COLLATE utf8_bin but we also agree we can't ask operators to migrate by one cycle and we accept the fact this command could be there for a while. # SQLAlchemy 2.0 The wave is coming and we need contributors to help us change what we have in our nova DB modules to no longer use the deprecated calls. This looks a low-hanging-fruit and I'll try to find some contributor for this. # Bumping minimum microversion from v2.1 No, we said no because $users use it. # Unified limits We agreed on providing a read-only API for knowing the limits but *not* providing proxy APIs for setting limits *as a first attempt*. We prefer operators to come back with usecases and feedback from their use of Unified Limits 1.0 before we start drafting some proxy API to Keystone. Also, we agreed on *not* having config-driven quotas. # Central vncproxy in a multiple-cells environment We understand the usecase which is very specific and we accept to create a central vncproxy service that would proxy calls to the cell-related vncproxy service but this is not a pattern we want to follow for every cell-specific nova service. # Move instances between projects. Well, we totally get the usecase but we absolutely lack of resources in order to work on this very large effort that would span multiple services. # Nova service healthchecks We agreed on providing a way for monitoring tools to ping Nova services for healthness thru http or unix socket, from every service that would return a status based on cached data. A spec has to be written. # Zombie Resource Providers no longer corresponding to Nova resources Thanks to the OWNED_BY_NOVA trait we agreed when discussing with the Cyborg team, we could find a way to know the ResourceProviders owned by Nova that are no longer in use and we could consequently delete them, or warn the operator if existing allocations are present. # NUMA balancing This is definitely a bug we will fix by providing a workaround config option that will let operators define the packing or spreading strategy they want for NUMA cell stacking (or not). # Deprecation of the novaclient shell command Yes, now that the SDK is able to negociate, we can deprecate the novaclient CLI. More investigation work has to be done in order to know whether we can also deprecate the novaclient library itself. # Integration with Off-Path Network Backends Lots of technicalities with this very large spec https://review.opendev.org/c/openstack/nova-specs/+/787458. Long story short, we asked the proposer to add a few more details in the spec about upgrade scenarios, move operations and testing, but we also told that we can't accept this spec until the Neutron one lands as there are some usage from the extended Neutron APIs that are proposed in the Nova spec. # 'pc' and 'q35' machine types We agreed on changing the default machine type to 'q35' but we also agreed on *not* deprecating the 'pc' type. Some documentation has to be written in order to explain the intent of the migration. # Nova use of privsep sean-k-mooney agreed on working on a patch to remove usage of CAP_DAC_OVERRIDE and on another patch to provide the new capabilities for the monolith privsep context (a few other topics were discussed but I skipped them from my summary as they're not significant for either operators or other contributors but a very few people - don't get me wrong, I like them but I don't wanna add more verbosity to an already large summary) ### Nova painpoints (taken from https://etherpad.opendev.org/p/pain-point-elimination) # Ironic hashring failure recovery That's a latent bug but we don't want the Ironic virt driver to modify the host value of every instance. We'd rather prefer some operator action in order to communicate Nova it has to shuffle a few things. More brainstorm has honestly to be done with this as we haven't clearly drafted a designed solution yet. # Problems with shelve, unshelve and then shelve back Well, this is a nasty bug and we need to fix it, agreed. We also have a testing gap we need to close. # Naming cinder volumes after nova instance name We said yes, why not. We also considered that 'delete on terminate' has to change so it does delete the volume when you delete the instance (for a boot-for-volume case) # Orphaned instances due to underlying network issues We agreed on the fact it would be nice to provide a tool for knowing such orphans and we also think it's import for instance force-delete API call to complete successfully in such case. # reminiscent guests on a recovered compute node while instance records were purged Well, we should avoid to purge instance records from the Nova DB if we are still unable to correctly delete the compute bits unless the operator explicitly wants to (in the case of a non-recoverable compute for example). A potential solution can be to add a config flag to *not* archive deleted rows on instances that are running on down computes. # Nova APIs leaking hypervisor hardware details No, we don't want this but we can try to add more traits for giving more visibility on a case-by-case basis # RabbitMQ replacement Well, we're unfortunately lacking resources on this. We recommend the community to investigate on use of a NATS backend for oslo.messaging # Placement strictness with move operations We agree this is a bug that needs to be fixed. Okay, if you reach this point, you're very brave. Kudos to you. I don't really want to reproduce this exercice often, but I just hope it helps you summarizing a thousand-line large etherpad. -Sylvain

2 2

Octavia loadbalancer status offline
by Md. Hejbul Tawhid MUNNA 26 Oct '21

26 Oct '21

Hi, We have installed openstack ussuri version from ubuntu universe repository. We have installed octavia 6.2.0 version. after creating loadbalancer , listener and pool all are offline. but the LB operation is working as expected. changing the pool member is also working. octavia is installed in compute node. 5555 is listening and allowed in iptables (iptables -I INPUT -i o-hm0 -p udp --dport 5555 -j ACCEPT). amphora to octavia-worker(172.16.0.2) is reachable. Any idea to troubleshoot this issue Please find the log from octavia-worker ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// 2021-10-25 18:15:13.482 1192307 WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [req-806e5e6b-46b0-4a52-900f-7c2d22d4442d - 9a817a70161d45fd9f0b5fe2cad30f5c - - -] Could not connect to instance. Retrying.: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='172.16.1.220', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f540e192be0>: Failed to establish a new connection: [Errno 111] Connection refused')) 2021-10-25 18:15:18.490 1192307 WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [req-806e5e6b-46b0-4a52-900f-7c2d22d4442d - 9a817a70161d45fd9f0b5fe2cad30f5c - - -] Could not connect to instance. Retrying.: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='172.16.1.220', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f540c0ddd00>: Failed to establish a new connection: [Errno 111] Connection refused')) 2021-10-25 18:15:23.507 1192307 WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [req-806e5e6b-46b0-4a52-900f-7c2d22d4442d - 9a817a70161d45fd9f0b5fe2cad30f5c - - -] Could not connect to instance. Retrying.: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='172.16.1.220', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f540c0ddd90>: Failed to establish a new connection: [Errno 111] Connection refused')) 2021-10-25 18:15:28.511 1192307 WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [req-806e5e6b-46b0-4a52-900f-7c2d22d4442d - 9a817a70161d45fd9f0b5fe2cad30f5c - - -] Could not connect to instance. Retrying.: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='172.16.1.220', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f540c0ddbb0>: Failed to establish a new connection: [Errno 111] Connection refused')) 2021-10-25 18:15:33.521 1192307 WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [req-806e5e6b-46b0-4a52-900f-7c2d22d4442d - 9a817a70161d45fd9f0b5fe2cad30f5c - - -] Could not connect to instance. Retrying.: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='172.16.1.220', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f540c064190>: Failed to establish a new connection: [Errno 111] Connection refused')) 2021-10-25 18:15:38.529 1192307 WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [req-806e5e6b-46b0-4a52-900f-7c2d22d4442d - 9a817a70161d45fd9f0b5fe2cad30f5c - - -] Could not connect to instance. Retrying.: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='172.16.1.220', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f540d111790>: Failed to establish a new connection: [Errno 111] Connection refused')) 2021-10-25 18:15:43.540 1192307 WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [req-806e5e6b-46b0-4a52-900f-7c2d22d4442d - 9a817a70161d45fd9f0b5fe2cad30f5c - - -] Could not connect to instance. Retrying.: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='172.16.1.220', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f53ec7a3670>: Failed to establish a new connection: [Errno 111] Connection refused')) 2021-10-25 18:15:48.549 1192307 WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [req-806e5e6b-46b0-4a52-900f-7c2d22d4442d - 9a817a70161d45fd9f0b5fe2cad30f5c - - -] Could not connect to instance. Retrying.: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='172.16.1.220', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f53ec74d0d0>: Failed to establish a new connection: [Errno 111] Connection refused')) 2021-10-25 18:15:53.554 1192307 WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [req-806e5e6b-46b0-4a52-900f-7c2d22d4442d - 9a817a70161d45fd9f0b5fe2cad30f5c - - -] Could not connect to instance. Retrying.: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='172.16.1.220', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f53ec75a7f0>: Failed to establish a new connection: [Errno 111] Connection refused')) 2021-10-25 18:15:58.561 1192307 WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [req-806e5e6b-46b0-4a52-900f-7c2d22d4442d - 9a817a70161d45fd9f0b5fe2cad30f5c - - -] Could not connect to instance. Retrying.: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='172.16.1.220', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f53ec75a6a0>: Failed to establish a new connection: [Errno 111] Connection refused')) 2021-10-25 18:16:04.707 1192307 INFO octavia.controller.worker.v1.tasks.database_tasks [req-806e5e6b-46b0-4a52-900f-7c2d22d4442d - 9a817a70161d45fd9f0b5fe2cad30f5c - - -] Mark ALLOCATED in DB for amphora: c661b828-1690-4866-8152-f745c43e0977 with compute id c9133819-b8e0-42d6-9544-bf83e3ad4b3f for load balancer: c0bd3e21-6983-40c9-8713-859194496b37 2021-10-25 18:16:40.660 1192307 INFO octavia.controller.worker.v1.tasks.database_tasks [req-78e78f29-3bdb-4b12-ae76-b8daa4926c09 - 9a817a70161d45fd9f0b5fe2cad30f5c - - -] Mark ACTIVE in DB for load balancer id: c0bd3e21-6983-40c9-8713-859194496b37 2021-10-25 18:16:44.317 1192307 INFO octavia.controller.queue.v1.endpoints [-] Creating listener 'cc45192d-de70-4d59-857b-ac23c4fc8d07'... 2021-10-25 18:16:44.325 1192307 WARNING octavia.controller.worker.v1.controller_worker [-] Failed to fetch listener cc45192d-de70-4d59-857b-ac23c4fc8d07 from DB. Retrying for up to 60 seconds. 2021-10-25 18:17:35.375 1192307 INFO octavia.controller.queue.v1.endpoints [-] Creating pool '9d23855f-d849-4ad9-9de1-66ab5cd268eb'... 2021-10-25 18:17:35.382 1192307 WARNING octavia.controller.worker.v1.controller_worker [-] Failed to fetch pool 9d23855f-d849-4ad9-9de1-66ab5cd268eb from DB. Retrying for up to 60 seconds. 2021-10-25 18:18:02.814 1192307 INFO octavia.controller.queue.v1.endpoints [-] Creating member '29bb41e5-457c-43ba-9149-5af55e73fe38'... 2021-10-25 18:18:02.825 1192307 WARNING octavia.controller.worker.v1.controller_worker [-] Failed to fetch member 29bb41e5-457c-43ba-9149-5af55e73fe38 from DB. Retrying for up to 60 seconds. Regards, Munna

3 4

Re: Openstack magnum
by Vikarna Tathe 26 Oct '21

26 Oct '21

Hi Yasemin, You can find all the stable releases in the below link https://builds.coreos.fedoraproject.org/browser?stream=stable&arch=x86_64 Vikarna On Sun, 24 Oct 2021 at 17:28, Yasemin DEMİRAL (BILGEM BTE) < yasemin.demiral(a)tubitak.gov.tr> wrote: > Hi, > > How can I dowloand fcos 33? I can't find any link for dowloanding it. > > *Yasemin DEMİRAL* > <http://www.tubitak.gov.tr/tr/icerik-sorumluluk-reddi> > > Senior Researcher at TUBITAK BILGEM B3LAB > > Safir Cloud Scrum Master > > > ------------------------------ > *Kimden: *"Vikarna Tathe" <vikarnatathe(a)gmail.com> > *Kime: *"Ammad Syed" <syedammad83(a)gmail.com> > *Kk: *"openstack-discuss" <openstack-discuss(a)lists.openstack.org> > *Gönderilenler: *19 Ekim Salı 2021 16:23:20 > *Konu: *Re: Openstack magnum > > Hi Ammad, > Thanks!!! It worked. > > On Tue, 19 Oct 2021 at 15:00, Vikarna Tathe <vikarnatathe(a)gmail.com> > wrote: > >> Hi Ammad, >> Yes, fcos34. Let me try with fcos33. Thanks >> >> On Tue, 19 Oct 2021 at 14:52, Ammad Syed <syedammad83(a)gmail.com> wrote: >> >>> Hi, >>> >>> Which fcos image you are using ? It looks like you are using fcos 34. >>> Which is currently not supported. Use fcos 33. >>> >>> On Tue, Oct 19, 2021 at 2:16 PM Vikarna Tathe <vikarnatathe(a)gmail.com> >>> wrote: >>> >>>> Hi All, >>>> I was able to login to the instance. I see that kubelet service is in >>>> activating state. When I checked the journalctl, found the below. >>>> >>>> >>>> >>>> >>>> >>>> >>>> *Oct 19 05:18:34 kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: >>>> Started Kubelet via Hyperkube (System Container).Oct 19 05:18:34 >>>> kubernetes-cluster-6cdrblcpckny-master-0 bash[6521]: Error: statfs >>>> /sys/fs/cgroup/systemd: no such file or directoryOct 19 05:18:34 >>>> kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: kubelet.service: Main >>>> process exited, code=exited, status=125/n/aOct 19 05:18:34 >>>> kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: kubelet.service: >>>> Failed with result 'exit-code'.Oct 19 05:18:44 >>>> kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: kubelet.service: >>>> Scheduled restart job, restart counter is at 18.Oct 19 05:18:44 >>>> kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: Stopped Kubelet via >>>> Hyperkube (System Container).* >>>> >>>> Executed the below command to fix this issue. >>>> *mkdir -p /sys/fs/cgroup/systemd* >>>> >>>> >>>> Now I am getiing the below error. Has anybody seen this issue. >>>> >>>> >>>> >>>> *failed to get the kubelet's cgroup: mountpoint for cpu not found. >>>> Kubelet system container metrics may be missing.failed to get the container >>>> runtime's cgroup: failed to get container name for docker process: >>>> mountpoint for cpu not found. failed to run Kubelet: mountpoint for not >>>> found* >>>> >>>> On Mon, 18 Oct 2021 at 14:09, Vikarna Tathe <vikarnatathe(a)gmail.com> >>>> wrote: >>>> >>>>> >>>>>> Hi Ammad, >>>>>> Thanks for responding. >>>>>> >>>>>> Yes the instance is getting created, but i am unable to login >>>>>> though i have generated the keypair. There is no default password for this >>>>>> image to login via console. >>>>>> >>>>>> openstack server list >>>>>> >>>>>> +--------------------------------------+--------------------------------------+---------+------------------------------------+----------------------+----------+ >>>>>> | ID | Name >>>>>> | Status | Networks | Image >>>>>> | Flavor | >>>>>> >>>>>> +--------------------------------------+--------------------------------------+---------+------------------------------------+----------------------+----------+ >>>>>> | cf955a75-8cd2-4f91-a01f-677159b57cb2 | >>>>>> k8s-cluster-01-2nyejxo3hyvb-master-0 | ACTIVE | private1=10.100.0.39, >>>>>> 10.14.20.181 | fedora-coreos-latest | m1.large | >>>>>> >>>>>> >>>>>> ssh -i id_rsa core(a)10.14.20.181 >>>>>> The authenticity of host '10.14.20.181 (10.14.20.181)' can't be >>>>>> established. >>>>>> ECDSA key fingerprint is >>>>>> SHA256:ykEMpwf79/zTMwcELDSI0f66Sxbri56ovGJ+RRwKXDU. >>>>>> Are you sure you want to continue connecting (yes/no/[fingerprint])? >>>>>> yes >>>>>> Warning: Permanently added '10.14.20.181' (ECDSA) to the list of >>>>>> known hosts. >>>>>> core(a)10.14.20.181: Permission denied >>>>>> (publickey,gssapi-keyex,gssapi-with-mic). >>>>>> >>>>>> On Mon, 18 Oct 2021 at 14:02, Ammad Syed <syedammad83(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> Can you check if the master server is deployed as a nova instance ? >>>>>>> if yes, then login to the instance and check cloud-init and heat agent logs >>>>>>> to see the errors. >>>>>>> >>>>>>> Ammad >>>>>>> >>>>>>> On Mon, Oct 18, 2021 at 12:03 PM Vikarna Tathe < >>>>>>> vikarnatathe(a)gmail.com> wrote: >>>>>>> >>>>>>>> Hello All, >>>>>>>> I am trying to create a kubernetes cluster using magnum. Image: >>>>>>>> fedora-coreos. >>>>>>>> >>>>>>>> >>>>>>>> The stack gets stucked in CREATE_IN_PROGRESS. See the output below. >>>>>>>> openstack coe cluster list >>>>>>>> >>>>>>>> +--------------------------------------+----------------+---------+------------+--------------+--------------------+---------------+ >>>>>>>> | uuid | name | keypair | >>>>>>>> node_count | master_count | status | health_status | >>>>>>>> >>>>>>>> +--------------------------------------+----------------+---------+------------+--------------+--------------------+---------------+ >>>>>>>> | 9381cd12-af60-40b1-b1c4-d3dcc93e926e | k8s-cluster-01 | ctrlkey | >>>>>>>> 2 | 1 | CREATE_IN_PROGRESS | None | >>>>>>>> >>>>>>>> +--------------------------------------+----------------+---------+------------+--------------+--------------------+---------------+ >>>>>>>> >>>>>>>> openstack stack resource show k8s-cluster-01-2nyejxo3hyvb >>>>>>>> kube_masters >>>>>>>> >>>>>>>> +------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >>>>>>>> | Field | Value >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | >>>>>>>> >>>>>>>> +------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >>>>>>>> | attributes | {'refs_map': None, 'removed_rsrc_list': >>>>>>>> [], 'attributes': None, 'refs': None} >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | >>>>>>>> | creation_time | 2021-10-18T06:44:02Z >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | >>>>>>>> | description | >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | >>>>>>>> | links | [{'href': ' >>>>>>>> http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu…', >>>>>>>> 'rel': 'self'}, {'href': ' >>>>>>>> http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu…', >>>>>>>> 'rel': 'stack'}, {'href': ' >>>>>>>> http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu…', >>>>>>>> 'rel': 'nested'}] | >>>>>>>> | logical_resource_id | kube_masters >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | >>>>>>>> | physical_resource_id | 3da2083f-0b2c-4b9d-8df5-8468e0de3028 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | >>>>>>>> | required_by | ['kube_cluster_deploy', >>>>>>>> 'etcd_address_lb_switch', 'api_address_lb_switch', 'kube_cluster_config'] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | >>>>>>>> | resource_name | kube_masters >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | >>>>>>>> | resource_status | CREATE_IN_PROGRESS >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | >>>>>>>> | resource_status_reason | state changed >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | >>>>>>>> | resource_type | OS::Heat::ResourceGroup >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | >>>>>>>> | updated_time | 2021-10-18T06:44:02Z >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> | >>>>>>>> >>>>>>>> +------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >>>>>>>> >>>>>>>> Vikarna >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> Syed Ammad Ali >>>>>>> >>>>>> -- >>> Regards, >>> >>> Syed Ammad Ali >>> >> >

1 0

kolla-ansible wallaby manila ceph pacific
by wodel youchi 25 Oct '21

25 Oct '21

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? Regards.

3 7

[neutron] October 2021 - PTG Summary
by Lajos Katona 25 Oct '21

25 Oct '21

Hi, Below is my summary of the Neutron sessions during last week's PTG. Here is the etherpad with the agenda: https://etherpad.opendev.org/p/neutron-yoga-ptg # Day 1 (Monday Oct 18.) ## Xena retrospective (I just list here the topics, not every discussion under them): * Good things: ** Less meetings ** New features ** CI jobs have again meaningful names ** Housekeeping - new payload style callbacks switch finished ** Healthy team - we have people from various companies, doing reviews and proposing patches * Bad / not so good / change it ** CI stability could be better ** lack of people involved in the CI meetings and CI issues ** is there a chance to decrease the number of jobs/backends to be * Actions coming out from the above: ** Having video based team meetings every few weeks. ** Video meeting with screen sharing for CI meeting every few weeks. ** ping people before the meetings ## Should we move some parts of neutron devstack plugin to devstack repo? Slaweq brought this topic to rationalize devstack plugin code between neutron and devstack. As a rule of thumb: "what is used/tested by jobs from other repositories (like tempest) should be in devstack repo and not in neutron's devstack plugin". The bad part is that we should loose review velocity if there's nobody to review in devstack. As a consequence some code should be moved back from devstack to neutron's devstack plugin (for drivers that are not that common now like linuxbridge) ## ML2/OVS -> ML2/OVN migration - presentation (continued on Friday) We got an overview from Jakub (jlibosva) of how the migration tool works now, what is finished and which are the possible directions to improve it. https://docs.google.com/presentation/d/1dCdvoi-Cdbl27AL0wjFJ_51NatOxepNOplm… * Problematic parts: ** steps that require the tool to touch the db (no API currently) ** no rollback ** no CI (at least upstream) ** no devstack based tools (related to the previous one) * Actions ** New job for ovs-to-ovn migration *** Now start with tripleo based job and go for a devstack based one ** Don't create new APIs for job type change and other operations during the migration as it seems there is no other usecase for them. ** Add developer documentation for the migration (preparation, steps, rollback....) ** add automatic rollback # Day 2 (Tuesday Oct. 19.) ## tempest_neutron_plugin - a RedHat downstream tests We got an overview of these tests from Eduardo Olivares. * tests requiring advance images ** move them to neutron-tempest-plugin with special tag and run them periodically ** use ubuntu cloud minimal image * tests requiring multinode topology + capturing traffic on hosts/computes ** These tests use a node to run tempest (tripleo based deployment) ** these tests should be changed to run in upstream CI * Tests that restart nodes / services / containers ** better not to run them in upstream CI ** check if it is possible to migrate some to tobiko ( https://opendev.org/x/tobiko ) * sriov tests (macvtap, direct and direct-physical ports) ** No possibility today to run these upstream. ## Edge session (https://etherpad.opendev.org/p/ecg-ptg-october-2021 ) * Thursday we had a session together with the Designate team where we discussed possible action items related to edge use cases. ## RBAC together with Nova * https://etherpad.opendev.org/p/nova-yoga-ptg l108. - l137. # Day 3 (Wednesday Oct. 20.) ## Job reorganization recap * We need fresh data to see where we still have pain points. * Ongoing CI rationalization items: ** Use Ubuntu minimal image where possible. ** Serialize the run of tests with advanced images (reduce memory usage): *** https://review.opendev.org/c/openstack/tempest/+/807790 ## ryu / os-ken Recently we realized that ryu has some activity to fix bugs that can hit Neutron as well (as we forked ryu as os-ken). * regularly checking ryu bugs and fixes (sync on team meeting) * Do not return to ryu as os-ken is adopted for Openstack workflow with CI, etc... ## Nova-Neutron cross-project session * OVN live-migration (https://etherpad.opendev.org/p/ovn_live_migration ) * RBAC continued (https://etherpad.opendev.org/p/nova-yoga-ptg l144 - l165) * libvirt virt driver does not wait for network-vif-plugged event during hard reboot ** document which backend sends what event and when ** workaround in nova for telling whether we should wait for an event ( https://review.opendev.org/c/openstack/nova/+/813419 ) ** long-term solution has to be Neutron providing event information thru the port binding information ** Improved testing of move operations *** Nova will keep one ML2/OVS multinode job running ** Supporting ports with QoS min bw and min pps in multi segment networks with multiple physnets *** finish the ongoing QoS min pps support *** extend placement to support any-trait queries ## Interop with Martin Kopec * Check which tests should be included to refstack * https://etherpad.opendev.org/p/refstack-test-analysis ## Quick introduction of the Tobiko test tool We got an overview of Tobiko from Frederico Ressi, and how it can be used to test scenarios which are destructive. * https://tobiko.readthedocs.io/en/master/ * http://kaplonski.pl/files/Tobiko_-_OpenStack_upgrade_and_disruptive_testing… * Neutron already has a periodic job with tobiko. # Day 4 (Thursday Oct. 21.) ## OVN and BGP * https://opendev.org/x/ovn-bgp-agent ** not just for neutron-dynamic-routing but for networking-bgpvpn as well. ** ovn-bgp-agent is another backend which could be behind neutron-dynamic-routing, and uses FRR. ** In the future it will be a Neutron stadium project ** need more tests, integration with Neutron and better documentation. * Make neutron-dynamic-routing work with OVN ** Frickler and bcafarel checked if the current jobs and tests can work with OVN. ** more investigation is necessary if it works as is now or some change is needed. ** Redhat and Ericsson help in the maintenance of neutron-dynamic-routing. ## Multi segments and provider networks on a host, with 1 subnet per segment * different from the usual routed network use case where we have one segment available in each rack * WIP patch which was never finished: ** https://review.opendev.org/c/openstack/neutron/+/623115 ## Use openstacksdk as client for Heat * Now Heat uses python-neutronclient for python bindings / client (not the CLI part which is deprecated but the python bindings) ** We collected a buch of projects over than heat which uses python-neutronclient: Nova, Horizon, Rally.... ** Actions: *** Write mail about it to have the attention of the community *** Have a migration plan and document it. *** Have a slot during the team meeting to track progress. ## Designate session The topics coming from Designate team were really helpful to translate the requirements from edge session to action items for Neutron. * https://etherpad.opendev.org/p/octavia-designate-neutron-ptg ** dns resolver is not specified for a subnet, (RFE for OVN as it works only for OVS currently) ** initiate a cross-project documentation effort for setting up an edge site ** initiate cross-project job for testing an edge site # Day 5 (Friday Oct. 22.) ## Continued discussion of neutron-dynamic-routing's future * Who will review new features (Both Redhat and Ericsson will increase review attention for this project) * Fixing the scheduler: ** New scheduler whith which the user can select which host/dragent to schedule ** https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/780675 * OVN and neutron-dynamic-routing ** add the missing features to the OVN gap list ( https://docs.openstack.org/neutron/latest/ovn/gaps.html ) ## RBAC discussion continued with TC * https://etherpad.opendev.org/p/tc-yoga-ptg ## ML2/OVS -> ML2/OVN migration - continue We continued the discussion from Monday, on how to integrate the ovs-ovn migration tool to Neutron CI. ## Team photo: https://photos.app.goo.gl/8ERv59XYoFVQz5oT7 I would like to thank you for the great discussions during last week, it was really useful and productive week. Based on these we have some plan what we will work on in the Yoga cycle. Lajos Katona (lajoskatona) Ericsson Software Technologies

1 0

CentOS-9 guests & 'qemu64' CPU model are incompatible; and reasons to avoid 'qemu64' in general
by Kashyap Chamarthy 25 Oct '21

25 Oct '21

Summary ------- RHEL-9 / CentOS-9 (but not Fedora) has switched[1] to a new baseline microarchitecture called "x86-64-v2". This is to bring in support for additioal low-level CPU instructions, among other reasons. Now, if you've explicitly configured "cpu_mode=none" in `nova.conf` on your compute nodes — which results in the guest getting the extremely undesirable "qemu64" CPU model — it will refuse to boot RHEL-9 or CentOS-9 guests. To fix this, please update the CPU model to "Nehalem". It is the oldest CPU model that is compatible with CentOS-9/RHEL-9 "x86-64-v2". Further, Nehalem also works with `virt_type=kvm|qemu`, _and_ on both Intel and AMD hardware. So this is a good alternative. Details ------- Nova has three config attributes to setup various aspect of a guest CPU: `cpu_mode`, `cpu_model[s]`, and `cpu_model_extra_flags`. Examples of how to use these are in the documentation[2]. If you're using `cpu_mode = none` (e.g. upstream DevStack defalts to it for understandable reasons, mainly live-migration compatiblity): [libvirt] cpu_mode = none ... and want to boot CentOS-9, replace the above with the custom model, "Nehalem", which is the oldest CPU model that's compatible with the new x86-64-v2 baseline: [libvirt] cpu_mode = custom cpu_model = Nehalem The same applies if you're using "qemu64" or "kvm64" with, or without any custom CPU flags — i.e. use Nehalem. (Also, please refer to[3] for more fine-grained recommendations of guest CPU configuration. It's a long document, but a patient reader will be rewarded.) Why is "qemu64" model undesirable for production? ------------------------------------------------- For those wondering about it, a few reasons why `qemu64` CPU model is not at all desirable: (1) It is vulnerable to many of the Spectre and other side-channel security flaws. To see this in "action", you can launch a guest with 'qemu64' CPU model, and then run the below: $ cd /sys/devices/system/cpu/vulnerabilities/ $ grep . * l1tf:Mitigation: PTE Inversion mds:Vulnerable: ... no microcode; SMT Host state unknown meltdown:Mitigation: PTI spec_store_bypass:Vulnerable spectre_v1:Mitigation: usercopy/swapgs barriers ... spectre_v2:Mitigation: Full generic retpoline ... Notice the "Vulnerable" entries. (2) "qemu64" does not support several critical CPU features: (a) AES (Advanced Encryption Standard) instruction, which is important for imporved TLS performance and encryption. (b) RDRAND instruction: without this, guests can get starved for entropy. (c) PCID flag: an obscure-but-important flag that'll lower the performance degradation that you incur from the "Meltdown" security fixes. Probably there are more reasons that I don't know of. An understandable reason why CI systems running in a cloud environment go with 'qemu64' is convenience: with 'qemu64', you can live-migrate a guest regardless of its underlying hardware (whether it's Intel or AMD). That's one main reason why upstream DevStack defaults to it. * * * Overall, the thumb-rule here is to either always explicitly specify a "sane" CPU model, based on the recommendations here[3]. Or to use Nova/libvirt's default ("host-model"). [1] https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-l… [2] https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.cp… [3] https://www.qemu.org/docs/master/system/i386/cpu.html#recommendations-for-k… [4] https://opendev.org/openstack/whitebox-tempest-plugin/src/branch/master/.zu… -- /kashyap

2 2

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

25 Oct '21

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

1 0

[magnum] [fcos33]
by Yasemin DEMİRAL (BILGEM BTE) 25 Oct '21

25 Oct '21

Hi, How can I dowloand fcos 33? I can't find any link for dowloanding it. Yasemin DEMİRAL [ http://www.tubitak.gov.tr/tr/icerik-sorumluluk-reddi ] Senior Researcher at TUBITAK BILGEM B3LAB Safir Cloud Scrum Master Kimden: "Vikarna Tathe" <vikarnatathe(a)gmail.com> Kime: "Ammad Syed" <syedammad83(a)gmail.com> Kk: "openstack-discuss" <openstack-discuss(a)lists.openstack.org> Gönderilenler: 19 Ekim Salı 2021 16:23:20 Konu: Re: Openstack magnum Hi Ammad, Thanks!!! It worked. On Tue, 19 Oct 2021 at 15:00, Vikarna Tathe < [ mailto:vikarnatathe@gmail.com | vikarnatathe(a)gmail.com ] > wrote: Hi Ammad, Yes, fcos34. Let me try with fcos33. Thanks On Tue, 19 Oct 2021 at 14:52, Ammad Syed < [ mailto:syedammad83@gmail.com | syedammad83(a)gmail.com ] > wrote: BQ_BEGIN Hi, Which fcos image you are using ? It looks like you are using fcos 34. Which is currently not supported. Use fcos 33. On Tue, Oct 19, 2021 at 2:16 PM Vikarna Tathe < [ mailto:vikarnatathe@gmail.com | vikarnatathe(a)gmail.com ] > wrote: BQ_BEGIN Hi All, I was able to login to the instance. I see that kubelet service is in activating state. When I checked the journalctl, found the below. Oct 19 05:18:34 kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: Started Kubelet via Hyperkube (System Container). Oct 19 05:18:34 kubernetes-cluster-6cdrblcpckny-master-0 bash[6521]: Error: statfs /sys/fs/cgroup/systemd: no such file or directory Oct 19 05:18:34 kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: kubelet.service: Main process exited, code=exited, status=125/n/a Oct 19 05:18:34 kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: kubelet.service: Failed with result 'exit-code'. Oct 19 05:18:44 kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: kubelet.service: Scheduled restart job, restart counter is at 18. Oct 19 05:18:44 kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: Stopped Kubelet via Hyperkube (System Container). Executed the below command to fix this issue. mkdir -p /sys/fs/cgroup/systemd Now I am getiing the below error. Has anybody seen this issue. failed to get the kubelet's cgroup: mountpoint for cpu not found. Kubelet system container metrics may be missing. failed to get the container runtime's cgroup: failed to get container name for docker process: mountpoint for cpu not found. failed to run Kubelet: mountpoint for not found On Mon, 18 Oct 2021 at 14:09, Vikarna Tathe < [ mailto:vikarnatathe@gmail.com | vikarnatathe(a)gmail.com ] > wrote: BQ_BEGIN BQ_BEGIN Hi Ammad, Thanks for responding. Yes the instance is getting created, but i am unable to login though i have generated the keypair. There is no default password for this image to login via console. openstack server list +--------------------------------------+--------------------------------------+---------+------------------------------------+----------------------+----------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+--------------------------------------+---------+------------------------------------+----------------------+----------+ | cf955a75-8cd2-4f91-a01f-677159b57cb2 | k8s-cluster-01-2nyejxo3hyvb-master-0 | ACTIVE | private1=10.100.0.39, 10.14.20.181 | fedora-coreos-latest | m1.large | ssh -i id_rsa [ mailto:core@10.14.20.181 | core(a)10.14.20.181 ] The authenticity of host '10.14.20.181 (10.14.20.181)' can't be established. ECDSA key fingerprint is SHA256:ykEMpwf79/zTMwcELDSI0f66Sxbri56ovGJ+RRwKXDU. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '10.14.20.181' (ECDSA) to the list of known hosts. [ mailto:core@10.14.20.181 | core(a)10.14.20.181 ] : Permission denied (publickey,gssapi-keyex,gssapi-with-mic). On Mon, 18 Oct 2021 at 14:02, Ammad Syed < [ mailto:syedammad83@gmail.com | syedammad83(a)gmail.com ] > wrote: BQ_BEGIN Hi, Can you check if the master server is deployed as a nova instance ? if yes, then login to the instance and check cloud-init and heat agent logs to see the errors. Ammad On Mon, Oct 18, 2021 at 12:03 PM Vikarna Tathe < [ mailto:vikarnatathe@gmail.com | vikarnatathe(a)gmail.com ] > wrote: BQ_BEGIN Hello All, I am trying to create a kubernetes cluster using magnum. Image: fedora-coreos. The stack gets stucked in CREATE_IN_PROGRESS. See the output below. openstack coe cluster list +--------------------------------------+----------------+---------+------------+--------------+--------------------+---------------+ | uuid | name | keypair | node_count | master_count | status | health_status | +--------------------------------------+----------------+---------+------------+--------------+--------------------+---------------+ | 9381cd12-af60-40b1-b1c4-d3dcc93e926e | k8s-cluster-01 | ctrlkey | 2 | 1 | CREATE_IN_PROGRESS | None | +--------------------------------------+----------------+---------+------------+--------------+--------------------+---------------+ openstack stack resource show k8s-cluster-01-2nyejxo3hyvb kube_masters +------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | attributes | {'refs_map': None, 'removed_rsrc_list': [], 'attributes': None, 'refs': None} | | creation_time | 2021-10-18T06:44:02Z | | description | | | links | [{'href': ' [ http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu… | http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu… ] ', 'rel': 'self'}, {'href': ' [ http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu… | http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu… ] ', 'rel': 'stack'}, {'href': ' [ http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu… | http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu… ] ', 'rel': 'nested'}] | | logical_resource_id | kube_masters | | physical_resource_id | 3da2083f-0b2c-4b9d-8df5-8468e0de3028 | | required_by | ['kube_cluster_deploy', 'etcd_address_lb_switch', 'api_address_lb_switch', 'kube_cluster_config'] | | resource_name | kube_masters | | resource_status | CREATE_IN_PROGRESS | | resource_status_reason | state changed | | resource_type | OS::Heat::ResourceGroup | | updated_time | 2021-10-18T06:44:02Z | +------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Vikarna -- Regards, Syed Ammad Ali BQ_END BQ_END BQ_END BQ_END -- Regards, Syed Ammad Ali BQ_END BQ_END

2 3

[Neutron] Bug Deputy Report October 19 - 23
by Jakub Libosvar 25 Oct '21

25 Oct '21

Hi all, I was the bug deputy for the week starting Oct 19. Here is the report, no critical bugs, it was a quiet week, maybe because of the PTG :) Medium ------ * "network_namespace_exists"can timeout in loaded systems Link: https://bugs.launchpad.net/neutron/+bug/1947974 Assigned to Rodolfo Fix proposed: https://review.opendev.org/c/openstack/neutron/+/814868 * Non HA router - missing iptables rule for redirect metadata queries to haproxy Link: https://bugs.launchpad.net/neutron/+bug/1947993 Assigned to Slawek Fix proposed: https://review.opendev.org/c/openstack/neutron/+/814892 * [OVN] Logical router port must have at least one network Edit Link: https://bugs.launchpad.net/neutron/+bug/1948457 Needs an assignee Low --- * qvo ports are not removed correctly when an instance is deleted immediately after creation Link: https://bugs.launchpad.net/neutron/+bug/1948452 Needs an assignee * [OVN] Mech driver fails to delete DHCP options during subnet deletion Link: https://bugs.launchpad.net/neutron/+bug/1948466 Needs an assignee Kuba

2 1

[Glance] Yoga PTG Summary
by Abhishek Kekane 25 Oct '21

25 Oct '21

Hi All, We had our fourth virtual PTG between 18th October to 22nd October 2020. Thanks to everyone who joined the virtual PTG sessions. Using bluejeans app we had lots of discussion around different topics for glance, glance + cinder and Secure RBAC. I have created etherpad [1] with Notes from the session and which also includes the recordings of each discussion. Here is a short summary of the discussions. Tuesday, October 19th # Xena Retrospective On the positive note, we merged a number of useful features this cycle. We managed to implement a project scope of secure RBAC for metadef APIs, Implemented quotas using unified limits and moved policy enforcing closer to API layer. We also manage to wipe out many bugs from our bug backlog. On the other side we need to improve our documentation and API reference guide. Recording: https://bluejeans.com/s/QuCBmIrMuVv - Chapter 1 # Cache API During Xena cycle we managed to start this work and implement the core functionality but failed to merge it due to lack of negative tests and tempest coverage. In the Yoga cycle we are going to focus on adding tempest coverage for the same along with a new API to cache the given image immediately rather than waiting for a periodic job to pre-cache it for us. Recordings: https://bluejeans.com/s/QuCBmIrMuVv - Chapter 2 # Native Image Encryption Unfortunately this topic is sitting in our agenda for the last couple of PTGs. Current update is the core feature is depending on Barbican microversion work and once it is complete then the Consumer API can be functional again. At the moment in Glance we have decided to go ahead and implement the glance side part and instead of having placeholder (barbican consumer API secret register and deletion) code as commented we can have a WIP patch for the same with depending on glance side work. Recordings: https://bluejeans.com/s/QuCBmIrMuVv - Chapter 3 # Default Glance to configure multiple stores Glance has deprecated single stores configuration since Stein cycle and now will start putting efforts to deploy glance using multistore by-default and then remove single store support from glance. This might be going to take a couple of cycles, so in yoga we are going to migrate internal unit and functional tests to use multistore config and also going to modify devstack to deploy glance using multistore configuration for swift and Ceph (for file and cinder it's already supported). Recordings: https://bluejeans.com/s/QuCBmIrMuVv - Chapter 4 # Quotas Usage API In Xena we have implemented quotas for images API using unified limits. This cycle we will add new APIs which will help enduser to get the clear picture of quotas like What is total quota, used quota and remaining quota. So first we are coming up with the spec for the design and then implementation for the same. Recordings: https://bluejeans.com/s/QuCBmIrMuVv - Chapter 5 Wednesday, October 20th 2021 # Policy Refactoring - Part 2 In Xena we have managed to move all policy checks to the API layer. This cycle we need to work on removing dead code of policy and authorization layer. Before removing both the layers we need to make sure that property protection is working as expected and for the same we need to add one job with a POST script to verify that removing auth and policy layer will not break property protection. Recordings: https://bluejeans.com/s/AMZzGObPhK4 - Chapter 1 # Database read only checks We have added new RBAC policy checks which are equivalent to readonly checks in our db layer, e.g. image ownership check, visibility check etc. To kick start work for this dansmith (thanks for volunteering) will work on PoC and abhishekk will work on specs about how we will modify/improve our db layer. # Secure RBAC - System Scope/Project Admin scope In Xena we have managed to move all policy checks to API layer and implemented project scope of metadef APIs. So as of now we have project scope for all glance APIs. During this discussion Security Team has updated us that discussions are still going about how the system scope should be used/implemented and they are planning to introduce a new role 'manager' which will act between 'admin' and 'member' roles. We need to keep an eye on this new development. https://etherpad.opendev.org/p/tc-yoga-ptg - line #446 https://etherpad.opendev.org/p/policy-popup-yoga-ptg - line #122 Recordings: https://bluejeans.com/s/AMZzGObPhK4 - Chapter 3 Thursday, October 21st 2021 # Glance- Interop interlock Due to confusion between timings this discussion didn't happen as planned. The InterOP team has added some questions later to PTG etherpad (refer line no #270). @Glance team please respond to those questions as I will be out for the next couple of weeks. # Upload volume to image in RBD backend In case when we upload a volume as an image to glance's rbd backend, it starts with a 0 size rbd image and performs resize in chunks of 8 MB which makes the operation very slow. Current idea is to pass volume size as image size to avoid these resize operations. As this change will lead to use locations API which are not advisable to use in glance due to security concerns and also checksum and multi-hash will not be available, cinder side will have new config option (default False) to use this optimization if set to True. Also this change needs a glance side to expose ceph pool information, so Rajat (whoami-rajat) will coordinate with the glance team to set up a spec and implement the same. # Upload volume to image when glance backend is cinder Similar to above topic this will have same security concerns and same config option can be used to have this optimization available. Rajat will coordinate with the glance team to implement glance side changes. Note, as we have joined the cinder team, Brian Rosmaita/Rajat will update/share the recording links for above two sessions in glance PTG etherpad once it is available. # Adding multiple tags overrides existing tags We are going to modify the create multiple tags API which will have one boolean parameter (Default to False) in the header to maintain backward compatibility. If it is True then we are going to add new tags to the existing list of tags rather than replacing those. Recordings: https://bluejeans.com/s/@ttsNs8vIFq - Chapter 1 # Delete newly created metadef resource types from DB after deassociating To maintain the consistency with other metadef APIs, we are going to add two new APIs. 1. Create resource types 2. Delete given resource type Recordings: https://bluejeans.com/s/@ttsNs8vIFq - Chapter 2 You will find the detailed information about the same in the PTG etherpad [1] along with the recordings of the sessions. Kindly let me know if you have any questions about the same. [1] https://etherpad.opendev.org/p/yoga-glance-ptg Thank you, Abhishek

2 1

[cyborg][ptg] Meeting time changes
by Brin Zhang(张百林) 25 Oct '21

25 Oct '21

Hi all, At PTG, base the contributors of Cyborg, we discussed the meeting time of Cyborg. By voting on the meeting time on PTG, everyone agreed to adjust the meeting time to Friday 6:00UTC-7:00UTC (Beijing time at China, 2:00-3:00pm). We look forward to your participation in our conference, and you can submit any requirements to us. You can register for the feature on Launchpad [1] at first. Later I will send a summary of our discussion on Cyborg PTG. [1] https://blueprints.launchpad.net/openstack-cyborg brinzhang

1 0

Freezer agent on Wallaby
by wodel youchi 24 Oct '21

24 Oct '21

Hi, Has anyone been able to make Freezer work with Openstack Wallaby? Regards.

1 1

[magnum] [victoria] [fedora-coreos] [ssl]
by Yasemin DEMİRAL (BILGEM BTE) 23 Oct '21

23 Oct '21

Hi I work on OpenStack stable/victoria version with OSA. I use CoreOS 31.20200323.3.2 to create kubernetes cluster. When the cluster creating, I can't connect with SSH on linux or windows, but I can connect on MacOS. Is there any idea about that. I need to connect SSH to master node while creating section at Windows machine. Than is it possible to be insecure keystone service in OpenStack magnum environment? Is SSL certificate mandatory? Thank you Yasemin DEMİRAL Senior Researcher at TUBITAK BILGEM B3LAB Safir Cloud Scrum Master [ http://www.tubitak.gov.tr/tr/icerik-sorumluluk-reddi ]

1 0

Openstack Glance image signature and validation for upload and boot controls?
by S Andronic 23 Oct '21

23 Oct '21

Hi, I have a question in regards to Openstack Glance and if I got it right this can be a place to ask, if I am wrong please kindly point me in the right direction. When you enable Image Signing and Certificate Validation in nova.conf: [glance] verify_glance_signatures = True enable_certificate_validation = True Will this stop users from uploading unsigned images or using unsigned images to spin up instances? Intuitively I feel that it will enforce checks only if the signature property exists, but what if it doesn't? Does it control in any way unsigned images? Does it stop users from uploading or using anything unsigned? Would an image without the signing properties just be rejected? If this feature doesn't stop the use of unsigned images as a security control what is the logic behind it then? Is this meant not to stop users from using unsigned images but such that people who do use signed images have verification for their code? So if the goal is to stop people from using random images and image signing and validation is not the answer what would be? Kind Regards, S. Andronic

2 2

[tripleo] Issue finding /etc/docker directory in Centos 8 Overcloud Deployment
by Anirudh Gupta 23 Oct '21

23 Oct '21

Hi Team, I am trying to install Tripleo Train Release on Centos 8 I have successfully installed Undercloud. For overcloud images, I have downloaded and uploaded images given on rdo_trunk https://images.rdoproject.org/centos8/train/rdo_trunk/current-tripleo/ For deployment of overcloud, I executed the command openstack overcloud deploy --templates This command successfully creates a stack, executed the SSH on the machines successfully and then started some ansible tasks. During execution of ansible tasks, it gave a error at below task TASK | manage /etc/docker/daemon.json *The error message clearly states that directory /etc/docker is not found.* This task is present at path " */usr/share/ansible/roles/container-registry/tasks/docker.yml"* Since, in Centos 8 docker has been replaced with Podman, this error is bound to happen Commenting this particular task can be a workaround, but I have no idea what would be the impact of this. There are multiple tasks which makes use of /etc/docker directory Is there any way to resolve this?

2 3

[charms] OpenStack Charms 21.10 release is now available
by Peter Matulis 22 Oct '21

22 Oct '21

The 21.10 release of the OpenStack Charms is now available. This release brings several new features to the existing OpenStack Charms deployments for Queens, Stein, Ussuri, Victoria, Wallaby, Xena and many stable combinations of Ubuntu + OpenStack. Please see the Release notes for full details: https://docs.openstack.org/charm-guide/latest/release-notes/2110.html == Highlights == * OpenStack Xena OpenStack Xena is now supported on Ubuntu 20.04 LTS (via UCA) and Ubuntu 21.10 natively. * Cinder storage backend charms Two stable charms are now available that provide LVM and NetApp storage backends for Cinder. The new charms are cinder-lvm and cinder-netapp respectively. The cinder-lvm charm deprecates the LVM functionality of the cinder charm. A migration path is available. * Cloud operational improvements Improvements have been implemented at the operational level through the addition of many actions and configuration options to the current set of stable charms. * Tech-preview charms Two tech-preview charms are now available. The ceph-dashboard charm deploys the Ceph Dashboard and the openstack-loadbalancer charm deploys a load balancer for OpenStack applications that support the charm. * Documentation updates Ongoing improvements to the OpenStack Charms Deployment Guide, the OpenStack Charm Guide, and the charm READMEs. == OpenStack Charms team == The OpenStack Charms team can be contacted on the #openstack-charms IRC channel (on OFTC) or in the Ubuntu user forum: https://discourse.ubuntu.com/c/openstack/ == Thank you == Lots of thanks to the 57 contributors below who squashed 131 bugs, enabled new features, and improved the documentation! Alex Kavanagh Arif Ali Aurelien Lourot Bartosz Woronicz Billy Olsen Brett Milford Chris MacNaughton Corey Bryant Cornellius Metto Cory Johns David Ames David Negreira Diko Parvanov Dmitrii Shcherbakov Edin Sarajlic Edward Hope-Morley Eric Chen Erlon R. Felipe Reyes Frode Nordahl Gabriel Angelo Garrett Thompson Ghanshyam Mann Gustavo Sanchez Hemanth Nakkina Hernan Garcia James Page James Troup Jarred Wilson John P Jose Phillips Julien Thieffry Liam Young Linda Guo Luciano Lo Martin Kalcok Nicholas Njihia Nicolas Bock Nikhil Kshirsagar Nobuto Murata Peter Matulis Robert Gildein Rodrigo Barbieri Sean McGinnis Simon Dodsley Stephan Pampel Trent Lloyd Vladimir Grevtsev Xav Paice Yoshi Kadokawa YuehuiLei Zhang Hua eric-chen jiangzhilin likui tushargite96 yangyawei -- OpenStack Charms Team

1 0

neutron l3 agents number
by Arnaud Morin 22 Oct '21

22 Oct '21

Hey team, When using DVR + HA, we endup with all routers beeing deployed on the computes (the DVR part) and 3 routers on dvr_snat nodes (for HA). The question is why 3 for snats? I know that this is the max_l3_agents_per_router config parameter, but 2 seems enough? On the other side, DHCP agent default (dhcp_agents_per_network) is 1, while this is also a precious service provided in the tenant network. So, is there any downside on having only 2 agents for routers? Thanks in advance, Arnaud.

3 4

Cannot login to gerrit
by F Yushiro 21 Oct '21

21 Oct '21

Hi, I tried to login ty Gerrit w/ OpenID but redirected the following page and saw "Not Found". https://review.opendev.org/SignInFailure,SIGN_IN,Contact+site+administrator Could you please help me to login? My login email is y.furukawa8(a)gmail.com. I used to use ex-company address. When I left the company, I've modified my email address to above gmail one. I wonder that might occur this situation. Best regards,

2 1

[cinder][PTG] Friday schedule update
by Brian Rosmaita 21 Oct '21

21 Oct '21

Thanks for everyone who's participated so far. We're having a productive PTG! It turns out that it's going to be important for us to participate in the TC discussion of the secure RBAC community goal tomorrow, so I've rearranged our schedule a bit. What we have now is: 1300 UTC: announcements 1302 UTC: Quotas!!! (geguileo) 1330-1500 UTC: community goal: secure RBAC 1500 UTC: Clarify the Volume Driver API, Part 2 1600 UTC: Yoga priorities and responsibilities (rosmaita) The etherpad has been updated and has links to relevant info: https://etherpad.opendev.org/p/yoga-ptg-cinder cheers, brian

1 0

Trove guest agent and Rabbitmq
by wodel youchi 21 Oct '21

21 Oct '21

Hi, I am trying to deploy Trove. I am using the Kolla-ansible and Openstack wallaby version. >From the documentation, the Trove guest agent, which runs inside the Tove instance communicates with the trove-taskmanager via rabbitmq, how is this done? The rabbitmq is running in the api network, the instance is running in the tunnel (tenant) network, and in my case, those networks are in different vlans, how should I configure this? Regards.

3 5

[swift][ptg] Ops feedback session soon - Oct 21 at 13:00 UTC
by Timothy Burke 21 Oct '21

21 Oct '21

As in PTGs past, we're getting devs and ops together to talk about Swift: what's working, what isn't, and what would be most helpful to improve. We're meeting in Havana (https://www.openstack.org/ptg/rooms/havana) at 13:00UTC -- if you run a Swift cluster, we hope to see you there! Even if you can't make it, I'd appreciate if you can offer some feedback on this PTG's etherpad (https://etherpad.opendev.org/p/swift-yoga-ops-feedback) Tim

1 0

[tempest] S3 API tests
by Vladimir Prokofev 20 Oct '21

20 Oct '21

Hello. Are there any Swift S3 API tests in tempest? I didn't find any standard packages, nor as a plugin.

4 5

[Nova][interop]
by Arkady Kanevsky 20 Oct '21

20 Oct '21

Sean and Nova team, Interop WG would like 20-30 minutes on Yaga PTG agenda to discuss latest interop guidelines for Nova. If you can point us to etherpad then we can add it to agenda. Thanks, Arkady -- Arkady Kanevsky, Ph.D. Phone: 972 707-6456 Corporate Phone: 919 729-5744 ext. 8176456

3 6

[all][tc] Yoga TC-PTG Planning
by Ghanshyam Mann 20 Oct '21

20 Oct '21

Hello Everyone, As you already know that the Yoga cycle virtual PTG will be held between 18th - 22nd October[1]. To plan the Technical Committee PTG sessions, please do the following: 1. Fill the below doodle poll as per your availability. Please fill it soon as deadline to book the slot is 21th July. - https://doodle.com/poll/6dfdmdfi4s8wc7cd 2. Add the topics you would like to discuss to the below etherpad. - https://etherpad.opendev.org/p/tc-yoga-ptg NOTE: this is not limited to TC members only; I would like all community members to fill the doodle poll and, add the topics you would like or want TC members to discuss in PTG. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-July/023540.html -gmann

1 2

[charms] Yoga charms PTG session 1 today
by Alex Kavanagh 20 Oct '21

20 Oct '21

Hi All Just a quick reminder that the 1st (of 2) charms PTG session is today at 14.00 UTC in the Icehouse room. Out etherpad is: https://etherpad.opendev.org/p/charms-yoga-ptg Full schedule is: https://object-storage-ca-ymq-1.vexxhost.net/swift/v1/6e4619c416ff4bd19e1c0… Feel free to come along and ask/discuss any of your OpenStack/charms questions! Thanks Alex -- Alex Kavanagh - Software Engineer OpenStack Engineering - Data Centre Development - Canonical Ltd

1 0

[Sahara]Sahara project PTG meeting from 3:00 to 5:00 PM on October 19, 2021.
by Juntingqiu Qiujunting (邱军婷) 20 Oct '21

20 Oct '21

Hi all I'm very sorry: I missed the scheduled sahara PTG meeting time. We tentatively schedule the Sahara project PTG meeting from 3:00 to 5:00 PM on October 19, 2021. Use IRC channel:#openstack-sahara to conduct PTG conferences. My topics are as follows: 1. Sahara supports the creation of cloud hosts by specifying system volumes. 2. Sahara deploys a dedicated cluster through cloud host VM tools (qemu-guest-agent). 发件人: Juntingqiu Qiujunting (邱军婷) 发送时间: 2021年9月24日 18:05 收件人: 'jeremyfreudberg(a)gmail.com' <jeremyfreudberg(a)gmail.com>; Faling Rui (芮法玲) <ruifaling(a)inspur.com>; 'ltoscano(a)redhat.com' <ltoscano(a)redhat.com> 抄送: 'openstack-discuss(a)lists.openstack.org' <openstack-discuss(a)lists.openstack.org> 主题: [Sahara]Currently about the development of the Sahara community there are some points Hi all: Currently about the development of the Sahara community there are some points as following: 1. About the schedule of the regular meeting of the Sahara project? What is your suggestion? How about the regular meeting time every Wednesday afternoon 15:00 to 16:30? 2. Regarding the Sahara project maintenance switch from StoryBoard to launchpad. https://storyboard.openstack.org/ https://blueprints.launchpad.net/openstack/ The reasons are as follows: 1. OpenSatck core projects are maintained on launchpad, such as nova, cinder, neutron, etc. 2. Most OpenStack contributors are used to working on launchpad. 3. Do you have any suggestions? If you think this is feasible, I will post this content in the Sahara community later. Thank you for your help. Thank you Fossen. --------------------------------- Fossen Qiu | 邱军婷 CBRD | 云计算与大数据研发部 T: 18249256272 E: qiujunting(a)inspur.com<mailto:qiujunting@inspur.com> 浪潮云海

3 4

[all] RBAC related discussion in Yoga PTG
by Ghanshyam Mann 20 Oct '21

20 Oct '21

Hello Everyone, As you might know, we are not so far from the Yoga PTG. I have created the below etherpad to collect the RBAC related discussion happening in various project sessions. - https://etherpad.opendev.org/p/policy-popup-yoga-ptg We have not schedule any separate sessions for this instead thought of attending the related discussion in project PTG itself. Please do the below two steps before PTG: 1. Add the common topics (for QA, Horizon etc) you would like to discuss/know. 2. Add any related rbac sessions you have planned in your project PTG. - I have added a few of them but few need the exact schedule/time so that we can plan to attend it. Please check and add the time for your project sessions. -gmann

1 1

[dev] Cannot login to Gerrit
by F Yushiro 20 Oct '21

20 Oct '21

Hi, I tried to login ty Gerrit w/ OpenID but redirected the following page and saw "Not Found". https://review.opendev.org/SignInFailure,SIGN_IN,Contact+site+administrator Could you please help me to login? My login email is y.furukawa8(a)gmail.com. I used to use ex-company address. When I left the company, I modified my email address to above gmail one. I wonder that might occur this situation. Best regards, -- Yushiro Furukawa

2 1

[horizon] No weekly meeting tomorrow due to meeting in PTG
by vishal manchanda 19 Oct '21

19 Oct '21

Hi all, As we are meeting in PTG, so there will be no horizon weekly meeting tomorrow. Thanks & Regards, Vishal Manchanda

1 0

[Octavia] 2021-10-21 meeting cancelled
by Gregory Thiemonge 19 Oct '21

19 Oct '21

Hi, This is the PTG week, we decided during our previous weekly meeting to cancel tomorrow's meeting. Thanks, Gregory

1 0

[TripleO] Gate blocker - please hold rechecks - tripleo-ci-centos-8-scenario001-standalone
by Ronelle Landy 19 Oct '21

19 Oct '21

Hello All, We have a gate blocker for tripleo at: https://bugs.launchpad.net/tripleo/+bug/1947548 tripleo-ci-centos-8-scenario001-standalone <https://zuul.opendev.org/t/openstack/build/04e3e2163fbf4bb5afdf4695dfaa8e1a> is failing. We are testing some reverts. Please hold rechecks if you are rechecking for this failure. We will update this list when the error is cleared. Thank you!

1 1

Re: openstack-discuss Digest, Vol 36, Issue 87
by Karera Tony 19 Oct '21

19 Oct '21

Even 32 works fine On Tue, 19 Oct 2021, 15:25 , <openstack-discuss-request(a)lists.openstack.org> wrote: > Send openstack-discuss mailing list submissions to > openstack-discuss(a)lists.openstack.org > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss > or, via email, send a message with subject or body 'help' to > openstack-discuss-request(a)lists.openstack.org > > You can reach the person managing the list at > openstack-discuss-owner(a)lists.openstack.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openstack-discuss digest..." > > > Today's Topics: > > 1. Re: Openstack magnum (Vikarna Tathe) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 19 Oct 2021 18:53:20 +0530 > From: Vikarna Tathe <vikarnatathe(a)gmail.com> > To: Ammad Syed <syedammad83(a)gmail.com> > Cc: openstack-discuss <openstack-discuss(a)lists.openstack.org> > Subject: Re: Openstack magnum > Message-ID: > < > CAE2S1+473YbwicxYGKq0VoNu4Ozjt-+khGsdy4Za6R8po1M+YA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Ammad, > > Thanks!!! It worked. > > On Tue, 19 Oct 2021 at 15:00, Vikarna Tathe <vikarnatathe(a)gmail.com> > wrote: > > > Hi Ammad, > > > > Yes, fcos34. Let me try with fcos33. Thanks > > > > On Tue, 19 Oct 2021 at 14:52, Ammad Syed <syedammad83(a)gmail.com> wrote: > > > >> Hi, > >> > >> Which fcos image you are using ? It looks like you are using fcos 34. > >> Which is currently not supported. Use fcos 33. > >> > >> On Tue, Oct 19, 2021 at 2:16 PM Vikarna Tathe <vikarnatathe(a)gmail.com> > >> wrote: > >> > >>> Hi All, > >>> > >>> I was able to login to the instance. I see that kubelet service is in > >>> activating state. When I checked the journalctl, found the below. > >>> > >>> > >>> > >>> > >>> > >>> > >>> *Oct 19 05:18:34 kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: > >>> Started Kubelet via Hyperkube (System Container).Oct 19 05:18:34 > >>> kubernetes-cluster-6cdrblcpckny-master-0 bash[6521]: Error: statfs > >>> /sys/fs/cgroup/systemd: no such file or directoryOct 19 05:18:34 > >>> kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: kubelet.service: > Main > >>> process exited, code=exited, status=125/n/aOct 19 05:18:34 > >>> kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: kubelet.service: > >>> Failed with result 'exit-code'.Oct 19 05:18:44 > >>> kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: kubelet.service: > >>> Scheduled restart job, restart counter is at 18.Oct 19 05:18:44 > >>> kubernetes-cluster-6cdrblcpckny-master-0 systemd[1]: Stopped Kubelet > via > >>> Hyperkube (System Container).* > >>> > >>> Executed the below command to fix this issue. > >>> *mkdir -p /sys/fs/cgroup/systemd* > >>> > >>> > >>> Now I am getiing the below error. Has anybody seen this issue. > >>> > >>> > >>> > >>> *failed to get the kubelet's cgroup: mountpoint for cpu not found. > >>> Kubelet system container metrics may be missing.failed to get the > container > >>> runtime's cgroup: failed to get container name for docker process: > >>> mountpoint for cpu not found. failed to run Kubelet: mountpoint for > not > >>> found* > >>> > >>> On Mon, 18 Oct 2021 at 14:09, Vikarna Tathe <vikarnatathe(a)gmail.com> > >>> wrote: > >>> > >>>> > >>>>> Hi Ammad, > >>>>> > >>>>> Thanks for responding. > >>>>> > >>>>> Yes the instance is getting created, but i am unable to login though > i > >>>>> have generated the keypair. There is no default password for this > image to > >>>>> login via console. > >>>>> > >>>>> openstack server list > >>>>> > >>>>> > +--------------------------------------+--------------------------------------+---------+------------------------------------+----------------------+----------+ > >>>>> | ID | Name > >>>>> | Status | Networks | Image > >>>>> | Flavor | > >>>>> > >>>>> > +--------------------------------------+--------------------------------------+---------+------------------------------------+----------------------+----------+ > >>>>> | cf955a75-8cd2-4f91-a01f-677159b57cb2 | > >>>>> k8s-cluster-01-2nyejxo3hyvb-master-0 | ACTIVE | > private1=10.100.0.39, > >>>>> 10.14.20.181 | fedora-coreos-latest | m1.large | > >>>>> > >>>>> > >>>>> ssh -i id_rsa core(a)10.14.20.181 > >>>>> The authenticity of host '10.14.20.181 (10.14.20.181)' can't be > >>>>> established. > >>>>> ECDSA key fingerprint is > >>>>> SHA256:ykEMpwf79/zTMwcELDSI0f66Sxbri56ovGJ+RRwKXDU. > >>>>> Are you sure you want to continue connecting (yes/no/[fingerprint])? > >>>>> yes > >>>>> Warning: Permanently added '10.14.20.181' (ECDSA) to the list of > known > >>>>> hosts. > >>>>> core(a)10.14.20.181: Permission denied > >>>>> (publickey,gssapi-keyex,gssapi-with-mic). > >>>>> > >>>>> On Mon, 18 Oct 2021 at 14:02, Ammad Syed <syedammad83(a)gmail.com> > >>>>> wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> Can you check if the master server is deployed as a nova instance ? > >>>>>> if yes, then login to the instance and check cloud-init and heat > agent logs > >>>>>> to see the errors. > >>>>>> > >>>>>> Ammad > >>>>>> > >>>>>> On Mon, Oct 18, 2021 at 12:03 PM Vikarna Tathe < > >>>>>> vikarnatathe(a)gmail.com> wrote: > >>>>>> > >>>>>>> Hello All, > >>>>>>> > >>>>>>> I am trying to create a kubernetes cluster using magnum. Image: > >>>>>>> fedora-coreos. > >>>>>>> > >>>>>>> > >>>>>>> The stack gets stucked in CREATE_IN_PROGRESS. See the output below. > >>>>>>> openstack coe cluster list > >>>>>>> > >>>>>>> > +--------------------------------------+----------------+---------+------------+--------------+--------------------+---------------+ > >>>>>>> | uuid | name | keypair | > >>>>>>> node_count | master_count | status | health_status | > >>>>>>> > >>>>>>> > +--------------------------------------+----------------+---------+------------+--------------+--------------------+---------------+ > >>>>>>> | 9381cd12-af60-40b1-b1c4-d3dcc93e926e | k8s-cluster-01 | ctrlkey | > >>>>>>> 2 | 1 | CREATE_IN_PROGRESS | None | > >>>>>>> > >>>>>>> > +--------------------------------------+----------------+---------+------------+--------------+--------------------+---------------+ > >>>>>>> > >>>>>>> openstack stack resource show k8s-cluster-01-2nyejxo3hyvb > >>>>>>> kube_masters > >>>>>>> > >>>>>>> > +------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ > >>>>>>> | Field | Value > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> | > >>>>>>> > >>>>>>> > +------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ > >>>>>>> | attributes | {'refs_map': None, 'removed_rsrc_list': > >>>>>>> [], 'attributes': None, 'refs': None} > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> | > >>>>>>> | creation_time | 2021-10-18T06:44:02Z > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> | > >>>>>>> | description | > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> | > >>>>>>> | links | [{'href': ' > >>>>>>> > http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu… > ', > >>>>>>> 'rel': 'self'}, {'href': ' > >>>>>>> > http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu… > ', > >>>>>>> 'rel': 'stack'}, {'href': ' > >>>>>>> > http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu… > ', > >>>>>>> 'rel': 'nested'}] | > >>>>>>> | logical_resource_id | kube_masters > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> | > >>>>>>> | physical_resource_id | 3da2083f-0b2c-4b9d-8df5-8468e0de3028 > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> | > >>>>>>> | required_by | ['kube_cluster_deploy', > >>>>>>> 'etcd_address_lb_switch', 'api_address_lb_switch', > 'kube_cluster_config'] > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> | > >>>>>>> | resource_name | kube_masters > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> | > >>>>>>> | resource_status | CREATE_IN_PROGRESS > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> | > >>>>>>> | resource_status_reason | state changed > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> | > >>>>>>> | resource_type | OS::Heat::ResourceGroup > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> | > >>>>>>> | updated_time | 2021-10-18T06:44:02Z > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> | > >>>>>>> > >>>>>>> > +------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ > >>>>>>> > >>>>>>> Vikarna > >>>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Regards, > >>>>>> > >>>>>> > >>>>>> Syed Ammad Ali > >>>>>> > >>>>> -- > >> Regards, > >> > >> > >> Syed Ammad Ali > >> > > >

1 0

[tripleo][release] tripleo-operator-ansible release job failure
by Előd Illés 19 Oct '21

19 Oct '21

Hi TripleO team, With the latest release [1] the release job failed [2] for tripleo-operator-ansible, specifically the "ansible-galaxy" command failed with: "ERROR! Unexpected Exception, this is probably a bug: [Errno 13] Permission denied: '/tmp/collection_built/tripleo-operator-0.7.0.tar.gz'" [3]. Have you seen this kind of error before? Could you have a look at the error? Thanks in advance, Előd [1] https://review.opendev.org/c/openstack/releases/+/813852 [2] see forwarded mail below [3] https://zuul.opendev.org/t/openstack/build/2dd817ac52824bc886c1839680cb44f1… -------- Forwarded Message -------- Subject: [Release-job-failures] Tag of openstack/tripleo-operator-ansible for ref refs/tags/0.7.0 failed Date: Mon, 18 Oct 2021 18:09:47 +0000 From: zuul(a)openstack.org Reply-To: openstack-discuss(a)lists.openstack.org To: release-job-failures(a)lists.openstack.org Build failed. - publish-openstack-releasenotes-python3 https://zuul.opendev.org/t/openstack/build/b34e7dfd6d4348aaaf3d7c25415cc801 : SUCCESS in 5m 00s - tripleo-operator-ansible-release https://zuul.opendev.org/t/openstack/build/2dd817ac52824bc886c1839680cb44f1 : FAILURE in 3m 18s _______________________________________________ Release-job-failures mailing list Release-job-failures(a)lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

2 1

[nova] Yoga PTG schedule
by Sylvain Bauza 19 Oct '21

19 Oct '21

Hello folks, Not sure people know about our etherpad for the Yoga PTG. This is this one : https://etherpad.opendev.org/p/nova-yoga-ptg You can see the schedule above but, here is there : PTG Schedule https://www.openstack.org/ptg/#tab_schedule https://ptg.opendev.org/ Fancy rendered PDF with hyperlinks for the schedule: https://object-storage-ca-ymq-1.vexxhost.net/swift/v1/6e4619c416ff4bd19e1c0… Connection details https://meet.jit.si/vPTG-Newton - *Monday*: project support team discussions, e.g. SIGs, QA, Infra, Release mgmt, Oslo - *Tuesday* *13:00 UTC - 17:00 UTC* - Nova (Placement) sessions - 13:00 - 14: 00 UTC Cyborg - Nova cross project mini-session - 14:00 - 14:30 UTC Oslo - Nova cross project mini-session - 15:00 - 16:00 UTC RBAC discussions with popup team - *Wednesday 14:00 UTC - 17:00 UTC*: Nova (Placement) sessions - 14:00 - 15:00 UTC Neutron - Nova cross project mini-session - 15:00 - 15:30 UTC Interop discussion with Arkady - *Thursday 14:00 UTC - 17:00 UTC* - Nova (Placement) sessions - 16:00 - 17:00 UTC Cinder - Nova cross project mini-session - *Friday 14:00 UTC - 17:00 UTC* - Nova (Placement) sessions See you then tomorrow at 1pm UTC ! -Sylvain

2 2

[openstack][manila] queens netapp share migration
by Ignazio Cassano 19 Oct '21

19 Oct '21

Hello all, I have an installation of openstack queens and manila is using netapp fas8040 storage with driver manila.share.drivers.netapp.common.NetAppDriver. When I try share migration it fails. manila migration-start --preserve-metadata False --preserve-snapshots False --writable True --nondisruptive True --new_share_type svmp2-nfs-1140 c765143e-d308-4e9d-8a3f-5cb4692be70b 10.138.176.16@svmp2-nfs-1140 #aggr_fas04_MANILA_TO2_UNITY600_Mixed In the share log file I read: 2021-10-18 18:35:01.211 80999 ERROR manila.share.manager NetAppException: Volume share_be9b819d_feab_431b_9ade_b257cc08c9f6 in Vserver svmp2-nfs-1138 is not part of any data motion operations. The svmp2-nfs-1138 is the share type where migration start from. Both source and destination are on netapp. Any help, please? Ignazio

2 7

Re: Openstack magnum
by Vikarna Tathe 19 Oct '21

19 Oct '21

> > > Hi Ammad, > > Thanks for responding. > > Yes the instance is getting created, but i am unable to login though i > have generated the keypair. There is no default password for this image to > login via console. > > openstack server list > > +--------------------------------------+--------------------------------------+---------+------------------------------------+----------------------+----------+ > | ID | Name > | Status | Networks | Image | > Flavor | > > +--------------------------------------+--------------------------------------+---------+------------------------------------+----------------------+----------+ > | cf955a75-8cd2-4f91-a01f-677159b57cb2 | > k8s-cluster-01-2nyejxo3hyvb-master-0 | ACTIVE | private1=10.100.0.39, > 10.14.20.181 | fedora-coreos-latest | m1.large | > > > ssh -i id_rsa core(a)10.14.20.181 > The authenticity of host '10.14.20.181 (10.14.20.181)' can't be > established. > ECDSA key fingerprint is > SHA256:ykEMpwf79/zTMwcELDSI0f66Sxbri56ovGJ+RRwKXDU. > Are you sure you want to continue connecting (yes/no/[fingerprint])? yes > Warning: Permanently added '10.14.20.181' (ECDSA) to the list of known > hosts. > core(a)10.14.20.181: Permission denied > (publickey,gssapi-keyex,gssapi-with-mic). > > On Mon, 18 Oct 2021 at 14:02, Ammad Syed <syedammad83(a)gmail.com> wrote: > >> Hi, >> >> Can you check if the master server is deployed as a nova instance ? if >> yes, then login to the instance and check cloud-init and heat agent logs to >> see the errors. >> >> Ammad >> >> On Mon, Oct 18, 2021 at 12:03 PM Vikarna Tathe <vikarnatathe(a)gmail.com> >> wrote: >> >>> Hello All, >>> >>> I am trying to create a kubernetes cluster using magnum. Image: >>> fedora-coreos. >>> >>> >>> The stack gets stucked in CREATE_IN_PROGRESS. See the output below. >>> openstack coe cluster list >>> >>> +--------------------------------------+----------------+---------+------------+--------------+--------------------+---------------+ >>> | uuid | name | keypair | >>> node_count | master_count | status | health_status | >>> >>> +--------------------------------------+----------------+---------+------------+--------------+--------------------+---------------+ >>> | 9381cd12-af60-40b1-b1c4-d3dcc93e926e | k8s-cluster-01 | ctrlkey | >>> 2 | 1 | CREATE_IN_PROGRESS | None | >>> >>> +--------------------------------------+----------------+---------+------------+--------------+--------------------+---------------+ >>> >>> openstack stack resource show k8s-cluster-01-2nyejxo3hyvb kube_masters >>> >>> +------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >>> | Field | Value >>> >>> >>> >>> >>> >>> >>> | >>> >>> +------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >>> | attributes | {'refs_map': None, 'removed_rsrc_list': [], >>> 'attributes': None, 'refs': None} >>> >>> >>> >>> >>> >>> | >>> | creation_time | 2021-10-18T06:44:02Z >>> >>> >>> >>> >>> >>> >>> | >>> | description | >>> >>> >>> >>> >>> >>> >>> | >>> | links | [{'href': ' >>> http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu…', >>> 'rel': 'self'}, {'href': ' >>> http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu…', >>> 'rel': 'stack'}, {'href': ' >>> http://10.14.20.159:8004/v1/f453bf8a2afa4fbba30030738f4dd216/stacks/k8s-clu…', >>> 'rel': 'nested'}] | >>> | logical_resource_id | kube_masters >>> >>> >>> >>> >>> >>> >>> | >>> | physical_resource_id | 3da2083f-0b2c-4b9d-8df5-8468e0de3028 >>> >>> >>> >>> >>> >>> >>> | >>> | required_by | ['kube_cluster_deploy', >>> 'etcd_address_lb_switch', 'api_address_lb_switch', 'kube_cluster_config'] >>> >>> >>> >>> >>> >>> | >>> | resource_name | kube_masters >>> >>> >>> >>> >>> >>> >>> | >>> | resource_status | CREATE_IN_PROGRESS >>> >>> >>> >>> >>> >>> >>> | >>> | resource_status_reason | state changed >>> >>> >>> >>> >>> >>> >>> | >>> | resource_type | OS::Heat::ResourceGroup >>> >>> >>> >>> >>> >>> >>> | >>> | updated_time | 2021-10-18T06:44:02Z >>> >>> >>> >>> >>> >>> >>> | >>> >>> +------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >>> >>> Vikarna >>> >> >> >> -- >> Regards, >> >> >> Syed Ammad Ali >> >

2 4

[openstack-ansible][osa][ptg] Yoga PTG session
by Dmitriy Rabotyagov 19 Oct '21

19 Oct '21

1 0

How to force kolla-ansible to rotate logs with given interval [kolla-ansible]
by Adam Tomas 19 Oct '21

19 Oct '21

Hi, different services in kolla-ansible have different log rotation policies and I’d like to make the logs easier to maintain and search (tried central logging with Kibana, but somehow I don’t like this solution). So I tried to write common config file for all logs. As I understand all logs should be rotated by cron container, inside of which there’s logrotate.conf file (and as I can see the logs are rotated according to this file). So I’ve copied this file, modified according to my needs and put it ina /etc/kolla/config with the name cron-logrotate-global.conf (as documentation says). And… nothing. I’ve checked permissions of this file - everything seems to be ok, so what’s the problem? Below is my logrotate.conf file Best regards, Adam Tomas cat /etc/kolla/config/cron-logrotate-global.conf daily rotate 31 copytruncate compress delaycompress notifempty missingok minsize 0M maxsize 100M su root kolla "/var/log/kolla/ansible.log" { } "/var/log/kolla/aodh/*.log" { } "/var/log/kolla/barbican/*.log" { } "/var/log/kolla/ceilometer/*.log" { } "/var/log/kolla/chrony/*.log" { } "/var/log/kolla/cinder/*.log" { } "/var/log/kolla/cloudkitty/*.log" { } "/var/log/kolla/designate/*.log" { } "/var/log/kolla/elasticsearch/*.log" { } "/var/log/kolla/fluentd/*.log" { } "/var/log/kolla/glance/*.log" { } "/var/log/kolla/haproxy/haproxy.log" { } "/var/log/kolla/heat/*.log" { } "/var/log/kolla/horizon/*.log" { } "/var/log/kolla/influxdb/*.log" { } "/var/log/kolla/iscsi/iscsi.log" { } "/var/log/kolla/kafka/*.log" { } "/var/log/kolla/keepalived/keepalived.log" { } "/var/log/kolla/keystone/*.log" { } "/var/log/kolla/kibana/*.log" { } "/var/log/kolla/magnum/*.log" { } "/var/log/kolla/mariadb/*.log" { } "/var/log/kolla/masakari/*.log" { } "/var/log/kolla/monasca/*.log" { } "/var/log/kolla/neutron/*.log" { postrotate chmod 644 /var/log/kolla/neutron/*.log endscript } "/var/log/kolla/nova/*.log" { } "/var/log/kolla/octavia/*.log" { } "/var/log/kolla/rabbitmq/*.log" { } "/var/log/kolla/rally/*.log" { } "/var/log/kolla/skydive/*.log" { } "/var/log/kolla/storm/*.log" { } "/var/log/kolla/swift/*.log" { } "/var/log/kolla/vitrage/*.log" { } "/var/log/kolla/zookeeper/*.log" { }

2 2

[openstack][manila] data-node ?
by Ignazio Cassano 19 Oct '21

19 Oct '21

Hello, I need to migrate some share in host assisted mode, but seems I need a data-node. I am using openstack queens on centos 7. How can I install a data-node ? I cannot find any manila packages related to it? Please, anyone can send me some documentation link ? I found only manila-scheduler, manila-api end manila-share services Thanks Ignazio

2 4

[openstack-helm] No Meeting Oct 19th
by Gage Hugo 19 Oct '21

19 Oct '21

Hey team, Since this week is the PTG, the meeting for this week is cancelled. We will meet for our session on Wednesday Oct 20th, then resume normal schedule next week. Thanks

1 0

[tc][horizon][skyline] Welcome to the Skyline PTG
by 高瀚翔 19 Oct '21

19 Oct '21

Hi all, Skyline project members will hold their own PTG this week (Tuesday, Wednesday and Thursday at 5 UTC). At present, the skyline project has submitted an application to become an official OpenStack project, and we also welcome more friends to join us. Skyline is an OpenStack dashboard optimized by UI and UE. It has a modern technology stack and ecology, is easier for developers to maintain and operate by users, and has higher concurrency performance. Here are two videos to preview Skyline: - Skyline technical overview[1]. - Skyline dashboard operating demo[2]. Skyline has the following technical advantages: 1. Separation of concerns, front-end focus on functional design and user experience, back-end focus on data logic. 2. Embrace modern browser technology and ecology: React, Ant Design, and Mobx. 3. Most functions directly call OpenStack-API, the call chain is simple, the logic is clearer, and the API responds quickly. 4. Use React component to process rendering, the page display process is fast and smooth, bringing users a better UI and UE experience. At present, Skyline has completed the function development of OpenStack core component, as well as most of the functions of VPNaaS, Octavia and other components. corresponding automated test jobs[3][4] are also integrated on Zuul, and there is good code coverage. Devstack deployment integration has also been completed, and integration of kolla and kolla-ansible will complete pending patch[5][6] after Skyline becomes an official project. Skyline’s next roadmap will be to cover all existing functions of Horizon and complete the page development of other OpenStack components. [1] https://www.youtube.com/watch?v=Ro8tROYKDlE [2] https://www.youtube.com/watch?v=pFAJLwzxv0 [3] https://zuul.opendev.org/t/openstack/project/opendev.org/skyline/skyline-ap… [4] https://zuul.opendev.org/t/openstack/project/opendev.org/skyline/skyline-co… [5] https://review.opendev.org/c/openstack/kolla/+/810796 [6] https://review.opendev.org/c/openstack/kolla-ansible/+/810566

4 3

[nova][cyborg] No meeting today due virtual PTG
by Brin Zhang(张百林) 19 Oct '21

19 Oct '21

Hi all, As agreed Cyborg Team with today meeting [1], the meeting is *CANCELLED* as all of us will be attending the virtual PTG today. If you have any idea or feature/issue want to discuss, you can add it to etherpad [1], whether you can join or not, but you should describe its details, we can talk and give a reply. [1] https://etherpad.opendev.org/p/cyborg-yoga-ptg Thanks brinzhang

1 0

[cyborg][ptg] Yoga PTG meeting
by Brin Zhang(张百林) 19 Oct '21

19 Oct '21

Hello, As part of the Yoga PTG, the Cyborg team project will meet on Wednesday October 19 , from 6UTC-8UTC,( https://ethercalc.openstack.org/8tum5yl1bx43 report 503 now), but you can join us on #openstack-cyborg channel. We have created an Etherpad to define the agenda: https://etherpad.opendev.org/p/cyborg-yoga-ptg Feel free to add topics you would like to see discussed. Thanks Brin Zhang

1 0