June 2020 - openstack-discuss - lists.openstack.org

[stein][neutron] gratuitous arp
by Ignazio Cassano 14 May '21

14 May '21

Hello, I have a problem on stein neutron. When a vm migrate from one node to another I cannot ping it for several minutes. If in the vm I put a script that ping the gateway continously, the live migration works fine and I can ping it. Why this happens ? I read something about gratuitous arp. Please, help me ? Any workaround , please ? Best Regards Ignazio

3 33

Re: [openstack-dev] Are we ready to put stable/ocata into extended maintenance mode?
by Alex Schultz 03 Mar '21

03 Mar '21

On Tue, Sep 18, 2018 at 1:30 PM Alex Schultz <aschultz(a)redhat.com> wrote: > > On Tue, Sep 18, 2018 at 1:27 PM, Matt Riedemann <mriedemos(a)gmail.com> wrote: > > The release page says Ocata is planned to go into extended maintenance mode > > on Aug 27 [1]. There really isn't much to this except it means we don't do > > releases for Ocata anymore [2]. There is a caveat that project teams that do > > not wish to maintain stable/ocata after this point can immediately end of > > life the branch for their project [3]. We can still run CI using tags, e.g. > > if keystone goes ocata-eol, devstack on stable/ocata can still continue to > > install from stable/ocata for nova and the ocata-eol tag for keystone. > > Having said that, if there is no undue burden on the project team keeping > > the lights on for stable/ocata, I would recommend not tagging the > > stable/ocata branch end of life at this point. > > > > So, questions that need answering are: > > > > 1. Should we cut a final release for projects with stable/ocata branches > > before going into extended maintenance mode? I tend to think "yes" to flush > > the queue of backports. In fact, [3] doesn't mention it, but the resolution > > said we'd tag the branch [4] to indicate it has entered the EM phase. > > > > 2. Are there any projects that would want to skip EM and go directly to EOL > > (yes this feels like a Monopoly question)? > > > > I believe TripleO would like to EOL instead of EM for Ocata as > indicated by the thead > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134671.ht… > Bringing this backup to see what we need to do to get the stable/ocata branches ended for the TripleO projects. I'm bringing this up because we have https://review.openstack.org/#/c/647009/ which is for the upcoming rename but CI is broken and we have no interest in continue to keep the stable/ocata branches alive (or fix ci for them). Thanks, -Alex > Thanks, > -Alex > > > [1] https://releases.openstack.org/ > > [2] > > https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… > > [3] > > https://docs.openstack.org/project-team-guide/stable-branches.html#extended… > > [4] > > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.… > > > > -- > > > > Thanks, > > > > Matt > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

5 11

Fwd: [MURANO] DevStack Murano "yaql_function" Error
by İzzettin Erdem 02 Nov '20

02 Nov '20

Thanks Andy. Regards. Forwarded Conversation Subject: [MURANO] DevStack Murano "yaql_function" Error ------------------------ Gönderen: Andy Botting <andy(a)andybotting.com> Date: 30 Nis 2020 Per, 14:13 To: İzzettin Erdem <root.mch(a)gmail.com> Cc: Rong Zhu <aaronzhu1121(a)gmail.com>, < openstack-discuss(a)lists.openstack.org> Hi İzzettin, Thanks for your interest. Complete log link is at below. It is happening > when i try to deploy or update an environment. > > http://paste.openstack.org/show/792444/ > I've encountered the error AttributeError: 'method' object has no attribute '__yaql_function__' in our environment recently. I believe it started after we upgraded to the Stein release. I haven't tracked it down yet, but calls to the YAQL function: std:Project.getEnvironmentOwner() in a Murano app seem to generate it. It's good to know that at least someone else has reproduced this. cheers, Andy ---------- Gönderen: İzzettin Erdem <root.mch(a)gmail.com> Date: 2 May 2020 Cmt, 16:08 To: Andy Botting <andy(a)andybotting.com> Hi Andy, I solved this problem, it is happening when you try to create or update an environment on existing network. If you change the network with "create new" parameter, it stuck on "creating -or updating- environment" state and after that throws connection error. So i searched Murano network errors and i found this: https://docs.oracle.com/cd/E73172_01/E73173/html/issue-21976631.html. I applied these steps and i created successfully an environment just only with "create new" network parameter. After all these, i realized my devstack environment has no internet connection and because of this murano-agent could not install. So i tried to install Murano on my OSA stable/train test environment and i came with success until last step. Murano-agent installed but this time agent could not connect to rabbitmq instance. I discussed this with OSA IRC channel and i think i have to struggle with this for a long time. Apologize for this long mail but i wanted to inform you. Thanks. Regards. ---------- Gönderen: Andy Botting <andy(a)andybotting.com> Date: 3 May 2020 Paz, 14:24 To: İzzettin Erdem <root.mch(a)gmail.com> Hi İzzettin, Glad you got it sorted. I think you've probably just worked around the issue. Using your new method, you're probably just avoiding the std:Project.getEnvironmentOwner YAQL call now. I've also worked around it in our environment, but I'd like to solve it properly. When I get some time to look into it properly, I'll let you know. cheers, Andy

3 3

[Neutron] no L3 meeting this week (2020-June-01)
by LIU Yulong 28 Oct '20

28 Oct '20

Hi there, Due to the PTG meetings this week, we will cancel the L3 meeting this week. See you guys online next week. Regards, LIU Yulong

1 2

[puppet][congress] Retiring puppet-congress
by Takashi Kajinami 10 Aug '20

10 Aug '20

Hello, As you know, Congress project has been retired already[1], so we will retire its puppet module, puppet-congress in openstack puppet project as well. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014292.ht… Because congress was directly retired instead of getting migrated to x namespace, we'll follow the same way about puppet-congress retirement and won't create x/puppet-congress. Thank you for the contribution made for the project ! Please let us know if you have any concerns about this retirement. Thank you, Takashi Kajinami

2 1

[horizon] patternfly?
by Mohammed Naser 06 Aug '20

06 Aug '20

Hi everyone, I was wondering if anyone in the community has explored the idea of implementing PatternFly inside Horizon. It seems like it shares a lot of the similar ideas that we use and we could really benefit from using a common library that already exists with a lot of good UX thought behind it. I know it's based on React which is a bit of a leap from where Horizon is today. However, I'd be curious if the Horizon team is interested in figuring out a plan to make a migration to something like this happen. Personally, I think I would be able to provide resources to have someone do this work. However, if this seems like a huge stretch and architecture change where it actually makes more sense to stand this up from scratch (and implement an architecture where the dashboard talks directly to the APIs?), perhaps we should explore that. I also would like to hear more from our extended community too, as I think we really need to improve our user interface experience. Thanks, Mohammed -- Mohammed Naser VEXXHOST, Inc.

11 31

[TC] [PTG] Victoria vPTG Summary of Conversations and Action Items
by Kendall Nelson 06 Aug '20

06 Aug '20

Hello Everyone! I hope you all had a productive and enjoyable PTG! While it’s still reasonably fresh, I wanted to take a moment to summarize discussions and actions that came out of TC discussions. If there is a particular action item you are interested in taking, please reply on this thread! For the long version, check out the etherpad from the PTG[1]. Tuesday ====== Ussuri Retrospective ---------------------------- As usual we accomplished a lot. Some of the things we accomplished were around enumerating operating systems per release (again), removing python2 support, and adding the ideas repository. Towards the end of the release, we had a lot of discussions around what to do with leaderless projects, the role of PTLs, and what to do with projects that were missing PTL candidates for the next release. We discussed office hours, their history and reason for existence, and clarified how we can strengthen communication amongst ourselves, the projects, and the larger community. TC Onboarding -------------------- It was brought up that those elected most recently (and even new members the election before) felt like there wasn’t enough onboarding into the TC. Through discussion about what we can do to better support returning members is to better document the daily, weekly and monthly tasks TC members are supposed to be doing. Kendall Nelson proposed a patch to start adding more detail to a guide for TC members already[2]. It was also proposed that we have a sort of mentorship or shadow program for people interested in joining the TC or new TC members by more experienced TC members. The discussion about the shadow/mentorship program is to be continued. TC/UC Merge ------------------ Thierry gave an update on the merge of the committees. The simplified version is that the current proposal is that UC members are picked from TC members, the UC operates within the TC, and that we are already setup for this given the number of TC members that have AUC status. None of this requires a by-laws change. One next step that has already begun is the merging of the openstack-users ML into openstack-discuss ML. Other next steps are to decide when to do the actual transition (disbanding the separate UC, probably at the next election?) and when to setup AUC’s to be defined as extra-ATC’s to be included in the electorate for elections. For more detail, check out the openstack-discuss ML thread[3]. Wednesday ========= Help Wanted List ----------------------- We settled on a format for the job postings and have several on the list. We talked about how often we want to look through, update or add to it. The proposal is to do this yearly. We need to continue pushing on the board to dedicate contributors at their companies to work on these items, and get them to understand that it's an investment that will take longer than a year in a lot of cases; interns are great, but not enough. TC Position on Foundation Member Community Contributions ---------------------------------------------------------------------------------- The discussion started with a state of things today - the expectations of platinum members, the benefits the members get being on the board and why they should donate contributor resources for these benefits, etc. A variety of proposals were made: either enforce or remove the minimum contribution level, give gold members the chance to have increased visibility (perhaps giving them some of the platinum member advantages) if they supplement their monetary contributions with contributor contributions, etc. The #ACTION that was decided was for Mohammed to take these ideas to the board and see what they think. OpenStack User-facing APIs -------------------------------------- Users are confused about the state of the user facing API’s; they’ve been told to use the OpenStackClient(OSC) but upon use, they discover that there are features missing that exist in the python-*clients. Partial implementation in the OSC is worse than if the service only used their specific CLI. Members of the OpenStackSDK joined discussions and explained that many of the barriers that projects used to have behind implementing certain commands have been resolved. The proposal is to create a pop up team and that they start with fully migrating Nova, documenting the process and collecting any other unresolved blocking issues with the hope that one day we can set the migration of the remaining projects as a community goal. Supplementally, a new idea was proposed- enforcing new functionality to services is only added to the SDK (and optionally the OSC) and not the project’s specific CLI to stop increasing the disparity between the two. The #ACTION here is to start the pop up team, if you are interested, please reply! Additionally, if you disagree with this kind of enforcement, please contact the TC as soon as possible and explain your concerns. PTL Role in OpenStack today & Leaderless Projects --------------------------------------------------------------------- This was a veeeeeeeerrrry long conversation that went in circles a few times. The very short version is that we, the TC, are willing to let project teams decide for themselves if they want to have a more deconstructed kind of PTL role by breaking it into someone responsible for releases and someone responsible for security issues. This new format also comes with setting the expectation that for things like project updates and signing up for PTG time, if someone on the team doesn’t actively take that on, the default assumption is that the project won’t participate. The #ACTION we need someone to take on is to write a resolution about how this will work and how it can be done. Ideally, this would be done before the next technical election, so that teams can choose it at that point. If you are interested in taking on the writing of this resolution, please speak up! Cross Project Work ------------------------- -Pop Up Teams- The two teams we have right now are Encryption and Secure Consistent Policy Groups. Both are making slow progress and will continue. -Reducing Community Goals Per Cycle- Historically we have had two goals per cycle, but for smaller teams this can be a HUGE lift. The #ACTION is to clearly outline the documentation for the goal proposal and selection process to clarify that selecting only one goal is fine. No one has claimed this action item yet. -Victoria Goal Finalization- Currently, we have three proposals and one accepted goal. If we are going to select a second goal, it needs to be done ASAP as Victoria development has already begun. All TC members should review the last proposal requesting selection[4]. -Wallaby Cycle Goal Discussion Kick Off- Firstly, there is a #ACTION that one or two TC members are needed to guide the W goal selection. If you are interested, please reply to this thread! There were a few proposed goals for VIctoria that didn’t make it that could be the starting point for W discussions, in particular, the rootwrap goal which would be good for operators. The OpenStackCLI might be another goal to propose for Wallaby. Detecting Unmaintained Projects Early --------------------------------------------------- The TC liaisons program had been created a few releases ago, but the initial load on TC members was large. We discussed bringing this program back and making the project health checks happen twice a release, either the start or end of the release and once in the middle. TC liaisons will look at previously proposed releases, release activity of the team, the state of tempest plugins, if regular meetings are happening, if there are patches in progress and how busy the project’s IRC channel is to make a determination. Since more than one liaison will be assigned to each project, those liaisons can divvy up the work how they see fit. The other aspect that still needs to be decided is where the health checks will be recorded- in a wiki? In a meeting and meeting logs? That decision is still to be continued. The current #ACTION currently unassigned is that we need to assign liaisons for the Victoria cycle and decide when to do the first health check. Friday ===== Reducing Systems and Friction to Drive Change ---------------------------------------------------------------- This was another conversation that went in circles a bit before realizing that we should make a list of the more specific problems we want to address and then brainstorm solutions for them. The list we created (including things already being worked) are as follows: - TC separate from UC (solution in progress) - Stable releases being approved by a separate team (solution in progress) - Making repository creation faster (especially for established project teams) - Create a process blueprint for project team mergers - Requirements Team being one person - Stable Team - Consolidate the agent experience - Figure out how to improve project <--> openstack client/sdk interaction. If you feel compelled to pick one of these things up and start proposing solutions or add to the list, please do! Monitoring in OpenStack (Ceilometer + Telemetry + Gnocchi State) ----------------------------------------------------------------------------------------- This conversation is also ongoing, but essentially we talked about the state of things right now- largely they are not well maintained and there is added complexity with Ceilometers being partially dependent on Gnocchi. There are a couple of ideas to look into like using oslo.metrics for the interface between all the tools or using Ceilometer without Gnocchi if we can clean up those dependencies. No specific action items here, just please share your thoughts if you have them. Ideas Repo Next Steps ------------------------------- Out of the Ussuri retrospective, it was brought up that we probably needed to talk a little more about what we wanted for this repo. Essentially we just want it to be a place to collect ideas into without worrying about the how. It should be a place to document ideas we have had (old and new) and keep all the discussion in one place as opposed to historic email threads, meetings logs, other IRC logs, etc. We decided it would be good to periodically go through this repo, likely as a forum session at a summit to see if there is any updating that could happen or promotion of ideas to community goals, etc. ‘tc:approved-release’ Tag --------------------------------- This topic was proposed by the Manila team from a discussion they had earlier in the week. We talked about the history of the tag and how usage of tags has evolved. At this point, the proposal is to remove the tag as anything in the releases repo is essentially tc-approved. Ghanshyam has volunteered to document this and do the removal. The board also needs to be notified of this and to look at projects.yaml in the governance repo as the source of truth for TC approved projects. The unassigned #ACTION item is to review remaining tags and see if there are others that need to be modified/removed/added to drive common behavior across OpenSack components. Board Proposals ---------------------- This was a pretty quick summary of all discussions we had that had any impact on the board and largely decided who would mention them. Session Feedback ------------------------ This was also a pretty quick topic compared to many of the others, we talked about how things went across all our discussions (largely we called the PTG a success) logistically. We tried to make good use of the raising hands feature which mostly worked, but it lacks context and its possible that the conversation has moved on by the time it’s your turn (if you even remember what you want to say). OpenStack 2.0: k8s Native ----------------------------------- This topic was brought up at the end of our time so we didn’t have time to discuss it really. Basically Mohammed wanted to start the conversation about adding k8s as a base service[5] and what we would do if a project proposed required k8s. Adding services that work with k8s could open a door to new innovation in OpenStack. Obviously this topic will need to be discussed further as we barely got started before we had to wrap things up. So. The tldr; Here are the #ACTION items we need owners for: - Start the User Facing API Pop Up Team - Write a resolution about how the deconstructed PTL roles will work - Update Goal Selection docs to explain that one or more goals is fine; it doesn’t have to be more than one - Two volunteers to start the W goal selection process - Assign two TC liaisons per project - Review Tags to make sure they are still good for driving common behavior across all openstack projects Here are the things EVERYONE needs to do: - Review last goal proposal so that we can decide to accept or reject it for the V release[4] - Add systems that are barriers to progress in openstack to the Reducing Systems and Friction list - Continue conversations you find important Thanks everyone for your hard work and great conversations :) Enjoy the attached (photoshopped) team photo :) -Kendall (diablo_rojo) [1] TC PTG Etherpad: https://etherpad.opendev.org/p/tc-victoria-ptg [2] TC Guide Patch: https://review.opendev.org/#/c/732983/ [3] UC TC Merge Thread: http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014736.html [4] Proposed V Goal: https://review.opendev.org/#/c/731213/ [5] Base Service Description: https://governance.openstack.org/tc/reference/base-services.html

3 2

[neutron][networking-midonet] Maintainers needed
by Slawek Kaplonski 28 Jul '20

28 Jul '20

Hi, Over the past couple of cycles we have noticed that new contributions and maintenance efforts for networking-midonet project were lower and lower. This impacts patches for bug fixes, new features and reviews. The Neutron core team is trying to at least keep the CI of this project more or less healthy, but we don't have enough cycles and knowledge about the details of this project code base to review more complex patches. During the PTG in Shanghai we discussed that with operators and TC members during the forum session [1] and later within the Neutron team during the PTG session [2]. During these discussions, with the help of operators and TC members, we reached the conclusion that we need to have someone responsible for maintaining project. This doesn't mean that the maintainer needs to spend full time working on this project. Rather, we need someone to be the contact person for the project, who takes care of the project's CI and review patches. Of course that'ss only a minimal requirement. If the new maintainer works on new features for the project, it's even better :) I recently spoke with members of current networking-midonet core team and they told me that they don't have cycles to focus on this project. So if we don't have any new maintainer(s) before milestone Victoria-2, which is Jul 27 - Jul 31 according to [3], we will need to mark networking-midonet as deprecated for removal. "Removal" means that in W cycle we will remove code of this project from its master branch and there will be no new releases of it. We will still keep code in stable branches which were already released until its EOL. So if You are using this project now, or if You have customers who are using it, please consider the possibility of maintaining it. Otherwise, please be aware that it is highly possible that the project will be deprecated and moved out from the official OpenStack projects. [1] https://etherpad.openstack.org/p/PVG-Neutron-stadium-projects-the-path-forw… [2] https://etherpad.openstack.org/p/Shanghai-Neutron-Planning-restored - Lines 379-421 [3] https://releases.openstack.org/victoria/schedule.html -- Slawek Kaplonski Senior software engineer Red Hat

1 1

[ceilometer][octavia] polling meters
by Ionut Biru 14 Jul '20

14 Jul '20

Hello guys, I was trying to add in polling.yaml and pipeline from ceilometer the following: - network.services.lb.active.connections - network.services.lb.health_monitor - network.services.lb.incoming.bytes - network.services.lb.listener - network.services.lb.loadbalancer - network.services.lb.member - network.services.lb.outgoing.bytes - network.services.lb.pool - network.services.lb.total.connections But it doesn't work, I think they are for the old lbs that were supported in neutron. I found https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollst… but this is not available in stein or train. I was wondering if there is a way to meter loadbalancers from octavia. I mostly want for start to just meter if a loadbalancer was deployed and has status active. -- Ionut Biru - https://fleio.com

3 17

[All][Neutron][Devstack] OVN as the Default Devstack Neutron Backend
by Slawek Kaplonski 09 Jul '20

09 Jul '20

Hi, The Neutron team wants to propose a switch of the default Neutron backend in Devstack from OVS (neutron-ovs-agent, neutron-dhcp-agent, neutron-l3-agent) to OVN with its own ovn-metadata-agent and ovn-controller. We discussed that change during the virtual PTG - see [1]. In this document we want to explain reasons why we want to do that change. OVN in 75 Words --------------- Open Virtual Network is managed under the OVS project, and was created by the original authors of OVS. It is an attempt to re-do the ML2/OVS control plane, using lessons learned throughout the years. It is intended to be used in projects such as OpenStack and Kubernetes. OVN has a different architecture, moving us away from Python agents communicating with the Neutron API service via RabbitMQ to C daemons communicating via OpenFlow and OVSDB. Here’s a heap of information about OpenStack’s integration of OVN: * OpenStack Boston Summit talk on OVN [2] * Upstream OpenStack networking-ovn documentation [3] and [4] * OSP 13 OVN documentation, including how to install it using Director [5] Neutron OVN driver was developed as a Neutron stadium project, "networking-ovn". In the Ussuri cycle, networking-ovn was merged into the main Neutron repository. Why? ---- In the Neutron team we believe that OVN and the Neutron OVN driver are built with a modern architecture that offers better foundations for a simpler and more performant solution. We see increased participation in kubernetes-ovn, resulting in a larger core OVN community, and we would like OpenStack to benefit from this Kubernetes driven OVN investment. Neutron OVN driver currently has got some feature parity gaps comparing to ML2/OVS (see [6] for details) but our team is working hard to close those gaps and we believe that this driver is the future for Neutron and that’s why we want to make it the default Neutron ML2 backend in the Devstack configuration. What Does it Mean? ------------------ Since most Openstack projects use Neutron in their CI and gate jobs, this change has the potential for a large impact. But this backend is already tested with various jobs in the Neutron CI and it works fine. Recently (See [7]) we also proposed to add an OVN based job to the Devstack’s check queue. Similarly the default Neutron backend in TripleO was changed in the Stein cycle and there were no any significant issues related strictly to this change. It worked well for other projects. Of course in the Neutron project we will be still gating other drivers, like ML2/Linuxbridge and ML2/OVS - nothing will change here, except for the names of some of the jobs. The Neutron team is *NOT* going to deprecate any of the other existing ML2 drivers. We will be still maintaining Linuxbridge, OVS and other in-tree drivers in the same way as it is now. Action Plan ----------- We want to make this change before the Victoria-2 milestone to not make such changes too late in the release cycle. Our action plan is as below: 1. Share the plan and get feedback from the upstream community (this thread) 2. Move OVN related Devstack code from a plugin defined in the Neutron repo to Devstack repo - we don’t want to force everyone else to add “enable_plugin neutron” in their local.conf file to use default Neutron backend, 3. Switch default Neutron backend in Devstack to be OVN, a. Switch definition of base devstack CI jobs that it will run Neutron with OVN backend, 4. Propose DNM patches depend on patch from point 3 and 3a to main OpenStack projects to check if it will not break anything in the gate of those projects. 5. If all will be running fine, merge patches proposed in points 3 and 3a. [1] https://etherpad.opendev.org/p/neutron-victoria-ptg - Lines 185 - 193 [2] https://www.youtube.com/watch?v=sgc7myiX6ts [3] https://docs.openstack.org/neutron/latest/admin/ovn/index.html [4] https://docs.openstack.org/neutron/latest/ovn/index.html [5] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/13… [6] https://docs.openstack.org/neutron/latest/ovn/gaps.html [7] https://review.opendev.org/#/c/736021/ -- Slawek Kaplonski Senior software engineer Red Hat

6 8

[ironic] 2nd Victoria meetup
by Dmitry Tantsur 08 Jul '20

08 Jul '20

Hi all, Since we're switching to 6 releases per year cadence, I think it makes sense to have short virtual meetups after every release. The goal will be to sync on priorities, exchange ideas and define plans for the upcoming 2 months of development. Fooling around is also welcome! Please vote for the best 2 hours slot next week: https://doodle.com/poll/3r9tbhmniattkty8. I tried to include more potential time zones, so apologies for so many options. Please cast your vote until Friday, 12pm UTC, so that I can announce the final time slot this week. Dmitry

2 4

[glance] Global Request ID issues in Glance
by Markus Hentsch 07 Jul '20

07 Jul '20

Hello everyone, while I was experimenting with the Global Request ID functionality of OpenStack [1], I identified two issues in Glance related to this topic. I have written my findings below and would appreciate it if you could take a look and confirm whether those are intended behaviors or indeed issues with the implementation. In case of the latter please advice me which bug tracker to report them to. 1. The Glance client does not correctly forward the global ID When the SessionClient class is used, the global_request_id is removed from kwargs in the constructor using pop() [2]. Directly after this, the parent constructor is called using super(), which in this case is Adapter from the keystoneauth1 library. Therein the global_request_id is set again [3] but since it has been removed from the kwargs, it defaults to None as specified in the Adapter's __init__() header. Thus, the global_request_id passed to the SessionClient constructor never actually makes it to the Glance API. This is in contrast to the HTTPClient class, where get() is used instead of pop() [4]. This can be reproduced simply by creating a server in Nova from an image in Glance, which will attempt to create the Glance client instance using the global_request_id [5]. Passing the "X-Openstack-Request-Id" header during the initial API call for the server creation, makes it visible in Nova (using a suitable "logging_context_format_string" setting) but it's not visible in Glance. Using a Python debugger shows Glance generating a new local ID instead. 2. Glance interprets global ID as local one for Oslo Context objects While observing the Glance log file, I observed Glance always logging the global_request_id instead of a local one if it is available. Using "%(global_request_id)s" within "logging_context_format_string"[6] in the glance-api.conf will always print "None" in the logs whereas "%(request_id)s" will either be an ID generated by Glance if no global ID is available or the received global ID. Culprit seems to be the context middleware of Glance where the global ID in form of the "X-Openstack-Request-Id" header is parsed from the request and passed as "request_id" instead of "global_request_id" to the "glance.context.RequestContext.from_environ()" call [7]. This is in contrast to other services such as Nova or Neutron where the two variables actually print the values according to their name (request_id always being the local one, whereas global_request_id is the global one or None). [1] https://specs.openstack.org/openstack/oslo-specs/specs/pike/global-req-id.h… [2] https://github.com/openstack/python-glanceclient/blob/de178ac4382716cc93022… [3] https://github.com/openstack/keystoneauth/blob/dab8e1057ae8bb9a0e778fb8d314… [4] https://github.com/openstack/python-glanceclient/blob/de178ac4382716cc93022… [5] https://github.com/openstack/nova/blob/1cae0cd7229207478b70275509aecd778ca6… [6] https://docs.openstack.org/oslo.context/2.17.0/user/usage.html#context-vari… [7] https://github.com/openstack/glance/blob/e6db0b10a703037f754007bef6f5645108… Thanks! Markus -- Markus Hentsch Team Leader secustack GmbH - Digital Sovereignty in the Cloud https://www.secustack.com Königsbrücker Straße 96 (Gebäude 30) | 01099 Dresden District Court Dresden, Register Number: HRB 38890

2 2

Re: [rdo-users] [rdo][ussuri][TripleO][nova][kvm] libvirt.libvirtError: internal error: process exited while connecting to monitor
by Arkady Shtempler 06 Jul '20

06 Jul '20

Hi all! I was able to analyze the attached log files and I hope that the results may help you understand what's going wrong with instance creation. You can find *Log_Tool's unique exported Error blocks* here: http://paste.openstack.org/show/795356/ *Some statistics and problematical messages:* ##### Statistics - Number of Errors/Warnings per Standard OSP log since: 2020-06-30 12:30:00 ##### Total_Number_Of_Errors --> 9 /home/ashtempl/Ruslanas/controller/neutron/server.log --> 1 /home/ashtempl/Ruslanas/compute/stdouts/ovn_controller.log --> 1 /home/ashtempl/Ruslanas/compute/nova/nova-compute.log --> 7 *nova-compute.log* *default default] Error launching a defined domain with XML: <domain type='kvm'>* 368-2020-06-30 12:30:10.815 7 *ERROR* nova.compute.manager [req-87bef18f-ad3d-4147-a1b3-196b5b64b688 7bdb8c3bf8004f98aae1b16d938ac09b 69134106b56941698e58c61... 70dc50f] Instance *failed* to spawn: *libvirt.libvirtError*: internal *error*: qemu unexpectedly closed the monitor: 2020-06-30T10:30:10.182675Z qemu-kvm: *error*: failed to set MSR 0... he monitor: 2020-06-30T10:30:10.182675Z *qemu-kvm: error: failed to set MSR 0x48e to 0xfff9fffe04006172* _msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' *failed*. [instance: 128f372c-cb2e-47d9-b1bf-ce17270dc50f] *Traceback* (most recent call last): 375-2020-06-30 12:30:10.815 7* ERROR* nova.compute.manager [instance: 128f372c-cb2e-47d9-b1bf-ce17270dc50f] File "/usr/lib/python3.6/site-packages/nova/vir... *server.log * 5821c815-d213-498d-9394-fe25c6849918', 'status': 'failed', *'code': 422} returned with failed status* *ovn_controller.log* 272-2020-06-30T12:30:10.126079625+02:00 stderr F 2020-06-30T10:30:10Z|00247|patch|WARN|*Bridge 'br-ex' not found for network 'datacentre'* Thanks! On Tue, Jun 30, 2020 at 2:13 PM Ruslanas Gžibovskis <ruslanas(a)lpic.lt> wrote: > attaching logs here. let's see if it will work. > > On Tue, 30 Jun 2020 at 12:55, Ruslanas Gžibovskis <ruslanas(a)lpic.lt> > wrote: > >> hi all, >> >> I am back, had some issues with MTU. >> Now looks good, at least deployment part. >> >> So I have installed back what I had, and still failing at same point as >> in first message. >> >> I have tried to use: LogTool, how to use it? well, I launched it, but it >> always say [0] detailed output: >> File "./PyTool.py", line 596, in <module> >> random_node=random.choice(overcloud_nodes) >> >> I do not get, how to make it work, should it get from stackrc ? as I see >> in >> overcloud_nodes = [] >> all_nodes = exec_command_line_command('source ' + source_rc_file_path >> + 'stackrc;openstack server list -f json')[ >> >> [0] http://paste.openstack.org/show/795345/ >> >> On Wed, 24 Jun 2020 at 20:02, Arkady Shtempler <ashtempl(a)redhat.com> >> wrote: >> >>> Hi Ruslanas! >>> >>> Is it possible to get all logs under /var/log/containers somehow? >>> >>> Thanks! >>> >>> On Wed, Jun 24, 2020 at 2:18 AM Ruslanas Gžibovskis <ruslanas(a)lpic.lt> >>> wrote: >>> >>>> Hi Alfredo, >>>> >>>> Compute nodes are baremetal or virtualized?, I've seen similar bug >>>>>> reports when using nested virtualization in other OSes. >>>>>> >>>>> baremetal. Dell R630 if to be VERY precise. >>>> >>>> >>>> >>>>>> When using podman, the recommended way to restart containers is using >>>>> systemd: >>>>> >>>>> >>>>> https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deploym… >>>>> >>>> >>>> Thank you, I will try. I also modified a file, and it looked like it >>>> relaunched podman container once config was changed. Either way, if I >>>> understand Linux config correctly, the default value for user and group is >>>> root, if commented out: >>>> #user = "root" >>>> #group = "root" >>>> >>>> also in some logs, I saw, that it detected, that it is not AMD CPU :) >>>> and it is really not AMD CPU. >>>> >>>> >>>> Just for fun, it might be important, here is how my node info looks. >>>> ComputeS01Parameters: >>>> NovaReservedHostMemory: 16384 >>>> KernelArgs: "crashkernel=no rhgb" >>>> ComputeS01ExtraConfig: >>>> nova::cpu_allocation_ratio: 4.0 >>>> nova::compute::libvirt::rx_queue_size: 1024 >>>> nova::compute::libvirt::tx_queue_size: 1024 >>>> nova::compute::resume_guests_state_on_host_boot: true >>>> _______________________________________________ >>>> users mailing list >>>> users(a)lists.rdoproject.org >>>> http://lists.rdoproject.org/mailman/listinfo/users >>>> >>>> To unsubscribe: users-unsubscribe(a)lists.rdoproject.org >>>> >>> >> >> -- >> Ruslanas Gžibovskis >> +370 6030 7030 >> > > > -- > Ruslanas Gžibovskis > +370 6030 7030 >

4 10

[All][Neutron] Migrate old DB migration versions to init ops
by Rodolfo Alonso Hernandez 06 Jul '20

06 Jul '20

Hello all: Along this years we have increased the number of DB migrations each time we needed a new DB schema. This is good because that means the project is evolving and adding new features. Although this is not a problem per se, there are some inconvenients: - Every time a system is deployed (for example in the CI using devstack), the initial DB schema is created. Then, each migration is applied sequentially. - Some FT tests are still checking the sanity of some migrations [1] implemented a few releases ago. - We are still testing the contract DB migrations. Of course, this is something supported before and we still need to apply those revisions. - "TestWalkMigrationsMysql" and "TestModelsMigrationsMysql", both using MySQL backend, are still affected by LP#1687027. The proposal is to remove some DB migrations, starting from Liberty; of course, because all migrations must be applied in a specific order, we should begin from the initial revision, "kilo". The latest migration to be removed should be decided depending on the stable releases support. Apart from mitigating or solving some of the commented problems, we can "group" the DB model definition in one place. E.g.: "subnetpools" table is created in "other_extensions_init_ops". This file contains the first table. However is modified in at least two migrations: - 1b4c6e320f79_address_scope_support_in_subnetpool: added "address_scope_id" field - 13cfb89f881a_add_is_default_to_subnetpool: added "is_default" field Instead of having (at least) three places where the "subnetpools" DB schema is defined, we can remove the Mitaka migration and group this definition in just one place. One possible issue: some migrations add dependencies on other tables. That means the table the dependency is referring should be created in advance. That implies that, in some cases, the table creation order should be modified. That should never affect subsequent created tables or migrations. Do you see any inconvenience on this proposal? Am I missing something that I didn't consider? Thank you and regards. [1] https://github.com/openstack/neutron/blob/9fd60ffaac6b178de62dab169c826d52f…

4 6

[Telemetry] Propose Matthias Runge for Telemetry core
by Rong Zhu 03 Jul '20

03 Jul '20

Hello all, Matthias Runge have been very active in the repository with patches and reviews. So I would like to propose adding Matthias as core developer for the telemetry project. Please, feel free to add your votes into the thread. -- Thanks, Rong Zhu

3 3

[2020 Summit] Programming Committee Nominations Open
by Ashlee Ferguson 02 Jul '20

02 Jul '20

Programming Committee nominations for the 2020 Open Infrastructure Summit are open! Programming Committees for each Track will help build the Summit schedule, and are made up of individuals working in open infrastructure. Responsibilities include: • Help the Summit team put together the best possible content based on your subject matter expertise • Promote the individual Tracks within your networks • Review the submissions and Community voting results in your particular Track • Determine if there are any major content gaps in your Track, and if so, potentially solicit additional speakers directly to submit • Ensure diversity of speakers and companies represented in your Track • Avoid vendor sales pitches, focusing more on real-world user stories and technical, in-the-trenches experiences 2020 Summit Tracks: • 5G, NFV & Edge • AI, Machine Learning & HPC • CI/CD • Container Infrastructure • Getting Started • Hands-on Workshops • Open Development • Private & Hybrid Cloud • Public Cloud • Security If you’re interested in nominating yourself or someone else to be a member of the Summit Programming Committee for a specific Track, please fill out the nomination form[1]. Nominations will close on July 10, 2020. NOMINATION FORM[1] Programming Committee selections will occur before we open the Call for Presentations (CFP) to receive presentations so that the Committees can host office hours to consult on submissions, and help promote the event. The CFP will be open July 1 - August 4, 2020. Please email speakersupport(a)openstack.org with any questions or feedback. Cheers, Ashlee [1] https://openstackfoundation.formstack.com/forms/programmingcommitteenom_sum… Ashlee Ferguson Community & Events Coordinator OpenStack Foundation

1 1

[all][stable] Moving the stable/ocata to 'Unmaintained' phase and then EOL
by Ghanshyam Mann 02 Jul '20

02 Jul '20

Hello Everyone, Ocata is in the 'Extended Maintenance' phase[1] but its gate is broken and difficult to fix now. The main issue started for gate is about Tempest and its deps constraint is correctly used on Ocata or not. We fixed most of those issues when things started failing during py2 drop[2]. But now things are broken due to newer stestr is installed in Ocata jobs[2]. As Sean also mentioned in this backport[4] that stestr is not constraint in Ocata[5] as it was not in g-r that time so cannot be added in u-c. Tempest old tag cannot be fixed to have that with cap on the tempest side. The only option left to unblock the gate is to remove the integration testing from Ocata gate. But it will untested after that as we cannot say unit testing is enough to mark it tested. At least from QA perspective, I would not say it is tested if there is no integration job running there. Keeping it untested (no integration testing) and saying it is Maintained in the community can be very confusing things. I think its time to move it to the 'Unmaintained' phase and then EOL. Thought? [1] https://releases.openstack.org/ [2] https://review.opendev.org/#/q/topic:fix-stable-gate+(status:open+OR+status… [3] https://zuul.opendev.org/t/openstack/build/e477d0919ff14eea9cd8a6235ea00c3d… [4] https://review.opendev.org/#/c/726931/ [5] https://opendev.org/openstack/requirements/src/branch/stable/ocata/upper-co… -gmann

8 12

[tripleo][ci] status RED
by Wesley Hayutin 02 Jul '20

02 Jul '20

Greetings, Unfortunately both check and gate are RED atm due to [1]. The issue w/ CirrOS-5.1 was fixed / reverted over the weekend [2]. I expect the check and gate jobs to continue to be RED for the next few days as the investigation proceeds. I would encourage folks to only workflow patches that are critical as the chances you will actually merge anything is not great. [1] https://bugs.launchpad.net/tripleo/+bug/1885286 [2] https://review.opendev.org/#/c/738025/

1 2

[neutron][drivers] Propose Rodolfo Alonso Hernandez for Neutron drivers team
by Slawek Kaplonski 01 Jul '20

01 Jul '20

Hi, Rodolfo is very active Neutron contributor since long time. He has wide knowledge about all or almost all areas of the Neutron and Neutron stadium projects. He is an expert e.g. in ovs agent, pyroute and privsep module, openvswitch firewall, db layer, OVO and probably many others. He also has very good understanding about Neutron project in general, about it's design and direction of development. Rodolfo is also active on our drivers meetings already and I think that his feedback about many things there is very good and valuable for the team. For all these reasons I think that he will be great addition to our drivers team. I will keep this nomination open for a week waiting for Your feedback and votes. -- Slawek Kaplonski Senior software engineer Red Hat

6 6

[cinder] monthly video meeting poll
by Brian Rosmaita 30 Jun '20

30 Jun '20

https://rosmaita.wufoo.com/forms/monthly-video-meeting-proposal/ Please respond before 1200 UTC on Thursday 9 July. cheers, brian

1 0

[manila] IRC meeting this week has been canceled
by Goutham Pacha Ravi 30 Jun '20

30 Jun '20

Hello Zorillas, Per the conversation on freenode #openstack-manila, the next occurrence of the Manila community IRC meeting on Thursday, 2nd July 2020 has been cancelled as a number of the regular folks will be on vacation. Our next meeting will be on 9th July 2020 at 1500 UTC: https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting Please note that the specifications targeting the Victoria cycle must be submitted by 9th July 2020. Please pop into #openstack-manila if you have any concerns in the meantime. Thanks! Goutham

1 0

[all]OpenStack Saves the Day
by Apsey, Christopher 30 Jun '20

30 Jun '20

All, Ref: https://www.fifthdomain.com/dod/army/2020/06/25/pandemic-doesnt-slow-cyber-… The system referenced in the article was the one that I managed in my previous job and is an OpenStack/Ceph platform. It started as three servers that we took out of the trash and slapped on a desk in a classroom four years ago using MOS 8.0 and grew to hit ~20,000 cores and ~12PB of raw ceph storage a few months ago right before I left. We used a mix of UCA and RDO packages depending on the project as well as source compilation if needed. The system referenced in the article is a close fork of https://github.com/GeorgiaCyber/kinetic. Special thanks to the folks at Red Hat and Canonical as well as all the other companies and individual contributors that made that success possible. Everyone's contribution matters. Chris Apsey Director | Georgia Cyber Range GEORGIA CYBER CENTER 100 Grace Hopper Lane | Augusta, Georgia | 30901 https://www.gacybercenter.org

2 1

Re: [rdo-users] [rdo][ussuri][TripleO][nova][kvm] libvirt.libvirtError: internal error: process exited while connecting to monitor
by Ruslanas Gžibovskis 30 Jun '20

30 Jun '20

here are container logs, from compute and controller. https://drive.google.com/drive/folders/158HHigQmHAyg9NvXmiC45ztenFOCosUR?us…

2 2

[rdo][ussuri][TripleO][nova][kvm] libvirt.libvirtError: internal error: process exited while connecting to monitor
by Ruslanas Gžibovskis 30 Jun '20

30 Jun '20

Hi all. I have finally deployed Ussuri, it went quite good, except some my site specific issues and newton config files remake, but now I face issues when launching an instance. [4] Here are logs from compute: /var/log/containers/nova/nova-compute.log [5] from the controller - nova-conductor.log According to errors from compute, something is wrong with kvm? some older bugs refer to kvm exec permissions [2] a bit more recent [1] which refers to selinux issues, but I have setenforce 0 and tried to create instance, not much changed. Also, [3] very interesting kvm.conf file updates suggested, but I am not sure, how to restart service since config changed, as I am BRAND new to container concept with docker/podman, bit more used to uml :) so, how to reload service in container (when container is running as non-root user)? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1551651 # related to RHOSP7 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1091710 # 6 year old. [3] https://ask.openstack.org/en/question/95198/could-not-access-kvm-kernel-mod… [4] http://paste.openstack.org/show/pBVlVbaQGNuoRLHozHGO/ [5] http://paste.openstack.org/show/OqvozreN5aW4HRXM4g4p/ -- Ruslanas Gžibovskis +370 6030 7030

3 6

[neutron] QoS meeting - Tuesday 30.06.2020
by Rodolfo Alonso Hernandez 30 Jun '20

30 Jun '20

Hello: Because the meeting agenda is very short (and nothing urgent) and overlaps the OpenDev sessions, let's cancel today's meeting. Regards.

1 0

[kolla] Kolla klub meeting
by Mark Goddard 30 Jun '20

30 Jun '20

Hi, The next Kolla klub meeting is scheduled for Thursday at 15:00 UTC. We have the following topics on the agenda: * Gaël: Offline usage of Kolla & Kolla Ansible * Justinas: host OS lifecycle management * Mark: summary of the priorities agreed on for the Victoria cycle https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_… Thanks, Mark

1 0

[neutron] Team meeting - Tuesday 30.06.2020
by Slawek Kaplonski 30 Jun '20

30 Jun '20

Hi, Our today team meeting overlaps with opened event sessions [1] so lets cancel this meeting. See You all on the meeting next week. [1] https://www.openstack.org/events/opendev-2020/opendev-schedule — Slawek Kaplonski Senior software engineer Red Hat

1 0

[neutron] DVR / IPv6 on provider network instead?
by Eric K. Miller 30 Jun '20

30 Jun '20

Hi, Should I assume that the statement: "IPv6 traffic is not distributed, even when DVR is enabled. IPv6 routing does work, but all ingress/egress traffic must traverse through the centralized Controller node. Customers that are extensively using IPv6 routing are advised not to use DVR at this time." is still true in Stein and later (we are running Stein for now, which is why I explicitly mentioned this version)? If so, is there a possibility of using a provider network that is connected to all compute nodes where IPv6 subnets are issued to tenants from a subnet pool, with traffic being routed directly to an external router (not a Neutron router) using Linux Bridge instead of OVS? Yet, still use port security? Just trying to figure out the best way to support IPv6 without forwarding all traffic through a single network node, while using DVR for IPv4. Also, unrelated, but hopefully a quick question... is the "internal" or "external" label on a network just used for filtering lists, such as for "openstack network list --external"? or does it change the behavior of anything? Thanks! Eric

2 2

[neutron] Bug deputy - week of June 22nd
by Slawek Kaplonski 30 Jun '20

30 Jun '20

Hi, Below is my bug deputy summary. It was pretty busy week in Neutron regarding bugs. *High* https://bugs.launchpad.net/neutron/+bug/1885114 - job neutron-tempest-plugin-scenario-openvswitch-iptables_hybrid-ussuri may not be using ussuri Assigned Fixed: https://review.opendev.org/738169 https://bugs.launchpad.net/neutron/+bug/1884906 - L3 agent cannot be manually scheduled Assigned Fixed proposed: https://review.opendev.org/737736 https://bugs.launchpad.net/neutron/+bug/1884808 - [SSL] neutron-rpc-server: RecursionError: maximum recursion depth exceeded while calling a Python object Stable/rocky only, issue caused by old eventlet, Assigned Fix proposed: https://review.opendev.org/#/c/737651/ https://bugs.launchpad.net/neutron/+bug/1884708 - explicity_egress_direction prevents learning of local MACs and causes flooding of ingress packets Unnasigned, It seems that fixes https://bugs.launchpad.net/neutron/+bug/1732067 and https://bugs.launchpad.net/neutron/+bug/1866445 broke other scenarios, *We need someone to take a look into that one* *Medium* https://bugs.launchpad.net/neutron/+bug/1884986 - [OVN] functional test failing TestNBDbMonitorOverTcp test_floatingip_mac_bindings Marked as medium even if it's gate failure because it don't happens often, Assigned, Patch proposed: https://review.opendev.org/738415 https://bugs.launchpad.net/neutron/+bug/1884764 - Some overcloud nodes are missing in the ansible inventory file generated for migration to ML2OVN Assigned, Patches proposed: https://review.opendev.org/#/c/738212/ and https://review.opendev.org/#/c/738192/ https://bugs.launchpad.net/neutron/+bug/1884723 - [OVS] multicast between VM instances on different compute nodes is broken with IGMP snooping enabled Assigned, No patch proposed yet, https://bugs.launchpad.net/neutron/+bug/1884527 - Related dvr routers aren't created on compute nodes Regression introduced with fix for other bug, Assigned, Patch proposed: https://review.opendev.org/737286 *Low* https://bugs.launchpad.net/neutron/+bug/1885547 - [fullstack] OVS interface events isolation error with more than one OVS agent Assigned, Patch https://review.opendev.org/#/c/738446/ *Whishlist* https://bugs.launchpad.net/neutron/+bug/1885261 - Add stateless firewall support to OVS firewall Unassigned, https://bugs.launchpad.net/neutron/+bug/1885262 - Add stateless firewall support to OVN Unassigned, *Opinion* https://bugs.launchpad.net/neutron/+bug/1884504 - nova assume ports with vnic_type=direct-physical use the libvirt interface element when processing network-vif-deleted events *Incomplete* https://bugs.launchpad.net/neutron/+bug/1884532 - inconsistent data in ipamallocations I asked for some more info Would be good if someone who knows IPAM could take a look, *Older bugs which needs some attention* https://bugs.launchpad.net/neutron/+bug/1883321 - Neutron OpenvSwitch DVR - connection problem dvr issue to check by L3 team, https://bugs.launchpad.net/neutron/+bug/1671448 - [RFE] Neutron quota api should be configurable via policy.json — Slawek Kaplonski Senior software engineer Red Hat

1 0

[tc] weekly update
by Mohammed Naser 29 Jun '20

29 Jun '20

Hello everyone, Here’s an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in OpenStack/governance repository. # OPEN REVIEW - Add "tc:approved-release" tag to manila https://review.opendev.org/#/c/738105/ - Create starter-kit:kubernetes-in-virt tag https://review.opendev.org/#/c/736369/ - [draft] Add assert:supports-standalone https://review.opendev.org/#/c/722399/ - Add legacy repository validation https://review.opendev.org/#/c/737559/ # PROJECT UPDATES - Add deprecated cycle for deprecated deliverables https://review.opendev.org/#/c/737590/ - No longer track refstack repos in governance https://review.opendev.org/#/c/737962/ - Add Neutron Arista plugin charm to OpenStack charms https://review.opendev.org/#/c/737734/ - Retire puppet-congress https://review.opendev.org/#/c/737145/ # GOAL UPDATES - Update policy in code goal for glance https://review.opendev.org/#/c/738278/ # GENERAL CHANGES - Add storyboard link to migrate-to-focal goal https://review.opendev.org/#/c/738129/ - TC Guide Follow-Ups https://review.opendev.org/#/c/737650/ - Tools: update check-review-status to drop grace period https://review.opendev.org/#/c/736737/ - Remove grace period on resolutions https://review.opendev.org/#/c/735361/ Thanks all. -- Mohammed Naser VEXXHOST, Inc.

1 0

Delegating and routing an IPv6 prefix to an instance
by Christian Rohmann 29 Jun '20

29 Jun '20

Hello OpenStack-Discuss, I have a use case in which an instance / VM is hosting i.e. an OpenVPN gateway which shall be doing some routing / networking by itself. For that purpose one would like to have a global unique IPv6 prefix delegated and routed to it to, which it can in turn give out to its VPN clients. This can and should not be cut out of the on-link network that is provided by Neutron and used to connect the instance itself. If you look at https://community.openvpn.net/openvpn/wiki/IPv6, which has a section *Details: IPv6 routed block* explaining just how that is one intended approach on how to do it. I am now wondering if the existing DHCPv6 prefix delegation implemented in OpenStack is capable of providing a prefix to an instance. Digging a little into what can be found online I ran into this Etherpad doc https://etherpad.opendev.org/p/neutron-kilo-prefix-delegation (linked to on https://wiki.openstack.org/wiki/Neutron/IPv6/PrefixDelegation) There is a list of use-cases, the second one being exactly what I described above: > [...] > > Use cases: > > We need to allocate addresses to ports from an external or > providernetwork, and route them via Neutron routers. > > We wish to allocate whole prefixes to devices (and their specific > neutron port) on demand. A port must be authorised via the API for a > prefix. The prefix could be issued to the device via PD (since the > device has to discover the prefix it's been given). > > [...] But to my understanding the spec used to implement the current IPv6 networking and also prefix delegation mechanism, also mentioned this use case as an "limitation and future enhancement" - see: https://specs.openstack.org/openstack/neutron-specs/specs/liberty/ipv6-pref… Does anyone have any thoughts on this matter of dedicating a prefix and and routingits traffic to a VM, but not just a subnet? Regards Christian

4 8

[all][qa] devstack dropping python 2 support
by Ghanshyam Mann 29 Jun '20

29 Jun '20

Hello Everyone, Devstack has been default to python3 since ussuri release and Victoria cycle is time to drop the support of python2 completely. - https://review.opendev.org/#/c/737455/ Being ussuri as python3-only release and all grenade jobs has been migrated to python3 in ussuri, we are all good here but in case your project is still using the py2 jobs or replying on python2 support in devstack in any extend, do ping us on #openstack-qa channel. We will be keeping USE_PYTHON3 variable support till all consumer remove this, like storlets to adjust the requirement. NOTE: branchless repo keeping common jobs for master and stable branch gate with USE_PYTHON3=False need to keep setting this var for configuring the devstack with right python. For example, tempest-full job definition in tempest master. Such jobs should be run till stable/train only as ussuri onward we tests things on python3 only. -gmann

1 0

Monasca duplicate metrjcs
by junaid soomro 29 Jun '20

29 Jun '20

Hello everyone, I am new to this. my scenario is when i try to get io.read_bytes metric from monasca api it gives me more than one metrics of a singke hostname. Although device is different vda vdb etc. This is fine but when i remove the volume from the vm. Monasca api still sbows its metrics. Ideally it should remove the vdb because i removed it but it does not. why does this happen? Thank you

2 1

RE: [neutron] DVR / IPv6 on provider network instead?
by Eric K. Miller 29 Jun '20

29 Jun '20

> If so, is there a possibility of using a provider network that is connected to all compute nodes where IPv6 subnets are issued to tenants from a subnet pool, with traffic being routed directly to an external router (not a Neutron router) using Linux Bridge instead of OVS? Yet, still use port security? > Just trying to figure out the best way to support IPv6 without forwarding all traffic through a single network node, while using DVR for IPv4. I believe I have a solution, which works for IPv4, where public IP addresses are assigned to a VM's port without the use of floating IPs. I think this approach can work for IPv6, with an upstream DHCPv6 server. My IPv4 approach was to create an internal VLAN on our firewalls, where a public subnet is assigned (statically routed), and a gateway IP is assigned to the firewall. This VLAN is then assigned to a provider network. An OpenStack subnet is created on the provider network for the public subnet range with an allocation range associated with the IPs we want to hand out to VMs, with DHCP enabled. The subnet's gateway property is set to "None", along with DNS servers set, and a "host-route" is added for a default gateway, using our firewall's IP as the gateway. When a server is created on this network, an IP is allocated from the public subnet, the gateway is assigned to our firewall's IP, DNS is set correctly, and security groups work fine on the port. Best of all, traffic is sent/received from the host, not through the network node, so this is a reasonably scalable solution. Eric

1 0

[cyborg][nova] Support flexible use scenario for Mdev(such as vGPU)
by Feng, Shaohe 28 Jun '20

28 Jun '20

Hi all, Currently openstack support vGPU as follow: https://docs.openstack.org/nova/latest/admin/virtual-gpu.html In order to support it, admin should plan ahead and configure the vGPU before deployable as follow: https://docs.openstack.org/nova/latest/configuration/config.html#devices.en… This is very inconvenient for the administrator, this method has a limitation that a same PCI address does not provide two different types. Cyborg as an accelerator management tool is more suitable for mdev device management. One solution as follow： Firstly, we need a vender driver(this can be a plugin), it is used to discovery its special devices and report them to placement for schedule. The difference from the current implementation is that: 1. report the mdev_supported_types as traits to resource provider. How to discover a GPU type: $ ls /sys/class/mdev_bus/*/mdev_supported_types /sys/class/mdev_bus/0000:84:00.0/mdev_supported_types: nvidia-35 nvidia-36 nvidia-37 nvidia-38 nvidia-39 nvidia-40 nvidia-41 nvidia-42 nvidia-43 nvidia-44 nvidia-45 so here we report nvidia-3*, nvidia-4* as traits to resource provider. 2. Report the number of allocable resources instead of vGPU unit numbers to resource provider inventory Example for the NVidia V100 PCIe card (one GPU per board) : Virtual GPU Type Frame Buffer (Gbytes) Maximum vGPUs per GPU Maximum vGPUs per Board V100D-32Q 32 1 1 V100D-16Q 16 2 2 V100D-8Q 8 4 4 V100D-4Q 4 8 8 V100D-2Q 2 16 16 V100D-1Q 1 32 32 so here we report 32G Buffers(an example, maybe other resources) to resource provider inventory 3. driver should also support a function to create certain mdev type, such as (V100D-1Q, V100D-2Q,) Secondly, we need a mdev extend ARQ(it can be a plugin): Here is an example for fpga ext arq: https://review.opendev.org/#/c/681005/26/cyborg/objects/extarq/fpga_ext_arq… The difference is that, we replace the _do_programming to _do_create_mdev For _do_programming, it is used to create a new FPGA function. For _do_create_mdev, it is used to create a new type mdev, it will call the implementation function in vendor driver. At last we need to support a mdev handler for xml generation in nova, we can refer to the cyborg PCI handler in nova So after the above changes： Admin can create different SLA devices profiles such as: {“name”: “Gold_vGPU”, “groups”: [ {“resources:vGPU_BUFFERS”: “16”, “traits: V100D-16Q,”: “required”, }] } And {“name”: “Iron_vGPU”, “groups”: [ {“resources:vGPU_BUFFERS”: “1”, “traits: V100D-1Q,”: “required”, }] } Then a tenant can use Gold_vGPU to create with a VM with V100D-16Q vGPU And another tenant can use Iron_vGPU to create with a VM with V100D-1Q vGPU When ARQ binding during the VM creating, the Cyborg will call the vendor driver to create expected mdev vGPU. And these 2 mdev vGPU can be on same physical GPU card. The mdev extend ARQ and vendor driver can be plugin, they are loose couple with the upstream code. So the downstream can get the upstream code to customize the own mdev extend ARQ and vendor driver. Here vGPU is just an example, it can be other mdev devices. BR Shaohe Feng

3 11

RE: [neutron] DVR / IPv6 on provider network instead?
by Eric K. Miller 28 Jun '20

28 Jun '20

> Also, unrelated, but hopefully a quick question... is the "internal" or "external" label on a network just used for filtering lists, such as for "openstack network list --external"? or does it change the behavior of anything? Regarding my second question, I found some information that indicates --external will share the network with all projects. Whereas the --shared option is only used for sharing a network with a specified list of projects using RBAC rules. It also looks like networks marked as external, not internal, can be specified for the --external-gateway network when creating/updating a router. This has some good info too: https://superuser.openstack.org/articles/tenant-networks-vs-provider-networ… Eric

1 0

[ops][cinder] removal of brocade fczm driver
by Brian Rosmaita 27 Jun '20

27 Jun '20

Brocade no longer supports their cinder Fibre Channel Zone Manager driver [0]. It was marked 'unsupported' in Ussuri and deprecated for removal during the Victoria development cycle. (We just discovered this week that it is in fact unusable in Ussuri as it does not run in Python 3. It does pass all unit tests in Python 3, though.) Its removal will leave cinder with only one FCZM driver, so there has been some interest among Cinder project members in fixing the driver so it will at least run in Python 3.6 and 3.8. However, we don't know at the moment how much effort that will take. Further, without a third-party CI continually testing this driver, we cannot guarantee that once fixed, it will continue to function correctly. (No human can guarantee that any software of sufficient complexity functions correctly, but you know what I mean.) The point of this email is threefold: 1. If nobody is using the Brocade FCZM driver, then maybe we should just go ahead and remove it. So if you are using it, please let us know. 2. According to [0], for OpenStack users after Train, "Brocade encourages customers to perform SAN Zoning operations using other available tools or APIs." So if you are a Brocade user who has successfully configured another solution to replace the Brocade FCZM, the Cinder team (and the wider OpenStack community) would be interested in hearing about it. 3. If you are a consumer of the current cinder Brocade FCZM and are interested in its continued existence, the Cinder team would be interested in discussing with you how we could set up a third-party CI for it. As I said earlier, without the third-party CI, we really have no idea whether this thing works or not. I've already posted a patch to remove the Brocade FCZM driver [1]. (Just so you know we're serious about this.) At our R-16 mid-cycle meeting earlier this week, the Cinder team agreed to make a final decision at our next mid-cycle at week R-9. (Yes, we have two mid-cycles and neither is at the middle of the cycle -- we're already meeting in virtual space, so we also meet in virtual time.) So please communicate your thoughts to us before week R-9 by replying to this email on the mailing list. cheers, brian [0] https://docs.broadcom.com/doc/12397527 [1] https://review.opendev.org/#/c/738148/

1 0

[all][interop] Tasks completed and help for Interop Survey questions
by prakash RAMCHANDRAN 26 Jun '20

26 Jun '20

Hi all, It was bit odd to use meetpad instead of irc today, still need to understand how to share multiple screens or desktop on the meetpad.Any help is welcome as hat the procedure will be. Plus apology to Mark for late update on irc to meetpad. Weekly we will be using - (https://etherpad.opendev.org/p/interop) Interop Working Group - Weekly Friday 10-11 AM or UTC 17-18 Lnink: https://meetpad.opendev.org/Interop-WG-weekly-meeting But communication was really better than irc with chat plus verbal+video talk. How to add ircbot to meetpad any suggestions? Following is action Items to follow up. AI-01- GM to update/close? launchpad item - https://blueprints.launchpad.net/refstack/+spec/interop-2020.06With following two references to storyboard for all API guidelines for 2020.06.json.https://storyboard.openstack.org/#!/story/2007509https://story… AI-02 - Survey Questions please add what you seek for your projects? - https://storyboard.openstack.org/#!/story/2007511 6/26/2020 - AT todays Interop call it was decided to add following questions and is being circulated for updates via openstack-discuss list.level 1 Q &A1.Do you use OpenStack Marketplace data for your decision on use of OpenStack Cloud?2.Do you look at Interoperability reports available to you on different offerings in Marketplace portal?3. If you offer OpenStack Cloud do you use the OpenStack logo programs.?4. If you are using Object Storage for your cloud do you use Swift? What would you like to see improve in current Marketplace Logo Program?[1] Do you want to add Interop for kubernetes API conformance for OpenStack and Open Infrastructure Projects?[2] Do you want to add Interop for bare metal service?[3][4] (Add above your suggestions)level 2 Q&A1. Do you use data on add-on programs in the OpenStack Marketplace?1.1 If yes which ones? AI-03 - (for Core + Add-ons for OpenStack Integrated Projects) - Can you volunteer to add tag assert:supports-api-interoperability to your projects?Any comments on what Projects need to do to claim this based on 2020.06 - interop - https://opendev.org/osf/interop/src/branch/master/2020.06.json Can someone take a crack at documenting how to for one project like nova compute api does now? AI-04 - Seeking volunteers to maintain - Refstack - https://opendev.org/osf/refstack AI-05 - Can someone volunteer to present at next Interop meeting Friday 3rd at 17 UTC (10 AM PDT) - https://github.com/cncf/k8s-conformance Any Other suggestions for future events? ThanksInterop team: Prakash/Mark/Ghanshyam/Arkady

1 0

[openstack-discuss][airship-discuss][openstack-helm] Ceph Bluestore
by Roman Gorshunov 26 Jun '20

26 Jun '20

Hello Dominik, Thanks for the question. Please, let me redirect it to the OpenStack-Helm project mailing list, as Airship only consumes Ceph charts from openstack-helm-infra repository (previously from openstack-helm repo). Technically I see that ceph-osd in OpenStack-Helm supports Bluestore [0], so if you would want to deploy with Bluestore, you would need to change Armada documents (e.g. [1][2]) to use Bluestore. [0] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/ceph-o… <https://opendev.org/openstack/openstack-helm-infra/src/branch/master/ceph-o…> [1] https://opendev.org/airship/treasuremap/src/branch/master/site/seaworthy/so… <https://opendev.org/airship/treasuremap/src/branch/master/site/seaworthy/so…> [2] https://opendev.org/airship/treasuremap/src/branch/master/site/seaworthy/so… <https://opendev.org/airship/treasuremap/src/branch/master/site/seaworthy/so…> Best regards, Roman Gorshunov > On 25 Jun 2020, at 17:36, Dominik Bender <db(a)db-itsolutions.com> wrote: > > Hello everyone, > > I need some help with Ceph configuration. What changes need to be made in the charts to use bluestore? > In general I would still be interested in why bluestore is not yet standard in treasuremap? > > Thanks in advance > > -- > Dominik Bender > > > _______________________________________________ > Airship-discuss mailing list > Airship-discuss(a)lists.airshipit.org > http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss

1 0

OpenStack on CentOS 8 VM using packstack
by Pradeep Antil 26 Jun '20

26 Jun '20

Hi Techies, I am trying to deploy the latest Openstack "ussuri" on CentOS 8 VM using packstack. I have successfully installed it but the issue is that i want to i want to add my interface "enp0s3" to ovs bridge br-ex. On CentOS 7 we can do this via ifcfg-* files using network-scripts. But i am not sure how this can be done on CentOS 8 VM as in this release network is controlled via network manager. On br-ex i will attach an external provider network or a flat network. [image: image.png] I have referred the below steps for the deployment. dnf update -y dnf config-manager --enable PowerTools dnf install -y centos-release-openstack-ussuri dnf update -y dnf install -y openstack-packstack reboot packstack --gen-answer-file=/root/answer.txt Edit answer file CONFIG_NEUTRON_ML2_TYPE_DRIVERS=vxlan,flat CONFIG_NEUTRON_ML2_TENANT_NETWORK_TYPES=vxlan CONFIG_PROVISION_DEMO=n CONFIG_KEYSTONE_ADMIN_PW=P@ssw0rd packstack --answer-file=/root/answer.txt Following is the output of ovs command and interfaces on my centos 8 system [image: image.png] -- Best Regards Pradeep Kumar

2 1

[tc][networking-l2gw] Finish the retirement for networking-l2gw and networking-l2gw-tempest-plugin
by Ghanshyam Mann 26 Jun '20

26 Jun '20

Hello Everyone, networking-l2gw and networking-l2gw-tempest-plugin projects were retired in Ocata[1] but their retirement was not completed. I have started the retirement completion as discussed in TC and neutron team. - https://review.opendev.org/#/q/topic:complete-retirement-networking-l2gw+(s… Please let me know any injection to that. Their development can be continued under opendev as mentioned in this doc - https://governance.openstack.org/tc/reference/dropping-projects.html#contin… [1] https://review.opendev.org/#/c/392010/2 -gmann

5 9

[blazar] Broken CI
by Pierre Riteau 26 Jun '20

26 Jun '20

Hello, The blazar devstack CI jobs are currently failing due to issues related to uwsgi. logs/screen-blazar-a.txt shows: Jun 25 09:26:47.037179 ubuntu-bionic-limestone-regionone-0017387278 systemd[1]: Starting Devstack devstack(a)blazar-a.service... Jun 25 09:26:47.038997 ubuntu-bionic-limestone-regionone-0017387278 systemd[18254]: devstack(a)blazar-a.service: Failed to execute command: No such file or directory Jun 25 09:26:47.039047 ubuntu-bionic-limestone-regionone-0017387278 systemd[18254]: devstack(a)blazar-a.service: Failed at step EXEC spawning /usr/local/bin/uwsgi: No such file or directory Jun 25 09:26:47.039445 ubuntu-bionic-limestone-regionone-0017387278 systemd[1]: devstack(a)blazar-a.service: Main process exited, code=exited, status=203/EXEC Jun 25 09:26:47.039454 ubuntu-bionic-limestone-regionone-0017387278 systemd[1]: devstack(a)blazar-a.service: Failed with result 'exit-code'. Jun 25 09:26:47.039734 ubuntu-bionic-limestone-regionone-0017387278 systemd[1]: Failed to start Devstack devstack(a)blazar-a.service. I think it's our devstack plugin that needs fixing. In the meantime no need to recheck patches, they will keep failing until resolved. Pierre Riteau (priteau)

2 2

[all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal: Week R-16 Update
by Ghanshyam Mann 26 Jun '20

26 Jun '20

Hello Everyone, Please find the updates on Ubuntu Focal migration community goal. Tracking: https://storyboard.openstack.org/#!/story/2007865 Progress: ======= * devstack and tempest base patches are ready for testing on projects side. Thanks frickler for doing the base work. * neutron, nova project started the testing. Bugs: ==== 1. There is open bug for nova/cinder where three tempest tests are failing for volume detach operation. There is no clear root cause found yet -https://bugs.launchpad.net/cinder/+bug/1882521 We have skipped the tests in tempest base patch to proceed with the other projects testing but this is blocking things for the migration. 2. We encountered the nodeset name conflict with x/tobiko, i have proposed it to consume it form devstack -https://review.opendev.org/#/c/738128/ What work to be done on project side: ============================= This goal is more of testing the jobs on focal and fixing bugs if any otherwise migrate jobs by switching the nodeset to focal node sets defined in devstack. 1. Start a patch in your repo by making depends-on on either of below: devstack base patch if you are using only devstack base jobs not tempest: https://review.opendev.org/#/c/731207/ OR tempest base patch if you are using the tempest base job (like devstack-tempest): https://review.opendev.org/#/c/734700/ Example: https://review.opendev.org/#/c/738126/ 2. If none of your project jobs override the nodeset then above patch will be testing patch(do not merge) otherwise change the nodeset to focal. Example: https://review.opendev.org/#/c/737370/ 3. If the jobs are defined in branchless repo like tempest plugins then you need to override the branches variant to adjust the nodeset on jobs so that only Victoria onwards those jobs run on focal not old stable. Once we finish the testing on projects side and no failure then we will merge the devstack and tempest base patches. Important things to note: =================== * Do not forgot to add the story and task link to your patch so that we can track it smoothly. * Use gerrit topic 'migrate-to-focal' * Do not backport any of the patch. References: ========= Goal doc: https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-j… Storyboard tracking: https://storyboard.openstack.org/#!/story/2007865 -gmann

1 0

[tc] Monthly meeting
by Mohammed Naser 26 Jun '20

26 Jun '20

Hi everyone, Our monthly TC meeting is scheduled for next Thursday, July 2nd, at 1400 UTC. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, July 1st, at 1900 UTC. Thank you, Regards, Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[cinder] priorities for the next 2 weeks
by Brian Rosmaita 25 Jun '20

25 Jun '20

As mentioned at yesterday's virtual mid-cycle, our top priority right now is to get the milestone-1 items reviewed and re-reviewed. And the specs freeze is next week ... so our *two* top priorities are to get the milestone-1 items reviewed and also review specs. Here is a handy list: volume-local-cache - https://review.opendev.org/#/c/663549/ os-brick - https://review.opendev.org/#/c/700799/ cinder - https://review.opendev.org/#/c/715762/ tempest test case NFS encrypted volume support - https://review.opendev.org/#/c/597148/ brick gpg encryption support - https://review.opendev.org/#/c/709432/ new backend driver - Hitachi - https://review.opendev.org/#/c/712832/ specs: https://review.opendev.org/#/q/project:openstack/cinder-specs+status:open

1 0

[cinder] victoria mid-cycle part 1 summary available
by Brian Rosmaita 25 Jun '20

25 Jun '20

In case you missed yesterday's R-16 virtual mid-cycle session, I've posted a summary: https://wiki.openstack.org/wiki/CinderVictoriaMidCycleSummary It includes a link to the recording (in case you want to see what you missed or if you want to re-live the excitement). Part 2 of the mid-cycle will be held the week of R-9. cheers, brian

1 0

OSF Community Meeting 1 Recording & Slides
by Allison Price 25 Jun '20

25 Jun '20

Hi everyone, Thank you for joining today’s OSF Community Meeting. If you missed the meeting, you have a few options on getting updated on what was covered. You can listen to the recording [1] and check out the slides [2] that were presented this morning. I have also attached a PDF of the slides if that’s easier to access. There will be a second OSF Community Meeting covering the same material tomorrow, Friday, June 26 at 0200 UTC (today, June 25 at 7pm PT). You can find the lineup of speakers and dial-in information here [3]. Stay tuned for the next OSF Community Meeting in July that will cover the OpenStack 10th birthday, and the next all project, quarterly update that will be held in September. Cheers, Allison [1] https://zoom.us/rec/share/vJF_FqPgxGJJQ9bntR7vaqM7N7i_X6a81yQa8vtcxU06amK9p… <https://zoom.us/rec/share/vJF_FqPgxGJJQ9bntR7vaqM7N7i_X6a81yQa8vtcxU06amK9p…> Password: 7W!T*i74 [2] https://docs.google.com/presentation/d/16V82OIYfthb3fFlVoes9jZGKMgDIJZ55F8f… [3] https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2 <https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2> Allison Price OpenStack Foundation allison(a)openstack.org

1 0

Python OpenStack SDK does not return Hypervisor hostname
by Anil Jangam 25 Jun '20

25 Jun '20

I have written a client code as follows. # Get Hypervisor details try: print(f"+----------------------------------------------------------+") print(f"| Hypervisor details |") print(f"+----------------------------------------------------------+") for hypervisor in conn.list_hypervisors(): print(f"Hypervisor is: {hypervisor}") print(f"Hypervisor status: {hypervisor.status}") print(f"Hypervisor vcpus: {hypervisor.vcpus_used}") print(f"Hypervisor type: {hypervisor.hypervisor_type}") print(f"Hypervisor id: {hypervisor.id}") print(f"Hypervisor state: {hypervisor.state}") print(f"Hypervisor host IP: {hypervisor.host_ip}") print(f"Hypervisor running VMs: {hypervisor.running_vms}") print(f"Hypervisor running VMs: {hypervisor.vcpus}") print(f"Hypervisor hostname: {hypervisor.hypervisor_hostname}") print(f"") except EndpointNotFound as exp: print("Error: {}".format(exp)) print(f"") When I print the 'hypervisor' object itself, most of the values are printed as shown below, however when I try to access 'hypervisor.hypervisor_hostname', it throws an exception. +----------------------------------------------------------+ | Hypervisor details | +----------------------------------------------------------+ Hypervisor is: openstack.compute.v2.hypervisor.Hypervisor(status=enabled, service={'host': 'cl3-Compute3', 'disabled_reason': None, 'id': '34db399d-25b9-4004-98b9-2d8bbce7b228'}, vcpus_used=0, hypervisor_type=QEMU, local_gb_used=0, vcpus=52, hypervisor_hostname=cl3-Compute3, memory_mb_used=25600, memory_mb=262032, current_workload=0, state=up, host_ip=192.168.10.116, cpu_info={'arch': 'x86_64', 'model': 'Broadwell', 'vendor': 'Intel', 'features': ['pge', 'avx', 'xsaveopt', 'clflush', 'sep', 'rtm', 'tsc_adjust', 'tsc-deadline', 'dtes64', 'invpcid', 'tsc', 'fsgsbase', 'xsave', 'smap', 'vmx', 'erms', 'xtpr', 'cmov', 'hle', 'smep', 'pcid', 'est', 'pat', 'monitor', 'smx', 'pbe', 'lm', 'msr', 'adx', '3dnowprefetch', 'nx', 'fxsr', 'syscall', 'tm', 'sse4.1', 'pae', 'sse4.2', 'pclmuldq', 'acpi', 'fma', 'vme', 'popcnt', 'mmx', 'osxsave', 'cx8', 'mce', 'de', 'rdtscp', 'ht', 'dca', 'lahf_lm', 'abm', 'rdseed', 'pdcm', 'mca', 'pdpe1gb', 'apic', 'sse', 'f16c', 'pse', 'ds', 'invtsc', 'pni', 'tm2', 'avx2', 'aes', 'sse2', 'ss', 'ds_cpl', 'arat', 'bmi1', 'bmi2', 'ssse3', 'fpu', 'cx16', 'pse36', 'mtrr', 'movbe', 'rdrand', 'x2apic'], 'topology': {'cores': 14, 'cells': 2, 'threads': 2, 'sockets': 1}}, running_vms=0, free_disk_gb=852, hypervisor_version=2012000, disk_available_least=849, local_gb=852, free_ram_mb=236432, id=1130407d-5afd-41f9-bc0c-2d7babda3ce7, location=Munch({'cloud': 'defaults', 'region_name': 'RegionOne', 'zone': None, 'project': Munch({'id': '6d4f1b107bbf4b94832f7ef72df61ef2', 'name': '5g', 'domain_id': None, 'domain_name': 'default'})})) Hypervisor status: enabled Hypervisor vcpus: 0 Hypervisor type: QEMU Hypervisor id: 1130407d-5afd-41f9-bc0c-2d7babda3ce7 Hypervisor state: up Hypervisor host IP: 192.168.10.116 Hypervisor running VMs: 0 Hypervisor running VMs: 52 Traceback (most recent call last): File "/Users/workspace/testprogs/python/opsviz/ops_worker.py", line 321, in <module> main() File "/Users/workspace/testprogs/python/opsviz/ops_worker.py", line 317, in main print_servers() File "/Users/workspace/testprogs/python/opsviz/ops_worker.py", line 115, in print_servers print(f"Hypervisor hostname: {hypervisor.hypervisor_hostname}") File "/Users/inventory/lib/python3.7/site-packages/openstack/resource.py", line 588, in __getattribute__ raise e File "/Users/inventory/lib/python3.7/site-packages/openstack/resource.py", line 582, in __getattribute__ return object.__getattribute__(self, name) AttributeError: 'Hypervisor' object has no attribute 'hypervisor_hostname' Is there anything wrong with the use of the API? How do I get the hypervisor hostname in my application code? Thank you.

3 6

[kolla] Introducing Kolla Kalls
by Radosław Piliszek 25 Jun '20

25 Jun '20

Hi fellow OpenStackers! During yesterday's Kolla meeting [1] I have proposed to have more focused, voice-based sessions related to Kolla development, similarly to what we have for operators with Kolla Klub [1]. The immediate response was rather positive and the name Kolla Kalls has been coined. Since Kolla Klub is running every other Thursday at 15:00 UTC, we decided to use the alternate weeks slot for Kolla Kalls but this can change if need arises. Kolla Kalls got their wiki page already [3] where the agenda will be posted. The first Kall is scheduled on July 9, 15:00 UTC (i.e. in two weeks time from today). The agenda for the first Kall is mostly about trying this meeting approach out. The hottest topic from our PTG is the quality/completeness of our documentation so it is a good topic for our first few sessions. It is likely going to involve CI testing discussions as well. The platform has not been decided on yet. We plan to give OpenDev's Meetpad a test ride and fall back to Google Meet which we practiced well with Kolla Klub and similar events - if Jitsu breaks for us. I learnt Meetpad does not (yet) support recording but we plan to document the meeting in a text form anyhow so we should be fine. Everyone interested in developing Kolla projects, that is Kolla, Kolla-Ansible and/or Kayobe is welcome to join the Kalls. The Kalls will be development-oriented and focus on topics such as implementation discussion, change planning, release planning and housekeeping. [1] http://eavesdrop.openstack.org/meetings/kolla/2020/kolla.2020-06-24-15.01.h… [2] https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_… [3] https://wiki.openstack.org/wiki/Meetings/Kolla/Kall -yoctozepto

1 0

[neutron] Drivers meeting agenda - 26.06.2020
by Slawek Kaplonski 25 Jun '20

25 Jun '20

Hi Neutron drivers, Below is agenda for tomorrow’s meeting. We have 2 RFE to discuss: https://bugs.launchpad.net/neutron/+bug/1882804 - RFE: allow replacing the QoS policy of bound port This one is follow-up after virtual PTG and discussions with Nova team, https://bugs.launchpad.net/neutron/+bug/1828494 - L3 agent’s capacity lets discuss again this proposal with “routers_max” parameter instead of bandwidth (See last comment there) There is also proposed spec (https://review.opendev.org/#/c/729532/) for: https://bugs.launchpad.net/neutron/+bug/1880532 - [RFE]L3 Router should support ECMP Please review it if You can and we will get back to this RFE next week. Ok, that’s all for today. See You all tomorrow on the meeting. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[all][tc][stable][qa] Grenade testing for Extended Maintenance stable
by Ghanshyam Mann 25 Jun '20

25 Jun '20

Hello Everyone, As you know devstack (so does grenade) got broken due to uwsgi new release, the master branch is fixed and stable branches are in progress[1]. But It is hard to maintain or fix the EM stable for those issues. Especially the greande job which depends on the source branch (previous branch of one where the job is running). For example, for stein grenade job, we need to keep rocky branch working and fix if failure. Till now, we have not removed the grenade testing from any of the EM stable branches because they were running fine till now but with uwsgi issues, those are failing and need more work to fix. This triggers the discussion of grenade testing on EM stable branches. Usual policy for grenade testing is to keep the job running from the 'oldest supported stable +1' branch. For example, if stein is the oldest supported stable (in the old stable definition) then run grenade from train onwards. But with the Extended Maintainance model, defining 'oldest supported stable' is not clear whether it is the oldest non-EM(stein) or oldest EM stable(ocata). To make it clear, we discussed this in the QA channel and come up with the below proposal. * 'oldest' is the oldest non-EM. In current time, it is stein. * With the above 'oldest' definition, we will: ** Make grenade jobs as n-v on all EM stable branches (which is till stable/rocky as of today) + on stable/stein also because that is 'oldest' as of today. ** Keep supporting and running grenade job on 'oldest+1' which is stable/train onwards as of today. NOTE: we will make n-v when they start failing and anyone can volunteer to fix them and change back to voting. elod expressed interest to work on current failure. If no objection to the above proposal, I will document it on the grenade documents to follow it whenever we see EM failing and need more work. In Tempest, we already have the EM stable testing policy documented which is to support those till they run fine[2]. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015496.html [2] https://docs.openstack.org/tempest/latest/stable_branch_support_policy.html [3] http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2020… -gmann

5 5

[tripleo] Proposing Francesco Pantano as core on TripleO/Ceph
by Giulio Fidente 25 Jun '20

25 Jun '20

Hi all, Francesco (fmount on freenode) started working on the Ceph integration bits in TripleO more than a year ago now [1], contributing over time to all components, heat templates, validations, puppet and ansible repos. He understood the tight relationship in between TripleO and ceph-ansible and contributed directly to ceph-ansible as well, when necessary [2]. I think he'd be a great addition to the TripleO cores group and I hope for him to work more in the future even outside the Ceph integration efforts. I would like to propose Francesco core for the TripleO group on the Ceph bits. Please vote here or leave any feedback for him. Thanks, Giulio 1. https://review.opendev.org/#/q/owner:fpantano%2540redhat.com+status:merged 2. https://github.com/ceph/ceph-ansible/commits?author=fmount -- Giulio Fidente GPG KEY: 08D733BA

9 8

[neutron][tc][solum] Properly retire networking-onos, solum-infra-guestagent, openstack-ux
by Andreas Jaeger 25 Jun '20

25 Jun '20

These three repositories have been retired by their projects some time ago [1]: - openstack-ux: 2017-02-24 - networking-onos: 2016-11-01 - solum-infra-guestagent: 2016-11-24 They have no contribution and are still setup in Zuul, I'll retire them now following our retirement process [2] and thus remove them from Zuul. See [3] for changes, Andreas Links: [1] https://opendev.org/openstack/governance/src/branch/master/reference/legacy… [2] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-re… [3] https://review.opendev.org/#/q/topic:finish-retire -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

1 0

[neutron][dynamic-routing] Adding Jens Harbott and Tobias Urdin to neutron-dynamic-routing core team
by Slawek Kaplonski 25 Jun '20

25 Jun '20

Hi, Recently I asked for new maintainers for the neutron-dynamic-routing project. Tobias Urdin and Jens Harbott stepped in for that. So now I added them both to be core reviewers in the neutron-dynamic-routing project also. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[cinder] volume list query ("managing" statuses) spec
by Brian Rosmaita 25 Jun '20

25 Jun '20

The spec is https://review.opendev.org/#/c/726070/ I took the action item at today's virtual mid-cycle meeting to summarize the discussion on the review so that the spec can be revised. While doing that, I looked through the code carefully, and I think that the spec is actually on the right track, though there seem to be several bugs associated with this issue. In any case, I just left an enormous comment on the review. I need other reviewers to read through and comment/respond so that haixin and zhangbailin can get some consensus on how to revise the spec. thanks, brian

1 0

[cyborg] Cyborg IRC meeting cancelled this week
by yumeng bao 24 Jun '20

24 Jun '20

Hi all, Cyborg weekly meeting will be cancelled this week since most of the team members will be having the Dragon Boat Festival on Thursday. We will see you next week! Regards， Yumeng

1 0

[kolla] Victoria priorities
by Mark Goddard 24 Jun '20

24 Jun '20

Hi, Hot on the heels of the Ussuri release, we have the results of the votes for Victoria priorities. We voted in etherpad [1], and the results have been added to the whiteboard (L181). Feel free to add your name as an owner on the whiteboard if you would like to be involved. [1] https://etherpad.opendev.org/p/kolla-victoria-priorities Thanks, Mark = Kolla = Infra images (8 votes) https://blueprints.launchpad.net/kolla/+spec/infra-images Owners: Image tiering (6 votes) Avoid breakage of non-core images blocking publishing of all others Owners: Ubuntu focal 20.04 (6 votes) (likely must-have anyway unless we are dropping ubuntu) Owners: Stable branch life-cycle (6 votes) Use stable/<release> rather than versions Owners: Integrate support for pull-retag-push (4 votes) https://storyboard.openstack.org/#!/story/2007731 (original kayobe story) Owners: Kolla depends-on upstream projects to behave as it should (2 votes) Owners: Build, test, promote CI pipeline (2 votes) Build images, test them, promote for general availability Owners: = Kolla Ansible = Let's Encrypt integration - container running certbot, triggers certificate distribution (10 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/letsencrypt-https this would be useful to have for tls everywhere deployment too. Owners: headphoneJames Document, automate and test Octavia resource registration (10 votes) Owners: Document, automate and test Designate resource registration (8 votes) Also designate sink set up for instance dns Owners: yoctozepto Documentation review & refresh (8 votes) Owners: everyone Federated keystone (7 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/add-openid-support Owners: Container health checks (7 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/container-health-check mix with sanity checks? https://blueprints.launchpad.net/kolla-ansible/+spec/sanity-check-container Owners: mnasiadka Fix the "Ansible may run more handlers than originally planned" with all the extras around config (6 votes) https://bugs.launchpad.net/kolla-ansible/+bug/1863510 Owners: Improve test coverage (the never-ending story) (6 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/kolla-deployment-scena… Multiple regions Owners: Performance & scalability improvements (5 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/performance-improvemen… Owners: mgoddard Implement TLS Backend for all core services with externally exposed API (nova for example) (4 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/add-ssl-internal-netwo… Owners: headphoneJames TLS in other services: (4 votes) MariaDB https://blueprints.launchpad.net/kolla-ansible/+spec/mariadb-ssl-support RabbitMQ https://blueprints.launchpad.net/kolla-ansible/+spec/message-queue-ssl-supp… Memcached https://blueprints.launchpad.net/kolla-ansible/+spec/memcached-ssl-support Owners: Upgrade checkers (4 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/upgrade-checkers Owners: Node removal (decommission) (4 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/remove-node Mark has already done related work for CentOS 8 migration do more than destroy - clean them up! from databases etc. aligns with day-2 ops Owners: Support for reload (e.g. for TLS), also graceful shutdown (4 votes) Owners: Mechanism for distributing certificates to services after deployment (2 votes) Owners: Day 2 ops tools (restart containers, upgrade Docker, prune DBs…) (2 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/docker-upgrade-reconfi… Owners: Capture docker logs (2 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/capture-docker-logs Owners: Nova cells v2 - shared cell controllers, multiple DBs and MQs (0 votes) https://blueprints.launchpad.net/kolla-ansible/+spec/nova-cells-shared-cont… https://blueprints.launchpad.net/kolla-ansible/+spec/cellsv2-rabbitmq-suppo… Owners: = Kayobe = Document configuration walk through (7 votes) https://storyboard.openstack.org/#!/story/2004360 Owners: Support multiple environments from a single kayobe configuration (3 votes) https://storyboard.openstack.org/#!/story/2002009 Owners: priteau Support for multiple deploy image types on overcloud nodes (2 votes) https://storyboard.openstack.org/#!/story/2002098 Owners: Next generation discovery & network configuration (2 votes) https://storyboard.openstack.org/#!/story/2004295 https://github.com/markgoddard/kayobe-switch-config-poc Owners: Replace bifrost with kolla-ansible for seed services (2 votes) https://storyboard.openstack.org/#!/story/2004293 Owners: Easier customization of Kayobe commands (0 votes) https://storyboard.openstack.org/#!/story/2001663 Owners: jovial Command plan that tells you which playbooks will run / Fix dry run (0 votes) Pierre pointed out that -lt provides similar functionality, e.g kayobe overcloud host configure -lt Owners: Inventory exporter (0 votes) Owners:

1 0

[kolla] Ussuri releases available
by Mark Goddard 24 Jun '20

24 Jun '20

Hi, I'm pleased to announce the availability of the first Ussuri releases for all Kolla deliverables: * kolla 10.0.0 (https://docs.openstack.org/releasenotes/kolla/ussuri.html#relnotes-10-0-0-s…) * kolla-ansible 10.0.0 (https://docs.openstack.org/releasenotes/kolla-ansible/ussuri.html#relnotes-…) * kolla-cli 10.0.0 * kayobe 8.0.0 (https://docs.openstack.org/releasenotes/kayobe/ussuri.html#relnotes-8-0-0-s…) Thanks to everyone who contributed to these releases. Some things to note: * Support for CentOS 7 has been dropped. Train provides a migration path from CentOS 7 to 8 * Ceph deployment support and images have been dropped. External Ceph cluster integration should be used instead. * Support for Python 2 has been dropped. * This is the last planned release of kolla-cli. As usual with deprecations, please get in touch if you are able to help support this project. And now onto Victoria! Thanks, Mark

1 0

[largescale-sig] Next meeting: June 24, 8utc
by Thierry Carrez 24 Jun '20

24 Jun '20

Hi everyone, The Large Scale SIG will have a meeting this week on Wednesday, June 24 at 8 UTC[1] in the #openstack-meeting-3 channel on IRC: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200624T08 Feel free to add topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting A reminder of the TODOs we had from last meeting, in case you have time to make progress on them: - all to describe briefly how you solved metrics/billing in your deployment on https://etherpad.opendev.org/p/large-scale-sig-documentation - amorin to add some meat to the wiki page before we push the Nova doc patch further - ttx to solve merge conflict and push initial oslo.metrics code in from https://review.opendev.org/#/c/730753/ Talk to you all on Wednesday, -- Thierry Carrez

1 1

[Octavia] multi-arch Amphora
by Tony Breeds 24 Jun '20

24 Jun '20

Hello Octavia team! I have a somewhat obscure question for y'all about the "best way" to run an Amphora in an multi-arch OpenStack. I'm going to start with some level-setting assumptions, the describe my understanding so that if I'm wrong we can correct that before we get to the crux of my question(s) Assumptions ----------- - The build of all objects, amphora guest images etc etc is fine - The deployment of OpenStack is reasonably simple and defined. - An OpenStack that runs entirely on on CPU Architecture (aarch64, ppc64le, x86_64, etc) "works" Bottom line we don't need to care about how the 'bits' are built or installed just that they are :) My Understanding ---------------- When asked to create a loadbalancer. Octavia will spawn an instance (via Nova) running the image tagged in glance with $amp_image_tag[1,2]. This instances shoudl be scheduled closer to the ingress/egress of the network then the workload it's balancing. All communication between the Amphora and Octavia API is via REST (as opposed to RPC) and therefore we won't have any 'endianness/binary bugs' [3] The question(s) --------------- We have an OpenStack that has compute nodes running mixed architectures (aarch64, ppc64le, x86_64, etc) we can ensure that images run on the correct system (either with hw_architecture or aggregates). To make that work today we load an appropriately tagged image into glance and then the amphora just runs on type of system and it's all pretty easy. Can, should, we do better? - Does OVN/DVR alter the perfomance such that there *is* merit in scheduling the amphora closer to the workloads - Should we support multiple Amphora (one per architecture)? - If so should this be exposed to the user? openstack loadbalancer create \ --name lb1 --vip-subnet-id public-subnet \ --run-on aarch64 Yours Tony. [1] https://docs.openstack.org/octavia/latest/configuration/configref.html#cont… [2] There should be only one image tagged as such: https://opendev.org/openstack/octavia/src/branch/master/octavia/compute/dri… [3] https://www.youtube.com/watch?v=oBSuXP-1Tc0

2 1

[tc][uc] Status update: Uniting TC and UC
by Thierry Carrez 23 Jun '20

23 Jun '20

Hi everyone, A quick status update on that effort. The TC just merged a change[1] that will result in the TC and UC acting as a single body, starting on August 1st, 2020. The date was chosen so that the remaining UC members (Mohamed Elsakhawy and Jaesuk Anh) can finish their term. After that date, the UC mission will be taken over by the elected TC members, and from there on we'll have a single elected body, including developers, operators and end users of the OpenStack software, and inclusive of all types of contributions to the project. In August I'll work to merge the content on the UC governance site and the TC governance site. This will include adding a new file on openstack/governance to add and track voters corresponding to the AUC criteria. Those will be added to the electorate in time for the next round of elections in September. This simplification will make the OpenStack community more easily navigable, and further remove barriers between contributors with an operations background and contributors with a development background. For more information on the motivations behind that change, please read the original thread[2] proposing it. I'd like to personally thank the User Committee members for their support in that transition, and for all the work they accomplished for OpenStack in the past. [1] https://review.opendev.org/#/c/734074/ [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012806… -- Thierry Carrez (ttx)

2 1

[all][qa][gate] Gate Status: week 20-25
by Ghanshyam Mann 23 Jun '20

23 Jun '20

Hello Everyone, I am highlighting the few of the gate issues we fixed or in-progress last week 1. uwsgi bug: https://bugs.launchpad.net/devstack/+bug/1883468: Fixed till stable/stein Updates - http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015558.html 2. neutron-greande-multinode failure: In-progress greande base zuulv3 jobs are backported till train[1] which will be required to backport neutron-greande-multinode zuulv3 version. Ussuri backports are not yet merged which need more fixes on neutron CI[2]. Please wait for that backport to merge before recheck. 3. 'tox not found': https://bugs.launchpad.net/devstack/+bug/1884256: Fixed for known failure. This also started happening in many jobs. neutron and python-temepstconf jobs. devstack base integration jobs do not install tox (devstack functional base jobs does). If your job is derived from devstack integration base jobs and run test via tox env then you may need this to fix. NOTE: tempest jobs are all good as devstack's install_tempest() method do install tox for tempest tests run. Fix- https://review.opendev.org/#/c/737016/1 4. 'virtualenv not found': If this is happening on zuulv3 jobs then please refer the Ian's email[3]. if that is happening on legacy jobs then the recommendation is to migrate the jobs to zuulv3 like done for neutron-greande-multinode job. We are facing this issue on nova grenade as well as nova live migration jobs(legacy multinode jobs), there are multiple updates happened on devstack, grenade and image side, so I have reached the nova stable branch patches let's see what all still failing. 5. tempest sanity job failure for 'virualenv not found': Fixed The fix is merged and you can recheck your Tempest patches. Fixed: https://review.opendev.org/#/c/736952/5 6. To fixes all the all failure happening on EM stables, first step we are trying is to move the process-stackviz role from tempest to devstack so that we can apply the fixes for those stable in that role. If it stays in Tempest then fixes cannot be applied to old Tempest used for EM stable testing. More details in these patches[4] [1] https://review.opendev.org/#/q/topic:fix-grenade-multinode-train+(status:op… [2] https://review.opendev.org/#/c/735948/ [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015425.html [4] https://review.opendev.org/#/q/topic:move-stackviz-role+(status:open+OR+sta… -gmann

1 2

[nova][db][haproxy] Question
by Amjad Kotobi 23 Jun '20

23 Jun '20

Hi, In our control plane cluster which HA setup by - Pacemaker/Corosync - HAProxy When I’m moving virtual IP (VIP) to another node services - nova[api-scheduler-conductor] - cinder - etc… In all logs show ERROR nova.servicegroup.drivers.db DBConnectionError: (pymysql.err.OperationalError) (2003, "Can't connect to MySQL server on '10.60.1.220' ([Errno 111] ECONNREFUSED)") [SQL: u'SELECT 1’] And here is haproxy.cfg ########## global chroot /var/lib/haproxy daemon group haproxy maxconn 16000 pidfile /var/run/haproxy.pid user haproxy defaults log 127.0.0.1 local0 maxconn 16000 option redispatch retries 3 timeout http-request 10s timeout queue 1m timeout connect 10s timeout client 3600s timeout server 3600s timeout check 10s listen galera_cluster bind 10.60.1.220:3306 balance source server controller5 10.60.1.15:3306 check inter 2000 rise 2 fall 5 server controller6 10.60.1.16:3306 backup check inter 2000 rise 2 fall 5 server controller7 10.60.1.17:3306 backup check inter 2000 rise 2 fall 5 ########### I know it’s not service level problem or bug and causing by haproxy and mysql connection. I’m wondering if any experience or idea how to deal with it will be great

1 0

[dragonflow] Finish retiring project
by Sean McGinnis 23 Jun '20

23 Jun '20

This is a notice to make sure folks are aware. I plan on completing the retirement process for the dragonflow project. Dragonflow was removed from official governance in late 2018 with: https://review.opendev.org/#/c/613856/ While removed from governance, the project still had a few occasional contributors. Actual development had already tapered off, but really since removal from governance, activity has dwindled to the occasional gate or requirement related update, or random typo corrections. The last patches that have merged for this repo were in August 2019, and gate jobs have been broken for some time now with no one working on fixing them. This is to serve as an announcement of my intent to follow the retirement process to officially mark the project as retired and clean things up. Please respond here if there are an concerns about this plan. Sean

1 0

[neutron][neutron-dynamic-routing] Call for maintainers
by Slawek Kaplonski 23 Jun '20

23 Jun '20

Hi, During last, virtual PTG we discussed about health of neutron stadium projects (again). And it seems that neutron-dynamic-routing project is slowly going to be in similar state as neutron-fwaas in Ussuri. So there is basically no active maintainers of this project in our community. In Ussuri cycle there was Ryan Tidwell from SUSE who was taking care of this project but AFAIK he is not able to do that anymore in Victoria cycle. So, if You are using this project or are interested in it, please contact me by email or on IRC that You want to take care of it. Usually this don't means like a lot of work every day. But we need someone who we can ask for help e.g. when gate is broken or when there is some new bug reported and there is need to triage it. -- Slawek Kaplonski Senior software engineer Red Hat

6 10

[openstack-helm] Meeting Canceled - June 23rd 2020
by Gage Hugo 23 Jun '20

23 Jun '20

Hello, Today's meeting for OpenStack-Helm is cancelled. We will meet at the regular time next week.

1 0

[kuryr][kuryr-libnetwork]
by Michał Dulko 23 Jun '20

23 Jun '20

Hi, Due to shortage of kuryr-libnetwork core reviewers Hongbin proposed that we should soften the rules a bit and allow merging patches with just one +2. I'm totally fine with that, especially as the volume of changes showing up in the project is pretty small. If nobody will have anything against the idea, I'll just go on and update the docs later this week. Thanks, Michał

2 2

[tripleo] Stop using host's /run|/var/run inside containers
by Cédric Jeanneret 23 Jun '20

23 Jun '20

Hello all! While working on podman integration, especially the SELinux part of it, I was wondering why we kept using the host's /run (or its replicated /var/run) location inside containers. And I'm still wondering, 2 years later ;). Reasons: - from time to time, there are patches adding a ":z" flag to the run bind-mount. This breaks the system, since the host systemd can't write/access container_file_t SELinux context. Doing a relabeling might therefore prevent a service restart. - in order to keep things in a clean, understandable tree, getting a dedicated shared directory for the container's sockets makes sense, as it might make things easier to check (for instance, "is this or that service running in a container?") - if an operator runs a restorecon during runtime, it will break container services - mounting /run directly in the containers might expose unwanted sockets, such as DBus (this creates SELinux denials, and we're monkey-patching things and doing really ugly changes to prevent it). It's more than probable other unwanted shared sockets end in the containers, and it might expose the host at some point. Here again, from time to time we see new SELinux policies being added in order to solve the denials, and it creates big holes in the host security AFAIK, no *host* service is accessed by any container services, right? If so, could we imagine moving the shared /run to some other location on the host, such as /run/containers, or /container-run, or any other *dedicated* location we can manage as we want on a SELinux context? I would therefore get some feedback about this proposed change. For the containers, nothing should change: - they will get their /run populated with other containers sockets - they will NOT be able to access the host services at all. Thank you for your feedback, ideas and thoughts! Cheers, C. -- Cédric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/

2 3

[tc][election] campaign discussion: how TC can solve the less contributor issue?
by Ghanshyam Mann 23 Jun '20

23 Jun '20

This topic is a very important and critical area to solve in the OpenStack community. I personally feel and keep raising this issue wherever I get the opportunity. To develop or maintain any software, the very first thing we need is to have enough developer resources. Without enough developers (either open or closed source), none of the software can survive. OpenStack current situation on contributors is not the same as it was few years back. Almost every project is facing the less contributor issue as compare to requirements and incoming requests. Few projects already dead or going to be if we do not solve the less contributors issue now. I know, TC is not directly responsible to solve this issue but we should do something or at least find the way who can solve this. What do you think about what role TC can play to solve this? What platform or entity can be used by TC to raise this issue? or any new crazy Idea? -gmann

14 26

[Image-Encryption] current state
by Josephine Seifert 23 Jun '20

23 Jun '20

Hi from the image-encryption-popupteam, we would like to provide a summary of what happened during the last year: 1. Secret Consumers in Barbican [1] As a foundation for the image encryption - and to not accidentally delete a secret, which is still in use - the Barbican team implemented the secret consumers. Their is still some work ongoing for the API part. We will use this feature whenever a image will be encrypted. 2. Specs We wrote Specs to describe, what we Image Encryption is and how it would affect Glance, Cinder and Nova. The Cinder spec got merged [2] . The Glance spec is still being reviewed [3]. And the nova spec is abandoned [4]. Nova is currently not part anymore, because of a missing ephemeral storage encryption needed for a coherent security mode. 3. WIP-patches We implemented two WIP-patches to let Glance devs get a better idea of how image encryption is affecting Glance. We provided a patch for Glance [5] and one for os-brick [6], which handles the encryption and decryption of images. [1] https://review.opendev.org/#/q/project:openstack/barbican+secret-consumer [2] https://review.opendev.org/#/c/608663/ [3] https://review.opendev.org/#/c/609667/11 [4] https://review.opendev.org/#/c/608696/ [5] https://review.opendev.org/#/c/705445/ [6] https://review.opendev.org/#/c/709432/ We appreciate reviews on the spec and the WIP-patches. greetings Josephine (Luzi) & Markus (mhen)

2 1

Q2 Open Infrastructure Community Meetings - June 25th
by Sunny Cai 22 Jun '20

22 Jun '20

Hello everyone, The Q2 OSF Community meetings are only three days away! The project teams are holding two community meetings: one on Thursday, June 25th at 8am PT and another one on the same day at 7pm PT (June 26th at 10am Beijing Time). Here I have attached the calendar invites for the two community meetings. Join us: • Thursday, June 25 at 8am PT (1500 UTC) • Moderator • Jimmy McArthur, OSF • Presenters / Open for Questions • Airship: Alex Hughes • Kata Containers: Eric Ernst • OpenInfra Labs: Michael Daitzman • OpenStack: Ghanshyam Mann • OpenStack 10th birthday: Sunny Cai • StarlingX: Bruce Jones • Zuul: Monty Taylor • OpenInfra / OpenStack Days: Allison Price • Open Infrastructure Summit: Erin Disney • PTG: Kendall Waters • OpenDev: Ashlee Ferguson • Thursday, June 25 at 7pm PT (June 26th at at 0200 UTC/10am China Standard Time) • Moderator: • Sunny Cai, OSF • Presenters / Open for Questions • Airship: Alex Hughes • Kata Containers: Xu Wang • OpenInfra Labs: Michael Daitzman • OpenStack: Rico Lin • OpenStack 10th birthday: Sunny Cai • StarlingX: Yong Hu • Zuul: Clark Boylan • OpenInfra / OpenStack Days: Horace Li • Open Infrastructure Summit: Erin Disney • PTG: Kendall Waters • OpenDev: Ashlee Ferguson Zoom links for each meeting can be found in the calendar hold or here: https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2 <https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2> See you there! Sunny Cai OpenStack Foundation sunny(a)openstack.org <mailto:sunny@openstack.org>

1 0

[tc] weekly update
by Mohammed Naser 22 Jun '20

22 Jun '20

Hi everyone, Here’s an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. Kristi’s change has been open for quite sometime without much response, I’d like to ask for our TC members to please have a look at it. # OPEN REVIEW - [draft] Add assert:supports-standalone https://review.opendev.org/#/c/722399/ [open for 47 days] - Create starter-kit:kubernetes-in-virt tag https://review.opendev.org/#/c/736369/ # PROJECT UPDATES - Record deprecated cycle for deprecated project https://review.opendev.org/#/c/736084/ - Remove mox3 from governance https://review.opendev.org/#/c/736754/ - Deprecate neutron-fwaas and neutron-fwaas-dashboard master branch https://review.opendev.org/#/c/735828/ - Add openstack-ansible-os_adjutant repo https://review.opendev.org/#/c/736140/ - Retire Paunch https://review.opendev.org/#/c/734855/ - Retire swift-specs https://review.opendev.org/#/c/733901/ - Retire puppet-congress https://review.opendev.org/#/c/737145/ # PROJECTS RETIRED - Remove tricircle project team https://review.opendev.org/#/c/731566/ # GENERAL CHANGES - Remove grace period on resolutions https://review.opendev.org/#/c/735361/ - Tools: update check-review-status to drop grace period https://review.opendev.org/#/c/735361/ - Tools: fix check_review_status for new project-update https://review.opendev.org/#/c/735660/ - Update joining-tc.rst to be general tc-guide.rst https://review.opendev.org/#/c/735660/ - Assign TC Liasons for the Victoria Cycle https://review.opendev.org/#/c/735667/ - Add evrardjp liaison preferences https://review.opendev.org/#/c/735499/ - Add ricolin liaison preference https://review.opendev.org/#/c/735506/ - Add more clarification on project retirement process https://review.opendev.org/#/c/734648/ - Merging TC and UC into a single body https://review.opendev.org/#/c/734074/ # ABANDONED CHANGES - Document project removal and deprecation process https://review.opendev.org/#/c/734930/ Overall, I’m also pretty happy with our bandwidth at landing things with our relaxing governance rules. I'm going to look at more ways we can land more things quicker soon again Thanks, Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[neutron] netflow exports from open vswitch
by James Denton 22 Jun '20

22 Jun '20

Hello all, Has anyone here configured their Neutron-managed Open vSwitch to export netflow data to a collector? I’ve seen plenty of documentation on how to configure the export, but little-to-nothing regarding this configuration within the scope of an OpenStack cloud. Seems pretty straightforward, but we’re curious as to what the performance impacts might be and whether or not the configuration gets wiped or persists in the OVSDB. Thanks! James Denton

1 0

[neutron] subnet policy for ip allocation
by Ruslanas Gžibovskis 22 Jun '20

22 Jun '20

Hi team, I need that my IP addresses in subnet would not be allocated from the beginning, but it would go to the next IP compared to previous used: instance1 created: 1.1.1.1 Instance2 created: 1.1.1.2 instance1 deleted. instance2 deleted. Instance3 created: 1.1.1.3 (not 1.1.1.1 again) I remember have read about such, do not remember how to google it... -- Ruslanas Gžibovskis +370 6030 7030

2 2

[neutron] Bug deputy report (week starting on 2020-06-15)
by Bernard Cafarelli 22 Jun '20

22 Jun '20

Hello neutrinos, time for a new bug deputy rotation again, here is the list for week 25. Aside from the week highlights (aka multiple gate issues, see Ghanshyam's gate status recap mail), most reported bugs are underway except 1884067 <https://bugs.launchpad.net/neutron/+bug/1884067> (high, filtering issue) and 1884254 <https://bugs.launchpad.net/neutron/+bug/1884254> (low, potential dataplane issues) Critical * ovn based neutron gate jobs failing 100% of times - https://bugs.launchpad.net/neutron/+bug/1883601 OVS compilation failure with latest kernel, fixed in master https://review.opendev.org/735799 * 'tox' not present on devstack based jobs - https://bugs.launchpad.net/devstack/+bug/1884256 Fixed in master: https://review.opendev.org/737016/ High * [API] Filtering by fields not allowed to see is possible for regular users - https://bugs.launchpad.net/neutron/+bug/1884067 Unassigned * Adding a third DHCP agent to the network fails due to binding index error - https://bugs.launchpad.net/neutron/+bug/1883513 Probably introduced by https://review.opendev.org/288271/, fix in progress: https://review.opendev.org/735872 * [ovn] Agent liveness checks create too many writes into OVN db - https://bugs.launchpad.net/neutron/+bug/1883554 OVN Performance hit, fix merged: https://review.opendev.org/735618 * [SRIOV] SR-IOV agent need to have privsep configured - https://bugs.launchpad.net/neutron/+bug/1883757 Fix for SRIOV with macvtap, merged: https://review.opendev.org/735982 * [DHCP] IPv6 "addr6_list" change the "host" file format - https://bugs.launchpad.net/neutron/+bug/1884105 Fix merged: https://review.opendev.org/736778 Medium * [OVN] enable_distributed_floating_ip changes are not applied for existing NAT entries - https://bugs.launchpad.net/neutron/+bug/1883559 Fix in progress: https://review.opendev.org/735613 * Failed to create a duplicate DefaultSecurityGroup (with Calico plugin) - https://bugs.launchpad.net/neutron/+bug/1883730 Fix in progress: https://review.opendev.org/736842 Low * Restart of neutron-ovs-agent may cause data plane breakage - https://bugs.launchpad.net/neutron/+bug/1884254 Unassigned, can happen with rabbitmq connectivity issue * tc_lib (QoS; tc qdisc tbf) uses wrong value for byte/s conversion - https://bugs.launchpad.net/bugs/1884273 kbit/kibit issue, fix in progress: https://review.opendev.org/737044 Wishlist * Neutron should retry http connections when notifying e.g. nova - https://bugs.launchpad.net/neutron/+bug/1883712 Similar to a patch in nova (adding retries parameter to neutron client calls), fix in progress: https://review.opendev.org/736026 Invalid/incomplete * Subnet creation with gateway outside of CIDR is allowed - https://bugs.launchpad.net/neutron/+bug/1884009 As reminded by amotoki, this is intentional, discussed in https://bugs.launchpad.net/neutron/+bug/1335023 * Got unknown error when creating subnet without subnetpool - https://bugs.launchpad.net/python-neutronclient/+bug/1884334 Error missing in openstack CLI command, this was fixed some time ago -- Bernard Cafarelli

1 0

[all][qa] uWSGI release broke devstack jobs
by Andreas Jaeger 22 Jun '20

22 Jun '20

The new uWSGI 2.0.19 release changed packaging (filename and content) and thus broke devstack. The QA team is currently fixing this, changes need backporting to fix grenade as well. On master, change [1] was merged to use distro packages for Ubuntu and Fedora instead of installation from source for uWSGI. CentOS and openSUSE installation is not fixed yet ([2] proposed for openSUSE). Thus, right now this should work again: * Fedora and Ubuntu the devstack jobs on master Other distributions and branches and grenade are still broken. Please do NOT recheck until all fixes are in. If you want to help, best reach out on #openstack-qa. Thanks especially to Jens Harbott for driving this! Andreas [1] https://review.opendev.org/577955 [2] https://review.opendev.org/735519 -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

3 3

[tripleo] CI is red
by Wesley Hayutin 20 Jun '20

20 Jun '20

Greetings, It's a been a week that started w/ CentOS mirror outage [0], followed by breaking changes caused by CentOS-8.2 [.5] and has not improved much since. The mirror issues are resolved, the updates required for CentOS-8.2 have been made here's the latest issue causing your gate jobs to fail. tripleo-common and python-tripleoclient became out of sync and started to fail unit tests. You can see this in the dlrn builds of your changes. [1] There was also a promotion to train [2] today and we noticed that mirrors were failing on container pulls for a bit (train only). This should resolve over time as the mirrors refresh themselves. Usually the mirrors handle the promotion more elegantly. CI status is updated in the $topic in #tripleo. I update the $topic as needed. Tomorrow is another day.. [0] https://bugs.launchpad.net/tripleo/+bug/1883430 [.5] https://bugs.launchpad.net/tripleo/+bug/1883937 [1] https://bugs.launchpad.net/tripleo/+bug/1884138 http://dashboard-ci.tripleo.org/d/wb8HBhrWk/cockpit?orgId=1&var-launchpad_t… http://status.openstack.org/elastic-recheck/ http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:… https://6f2b36b80678b13e4394-1a783ef91f61ec7475bcc10015912dcc.ssl.cf2.rackc… [2] https://trunk.rdoproject.org/centos7-train/

1 3

Re: Switching the Interop meeting from irc to meetpad + next week Friday 26 UTC 17 - agenda
by prakash RAMCHANDRAN 19 Jun '20

19 Jun '20

Hi all, The irc was unkind to us and cancelled today's meeting of #openstack-interop. Appreciate for your considerations - lets go back and revive meetpad from next week and we will be better off as with less than 30 people this option will be better than either zoom or irc, as we do have an "Interop-WG-weekly-meeting" established. https://meetpad.opendev.org/Interop-WG-weekly-meeting or (https://meetpad.opendev.org) After click join by entering - Interop-WG-weekly-meeting - courtesy - Kendall [extra benefit of including etherpad integration (the videoconference doubles as an etherpad document, avoiding jumping between windows).] Agenda for next Friday 26th June 17 UTC / 10 PDT call on meetpad: (If you can solve through email do answer back) (Please update if you need changes - https://etherpad.opendev.org/p/interop) 1.Interop Ussusri Guidelines established - documented the details in here and merged. https://storyboard.openstack.org/#!/story/2007510 https://storyboard.openstack.org/#!/story/2007509 2. To supersede or abandon this.https://blueprints.launchpad.net/refstack/+spec/interop-2020.06 - Ghanshyam or Mark - please confirm 3. Marketplace participants Regards to Survey questions - https://storyboard.openstack.org/#!/story/2007511 4. The Content & Procedure of Survey to be identified and agreed - How to send message to Vendors , Distro's, Hosting Partners and other Marketplace participants to test for Logo updates for 2020.06 Ussuri cycle - Consistency in meeting times on irc and websites - Update site for logo - https://www.openstack.org/brand/interop/ - update site for irc meeting time - https://refstack.openstack.org/#/about#about 5. Implementing updates to project governance - https://opendev.org/openstack/governance/src/branch/master/reference/projec… to enable tag assert:supports-api-interoperability (for Core + Add-ons for Integrated Projects) - tags: - - tc:approved-release - - starter-kit:compute - - vulnerability:managed - - assert:follows-standard-deprecation - - assert:supports-upgrade - - assert:supports-rolling-upgrade - - assert:supports-accessible-upgrade - - stable:follows-policy - - assert:supports-api-interoperability 6. Ideas for new logo programs to propose to Board working with TC- Any legal disclaimers or change required - Conformance or validation vs. compliance?- Revising Object Storage Logo for Swift Compliance (For paid partners)- Bare Metal Ironic- Container Projects - Airship Cloud to StarlingX Edge Interop,- kubernetes Conformance for OpenStack & Opne Infra Projects. Chair / Interop WG (Prakash Ramchandran)Co-Chairs (Mark V.Voelker & Ghanshyam Maan) Platinum Partner Rep. from Board (Arkady Kanevsky) On Friday, June 19, 2020, 10:27:16 AM PDT, prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote: Hi, All I tried to get into irc and its way slow and not sure what nic registration and are access issues are for irc.Either you would have started the meeting and continued on the topics listed in agenda or I assume its cancelled. We will regroup next week but looks like again coming back to only zoom as option and so will setup with either Openstack Staff or go back to Dell Zoom as my only option. My apology, all botched up on communication for last 4 weeks with no real verbal communications. It has been a challenge for me, previous StarlingX vs Airship meeting went off well but this happened, not sure why and still tring to track irc issues. Thanks Prakash

1 0

[tripleo] TripleO CI Summary: Unified Sprint 28
by Rafael Folco 19 Jun '20

19 Jun '20

Greetings, The TripleO CI team has just completed **Unified Sprint 28** (May 28 thru June 17). The following is a summary of completed work during this sprint cycle [1]: - Built internal component and integration pipelines by adding more baremetal and scenario jobs. OVB against PSI still in progress. - Continued to fix promoter tests on CentOS8. - Built an internal promoter server for the internal pipeline promotions. - Added TripleO IPA multinode job to integration pipeline in master, ussuri, and now train - Built CentOS8 train jobs upstream and created the CentOS8 version of promotion pipeline for train release. Still in progress, now based on a componentized DLRN - Tempest skip list and ironic plugin general improvements. - 3rd party dependency jobs for ceph-ansible. - Github pull request zuul jobs e.g. https://review.rdoproject.org/zuul/buildset/5aadebee715d49fc9f030b455a8d8f71 - Build ansible 2.9, ceph-ansible 2.4 - Execute against tripleo master, ussuri, train. - Ruck/Rover recorded notes [2]. The planned work for the next sprint [3] extends the work started in the previous sprint and focuses on creating CentOS8 jobs for train release. The Ruck and Rover for this sprint are Sagi Shnaidman (sshnaidm), Soniya Vyas (soniya29) and Ronelle Landy (rlandy). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes to be tracked in etherpad [4]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-28 [2] https://hackmd.io/YAqFJrKMThGghTW4P2tabA [3] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-29 [4] https://hackmd.io/XcuH2OIVTMiuxyrqSF6ocw

1 0

[kolla] Re: [Release-job-failures] Release of openstack/kolla for ref refs/tags/9.1.1 failed
by Sean McGinnis 19 Jun '20

19 Jun '20

On 6/19/20 5:45 AM, zuul(a)openstack.org wrote: > Build failed. > > - openstack-upload-github-mirror https://zuul.opendev.org/t/openstack/build/3bb83ca0c7344c7cac47d912a724ea07 : SUCCESS in 1m 03s > - release-openstack-python https://zuul.opendev.org/t/openstack/build/a54166b5f31340b1bdb6f28e4b4a8e61 : SUCCESS in 5m 22s > - announce-release https://zuul.opendev.org/t/openstack/build/5cee678de9b447428ca26b8b3ffd6ee7 : SUCCESS in 4m 07s > - propose-update-constraints https://zuul.opendev.org/t/openstack/build/fb96f3ad6edd43d7a611377542db95bc : SUCCESS in 3m 22s > - kolla-publish-centos-source https://zuul.opendev.org/t/openstack/build/9c7921b0b4a64641974ae616b27f03dc : RETRY_LIMIT in 3m 18s > - kolla-publish-centos-binary https://zuul.opendev.org/t/openstack/build/0388a788ca8a48949c20f48c60b2b7ba : RETRY_LIMIT in 2m 42s (non-voting) > - kolla-publish-centos8-source https://zuul.opendev.org/t/openstack/build/eac8ad3447bc49c1b3d306bffd7f905d : RETRY_LIMIT in 3m 14s > - kolla-publish-centos8-binary https://zuul.opendev.org/t/openstack/build/e68f3f687d3c452c823017a355049f5d : RETRY_LIMIT in 5m 04s (non-voting) > - kolla-publish-debian-source https://zuul.opendev.org/t/openstack/build/4c5a39b30f834bd597b167208c8cf322 : RETRY_LIMIT in 2m 51s (non-voting) > - kolla-publish-debian-source-aarch64 https://zuul.opendev.org/t/openstack/build/None : NODE_FAILURE in 0s (non-voting) > - kolla-publish-debian-binary https://zuul.opendev.org/t/openstack/build/144b9b8109804f8daa23bca8cc4a41d6 : RETRY_LIMIT in 2m 36s (non-voting) > - kolla-publish-ubuntu-source https://zuul.opendev.org/t/openstack/build/23f44f0a4ccb484c81abc76d0a7627d7 : RETRY_LIMIT in 3m 52s > - kolla-publish-ubuntu-binary https://zuul.opendev.org/t/openstack/build/a2ba0db9d974424f9f8424fef14d8e38 : RETRY_LIMIT in 3m 29s (non-voting) I haven't looks at all of these, but it looks like these kolla jobs need to be updated to have the ensure_pip role added like we've had to do for some of the other release jobs. My guess would be ensure_pip needs to be added somewhere like here: https://opendev.org/openstack/kolla/src/branch/master/tests/playbooks/pre.y… But I think someone from that team will need to look into that. Sean

3 2

[kolla] Kolla Klub meeting
by Mark Goddard 19 Jun '20

19 Jun '20

Hi, The next Kolla klub meeting is scheduled for Thursday at 15:00 UTC. We'll have a summary of the recent PTG discussions and some open discussion. Please bring ideas for discussion topics! https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_… Thanks, Mark

1 1

[nova][oslo][rabbitmq][compute]
by Amjad Kotobi 19 Jun '20

19 Jun '20

Hi all, After trying to upgrade last piece of release Stein to Train which were all “python-oslo*” & “python2-oslo*” packages along with some others, nova computes status changed to “DOWN”, and from nova-compute.log below logs ERROR oslo.messaging._drivers.impl_rabbit [req-de95c598-8e72-46ad-aba6-1b26893ccad7 - - - - -] [739dc403-021e-4bba-a31a-3d86f3d7a908] AMQP server on controller5:5672 is unreachable: Server unexpectedly closed connection. Trying again in 1 seconds.: IOError: Server unexpectedly closed connection 2020-06-19 17:40:20.681 5518 INFO oslo.messaging._drivers.impl_rabbit [req-de95c598-8e72-46ad-aba6-1b26893ccad7 - - - - -] [739dc403-021e-4bba-a31a-3d86f3d7a908] Reconnected to AMQP server on controller5:5672 via [amqp] client with port 32894 This happened every two minutes or so. Connection between rabbitmq servers all looks fine and tested on port accessibility. Logs in rabbitmq got really nasty and after downgrading below packages(downgrade to Stein) all got to normal ############################# openvswitch.x86_64 python-openvswitch.x86_64 python-pycadf-common.noarch python2-automaton.noarch python2-barbicanclient.noarch python2-castellan.noarch python2-cliff.noarch python2-debtcollector.noarch python2-django-horizon.noarch python2-etcd3gw.noarch python2-eventlet.noarch python2-futurist.noarch python2-kombu.noarch python2-os-brick.noarch python2-os-client-config.noarch python2-os-ken.noarch python2-os-vif.noarch python2-os-win.noarch python2-osprofiler.noarch python2-ovsdbapp.noarch python2-pycadf.noarch python2-qpid-proton.x86_64 python2-simplejson.x86_64 python2-stevedore.noarch python2-swiftclient.noarch python2-taskflow.noarch python2-tenacity.noarch python2-tooz.noarch qpid-proton-c.x86_64 ########################## I’m not sure completely but suspecting in “kombu”. Also after rabbitmq got in high load and high ratio of failure “cinder” services got to DOWN too. Any idea will be great, thanks

1 0

[Neutron] Drivers meeting agenda - 19.06.2020
by Slawek Kaplonski 19 Jun '20

19 Jun '20

Hi, Here is the agenda for tomorrows drivers meeting. I want to discuss few RFEs there: - https://bugs.launchpad.net/neutron/+bug/1880532 - L3 Router should support ECMP - this is continuation of the discussion from previous meeting. There is also spec proposed for that one https://review.opendev.org/#/c/729532/ - https://bugs.launchpad.net/neutron/+bug/1751040 - Extended resources should not always calculate all attributes - old RFE but we should discuss that finally, - https://bugs.launchpad.net/neutron/+bug/1882804 - allow replacing the QoS policy of bound port - this one is follow up after nova-neutron discussion during the PTG. TBH I don't think we will need a lot of discussion about that but still it needs an approval. There are also 2 items in "On demand agenda": - (ralonsoh) [RFE] Optional NUMA affinity for neutron ports (commented in the PTG and scheduled to be commented here before). BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1791834. No LP or BP created, this is just to present and discuss the idea of **using or not the QoS API** for this RFE. - (slaweq) We are deprecating neutron-fwaas. What with the API-REF? It's question from the ML http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015508.html As agenda is pretty busy, I would like to start with On Demand agenda tomorrow and then continue with RFEs according to how much time we will have. See You on the meeting tomorrow. -- Slawek Kaplonski Senior software engineer Red Hat

2 2

[neutron][fwaas] Removal of neutron-fwaas projects from the neutron stadium
by Slawek Kaplonski 19 Jun '20

19 Jun '20

Hi, In Shanghai PTG we agreed that due to lack of maintainers of neutron-fwaas project we are going to deprecate it in neutron stadium in Ussuri cycle. Since then we asked couple of times about volunteers who would like to maintain this project but unfortunatelly there is still lack of such maintainers. So now, as we are already in Victoria cycle, I just proposed serie of patches [1] to remove master branch of neutron-fwaas and neutron-fwaas-dashboard from the neutron stadium. Stable branches will be still there and can be maintained but there will be no any code in master branch and there will be no new releases of those 2 projects in Victoria. If You are using this project and wants to maintain it, You can respin it in x/ namespace if needed. Feel free to ping me on IRC (slaweq) or by email if You would have any questions about that. [1] https://review.opendev.org/#/q/topic:retire-neutron-fwaas+(status:open+OR+s… -- Slawek Kaplonski Senior software engineer Red Hat

3 3

[release] Release countdown for week R-16, Jun 22 - Jun 26
by Sean McGinnis 19 Jun '20

19 Jun '20

Development Focus ----------------- We are now past the victoria-1 milestone. Teams should now be focused on feature development and completion of release cycle goals [0]. [0] https://governance.openstack.org/tc/goals/selected/victoria/index.html General Information ------------------- Our next milestone in this development cycle will be victoria-2, on July 30. This milestone is when we freeze the list of deliverables that will be included in the Victoria final release, so if you plan to introduce new deliverables in this release, please propose a change to add an empty deliverable file in the deliverables/victoria directory of the openstack/releases repository. Now is also generally a good time to look at bugfixes that were introduced in the master branch that might make sense to be backported and released in a stable release. If you have any question around the OpenStack release process, feel free to ask on this mailing-list or on the #openstack-release channel on IRC. Upcoming Deadlines & Dates -------------------------- Victoria-2 milestone: July 30 Ussuri cycle-trailing deadline: August 13

1 0

Re: [Release-job-failures] Release of openstack/puppet-nova for ref refs/tags/15.6.0 failed
by Thierry Carrez 19 Jun '20

19 Jun '20

zuul(a)openstack.org wrote: > Build failed. > > - openstack-upload-github-mirror https://zuul.opendev.org/t/openstack/build/fd8c86f9b57947239bd0273424e1d4d5 : FAILURE in 2m 30s > - release-openstack-puppet https://zuul.opendev.org/t/openstack/build/05dd9c7ffdc74af5ae4065eb16a522f9 : SUCCESS in 5m 40s > - announce-release https://zuul.opendev.org/t/openstack/build/188851ebacf9455ab50edc2101ae02bc : SUCCESS in 5m 31s Github mirroring failure as a concurrent mirror operation already synced that tag up. Can be safely ignored. -- Thierry Carrez (ttx)

1 0

[all][InteropWG] Request to review tests your Distro for 2020.06 draft guidelines
by prakash RAMCHANDRAN 19 Jun '20

19 Jun '20

Hi all, Please review your tests for Draft 2020.06 guidelines to be proposed to Board.You can do that on and should start appearing in next 24-48 hours depending on Zuulhttps://refstack.openstack.org/#/community_results Plus please register for InteropWG PTG meet on June 1 st 6AM-*AM PDT slot See etherpadsPTG eventhttps://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_2020S… invite Tempest, TC members, QA/API SIG teams, Edge SIG WG , Baremetal SIG (for Ironic), K8s SIG (for OoK / KoO) & Scientific SIG teams. Other discussions https://etherpad.opendev.org/p/interop2020 Welcome to join weekly Friday Meetings (Refer NA/EU/APJ in etherpad below) https://etherpad.opendev.org/p/interop Appreciate all support from committee and special appreciation to Mark T Voelker for providing the bridge.He has been immensely valuable in bringing as Vice Chair the wealth of history to enable this Interop WG. ThanksPrakash

2 3

[cinder] impending SPECS FREEZE
by Brian Rosmaita 19 Jun '20

19 Jun '20

To all people with unmerged proposed Cinder specs: The spec freeze is less than 2 weeks away (Wed 1 July at 23:59 UTC). If you have questions or want live discussion of issues, take advantage of next week's Cinder virtual mid-cycle: DATE: 24 JUNE 2020 TIME: 1400-1600 UTC LOCATION: https://bluejeans.com/3228528973 Add your spec to the list of topics: https://etherpad.opendev.org/p/cinder-victoria-mid-cycles All proposed specs were discussed at the Victoria Virtual Midcycle; see the PTG etherpad for comments about yours: https://etherpad.opendev.org/p/victoria-ptg-cinder Additionally, the etherpad has links to recordings of the discussions. cheers, brian

1 0

[OSSN-0086] erratum: Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
by Brian Rosmaita 19 Jun '20

19 Jun '20

As you may recall, the fix for this issue required patches for both Cinder and the os-brick library. The original patch for os-brick contained a flaw [0] that prevented the scaleio connector from operating when run under Python 2.7. Thus for OpenStack releases supporting Python 2.7 (that is, Train and earlier), a second os-brick patch is required and is listed below. (The Cinder and first os-brick patch are unchanged, but are listed below for completeness). [0] https://bugs.launchpad.net/os-brick/+bug/1883654 #### Patches #### Queens * cinder: https://review.opendev.org/733110 * os-brick: https://review.opendev.org/733104 and https://review.opendev.org/736749 Rocky * cinder: https://review.opendev.org/733109 * os-brick: https://review.opendev.org/733103 and https://review.opendev.org/736415 Stein * cinder: https://review.opendev.org/733108 * os-brick: https://review.opendev.org/733102 and https://review.opendev.org/736395 Train * cinder: https://review.opendev.org/733107 * os-brick: https://review.opendev.org/733100 and https://review.opendev.org/735989 Updated releases of os-brick incorporating the second patch are now available: Stein: os-brick 2.8.6 Train: os-brick 2.10.4 Point releases of cinder for Stein and Train will be made as soon as possible. These will be: Stein: cinder 14.1.1, requires os-brick 2.8.6 Train: cinder 15.2.1, requires os-brick 2.10.4 ### Contacts / References ### Author: Brian Rosmaita, Red Hat OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0086 Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1823200 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg CVE: CVE-2020-10755

1 0

Re: [Release-job-failures] Release of openstack/puppet-nova for ref refs/tags/15.6.0 failed
by Emilien Macchi 18 Jun '20

18 Jun '20

Interesting. The tag was pushed but upload-git-mirror role failed: https://22ce6cebe995c8915d66-868b7eb6ba44b32e3b412bc5acf60e73.ssl.cf5.rackc… Is this a known issue? On Thu, Jun 18, 2020 at 2:23 PM <zuul(a)openstack.org> wrote: > Build failed. > > - openstack-upload-github-mirror > https://zuul.opendev.org/t/openstack/build/fd8c86f9b57947239bd0273424e1d4d5 > : FAILURE in 2m 30s > - release-openstack-puppet > https://zuul.opendev.org/t/openstack/build/05dd9c7ffdc74af5ae4065eb16a522f9 > : SUCCESS in 5m 40s > - announce-release > https://zuul.opendev.org/t/openstack/build/188851ebacf9455ab50edc2101ae02bc > : SUCCESS in 5m 31s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > -- Emilien Macchi

3 4

[all][api] Service discovery guidelines moving into frozen state
by Michael McCune 18 Jun '20

18 Jun '20

hello all, this is a general advisory from the API SIG to inform the wider community that we are moving 2 guidelines[0][1] into a frozen state for final review. You can learn more about the API SIG guideline process in this document[2]. These guidelines have been in the drafting stage for quite a long time and it is with much exuberance that i send this message. I would also like to give special thanks to Monty Taylor for his continued guidance and oversight. if you are listed as a cross project liaison for the API SIG, you have automatically been added to the reviewer list for these merge requests. these guidelines will be merged in 1 week if there are no objections on the reviews. peace o/ [0] https://review.opendev.org/#/c/459710 [1] https://review.opendev.org/#/c/459405 [2] https://specs.openstack.org/openstack/api-sig/process.html

1 0

[edge] Edge summaries from the virtual PTG
by Ildiko Vancsa 18 Jun '20

18 Jun '20

Hi, It was great seeing many of you at the virtual PTG two weeks ago. I wrote up two blog posts to summarize edge related sessions at the event: * Edge Computing Group recap: https://superuser.openstack.org/articles/osf-edge-computing-group-ptg-overv… * StarlingX recap: https://www.starlingx.io/blog/starlingx-vptg-june-2020-recap/ The articles have pointers to the etherpads we used at the event and include further pointers as well in case you would like to follow up on either discussion item or missed the event and would like to get a somewhat detailed view of what was discussed. Thanks and Best Regards, Ildikó

1 0

mox3 project retirement
by Sean McGinnis 18 Jun '20

18 Jun '20

Hey everyone, Way back in Rocky, we had a cycle goal to stop using mox/mox3: https://governance.openstack.org/tc/goals/selected/rocky/mox_removal.html The mox library itself is from the broader community, but mox3 specifically was a fork we were maintaining of that lib to add Python 3.x support. Not a lot has been happening there (or luckily needed either), but it is still a repo we have had to maintain while we were transitioning away from mox to mock. There were still a few repos that had mox3 in their requirements files, even though I think in most cases the actual use was dropped awhile ago. With these recent set of patches to clean that up, and remove it from global requirements, we now no longer have any repos in the openstack/* namespace referencing mox3: https://review.opendev.org/#/q/topic:remove-mox3+(status:open+OR+status:mer… This is to announce my intent to officially retire the mox3 repo and clean things up. Of course the lib is still out there in pypi, and can be used by others. It is also possible for the repo to be restored or forked elsewhere if someone not in openstack/* has a strong need for it. But at least within the OpenStack community, I think our time is better spent elsewhere. https://docs.openstack.org/mox3/latest/ https://opendev.org/openstack/mox3 Please raise any concerns here. Thanks, Sean

2 1

no-cache-dir patch bomb
by Monty Taylor 18 Jun '20

18 Jun '20

Hi all! We’ve apparently just gotten a bazillion patches uploaded that do a global search and replace to add —no-cache-dir to all of the pip commands it can find. I have a couple of issues with this and think people should be very careful about landing them a) —no-cache-dir is NOT universally a good idea, and in many cases for interactive install using it will be a worse user experience. The linked post is specifically about reducing docker image size. b) Importantly, it’s updating all of the end-user installation docs. That is highly inappropriate and makes our docs much more user unfriendly, especially given (a) c) In some install scripts we’re going to run them potentially in devstack. While constraints SHOULD prevent a large amount of reinstalling of different versions of things over and over, we all know reality is messier. I think we want to think carefully about removing cache dir usage in devstack as it could actually lead to an increase in install time, and optimizing for docker image size is not a thing we’re attempting to do in functional tests. Regarding the docker image size optimization, for those who are building docker images, I would highly recommend either installing from bistro packages or using builder-image pattern instead. We have one implemented in opendevorg/python-builder and opendevorg/python-base - but the pattern can be implemented elsewhere. The main idea/benefit is to use a builder image to install dev tools and -dev packages with headers and things needed to build wheels, build wheels for all of the dependencies - then in a second build stage copy the wheels from the builder image and install them. We’re using a “compile” tag in binder to indicate what packages are needed for compile-time tasks. The savings from this can be substantial - obviously at the cost of greater complexity. In any case, I HIGHLY recommend not landing any of these patches as submitted. Monty

2 1

[nova] stein to train upgrade
by Amjad Kotobi 18 Jun '20

18 Jun '20

Hi all, I tried to upgrade nova-compute from stein -> train release and “openstack-nova-compute” couldn’t able to start and from log here is coming up ################### 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service Traceback (most recent call last): 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 810, in run_service 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service service.start() 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/nova/service.py", line 174, in start 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service self.manager.init_host() 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1337, in init_host 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service expected_attrs=['info_cache', 'metadata', 'numa_topology']) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_versionedobjects/base.py", line 177, in wrapper 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service args, kwargs) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/nova/conductor/rpcapi.py", line 241, in object_class_action_versions 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service args=args, kwargs=kwargs) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 181, in call 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service transport_options=self.transport_options) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 129, in _send 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service transport_options=transport_options) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 646, in send 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service transport_options=transport_options) 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 636, in _send 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service raise result 2020-06-18 11:31:08.037 303344 ERROR oslo_service.service RemoteError: Remote error: DBError (pymysql.err.InternalError) (1054, u"Unknown column 'instances.hidden' in 'field list ……. ################### I only took beginning part, the field doesn’t exist in DB, or? I also upgrade rest of the nova components[api-scheduler-conductor,…] but that didn’t go away. Any idea how to tackle this?

3 4

[all][release] One following-cycle release model to bind them all
by Thierry Carrez 18 Jun '20

18 Jun '20

Hi everyone, As you know[1] I'm trying to push toward simplification of OpenStack processes, to make them easier to navigate for new members of our community and generally remove weight. A good example of that is release models. We used to have a single model (with milestones and RCs) but over time we grew a number of alternative models to accommodate corner cases. The result is a confusing collection of release models with abstract rules for each and not much flexibility. Projects are forced to choose between those models for their deliverables, with limited guidance. And much of the rationale for those models (exercise release machinery early and often, trigger external testing...) is no longer valid. I'd like to suggest we simplify this and have a single model for things that follow the development cycle: the "follows-cycle" model. The only alternative, its nemesis, its Wario would be the "independent" release model. In the "follows-cycle" model, deliverables would be released at least once per cycle, but could be released more often. The "final" release would be marked by creating a release (stable) branch, and that would need to be done before a deadline. Like today, that deadline depends on whether that deliverable is a library, a client library, a release-trailing exception or just a regular part of the common release. The main change this proposal introduces would be to stop having release candidates at the end of the cycle. Instead we would produce a release, which would be a candidate for inclusion in the coordinated OpenStack release. New releases could be pushed to the release branch to include late bugfixes or translation updates, until final release date. So instead of doing a 14.0.0.0rc1 and then a 14.0.0.0rc2 that gets promoted to 14.0.0, we would produce a 14.0.0, then a 14.0.1 and just list that 14.0.1 in the release page at coordinated release time. I feel like this would not change that much for deliverables following the cycle-with-rc model. It would not change anything for cycle-with-intermediary, libraries or cycle-trailing deliverables. But it would simplify our processes quite a bit, and generally make our releases more consistent. Thoughts? [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013236.ht… -- Thierry Carrez (ttx)

12 31

[neutron] Tap-as-a-service releases on pypi behind
by Sam Morrison 18 Jun '20

18 Jun '20

It looks like tap-as-a-service project isn’t getting it’s latest releases pushed to pypi and this is breaking networking-midonet in train release. Source [1] has tags for releases 4.0.0, 5.0.0 and 6.0.0 but these aren’t in pypi [2] I need a fix [3] to upper-constraints to get this to work but just realised pypi is behind Can someone help me please. Thanks, Sam [1] https://opendev.org/x/tap-as-a-service/ <https://opendev.org/x/tap-as-a-service/> [2] https://pypi.org/project/tap-as-a-service/ <https://pypi.org/project/tap-as-a-service/> [3] https://review.opendev.org/#/c/735754/ <https://review.opendev.org/#/c/735754/>

4 8

[cinder] victoria virtual mid-cycle next week
by Brian Rosmaita 17 Jun '20

17 Jun '20

I know it seems early, but next week is R-16, and the spec freeze is R-15, so: Session One of the Cinder Victoria virtual mid-cycle will be held: DATE: 24 JUNE 2020 TIME: 1400-1600 UTC LOCATION: https://bluejeans.com/3228528973 The meeting will be recorded. Please add topics to the etherpad: https://etherpad.opendev.org/p/cinder-victoria-mid-cycles (Session Two will be held during the R-9 week. We'll do a poll to select the day/time around R-11.) cheers, brian

1 0

[tc] weekly update
by Mohammed Naser 17 Jun '20

17 Jun '20

Hi everyone, Here’s an update for what happened in the OpenStack TC last week. You can get more information by checking for changes in openstack/governance repository. We have some reviews that have been open for quite some time without many reviews. I’d like to kindly ask our technical committee members to review them. # OPEN REVIEWS - [draft] Add assert:supports-standalone https://review.opendev.org/#/c/722399/ [open for 42 days] - Update joining-tc.rst to be general tc-guide.rst https://review.opendev.org/#/c/732983/ - Remove grace period on resolutions https://review.opendev.org/#/c/735361/ - Deprecatre neutron-fwaas and neutron-fwaas-dashboard master branch https://review.opendev.org/#/c/735828/ - Record deprecated cycle for deprecated project https://review.opendev.org/#/c/736084/ - Add openstack-ansible-os_adjutant repo https://review.opendev.org/#/c/736140/ - Merging TC and UC into a single body https://review.opendev.org/#/c/734074/ # PROJECT UPDATES - Add whitebox-tempest-plugin under QA https://review.opendev.org/#/c/714480/ - Clarify the support for linux distro https://review.opendev.org/#/c/727238/ - Rename ansible-role-lunasa-hsm deliverable https://review.opendev.org/#/c/731313/ - Select migrate-to-focal goal for Victoria cycle https://review.opendev.org/#/c/731213/ # PROJECTS RETIRED - Remove congress project team https://review.opendev.org/#/c/728818/ # GENERAL CHANGES - Propose Kendall Nelson for vice-chair https://review.opendev.org/#/c/733141/ - Add njohnston liaison preference https://review.opendev.org/#/c/733269/ - Add diablo_rojo liaison preferences https://review.opendev.org/#/c/733284/ - Add gmann liaison preference https://review.opendev.org/#/c/734894/ - Fix Rally PTL email address https://review.opendev.org/#/c/735342/ # GOAL UPDATES - Add QA branchless projects also in py3.5 support list https://review.opendev.org/#/c/729325/ Regards, Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[cyborg][neutron][nova] Networking support in Cyborg
by Nadathur, Sundar 17 Jun '20

17 Jun '20

Hi all, Based on the Victoria PTG discussion [1], here's a stab at making some aspects of the Nova-Neutron-Cyborg interaction more concrete. * Background: A smart NIC may have a single 'device' that combines the accelerator and the NIC, or two (or more) components in a single PCI card, with separate accelerator and NIC components. * What we said in the PTG: We should model the smart NIC as a single RP representing the combined accelerator/NIC for the first case. For the second case, we could have a hierarchy with separate RPs for the accelerator and the NICs, and a top-level resource-less RP which aggregates all the children RPs and combines their traits. (Correspondingly, Cyborg may represent it as a single object, which we call a Deployable, or as a hierarchy of such objects. There is already support in Cyborg for creating a tree of such objects, though it may need validation for this use case.) * Who creates these RPs? I suggest Cyborg create it in all cases, to keep it uniform. Neutron creates RPs today for the bandwidth provider. But, if different services create RPs depend on which feature is enabled and whether it is a single/multi-component device, that can get complex and problematic. So, could we discuss the possibility of Neutron not creating the RP? The admin should not configure Neutron to handle such NICs. * Ideally, the admin should be able to formulate the device profile in the same way, independent of whether it is a single-component or multi-component device. For that, the device profile must have a single resource group that includes the resource, traits and Cyborg properties for both the accelerator and NIC. The device profile for a Neutron port will presumably have only one request group. So, the device profile would look something like this: { "name": "my-smartnic-dp", "groups": [{ "resources:FPGA": "1", "resources:CUSTOM_NIC_X": "1", "trait:CUSTOM_FPGA_REGION_ID_FOO": "required", "trait:CUSTOM_NIC_TRAIT_BAR": "required", "trait:CUSTOM_PHYSNET_VLAN3": "required", "accel:bitstream_id": "3AFE" }] } Having a single resource group for resources/traits for both accelerator and NIC would ensure that a single RP would provide all those resources, thus ensuring resource co-location in the same device. That single RP could be the top-level RP of a hierarchy. (If they were separate request groups, there is no way to ensure that the resources come from a single RP, even if we set group_policy to None.) * During ARQ binding, Cyborg would still get a single RP as today. In the case of a multi-component device, Cyborg would translate that to the top-level Deployable object, and figure out what constituent components are present. For this scheme to work, it is important that the resource classes and traits for the accelerator RP and the NIC RP be totally disjoint (no overlapping resource classes or traits). * We discussed the physnet trait at the PTG. My suggestion is to keep Cyborg out of this, and out of networking in general, if possible. [1] https://etherpad.opendev.org/p/nova-victoria-ptg "Cyborg-Nova" Lines 104-164 Regards, Sundar

5 7