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

[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