January 2021 - openstack-discuss - lists.openstack.org

Fwd: DPDK+OVS with OpenStack
by Mark Wittling 23 Apr '25

23 Apr '25

Looking for someone who knows OpenStack with OpenVSwitch, and in addition to that, DPDK with OpenStack and OVS.I am using OpenStack Queens, with OpenVSwitch. The architecture I am using is documented here: https://docs.openstack.org/neutron/queens/admin/deploy-ovs-provider.htmlThe OVS I am using on the Compute Node, is compiled with DPDK, and I have enabled the datapath to netdev (DPDK) on br-prv (provider network bridge), and br-tun (tunneling bridge). But these two bridges, br-tun and br-prv, are patched into another OpenStack bridge, called br-int. I wasn’t actually sure about whether to tinker with this bridge, and wondered what datapath it was using.Then, I realized there is a parameter in the openvswitch_agent.ini file, which I will list here: # OVS datapath to use. 'system' is the default value and corresponds to the # kernel datapath. To enable the userspace datapath set this value to 'netdev'. # (string value) # Possible values: # system - <No description provided> # netdev - <No description provided> #datapath_type = system datapath_type = netdev So in tinkering with this, what I realized, is that when you set this datapath_type to system or netdev, it will adjust the br-int bridge to that datapath type.So here is my question. How can I launch a non-DPDK VM, if all of the bridges are using the netdev datapath type?Here is another question. What if one of the flavors don’t have the largepages property set on them? I assumed OpenStack would revert to a system datapath and not use DPDK for those VM interfaces. Well, I found out in testing, that is not the case. If you set all your bridges up for netdev, and you don’t set the property on the Flavor of the VM (largepages), the VM will launch, but it simply won’t work.Is there no way, on a specific Compute Host, to support both DPDK (netdev datapaths) and non-DPDK (system datapaths)?Either on a VM interface level (VM has one interface that is netdev DPDK and another that is system datapath non-DPDK)?Or on a VM by VM basis (VM 1 has 1 or more netdev datapath interfaces and VM 2 has 1 or more system datapath interfaces)?Am I right here? Once you set up a Compute Host for DPDK, it’s DPDK or nothing on that Compute Host? (edited)

3 2

How to config DPDK compute in OVN
by dangerzone ar 22 Apr '25

22 Apr '25

Hi....as far I understand ovs does support dpdk compute to be deployed. I'm referring to the guideline ' *https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html <https://docs.openstack.org/networking-ovn/queens/admin/dpdk.html>* ' ... It's too brief.. May I know how to config dpdk compute in OVN networking openstack? Hope someone could help what is the config to be done.... Currently compute is run without dpdk over openstack train ovn based. Please need some info on how I can proceed. Thank you

2 1

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

04 Aug '22

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

5 7

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

05 Jan '22

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

2 2

Help with eventlet 0.26.1 and dnspython >= 2
by Thomas Goirand 04 Oct '21

04 Oct '21

Hi, As you may know, eventlet is incompatible with dnspython >= 2.0.0.0rc1. See [1] for the details. However, Debian unstable has 2.0.0. Would there be some good soul willing to help me fix this situation? I would need a patch to fix this, but I'm really not sure how to start. Cheers, Thomas Goirand (zigo)

8 15

[all]Introduction to venus which is the project of log management and has been contributed to the OpenStack community
by Liye Pang(逄立业) 10 Sep '21

10 Sep '21

Hello everyone, after feedback from a large number of operations and maintenance personnel in InCloud OpenStack, we developed the log management project “Venus” for the OpenStack projects and that has contributed to the OpenStack community. The following is an introduction to “Venus”. If there is interest in the community, we are interested in proposing it to become an official OpenStack project in the future. Background In the day-to-day operation and maintenance of large-scale cloud platform, the following problems are encountered： l Time-consuming for log querying while the server increasing to thousands. l Difficult to retrieve logs, since there are many modules in the platform, e.g. systems service, compute, storage, network and other platform services. l The large amount and dispersion of log make faults are difficult to be discovered. l Because of distributed and interaction between components of the cloud platform, and scattered logs between components, it will take more time to locate problems. About Venus According to the key requirements of OpenStack in log storage, retrieval, analysis and so on, we introduced Venus project, a unified log management module. This module can provide a one-stop solution to log collection, cleaning, indexing, analysis, alarm, visualization, report generation and other needs, which involves helping operator or maintainer to quickly solve retrieve problems, grasp the operational health of the platform, and improve the management capabilities of the cloud platform. Additionally, this module plans to use machine learning algorithms to quickly locate IT failures and root causes, and improve operation and maintenance efficiency. Application scenario Venus played a key role in the following scenarios： l Retrieval: Provide a simple and easy-to-use way to retrieve all log and the context. l Analysis: Realize log association, field value statistics, and provide multi-scene and multi-dimensional visual analysis reports. l Alerts：Convert retrieval into active alerts to realize the error finding in massive logs. l Issue location: Establish a chain relationship and knowledge graphs to quickly locate problems. Overall structure The architecture of log management system based on Venus and elastic search is as follows: Diagram 0: Architecture of Venus venus_api: API module，provide API、rest-api service. venus_manager: Internal timing task module to realize the core functions of the log system. Current progress The current progress of the Venus project is as follows: l Collection：Develop fluentd collection tasks based on collectd to read, filter, format and send plug-ins for OpenStack, operating systems, and platform services, etc. l Index：Dealing with multi-dimensional index data in elasticsearch, and provide more concise and comprehensive authentication interface to return query results. l Analysis：Analyzing and display the related module errors, Mariadb connection errors, and Rabbitmq connection errors. l Alerts：Develop alarm task code to set threshold for the number of error logs of different modules at different times, and provides alarm services and notification services. l Location：Develop the call chain analysis function based on global_requested series, which can show the execution sequence, time and error information, etc., and provide the export operation. l Management：Develop configuration management functions in the log system, such as alarm threshold setting, timing task management, and log saving time setting, etc. Application examples Two examples of Venus application scenarios are as follows. 1. The virtual machine creation operation was performed on the cloud platform and it was found that the virtual machine was not created successfully. First, we can find the request id of the operation and jump to the virtual machine creation call chain page. Then, we can query the calling process, view and download the details of the log of the call. 2. In the cloud platform, the error log of each module can be converted into alarms to remind the users. Further, we can retrieve the details of the error log and error log statistics. Next step The next step of the Venus project is as follows: * Collection：In addition to fluent, other collection plugins such as logstash will be integrated. * Analysis: Explore more operation and maintenance scenarios, and conduct statistical analysis and alarm on key data. * display: The configuration, analysis and alarm of Venus will be integrated into horizon in the form of plugin. * location: Form clustering log and construct knowledge map, and integrate algorithm class library to locate the root cause of the fault. Venus Project Registry Venus library: https://opendev.org/inspur/venus You can grab the source code using the following git command: git clone https://opendev.org/inspur/venus.git Venus Demo Youtu.be: <https://youtu.be/mE2MoEx3awM> https://youtu.be/mE2MoEx3awM

7 15

[simplification] Making ask.openstack.org read-only
by Thierry Carrez 27 May '21

27 May '21

Hi everyone, This has been discussed several times on this mailing list in the past, but we never got to actually pull the plug. Ask.openstack.org was launched in 2013. The reason for hosting our own setup was to be able to support multiple languages, while StackOverflow rejected our proposal to have our own openstack-branded StackExchange site. The Chinese ask.o.o side never really took off. The English side also never really worked perfectly (like email alerts are hopelessly broken), but we figured it would get better with time if a big community formed around it. Fast-forward to 2020 and the instance is lacking volunteers to help run it, while the code (and our customization of it) has become more complicated to maintain. It regularly fails one way or another, and questions there often go unanswered, making us look bad. Of the top 30 users, most have abandoned the platform since 2017, leaving only Bernd Bausch actively engaging and helping moderate questions lately. We have called for volunteers several times, but the offers for help never really materialized. At the same time, people are asking OpenStack questions on StackOverflow, and sometimes getting answers there[1]. The fragmentation of the "questions" space is not helping users getting good answers. I think it's time to pull the plug, make ask.openstack.org read-only (so that links to old answers are not lost) and redirect users to the mailing-list and the "OpenStack" tag on StackOverflow. I picked StackOverflow since it seems to have the most openstack questions (2,574 on SO, 76 on SuperUser and 430 on ServerFault). We discussed that option several times, but I now proposed a change to actually make it happen: https://review.opendev.org/#/c/746497/ It's always a difficult decision to make to kill a resource, but I feel like in this case, consolidation and simplification would help. Thoughts, comments? [1] https://stackoverflow.com/questions/tagged/openstack -- Thierry

10 18

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

13 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

[ironic] Announcing deprecation of the iSCSI deploy interface
by Dmitry Tantsur 04 May '21

04 May '21

Hi all, Following up to the previous mailing list [1] and virtual meetup [2] discussions, I would like to announce the plans to deprecate the 'iscsi' deploy interface. This is the updated plan discussed on the virtual meetup: 1) In the Victoria cycle (i.e. right now): - Fill in the detected feature gaps [3]. - Switch off the iscsi deploy interface by default. - Change [agent]image_dowload_source to HTTP by default. - Give the direct deploy a higher priority, so that it's used by default unless disabled. - Mark it as deprecated in the code (causing warnings when enabled). - Release a major version of ironic to highlight the defaults changes. 2) In the W cycle: - Keep the iscsi deploy deprecated. - Listen to operators' feedback. 3) In the X cycle - Remove the iscsi deploy completely from ironic and IPA. - Remove support code from ironic-lib with a major version bump. Please let us know if you have any questions or concerns. Dmitry [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016681.h… [2] https://etherpad.opendev.org/p/Ironic-Victoria-midcycle [3] https://storyboard.openstack.org/#!/story/2008075 -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

1 1

[barbican][oslo][nova][glance][cinder] cursive library status
by Brian Rosmaita 03 May '21

03 May '21

Hello Barbican team, Apologies for not including barbican in the previous thread on this topic: http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019430… The situation is that cursive is used by Nova, Glance, and Cinder and we'd like to move it out of the 'x' namespace into openstack governance. The question is then what team would oversee it. It seems like a good fit for Oslo, and the Oslo team seems OK with that, but since barbican-core is currently included in cursive-core, it make sense to give the Barbican team first dibs. From the consuming teams' side, I don't think we have a preference as long as it's clear who we need to bother about approvals if a bugfix is posted for review. Thus my ask is that the Barbican team indicate whether they'd like to move cursive to the 'openstack' namespace under their governance, or whether they'd prefer Oslo to oversee the library. Thank you! brian

5 5

[dev][cinder][keystone] Properly consuming system-scope in cinder
by Lance Bragstad 09 Apr '21

09 Apr '21

Hey folks, As I'm sure some of the cinder folks are aware, I'm updating cinder policies to include support for some default personas keystone ships with. Some of those personas use system-scope (e.g., system-reader and system-admin) and I've already proposed a series of patches that describe what those changes look like from a policy perspective [0]. The question now is how we test those changes. To help guide that decision, I worked on three different testing approaches. The first was to continue testing policy using unit tests in cinder with mocked context objects. The second was to use DDT with keystonemiddleware mocked to remove a dependency on keystone. The third also used DDT, but included changes to update NoAuthMiddleware so that it wasn't as opinionated about authentication or authorization. I brought each approach in the cinder meeting this week where we discussed a fourth approach, doing everything in tempest. I summarized all of this in an etherpad [1] Up to yesterday morning, the only approach I hadn't tinkered with manually was tempest. I spent some time today figuring that out, resulting in a patch to cinderlib [2] to enable a protection test job, and cinder_tempest_plugin [3] that adds the plumbing and some example tests. In the process of implementing support for tempest testing, I noticed that service catalogs for system-scoped tokens don't contain cinder endpoints [4]. This is because the cinder endpoint contains endpoint templating in the URL [5], which keystone will substitute with the project ID of the token, if and only if the catalog is built for a project-scoped token. System and domain-scoped tokens do not have a reasonable project ID to use in this case, so the templating is skipped, resulting in a cinder service in the catalog without endpoints [6]. This cascades in the client, specifically tempest's volume client, because it can't find a suitable endpoint for request to the volume service [7]. Initially, my testing approaches were to provide examples for cinder developers to assess the viability of each approach before committing to a protection testing strategy. But, the tempest approach highlighted a larger issue for how we integrate system-scope support into cinder because of the assumption there will always be a project ID in the path (for the majority of the cinder API). I can think of two ways to approach the problem, but I'm hoping others have more. First, we remove project IDs from cinder's API path. This would be similar to how nova (and I assume other services) moved away from project-specific URLs (e.g., /v3/%{project_id}s/volumes would become /v3/volumes). This would obviously require refactoring to remove any assumptions cinder has about project IDs being supplied on the request path. But, this would force all authorization information to come from the context object. Once a deployer removes the endpoint URL templating, the endpoints will populate in the cinder entry of the service catalog. Brian's been helping me understand this and we're unsure if this is something we could even do with a microversion. I think nova did it moving from /v2/ to /v2.0/, which was technically classified as a major bump? This feels like a moon shot. Second, we update cinder's clients, including tempest, to put the project ID on the URL. After we update the clients to append the project ID for cinder endpoints, we should be able to remove the URL templating in keystone, allowing cinder endpoints to appear in system-scoped service catalogs (just like the first approach). Clients can use the base URL from the catalog and append the admin project ID before putting the request on the wire. Even though the request has a project ID in the path, cinder would ignore it for system-specific APIs. This is already true for users with an admin role on a project because cinder will allow you to get volumes in one project if you have a token scoped to another with the admin role [8]. One potential side-effect is that cinder clients would need *a* project ID to build a request, potentially requiring another roundtrip to keystone. Thoughts? [0] https://review.opendev.org/q/project:openstack/cinder+topic:secure-rbac [1] https://etherpad.opendev.org/p/cinder-secure-rbac-protection-testing [2] https://review.opendev.org/c/openstack/cinderlib/+/772770 [3] https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/772915 [4] http://paste.openstack.org/show/802117/ [5] http://paste.openstack.org/show/802097/ [6] https://opendev.org/openstack/keystone/src/commit/c239cc66615b41a0c09e031b3… [7] http://paste.openstack.org/show/802092/ [8] http://paste.openstack.org/show/802118/

4 8

[cinder] Review of tiny patch to add Ceph RBD fast-diff to cinder-backup
by Christian Rohmann 07 Apr '21

07 Apr '21

Hey everyone, I wrote a tiny patch to add the Ceph RDB feature of fast-diff to backups created by cinder-backup: * https://review.opendev.org/c/openstack/cinder/+/766856/ Could someone please take a peek and let me know of this is sufficient to be merged? Thanks and with kind regards, Christian

3 12

Ospurge or "project purge" - What's the right approach to cleanup projects prior to deletion
by Christian Rohmann 28 Mar '21

28 Mar '21

Hello Openstack-Discuss, I was wondering what the right approach to clean up all resources of a project was in order for it to be deleted? 1) There is ospurge (https://opendev.org/x/ospurge) which works, but seems kind of abandoned looking at the last commits and pending issues (https://bugs.launchpad.net/ospurge) Will there still be any further development of this tool? 2) Then there is the project purge command (https://docs.openstack.org/python-openstackclient/victoria/cli/command-obje…) introduced with the Pike release (https://docs.openstack.org/releasenotes/python-openstackclient/pike.html#re… // https://bugs.launchpad.net/python-openstackclient/+bug/1584596 // https://review.opendev.org/c/openstack/python-openstackclient/+/367673/) While it seems only natural to have the cleanup / purge functionality built into the openstack client, I was wondering .. . a) if all potentially existing resources types are covered and this can fully replace ospurge to allow any project to be cleaned up and deleted? What about i.e. Networks, Containers or objects? b) Also ospurge seems to still have some extended options to target or exclude certain resources by using the following options: > [--resource > {Backups,Snapshots,Volumes,Zones,Images,Stacks,FloatingIPs,RouterInterfaces,Routers,Ports,Networks,SecurityGroups,Servers,LoadBalancers,Receivers,Policies,Clusters,Profiles,Objects,Containers}] > [--exclude-resource > {Backups,Snapshots,Volumes,Zones,Images,Stacks,FloatingIPs,RouterInterfaces,Routers,Ports,Networks,SecurityGroups,Servers,LoadBalancers,Receivers,Policies,Clusters,Profiles,Objects,Containers}] those options are not (yet) available for the "project purge" command of the openstack client. With regards, Christian

5 13

[all][tc] Dropping lower-constraints testing from all projects
by Ghanshyam Mann 19 Mar '21

19 Mar '21

Hello Everyone, You might have seen the discussion around dropping the lower constraints testing as it becomes more challenging than the current value of doing it. Few of the ML thread around this discussion: - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019521… - http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390… As Oslo and many other project dropping or already dropped it, we should decide it for all other projects also otherwise it can be more changing than it is currently. We have not defined it in PTI or testing runtime so it is always up to projects if they still want to keep it but we should decide a general recommendation here. -gmann

12 46

[ironic] [infra] Making Glean work with IPA for static IP assignment
by Dmitry Tantsur 18 Mar '21

18 Mar '21

Hi Ian, Given our timezone difference, I've decided to send you an email, adding openstack-discuss in CC for greater exposure. We're trying to make IPA (our agent ramdisk) to work without relying on DHCP for cases like Edge deployments. We've settled on the network_data.json format for the API side and wanted to use Glean on the ramdisk to apply it. You can read more details in [1]. The problem is, I cannot make Glean work with any ramdisk I build. The crux of the problem seems to be that NetworkManager (used by default in RHEL, CentOS, Fedora and Debian at least) starts very early, creates the default connection and ignores whatever files Glean happens to write afterwards. On Debian running `systemctl restart networking` actually helped to pick the new configuration, but I'm not sure we want to do that in Glean. I haven't been able to make NetworkManager pick up the changes on RH systems so far. I build ramdisks using IPA-builder [2] by adding the simple-init element. I've tried removing dhcp-all-interfaces (which we depend on by default) to no effect. I've tried disabling the DHCP server, ended up with no IP connectivity at all. I haven't tried to shutdown and restart a connection as recommended in [3] since it's not trivial to do via SSH. Do you maybe have any hints how to proceed? I'd be curious to know how static IP assignment works in the infra setup. Do you have images with NetworkManager there? Do you use the simple-init element? Any help is very appreciated. Dmitry [1] https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/L3… [2] https://opendev.org/openstack/ironic-python-agent-builder [3] https://mail.gnome.org/archives/networkmanager-list/2014-January/msg00032.h… -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

4 9

[all][tc] Thoughts on Python 3.7 support
by Pierre Riteau 11 Mar '21

11 Mar '21

Hello, There have been many patches submitted to drop the Python 3.7 classifier from setup.cfg: https://review.opendev.org/q/%2522remove+py37%2522 The justification is that Wallaby tested runtimes only include 3.6 and 3.8. Most projects are merging these patches, but I've seen a couple of objections from ironic and horizon: - https://review.opendev.org/c/openstack/python-ironicclient/+/769044 - https://review.opendev.org/c/openstack/horizon/+/769237 What are the thoughts of the TC and of the overall community on this? Should we really drop these classifiers when there are no corresponding CI jobs, even though more Python versions may well be supported? Best wishes, Pierre Riteau (priteau)

9 13

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

Some questions regarding OpenStack Trove Victoria release
by Bekir Fajkovic 18 Feb '21

18 Feb '21

Hello! My name is Bekir Fajkovic and i work at City Network cloud service provider mostly as a DBA but i am also involved in many other kind of activities inside the Company. We at City Network are currently in a process of deployment of OpenStack Trove project (latest official release) and are thus preparing a dedicated region inside our OpenStack hosting environment to host it as a beta version internally, to begin with, where we are going to involve some of our customers to evaluate the service after, hopefully, successful installation and configuration. To be totally honest, while there is a whole lot of a certain kind of documentation provided covering many aspects, some other aspects inside the project do not seem to be documented in depth or at all (which of course is totally understandable), so i am forced to ask some questions this way and i hope You find them not to be too annoying to anyone. The questions: ------------------------ Having the fact that Trove Victoria release provides Docker containers as a new way of database instance provisioning, i am wondering how far the project is developed in terms of covering the different types of databases. What i can see by mainly parsing the code provided on Github, those seem to be officially released: - MySQL - MariaDB - PostgreSQL and the rest of the planned database types are in "experimental" phase. And also, regarding certain types of databases (for example MySQL, version 5.7 and 8.0) only certain versions of the datastores seems to be supported, but not all. On the other hand, nothing regarding datastore versions supported for MariaDB and PostgreSQL seems to be mentioned somewhere. Could someone please confirm that as well as give some more details about it? I successfully managed to create certain versions of datastores in my devstack environment, belonging to those 3 database types mentioned above (and based on trovestack-generated dev guest image that is by default delivered with devstack installation), but not without some undesirable events. For example, i am able to register PostgreSQL datastore version 12 and instantiate a database instance of that version but not version 13 and above, where i get some hostname-related errors etc. Also, a question regarding the building of the production-ready guest image. As mentioned, Trovestack script is provided as a possible way of producing the images (by omitting dev option the Trove Guest Agent binaries are deployed into the instantiated VM). How does an image produced this way looks like? From where the base image is fetched, is it a "cloud based image" with cloud-init in it, are the automatic security and software patching features disabled in produced image, so that we do not get unexpected service interruptions when the OS suddenly decides to start updating itself etc.. Regarding the Trove Guest Agent service - i read in some Trove books previously that there are dedicated agents for each and every database type, is it the same situation in Victoria release, or is there an "universal" Guest Agent covering all the database types nowadays? Where is the code that adapts the Agent commands towards the database instances placed inside the project? The backups - as i can see there seem to be some kind of dedicated docker-backup images involved in each database type. Could someone explain the internals of backup mechanisms inside Trove Victoria release in more details? So, that would be all for the moment and although You probably consider my questions being as stupid as possible, i still dared to ask them :) I hope You will be able to provide the answers to at least some of them! Thanks in advance! Best Regards Bekir Fajkovic Senior DBA Mobile: +46 70 019 48 47 www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

3 10

[all][stackalytics] stackalytics.io
by Andrii Ostapenko 17 Feb '21

17 Feb '21

Hi all! Since https://stackalytics.com is not operational for quite some time already, I exposed another instance on https://stackalytics.io It shares the same configuration and is kept updated. You're welcome to use it at least until stackalytics.com is up and running (just please be gentle). Sincerely, Andrii Ostapenko

3 5

[tc][heat][tacker] Discusssion about heat-translater and tosca-parser maintenance
by TAKAHASHI TOSHIAKI(高橋　敏明) 14 Feb '21

14 Feb '21

Hi, I'm a tacker team member. I'd like to discuss how to maintain heat-translator[1] and tosca-parser[2] repositories. These 2 repositories have not been updated so actively, but tacker often requires code updates for these repositories. Recently, patch merge progress of tacker and these repo do not sometimes match, which affects the development of tacker. For example, our some functional tests on zuul fail because these master codes are not updated. Therefore, tacker members would like to take part more in these 2 developments. Tacker members have already started code reviews, patch posts, etc. If possible, we want some Tacker members to join the core team in the near future. How about this? [1] https://opendev.org/openstack/heat-translator [2] https://opendev.org/openstack/tosca-parser Regards, Toshiaki

5 9

[all][interop] Reforming the refstack maintainers team
by Ghanshyam Mann 12 Feb '21

12 Feb '21

Hello Everyone, As Goutham mentioned in a separate ML thread[2] that there is no active maintainer for refstack repo which we discussed in today's interop meeting[1]. We had a few volunteers who can help to maintain the refstack and other interop repo which is good news. I would like to call for more volunteers (new or existing ones), if you are interested to help please do reply to this email. The role is to maintain the source code of the below repos. I will propose the ACL changes in infra sometime next Friday (18th dec) or so. For easy maintenance, we thought of merging the below repo core group into a single group called 'refstack-core' - openstack/python-tempestconf - openstack/refstack - openstack/refstack-client - x/ansible-role-refstack-client (moving to osf/ via https://review.opendev.org/765787) Current Volunteers: - martin (mkopec(a)redhat.com) - gouthamr (gouthampravi(a)gmail.com) - gmann (gmann(a)ghanshyammann.com) - Vida (vhariria(a)redhat.com) - interop-core (we will add this group also which has interop WG chairs so that it will be easy to maintain in the future changes) NOTE: there is no change in the 'interop' repo group which has interop guidelines and doc etc. [1] https://etherpad.opendev.org/p/interop [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019263… -gmann

8 12

[largescale-sig] OpenStack DB Archiver
by Arnaud Morin 10 Feb '21

10 Feb '21

Hello large-scalers! TLDR: we opensource a tool to help reducing size of databases. See https://github.com/ovh/osarchiver/ Few months ago, we released a tool, name osarchiver, which we are using on our production environment (at OVH) to help reduce the size of our tables in mariadb (or mysql) In fact, some tables are well know to grow very quickly. We use it, for example, to clean the OpenStack mistral database from old tasks, actions and executions which are older than a year. Another use case could be to archive some data in another table (e.g. with _archived as suffix) if they are 6 months old, and delete this data after 1 year. The source code of this tool is available here: https://github.com/ovh/osarchiver/ We were wondering if some other users would be interested in using the tool, and maybe move it under the opendev governance? Feel free to contact us and/or answer this thread. Cheers, -- Arnaud, Pierre-Samuel and OVH team

12 18

[nova][placement] adding nova-core to placement-core in gerrit
by Balazs Gibizer 09 Feb '21

09 Feb '21

Hi, Placement got back under nova governance but so far we haven't consolidated the core teams yet. Stephen pointed out to me that given the ongoing RBAC works it would be beneficial if more nova cores, with API and RBAC experience, could approve such patches. So I'm proposing to add nova-core group to the placement-core group in gerrit. This means Ghanshyam, John, Lee, and Melanie would get core rights in the placement related repositories. @placement-core, @nova-core members: Please let me know if you have any objection to such change until end of this week. cheers, gibi

6 9

[ironic] On redfish-virtual-media vs idrac-redfish-virtual-media
by Dmitry Tantsur 08 Feb '21

08 Feb '21

Hi all, Now that we've gained some experience with using Redfish virtual media I'd like to reopen the discussion about $subj. For the context, the idrac-redfish-virtual-media boot interface appeared because Dell machines need an additional action [1] to boot from virtual media. The initial position on hardware interfaces was that anything requiring OEM actions must go into a vendor hardware interface. I would like to propose relaxing this (likely unwritten) rule. You see, this distinction causes a lot of confusion. Ironic supports Redfish, ironic supports iDRAC, iDRAC supports Redfish, ironic supports virtual media, Redfish supports virtual media, iDRAC supports virtual media. BUT! You cannot use redfish-virtual-media with iDRAC. Just today I had to explain the cause of it to a few people. It required diving into how exactly Redfish works and how exactly ironic uses it, which is something we want to protect our users from. We already have a precedent [2] of adding vendor-specific handling to a generic driver. I have proposed a patch [3] to block using redfish-virtual-media for Dell hardware, but I grew to dislike this approach. It does not have precedents in the ironic code base and it won't scale well if we have to handle vendor differences for vendors that don't have ironic drivers. Based on all this I suggest relaxing the rule to the following: if a feature supported by a generic hardware interface requires additional actions or has a minor deviation from the standard, allow handling it in the generic hardware interface. Meaning, redfish-virtual-media starts handling the Dell case by checking the System manufacturer (via the recently added detect_vendor call) and loading the OEM code if it matches "Dell". After this idrac-redfish-virtual-media will stay empty (for future enhancements and to make the patch backportable). Thoughts? Dmitry [1] https://opendev.org/openstack/ironic/src/commit/6ea73bdfbb53486cf9905d21024… [2] https://review.opendev.org/c/openstack/ironic/+/757198/ [3] https://review.opendev.org/c/openstack/ironic/+/771619 -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill

5 7

bindep, pacman, and PyPI release
by Jakob Lykke Andersen 05 Feb '21

05 Feb '21

Dear developers, I'm trying to use bindep on Arch but hitting a problem with the output handling. It seems that 'pacman -Q' may output warning lines if you have a file with the same name as the package. E.g.,: $ mkdir cmake $ pacman -Q cmake error: package 'cmake' was not found warning: 'cmake' is a file, you might want to use -p/--file. The current detection assumes the "was not found" is the last part of the output. Applying the patch below seems to fix it. After applying this patch, or whichever change you deem reasonable to fix the issue, it would be great if you could make a new release on PyPI. Thanks, Jakob diff --git a/bindep/depends.py b/bindep/depends.py index bb9553f..cacc863 100644 --- a/bindep/depends.py +++ b/bindep/depends.py @@ -558,7 +558,8 @@ class Pacman(Platform): stderr=subprocess.STDOUT).decode(getpreferredencoding(False)) except subprocess.CalledProcessError as e: eoutput = e.output.decode(getpreferredencoding(False)) - if e.returncode == 1 and eoutput.strip().endswith('was not found'): + s = "error: package '{}' was not found".format(pkg_name) + if e.returncode == 1 and s in eoutput: return None raise # output looks like

2 2

[all][mentoring][outreachy][GSoC]Summer Interns/ Student Coders Anyone?
by Kendall Nelson 05 Feb '21

05 Feb '21

Hello :) So, if you've been involved in Outreachy, the Google Summer of Code[1] is pretty similar. It looks like the applications for projects open January 29, 2021 at 11:00 (Pacific Standard Time) if anyone wants to apply. I encourage you all to do so! It gets a lot of attention from university students so it's a great opportunity to get some new contributors and teach some more of the world about our community and open source! If you are interested in applying, let me know and I will do what I can to help you with the application to get it done on time (deadline not listed on the site yet, but they always come faster than we'd like)! -Kendall (diablo_rojo) [1] https://summerofcode.withgoogle.com/get-started/

1 1

[All][StoryBoard] Angular.js Alternatives
by Kendall Nelson 05 Feb '21

05 Feb '21

Hello Everyone! The StoryBoard team is looking at alternatives to Angular.js since its going end of life. After some research, we've boiled all the options down to two possibilities: Vue.js or React.js I am diving more deeply into researching those two options this week, but any opinions or feedback on your experiences with either of them would be helpful! Here is the etherpad with our research so far[3]. Feel free to add opinions there or in response to this thread! -Kendall Nelson (diablo_rojo) & The StoryBoard Team [1] https://vuejs.org/ [2] https://reactjs.org/ [3] https://etherpad.opendev.org/p/replace-angularjs-storyboard-research

10 15

[ops][largescale-sig] How many compute nodes in a single cluster ?
by Thierry Carrez 04 Feb '21

04 Feb '21

Hi everyone, As part of the Large Scale SIG[1] activities, I'd like to quickly poll our community on the following question: How many compute nodes do you feel comfortable fitting in a single-cluster deployment of OpenStack, before you need to scale it out to multiple regions/cells/.. ? Obviously this depends on a lot of deployment-dependent factors (type of activity, choice of networking...) so don't overthink it: a rough number is fine :) [1] https://wiki.openstack.org/wiki/Large_Scale_SIG Thanks in advance, -- Thierry Carrez (ttx)

7 12

[magnum] [neutron] [ovn] No inter-node pod-to-pod communication due to missing ACLs in OVN
by Krzysztof Klimonda 04 Feb '21

04 Feb '21

Hi, This email is a follow-up to a discussion I've openened on ovs-discuss ML[1] regarding lack of TCP/UDP connectivity between pods deployed on magnum-managed k8s cluster with calico CNI and IPIP tunneling disabled (calico_ipv4pool_ipip label set to a default value of Off). As a short introduction, during magnum testing in ussuri deployment with ml2/ovn neutron driver I've noticed lack of communication between pods deployed on different nodes as part of magnum deployment with calico configured to *not* encapsulate traffic in IPIP tunnel, but route it directly between nodes. In theory, magnum configures adds defined pod network to k8s nodes ports' allowed_address_pairs[2] and then security group is created allowing for ICMP and TCP/UDP traffic between ports belonging to that security group[3]. This doesn't work with ml2/ovn as TCP/UDP traffic between IP addresses in pod network is not matching ACLs defined in OVN. I can't verify this behaviour under ml2/ovs for the next couple of weeks, as I'm taking them off for holidays, but perhaps someone knows if that specific usecase (security group rules with remote groups used with allowed address pairs) is supposed to be working, or should magnum use pod network cidr to allow traffic between nodes instead. [1] https://mail.openvswitch.org/pipermail/ovs-discuss/2020-December/050836.html [2] https://github.com/openstack/magnum/blob/c556b8964fab129f33e766b1c33908b2eb… [3] https://github.com/openstack/magnum/blob/c556b8964fab129f33e766b1c33908b2eb… -- Best Regards, - Chris

5 9

[all] Eventlet broken again with SSL, this time under Python 3.9
by Thomas Goirand 04 Feb '21

04 Feb '21

Hi, Swift proxy fails with Python 3.9 under Debian Unstable with Python 3.9: http://paste.openstack.org/show/802063/ (that's when doing a simple "openstack container list") I got the same problem with neutron-rpc-server: http://paste.openstack.org/show/802071/ (this happens when neutron-rpc-server tries to tell Nova that my new VM port is up) I didn't really look further, but I guess so many services are affected. This looks like general to OpenStack, and feels like yet-another-problem-with-eventlet, and looks very similar to this one: https://github.com/eventlet/eventlet/issues/677 even though that's here a Python 3.9 issue, not 3.7. I'd very much appreciate if some Eventlet specialist could look into this problem, because that's beyond my skills. Cheers, Thomas Goirand (zigo)

5 17

Backup drivers issue with the container parameter
by Gorka Eguileor 03 Feb '21

03 Feb '21

Hi all, In the next Cinder meeting I'll bring a Backup driver issue up for discussion, and this email hopefully provides the necessary context to have a fruitful discussion. The issue is around the `container` optional parameter in backup creation, and its user and administrator unfriendliness. The interpretation of the `container` parameter is driver dependent, and it's being treated as: - A bucket in Google Cloud Storage and the new S3 driver - A container in Swift - A pool in Ceph - A directory in NFS and Posix Currently the only way to prevent cloud users from selecting a different `container` is by restricting what the storage user configured in Cinder backup can do. For Ceph we can make the storage user unable to access any other existing pools, for Swift, GCS, and S3 we can remove permissions to create buckets/containers from the storage user. This achieves the administrator's objective of not allowing them to change the `container`, but cloud users will have a bad experience, because the API will accept the request but the backup will go into `error` state and they won't see any additional information. And this solution is an all or nothing approach, as we cannot allow just some cloud users select the container while preventing others from doing so. For example we may want some cloud users to be able to do backups on a specific RBD pool that is replicated to a remote location. I think we can solve all these issues if we: - Create a policy for accepting the `container` parameter on the API (defaulting to allow for backward compatibility). - Add a new configuration option `backup_container_regex` to control acceptable values for the `container` (defaults to `.*` for backward compatibility). This option would be used by the backup manager (not the drivers themselves) on backup creation, and would result in a user message if the provided container was not empty and failed the regex check. I think this summarizes the situation and my view on the matter. Feedback is welcome here or in the next Cinder meeting. Cheers, Gorka.

2 1

[baremetal-sig][ironic] Tue Jan 12, 2021, 2pm UTC: 'Multi-Tenancy in Ironic: Of Owners and Lessees'
by Arne Wiebalck 02 Feb '21

02 Feb '21

Dear all, Happy new year! The Bare Metal SIG will continue its monthly meetings and start again on Tue Jan 12, 2021, at 2pm UTC. This time there will be a 10 minute "topic-of-the-day" presentation by Tzu-Mainn Chen (tzumainn) on 'Multi-Tenancy in Ironic: Of Owners and Lessees' So, if you would like to learn how this relatively recent addition to Ironic works, you can find all the details for this meeting on the SIG's etherpad: https://etherpad.opendev.org/p/bare-metal-sig Everyone is welcome, don't miss out! Cheers, Arne

3 5

Strange behaviour of OSC in keystone MFA context
by Taltavull Jean-Francois 02 Feb '21

02 Feb '21

Hello, I'm experiencing the following strange behavior of openstack CLI with os-auth-methods option (most parameters are defined in clouds.yaml): $ openstack token issue --os-auth-type v3multifactor --os-auth-methods password,totp The plugin p could not be found Note that "p" is the first letter of "password". It looks like the option parser handled "password,totp" as a string instead of as a list of strings. Version of openstack CLI is 5.4.0. Any idea ? Thanks ! Jean-François

5 7

[cinder] wallaby R-9 mid-cycle poll
by Brian Rosmaita 02 Feb '21

02 Feb '21

Hello Cinder team and anyone interested in Cinder, The second wallaby mid-cycle meeting will be held during week R-9 (the week of 8 February 2021). It will be 2 hours long. Please indicate your availability on the following poll: https://doodle.com/poll/9vqri7855cab858d Please respond before 21:00 UTC on Tuesday 2 February 2021. thanks, brian

1 1

[magnum][heat] Rolling system upgrades
by Krzysztof Klimonda 01 Feb '21

01 Feb '21

Hi, While testing magnum, a problem of upgrades came up - while work has been done to make kubernetes upgrades without interruption, operating system upgrades seem to be handled only partially. According to the documentation, two ways of upgrading system are available: - via specifying ostree_commit or ostree_remote labels in the cluster template used for upgrade - via specifying a new image in the cluster template used for upgrade The first one is specific to Fedora Atomic (and, while probably untested, seems to be mostly working with Fedora CoreOS) but it has some drawbacks. Firstly, due to base image staying the same we require this image for the life of the cluster, even if OS has already been upgraded. Secondly, using this method only upgrades existing instances and new instances (spawned via scaling cluster up) will not be upgraded. Thirdly, even if that is fixed I'm worried that at some point upgrading from old base image to some future ostree snapshot will fail (there is also cost associated with diff growing with each release). The second method, of specifying a new image in the cluster template used for upgrade, comes with an ugly warning about nodes not being drained properly before server rebuild (and it actually doesn't seem to be working anyway as the new image parameter is not being passed to the heat template on upgrade). This does however seem like a more valid approach in general. I'm not that familar with Heat, and the documentation of various OS::Heat::Software* resources seems inconclusive, but is there no way of executing some code before instance is rebuilt? If not, how are other projects and users handling this in general? -- Krzysztof Klimonda kklimonda(a)syntaxhighlighted.com

2 3

[Diversity] Diversity &Inclusion WG Meeting reminder Amy Marrich <amy@demarco.com> Mon, Jan 11, 7:49 AM to foundation, openstack-discuss, kata-dev, starlingx-discuss, airship-discuss, zuul-discuss The Diversity & Inclusion WG invites members of all OSF projects to our meeting today, at 17:00 UTC in the #openstack-diversity channel. The agenda can be found at https://etherpad.openstack.org/p/diversity-wg-agenda. Please feel free to add any other topics you wish to discuss at the meeting. Thanks, Amy (spotz)
by Amy Marrich 31 Jan '21

31 Jan '21

The Diversity & Inclusion WG invites members of all OSF projects to our meeting tomorrow, at 17:00 UTC in the #openstack-diversity channel. The agenda can be found at https://etherpad.openstack.org/p/diversity-wg-agenda. Please feel free to add any other topics you wish to discuss at the meeting. Thanks, Amy (spotz)

1 0

[DHCP][Provider Network] Instances get IP from external DHCP server
by dangerzone ar 31 Jan '21

31 Jan '21

Hi, appreciate some advice on how instances in openstack get ip from external DHCP server. For example instance is attached to port eth1 (physical port) and this port is connected to home/office lan port and requests dhcp ip. How this can be achieved. ***User don't know the dhcp ip range/gw/dns that will be provided by the dhcp sever to that instance...instance just attach to eth1 and request ip.*** Similar like our pc/notebook request dhcp ip via wifi or lan port. How to establish this in openstack. Please advise and help me. Thank you

3 5

Advise Request
by Karera Tony 30 Jan '21

30 Jan '21

Dear Team, I deployed the Openstack Ussuri version and everything was working fine with the small cirros Image since its a test environment for now. I started facing an issue when I uploaded a bigger image (Ubuntu 16.04 Xenialand Ubuntu 18.04 Biomic), When I tried to create an instance using any of those images, I got the error below. Traceback (most recent call last): File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py", line 1942, in _prep_block_device wait_func=self._await_block_device_map_created) File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/virt/block_device.py", line 874, in attach_block_devices _log_and_attach(device) File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/virt/block_device.py", line 871, in _log_and_attach bdm.attach(*attach_args, **attach_kwargs) File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/virt/block_device.py", line 771, in attach wait_func=wait_func, image_id=self.image_id) File "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/virt/block_device.py", line 381, in _create_volume availability_zone=av_zone, Can any one advise on how to proceed ? Regards Tony Karera

1 0

[neutron] Secure RBAC api performance regression
by Slawek Kaplonski 29 Jan '21

29 Jan '21

Hi, In Neutron we are merging more and more patches related to the secure rbac policies [1]. Recently we noticed that our neutron-rally-task job is failing very often [2]. I did some tests and here is what were my results: * on latest neutron, with about 12 patches related to secure rbac merged - list of 4k ports took about 1m 40s: $ time neutron port-list | wc -l neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. 4044 real 1m41,644s user 0m0,926s sys 0m0,087s * same test with all those patches reverted - and it took 8 seconds: $ sudo systemctl restart devstack@q-svc; sleep 5; time neutron port-list | wc -l neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. 4044 real 0m8,131s user 0m0,907s sys 0m0,120s After a bit of digging I found out that most of the slowdown came from calls of the method self._handle_deprecated_rule(default) in [3]. When I commented that one line I had results same like without secure-rbac patches: $ sudo systemctl restart devstack@q-svc; sleep 5; time neutron port-list | wc -l neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead. 4044 real 0m7,875s user 0m0,931s sys 0m0,087s @Lance, can You maybe take a look at it and help me understand if we are doing something wrong with those new rules in Neutron? Or maybe there is a bug in oslo_policy? [1] https://review.opendev.org/q/topic:secure-rbac+project:openstack/neutron [2] https://bugs.launchpad.net/neutron/+bug/1913718 [3] https://github.com/openstack/oslo.policy/blob/e103baa002e54303b08630c436dfc… -- Slawek Kaplonski Principal Software Engineer Red Hat

2 1

[tc][all] Encouraging projects to apply for tag 'assert:supports-api-interoperability'
by Ghanshyam Mann 29 Jan '21

29 Jan '21

Hello Everyone, TC defined a tag for API interoperability (cover both stable and compatible APIs) called 'assert:supports-api-interoperability' which assert on API won’t break any users when they upgrade a cloud or start using their code on a new OpenStack cloud. Basically, Projects will not change (or remove) an API in a way that will break existing users of an API. We have updated the tag documentation to clarify its definition and requirements. If your projects follow the API interoperability guidelines[1] and some API versioning mechanism that does not need to be microversion then you should start thinking to apply for this tag. The complete requirement can be found here[2]. Currently, only nova has this tag but I am sure many projects are eligible for this, and TC encourage them to apply for this. [1] https://specs.openstack.org/openstack/api-wg/guidelines/api_interoperabilit… [2] https://governance.openstack.org/tc/reference/tags/assert_supports-api-inte… -gmann

2 3

[Release-job-failures] os-collect-config 11.0.2 and tripleo-ipsec 9.3.1
by Thierry Carrez 29 Jan '21

29 Jan '21

We had two release jobs failures around TripleO and stable/ussuri: > - openstack-upload-github-mirror https://zuul.opendev.org/t/openstack/build/cb4de2810bd147e2bf1cd98d6a1160fa : SUCCESS in 46s > - release-openstack-python https://zuul.opendev.org/t/openstack/build/fb61c0814f114a2ea0c7298378e10e5f : FAILURE in 3m 07s > - announce-release https://zuul.opendev.org/t/openstack/build/None : SKIPPED > - propose-update-constraints https://zuul.opendev.org/t/openstack/build/None : SKIPPED and > - openstack-upload-github-mirror https://zuul.opendev.org/t/openstack/build/fad34ae84b9d4a8c982ca4f75c01f0c9 : SUCCESS in 58s > - release-openstack-python https://zuul.opendev.org/t/openstack/build/0edc8da3c58842ed85b826f56153cde3 : FAILURE in 3m 25s > - announce-release https://zuul.opendev.org/t/openstack/build/None : SKIPPED > - propose-update-constraints https://zuul.opendev.org/t/openstack/build/None : SKIPPED In both cases those jobs are coming from post-processing of release tags being pushed as a result of merging https://review.opendev.org/c/openstack/releases/+/772047 The error is that os-collect-config 11.0.0 and tripleo-ipsec 9.3.0 both did not have a stable/ussuri branch cut around ussuri release time at https://review.opendev.org/c/openstack/releases/+/728537 (probably escaped our watch as they are cycle-trailing). os-collect-config 11.0.1 was released on master about 3 months ago, which worked because 12.0.0 (victoria) was not cut yet. But now that victoria is cut, 11.0.2 (and tripleo-ipsec 9.3.1) triggered an error. ----11.0.0------11.0.1-------12.0.0/11.0.2/13.0.0-------master \ -----stable/victoria ----9.3.0------10.0.0/11.0.0/9.3.1-----master \ ----- stable/victoria Given that os-collect-config 12.0.0/11.0.2/13.0.0 are the same commit and tripleo-ipsec 10.0.0/11.0.0/9.3.1 are the same commit, this might be solved by just cutting stable/ussuri on that same commit and reenqueuing the tag references in Zuul to trigger the jobs. I proposed https://review.opendev.org/c/openstack/releases/+/772995 to that effect. -- Thierry Carrez (ttx)

2 1

[rdo][ussuri][tripleo] use rsyslog by default for all OSP components and send them to undercloud
by Ruslanas Gžibovskis 29 Jan '21

29 Jan '21

Hi all, I would like to configure, during deployment, all OSP services save logs over rsyslog, not directly writing to files. I know OSP services support such. In most cases, services/modules write into files directly. Is there any TripleO option to set it all to logging over system logger? Also is there possibility, to send logs to centralised server, into undercloud, if to be precise? From there I want to send it to elastic, using rsyslog or send it to other log parser/analyser/storage. Have anyone met such articles/howtos/docs I could refer to tweak my config? -- Ruslanas Gžibovskis +370 6030 7030

2 2

Ussuri Trove trovestack problem
by Diaz, Santiago Miguel 28 Jan '21

28 Jan '21

Hi. Im new in Openstack. When I try to create Trove guest image with the next command ./trovestack build-image mariadb ubuntu xenial true ubuntu exit 1 obtain. Reading the logs I found: 2021-01-28 13:30:13.217 | [error] The following package is needed by the script, but not installed: 2021-01-28 13:30:13.218 | apt-transport-https 2021-01-28 13:30:13.218 | Please install and rerun the script. I resolved it changing then next file: /trove/integration/scripts/files/elements/ubuntu-guest/pre-install.d/04-baseline-tools - apt-get --allow-unauthenticated install -y language-pack-en python-software-properties software-properties-common + apt-get --allow-unauthenticated install -y language-pack-en python-software-properties software-properties-common apt-transport-https I hope it helps AVISO LEGAL: El presente correo electrónico y la información contenida en el mismo, es información privada y confidencial, está dirigida únicamente a su destinatario y no puede ser revelada a terceros, ni utilizada inapropiadamente en interés del destinatario. Excepto que se haya establecido expresamente de otra forma, éste correo electrónico y la mencionada información privada y confidencial no constituye una oferta, ni una promesa, ni una propuesta y no será interpretado como aceptación, ni como una tratativa pre-contractual, acuerdo parcial, contrato preliminar y/o pre-contrato, ni como un compromiso vinculante y/o declaración de voluntad oficial de TELECOM ARGENTINA S.A. Si Usted no es el destinatario original de éste mensaje y por ese medio pudo acceder a dicha información, por favor, elimine el mensaje. La distribución o copia de este mensaje esta estrictamente prohibida. La transmisión de e-mails no garantiza que el correo electrónico sea seguro o libre de error. Por consiguiente, no manifestamos que esta información sea completa o precisa. Toda información está sujeta a alterarse sin previo aviso. This email and the information contained herein are proprietary and confidential, and intended for the recipient only and cannot be disclosed to third parties or used inappropriately in the interest of the recipient. Except it has been expressly stated otherwise, the email and said private and confidential information are not an offer or promise, or a proposal and will not be construed as acceptance or as a pre-contractual negotiation, partial agreement, preliminary contract and / or pre-contract or binding commitment and/or an official statement of intent of TELECOM ARGENTINA S.A. If you are not the intended recipient of this message and thereby gained access to such information, please remove the message. Distribution or copying of this message is strictly prohibited. Transmission of e-mails does not guarantee that e-mail is safe or free from error. Therefore, we do not represent that this information is complete or accurate. All information is subject to change without notice.

2 1

[kolla][mariadb] failed to start a cluster
by Tony Liu 28 Jan '21

28 Jan '21

Hi, When running kolla-ansible to deploy 3 controller nodes (Ussuri), mariadb on node-1 started fine, but when start mariadb on node-2 and node-3 to join node-1, node-1 became nodor/desync and node-2 and node-3 complained "Member 2.0 (os-control-2) requested state transfer from '*any*', but it is impossible to select State Transfer donor: Resource temporarily unavailable". Ansible failed at "RUNNING HANDLER [mariadb : Wait for MariaDB service port liveness]" when timeout. What could be wrong here? Thanks! Tony

1 0

[tripleo] next irc meeting Tuesday Feb 02 @ 1400 UTC in #tripleo
by Marios Andreou 28 Jan '21

28 Jan '21

Reminder that the next TripleO irc meeting is: ** Tuesday 02 February at 1400 UTC in #tripleo ** ** https://wiki.openstack.org/wiki/Meetings/TripleO ** ** https://etherpad.opendev.org/p/tripleo-meeting-items ** Please add anything you want to hilight at https://etherpad.opendev.org/p/tripleo-meeting-items This can include recently completed things, ongoing review requests, blocking issues, or anything else tripleo you'd like to share. Our last meeting was on Jan 19 - you can find the logs there http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-01-19-14.… Hope you can make it on Tuesday, thanks, marios

1 0

2020 Open Infrastructure Foundation Annual Report
by Kendall Nelson 28 Jan '21

28 Jan '21

Hello Everyone :) Despite being a very different year than most, the Open Infrastructure community, which has over 110,000 community members, made it a productive and successful year. One of the biggest milestones that happened in the global community last year was that OpenStack, one of the top three most active open source projects with 15 million cores in production, marked its 10th anniversary in 2020. The Open Infrastructure Foundation would like to extend a huge thanks to the global community for all of the work that went into 2020 and is continuing in 2021 to help people build and operate open infrastructure. Check out the OpenStack community’s achievements in 2020 from the OpenInfra Foundation Annual Report[1] and join us <https://openinfra.dev/join/> to build the next decade of open infrastructure! -Kendall Nelson (diablo_rojo) [1] https://www.openstack.org/annual-reports/2020-openstack-foundation-annual-r…

1 0

Integration tests failing on ppc64le master branch
by aditi Dukle 28 Jan '21

28 Jan '21

2 1

[all] Proposed Xena cycle schedule
by Herve Beraud 28 Jan '21

28 Jan '21

Hey everyone, The Wallaby cycle is going by fast, and it's already time to start planning some of the early things for the Xena release. One of the first steps for that is actually deciding on the release schedule. Typically we have done this based on when the next Summit event was planned to take place. Due to several reasons, we don't have a date yet for the second 2021 event. The current thinking is it will likely take place in October (nothing is set, just an educated guess, so please don't use that for any other planning). So for the sake of figuring out the release schedule, we are proposing two schedules, one targeting a release date in mid of september, one targeting a release date in early October. Hopefully this will then align well with event plans. I have two proposed release schedule up for review here: - https://review.opendev.org/c/openstack/releases/+/772367 (23w) - https://review.opendev.org/c/openstack/releases/+/772357 (25w) Please feel free to comment on the patch if you see any major issues that we may have not considered. Thanks! -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 1

[neutron] Drivers meeting agenda - 29.01.2021
by Slawek Kaplonski 28 Jan '21

28 Jan '21

Hi, Agenda for tomorrow's drivers meeting is available at [1]. We have 2 things to discuss: * 1 RFE - [RFE] [QoS] add qos rule type packet per second (pps) [2] * 1 On demand topic - Do we want to apply for tag 'assert:supports-api-interoperability' - see [3] for details. See You tomorrow on the meeting. [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda [2] https://bugs.launchpad.net/neutron/+bug/1912460 [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019505… -- Slawek Kaplonski Principal Software Engineer Red Hat

2 2

Re: [Release-job-failures] Release of openstack/monasca-tempest-plugin for ref refs/tags/2.2.0 failed
by Herve Beraud 28 Jan '21

28 Jan '21

Hello monasca team, FYI a release failure happened on monasca-tempest-plugin within the job publish-monasca-tempest-plugin-docker-image. This build was triggered by https://review.opendev.org/c/openstack/releases/+/768551 (the Wallaby part). A new incompatibility in requirements was found by pip's new resolver: > pykafka 2.8.0 has requirement kazoo==2.5.0, but you'll have kazoo 2.8.0 which is incompatible. (c.f https://zuul.opendev.org/t/openstack/build/aba1acc623e74cf08e82ffc4d73134aa… ) I didn't find a trace of these requirements on your repo so I think they are pulled/resolved from/for underlying libraries. After that the job fails to push the "latest" docker tag because the tag is not found, I think it's a side effect of the previous error. (c.f https://zuul.opendev.org/t/openstack/build/aba1acc623e74cf08e82ffc4d73134aa… ) Let us know if we can help you, The Release Team. Le lun. 18 janv. 2021 à 23:31, <zuul(a)openstack.org> a écrit : > Build failed. > > - openstack-upload-github-mirror > https://zuul.opendev.org/t/openstack/build/8dd9a4fce3bc4ae2a32134b7d7fec5b5 > : SUCCESS in 52s > - release-openstack-python > https://zuul.opendev.org/t/openstack/build/ff7c8136563444df9c565f07f618c559 > : SUCCESS in 3m 44s > - announce-release > https://zuul.opendev.org/t/openstack/build/78731c6e0948490d82e1e2d14eb67857 > : SUCCESS in 3m 42s > - propose-update-constraints > https://zuul.opendev.org/t/openstack/build/3eab7a3209a84a33b8d7b69e41e185cb > : SUCCESS in 2m 49s > - publish-monasca-tempest-plugin-docker-image > https://zuul.opendev.org/t/openstack/build/aba1acc623e74cf08e82ffc4d73134aa > : POST_FAILURE in 8m 19s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

4 5

[osc-placement] placement_api_version in clouds.yaml not recognized
by jayaditya gupta 28 Jan '21

28 Jan '21

Hello it seems during plugin creation placement_api_version is not recognized by the osc-placement plugin. I have looked at other plugins too but can't seem to understand where the clouds.yaml file is loaded or referenced to get the desired value. Story : https://storyboard.openstack.org/#!/story/2008553 Would be helpful if i can get some pointers Thanks

1 0

[tc] weekly meeting
by Mohammed Naser 27 Jan '21

27 Jan '21

Hi everyone, Here’s the agenda for our weekly TC meeting. It will happen tomorrow (Thursday the 28th) at 1500 UTC in #openstack-tc and I will be your chair. If you can’t attend, please put your name in the “Apologies for Absence” section. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting # ACTIVE INITIATIVES * Follow up on past action items * Audit SIG list and chairs (diablo_rojo) - https://etherpad.opendev.org/p/2021-SIG-Updates - http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019994.… * Gate performance and heavy job configs (dansmith) - http://paste.openstack.org/show/jD6kAP9tHk7PZr2nhv8h/ * Dropping lower-constraints testing from all projects (gmann) - http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019672.… * Open Reviews - https://review.opendev.org/q/project:openstack/governance+is:open Thank you, Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[cinder] s3 backup driver status
by Brian Rosmaita 27 Jan '21

27 Jan '21

(I think there are time zone issues preventing the team working on the driver from attending the cinder weekly meeting, so I'm sending this update to the mailing list.) We discussed the proposed s3 backup driver [0] at today's cinder meeting. The code is looking good and the developers have been responsive to comments and doing quick revisions. The patch has one +2 and looks very close to being approved. One thing that's missing at this point is a comment on the review from one of the developers that they've deployed it with cinder and it works, and under what conditions it's been tested (that is, actually with S3, or only with the swift proxy). So please add such a comment to the review. This will allow us to merge the backup driver while you continue to work on getting the CI running [1]. We haven't required CI on backup drivers previously, so the cinder team has taken the position that lack of CI is not a reason to hold up the backup driver from merging. I want to stress, however, that we are excited that you are working on getting CI for the driver. The CI is looking close to completion as well (the holdup at the moment seems to be a problem with the swift proxy and recent versions of the boto library). The devstack support for this effort [2] is also looking good. [0] https://review.opendev.org/c/openstack/cinder/+/746561 [1] https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/772085 [2] https://review.opendev.org/c/openstack/devstack/+/770171

1 0

[infra][release] delete old EOL'd stable branches
by Előd Illés 27 Jan '21

27 Jan '21

Hi Infra Team! In October there was a discussion at Release Team meeting [1] about what can we do with the old, already EOL'd but not yet deleted branches (this is possible since with the Extended Maintenance process the general/"mass" EOL'ing was stopped and tagging a project branch EOL does not delete the branch anymore). Related to this, I would like to ask two things: 1. I've used the list_eol_stale_branches.sh [2] script to get the list of such not-yet-deleted branches for Ocata [3]. They are all tagged with 'ocata-eol', but stable/ocata branch still exists for them. Could you please delete these? [3] 2. On the Release Team meeting [1] we were hinted that with the newer version of gerrit (that was installed at the end of November) some automation is possible through gerrit API in the future. Can I get some help about where should I start with the automation? Which repository should I look, where can the deletion being triggered ("similarly like branch creation")? Thanks in advance, Előd [1] http://eavesdrop.openstack.org/meetings/releaseteam/2020/releaseteam.2020-1… [2] https://opendev.org/openstack/releases/src/commit/eb381492da3f7c826c35b9f14… [3] http://paste.openstack.org/show/801992/

4 9

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

27 Jan '21

Hi everyone, Our next Large Scale SIG meeting will be this Wednesday in #openstack-meeting-3 on IRC, at 15UTC. You can doublecheck how it translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210127T15 Our main topic will be to review progress and blockers on improving the documentation of various stages of our Scaling journey[1]. [1] https://wiki.openstack.org/wiki/Large_Scale_SIG Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Talk to you all later, -- Thierry Carrez

1 1

Secure RBAC work
by Lance Bragstad 27 Jan '21

27 Jan '21

Hey everyone, I wanted to take an opportunity to clarify some work we have been doing upstream, specifically modifying the default policies across projects. These changes are the next phase of an initiative that’s been underway since Queens to fix some long-standing security concerns in OpenStack [0]. For context, we have been gradually improving policy enforcement for years. We started by improving policy formats, registering default policies into code [1], providing better documentation for policy writers, implementing necessary identity concepts in keystone [2], developing support for those concepts in libraries [3][4][5][6][7][8], and consuming all of those changes to provide secure default policies in a way operators can consume and roll out to their users [9][10]. All of this work is in line with some high-level documentation we started writing about three years ago [11][12][13]. There are a handful of services that have implemented the goals that define secure RBAC by default, but a community-wide goal is still out-of-reach. To help with that, the community formed a pop-up team with a focused objective and disbanding criteria [14]. The work we currently have in progress [15] is an attempt to start applying what we have learned from existing implementations to other projects. The hope is that we can complete the work for even more projects in Wallaby. Most deployers looking for this functionality won't be able to use it effectively until all services in their deployment support it. I hope this helps clarify or explain the patches being proposed. As always, I'm happy to elaborate on specific concerns if folks have them. Thanks, Lance [0] https://bugs.launchpad.net/keystone/+bug/968696/ [1] https://governance.openstack.org/tc/goals/selected/queens/policy-in-code.ht… [2] https://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/… [3] https://review.opendev.org/c/openstack/keystoneauth/+/529665 [4] https://review.opendev.org/c/openstack/python-keystoneclient/+/524415 [5] https://review.opendev.org/c/openstack/oslo.context/+/530509 [6] https://review.opendev.org/c/openstack/keystonemiddleware/+/564072 [7] https://review.opendev.org/c/openstack/oslo.policy/+/578995 [8] https://review.opendev.org/q/topic:%22system-scope%22+(status:open%20OR%20s… [9] https://review.opendev.org/q/status:merged+topic:bp/policy-defaults-refresh… [10] https://review.opendev.org/q/topic:%22implement-default-roles%22+(status:op… [11] https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing… [12] https://docs.openstack.org/keystone/latest/admin/service-api-protection.html [13] https://docs.openstack.org/keystone/latest/contributor/services.html#author… [14] https://governance.openstack.org/tc/reference/popup-teams.html#secure-defau… [15] https://review.opendev.org/q/topic:%2522secure-rbac%2522+status:open

6 10

RE: [EXTERNAL] Re: [kolla][keystone] Another keycloak issue
by Braden, Albert 27 Jan '21

27 Jan '21

Another problem I'm encountering with keycloak is that the keycloak users can't login on the command line. I created user test2 via Keycloak and test3 via CLI. They have identical roles on the admin domain: (openstack) [root@chrnc-area51-build-01 ~]# os role assignment list --user test2 +----------------------------------+------------------------------------------------------------------+-------+----------------------------------+--------+--------+-----------+ | Role | User | Group | Project | Domain | System | Inherited | +----------------------------------+------------------------------------------------------------------+-------+----------------------------------+--------+--------+-----------+ | 406a5f1cd92d45b5b3d54979235e896c | f4287b6082b8f36048d052eaa3d35facb94e5eff598d59d2aee68252ddb13339 | | 15c32af517334e28a9427809a9fc4805 | | | False | +----------------------------------+------------------------------------------------------------------+-------+----------------------------------+--------+--------+-----------+ (openstack) [root@chrnc-area51-build-01 ~]# os role assignment list --user test3 +----------------------------------+----------------------------------+-------+----------------------------------+--------+--------+-----------+ | Role | User | Group | Project | Domain | System | Inherited | +----------------------------------+----------------------------------+-------+----------------------------------+--------+--------+-----------+ | 406a5f1cd92d45b5b3d54979235e896c | 06a5f28d061f4d42b3bf64df378338fd | | 15c32af517334e28a9427809a9fc4805 | | | False | +----------------------------------+----------------------------------+-------+----------------------------------+--------+--------+-----------+ I made identical env-setting "rc" files with only the username changed. Test3 logs in successfully but test2 fails: (openstack) [root@chrnc-area51-build-01 ~]# . ./test2-openrc.sh (openstack) [root@chrnc-area51-build-01 ~]# openstack server list The request you have made requires authentication. (HTTP 401) (Request-ID: req-ad7ee855-df98-434a-9afc-89f64a7addd1) (openstack) [root@chrnc-area51-build-01 ~]# . ./test3-openrc.sh (openstack) [root@chrnc-area51-build-01 ~]# openstack server list (openstack) [root@chrnc-area51-build-01 ~]# The only obvious difference is the longer UID for the Keycloak users. Do Keycloak-created users require something different in the env? Do I need to change something in Keycloak, to make the Keycloak users work the same as CLI-created users? Where can I look in the database to find the differences between these two users? RC files: (openstack) [root@chrnc-area51-build-01 ~]# cat test2-openrc.sh # Clear any old environment that may conflict. for key in $( set | awk '{FS="="} /^OS_/ {print $1}' ); do unset $key ; done export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_NAME=test2 export OS_TENANT_NAME=test2 export OS_USERNAME=test2 export OS_PASSWORD=<password> export OS_AUTH_URL=http://192.168.0.10:35357/v3 export OS_INTERFACE=internal export OS_ENDPOINT_TYPE=internalURL export OS_IDENTITY_API_VERSION=3 export OS_REGION_NAME=chrnc-area51-01 export OS_AUTH_PLUGIN=password export OS_CACERT=/etc/kolla/certificates/openstack.area51.dev.chtrse.com.pem (openstack) [root@chrnc-area51-build-01 ~]# cat test3-openrc.sh # Clear any old environment that may conflict. for key in $( set | awk '{FS="="} /^OS_/ {print $1}' ); do unset $key ; done export OS_PROJECT_DOMAIN_NAME=Default export OS_USER_DOMAIN_NAME=Default export OS_PROJECT_NAME=test export OS_TENANT_NAME=test export OS_USERNAME=test3 export OS_PASSWORD=<password> export OS_AUTH_URL=http://192.168.0.10:35357/v3 export OS_INTERFACE=internal export OS_ENDPOINT_TYPE=internalURL export OS_IDENTITY_API_VERSION=3 export OS_REGION_NAME=chrnc-area51-01 export OS_AUTH_PLUGIN=password export OS_CACERT=/etc/kolla/certificates/openstack.area51.dev.chtrse.com.pem E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

4 3

[tripleo] Removing tempest container from TripleO
by Chandan Kumar 27 Jan '21

27 Jan '21

Hello, In TripleO CI jobs, we used to run tempest tests using a tempest container via tripleo-quickstart-extras 's validate-tempest role. Nowadays, All the tempest execution is done via openstack-ansible-os_tempest role in TrIpleO CI job which is dependent on tempest rpms. Validate-tempest is also getting removed. Since the tempest container is no longer used and tested in CI. So we are removing it from TripleO. Here is the tripleo-common patch for Removing tempest container build: https://review.opendev.org/c/openstack/tripleo-common/+/771993 Thanks for reading. Thanks, Chandan Kumar

1 0

Trove Image Create Error
by Ammad Syed 27 Jan '21

27 Jan '21

Hi, I am creating a trove image with default parameters. ./trovestack build-image ubuntu bionic true ubuntu I am having below error . Please advise. 2021-01-26 13:19:24.905 | Installing collected packages: wheel, setuptools, pip 2021-01-26 13:19:25.292 | Attempting uninstall: pip 2021-01-26 13:19:25.293 | Found existing installation: pip 9.0.1 2021-01-26 13:19:25.294 | Uninstalling pip-9.0.1: 2021-01-26 13:19:25.309 | Successfully uninstalled pip-9.0.1 2021-01-26 13:19:26.231 | Successfully installed pip-21.0 setuptools-52.0.0 wheel-0.36.2 2021-01-26 13:19:26.761 | + python2 /tmp/get-pip.py -U --force-reinstall 2021-01-26 13:19:27.367 | Traceback (most recent call last): 2021-01-26 13:19:27.367 | File "/tmp/get-pip.py", line 24226, in <module> 2021-01-26 13:19:27.371 | main() 2021-01-26 13:19:27.371 | File "/tmp/get-pip.py", line 199, in main 2021-01-26 13:19:27.372 | bootstrap(tmpdir=tmpdir) 2021-01-26 13:19:27.372 | File "/tmp/get-pip.py", line 82, in bootstrap 2021-01-26 13:19:27.372 | from pip._internal.cli.main import main as pip_entry_point 2021-01-26 13:19:27.372 | File "/tmp/tmpxnphbN/pip.zip/pip/_internal/cli/main.py", line 60 2021-01-26 13:19:27.372 | sys.stderr.write(f"ERROR: {exc}") 2021-01-26 13:19:27.372 | ^ 2021-01-26 13:19:27.372 | SyntaxError: invalid syntax 2021-01-26 13:19:27.396 | ++ /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:run_in_target:59 : check_break after-error run_in_target bash 2021-01-26 13:19:27.409 | ++ /usr/lib/python3/dist-packages/diskimage_builder/lib/common-functions:check_break:143 : echo '' 2021-01-26 13:19:27.410 | ++ /usr/lib/python3/dist-packages/diskimage_builder/lib/common-functions:check_break:143 : egrep -e '(,|^)after-error(,|$)' -q 2021-01-26 13:19:27.428 | + /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:run_in_target:1 : trap_cleanup 2021-01-26 13:19:27.439 | + /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:trap_cleanup:36 : exitval=1 2021-01-26 13:19:27.447 | + /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:trap_cleanup:37 : cleanup 2021-01-26 13:19:27.457 | + /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:cleanup:42 : unmount_image -- Regards, Syed Ammad Ali

2 3

nova modify quota
by Ankele zhang 27 Jan '21

27 Jan '21

Hi~ I have an Rocky OpenStack platform on CentOS7.6. I need to delete some code about 'quota' in nova, because I build my baremetal node and my quota usage changed by nova. I have traced the Nova code by pdb, but I could not found the change quota usage place in nova. If ironic has config to avoid 'quota usage waste', or some good method to delete the code? Looking forward to your reply. Ankele

1 0

[all] CI test result table in the new gerrit review UI
by Balázs Gibizer 26 Jan '21

26 Jan '21

Hi, I understand that adapting the old CI test result table to the new gerrit review UI is not a simple task. As a temporary measure I hacked together a tampermonkey user script[1] that does a limited version of the CI table injection from the browser side. I tested it with recent chrome and firefox. Let me know if you have problems with it and I'll try to help. Also feel free to adapt it to your own needs. Cheers, gibi [1] https://gist.github.com/gibizer/717e0cb5b0da0d60d5ecf1e18c0c171a

15 34

[tact-sig][dev][infra][qa] OpenStack TaCT SIG 2021 Request for Help
by Jeremy Stanley 26 Jan '21

26 Jan '21

The tl;dr on this is that we need more volunteers to review CI job configuration and project creation requests for OpenStack, and if your proposed config changes are waiting longer to get reviewed than you like, consider that a not so gentle reminder that you bear some of the responsibility. Please read on and reach out if you'd like to help. Our community infrastructure, these days known as the OpenDev Collaboratory, is first and foremost a group effort for projects and their contributors to join forces in collectively maintaining the services and automation on which they rely. This has always been a bit of a "Tragedy of the Commons" situation, where it's all too easy for users of the commons to feel like it's someone else's job to maintain things. Unfortunately, when everyone feels this way, everyone also gets to suffer through the result. What we need is not just for people to avoid throwing trash on the ground when they visit the park, but for them to bring a trash bag (or bin liner, depending on your continent) along and collect a bit of rubbish they see along the way, even if it isn't theirs. The people who take some time out of their day to pick up after others in OpenStack are colloquially referred to as the Testing and Collaboration Tools Special Interest Group (TaCT SIG). Folks come and go over time, and lately we've had more going than coming, so could really use some new volunteers. Consider this a request that people who have (or are willing to invest in gaining) an understanding of things like our job configuration and project creation process make themselves known and pitch in on reviews. We're happy to fast-track approval rights for anyone who shows they can reliably evaluate these changes. Now down to the nitty-gritty details... if you're inclined to help, first and foremost let me or other TaCT SIG reviewers know so we can make sure to prioritize your input. Then take a look at open reviews in particular for the openstack/project-config and openstack/openstack-zuul-jobs repositories. Beyond that, checking through changes for opendev/base-jobs and zuul/zuul-jobs would also be great as they tend to get intertwined with OpenStack's job changes anyway. Not skipping changes which are failing CI results is really helpful too, since change authors often don't understand what the failure result is trying to tell them to fix. Further, answering job-related questions in IRC or on mailing lists helps spread out that load for the rest of us as well. The quickest way to get started is to join the #openstack-infra channel on the Freenode IRC network, and the #opendev and #opendev-meeting channels too if you like. You may want to set up a highlight in your IRC client for the string "config-core" which is what we've standardized on to try and bring things to the attention of the configuration core reviewers. When there are changes you've looked over and you think are probably ready to merge, let us know (#openstack-infra for OpenStack-related changes, non-OpenStack-specific things in #opendev). Mention config-core when you do so, to get our attention. If you have questions, I'm happy to answer them. You can reply on-list or in private to this message, or ask in #openstack-infra on IRC (I'm "fungi" in there if you need me). -- Jeremy Stanley, your humble OpenStack TaCT SIG chair

1 0

Trove Image Create Error
by Ammad Syed 26 Jan '21

26 Jan '21

Hi, I am creating a trove image with default parameters. ./trovestack build-image ubuntu bionic true ubuntu I am having below error . Please advise. 2021-01-26 13:19:24.905 | Installing collected packages: wheel, setuptools, pip 2021-01-26 13:19:25.292 | Attempting uninstall: pip 2021-01-26 13:19:25.293 | Found existing installation: pip 9.0.1 2021-01-26 13:19:25.294 | Uninstalling pip-9.0.1: 2021-01-26 13:19:25.309 | Successfully uninstalled pip-9.0.1 2021-01-26 13:19:26.231 | Successfully installed pip-21.0 setuptools-52.0.0 wheel-0.36.2 2021-01-26 13:19:26.761 | + python2 /tmp/get-pip.py -U --force-reinstall 2021-01-26 13:19:27.367 | Traceback (most recent call last): 2021-01-26 13:19:27.367 | File "/tmp/get-pip.py", line 24226, in <module> 2021-01-26 13:19:27.371 | main() 2021-01-26 13:19:27.371 | File "/tmp/get-pip.py", line 199, in main 2021-01-26 13:19:27.372 | bootstrap(tmpdir=tmpdir) 2021-01-26 13:19:27.372 | File "/tmp/get-pip.py", line 82, in bootstrap 2021-01-26 13:19:27.372 | from pip._internal.cli.main import main as pip_entry_point 2021-01-26 13:19:27.372 | File "/tmp/tmpxnphbN/pip.zip/pip/_internal/cli/main.py", line 60 2021-01-26 13:19:27.372 | sys.stderr.write(f"ERROR: {exc}") 2021-01-26 13:19:27.372 | ^ 2021-01-26 13:19:27.372 | SyntaxError: invalid syntax 2021-01-26 13:19:27.396 | ++ /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:run_in_target:59 : check_break after-error run_in_target bash 2021-01-26 13:19:27.409 | ++ /usr/lib/python3/dist-packages/diskimage_builder/lib/common-functions:check_break:143 : echo '' 2021-01-26 13:19:27.410 | ++ /usr/lib/python3/dist-packages/diskimage_builder/lib/common-functions:check_break:143 : egrep -e '(,|^)after-error(,|$)' -q 2021-01-26 13:19:27.428 | + /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:run_in_target:1 : trap_cleanup 2021-01-26 13:19:27.439 | + /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:trap_cleanup:36 : exitval=1 2021-01-26 13:19:27.447 | + /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:trap_cleanup:37 : cleanup 2021-01-26 13:19:27.457 | + /usr/lib/python3/dist-packages/diskimage_builder/lib/img-functions:cleanup:42 : unmount_image -- Regards, Syed Ammad Ali

2 1

[ironic] Having a regular review jam - Lets figure out a day/time?
by Julia Kreger 26 Jan '21

26 Jan '21

Greetings my fellow bringiners of irony! Yesterday, during our virtual midcycle meeting[0], we discussed having review jams in order to help facilitate working through some of the large volumes of patches. An example of a case where this will be necessary being the Secure RBAC work. As agreed yesterday, I've created a poll[1] to try and identify the best day of the week and time of day for us to have this get together to review patch chains, spread context of the changes, and discuss further. If you can, please reply to the poll in the next week and from there I'll go ahead and get something on a calendar. In all likelihood, I may actually send calendar invites for this, if that is acceptable for folks. Thanks everyone, and have a wonderful week! -Julia [0]: https://etherpad.opendev.org/p/ironic-wallaby-midcycle [1]: https://doodle.com/poll/mdv6vpw6qdfzteg2

1 0

[tripleo] move os-refresh-config, os-collect-config, tripleo-ipsec to 'release-management': none
by Marios Andreou 26 Jan '21

26 Jan '21

Hi TripleO, you may have seen the thread started by Herve at [1] around the deadline for making a victoria release for os-refresh-config, os-collect-config and tripleo-ipsec. This message is to ask if anyone is still using these? In particular would anyone mind if we stopped making tagged releases, as discussed at [2]. Would someone mind if there was no stable/victoria branch for these repos? For the os-refresh/collect-config I suspect the answer is NO - at least, we aren't using these any more in the 'normal' tripleo deployment for a good while now, since we switched to config download by default. We haven't even created an ussuri branch for these [3] and no one has shouted about that (or at least not loud enough I haven't heard anything). For tripleo-ipsec it *looks* like we're still using it in the sense that we carry the template and pass the parameters in tripleo-heat-templates [4]. However we aren't running that in any CI job as far as I can see, and we haven't created any branches there since Rocky. So is anyone using tripleo-ipsec? Depending on the answers here and as discussed at [2] I will move to make these as unreleased (release-management: none in openstack/governance reference/projects.yaml) and remove the release file altogether. For now however and given the deadline of this week for a victoria release I am proposing that we move forward with [2] and cut the victoria branch for these. thanks for reading and please speak up if any of the above are important to you! thanks, marios [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019730.… [2] https://review.opendev.org/c/openstack/releases/+/769915/1/deliverables/vic… [3] https://pastebin.com/raw/KJ0JxKPx [4] https://opendev.org/openstack/tripleo-heat-templates/src/commit/9fd709019fd…

5 8

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

26 Jan '21

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

1 0

[tc] weekly update
by Mohammed Naser 26 Jan '21

26 Jan '21

Hi everyone, Here's an update on what happened in the OpenStack TC this week. You can get more information by checking for changes in the openstack/governance repository. # Patches ## Open Reviews - [manila] add assert:supports-api-interoperability https://review.opendev.org/c/openstack/governance/+/770859 - Define Xena release testing runtime https://review.opendev.org/c/openstack/governance/+/770860 - Setting Ke Chen as Watcher's PTL https://review.opendev.org/c/openstack/governance/+/770913 - Cool-down cycle goal https://review.opendev.org/c/openstack/governance/+/770616 - Drop openSUSE from commonly tested distro list https://review.opendev.org/c/openstack/governance/+/770855 - Define 2021 upstream investment opportunities https://review.opendev.org/c/openstack/governance/+/771707 - js-openstack-lib does not make releases https://review.opendev.org/c/openstack/governance/+/771789 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/c/openstack/governance/+/759904 - Move openstack-tempest-skiplist to release-management: none https://review.opendev.org/c/openstack/governance/+/771488 - monasca-log-api & monasca-ceilometer does not make releases https://review.opendev.org/c/openstack/governance/+/771785 - Remove Karbor project team https://review.opendev.org/c/openstack/governance/+/767056 - WIP NO MERGE Move os-*-config to Heat project governance https://review.opendev.org/c/openstack/governance/+/770285 ## Abandoned Reviews - Add QA in 2021 upstream investment opportunities https://review.opendev.org/c/openstack/governance/+/771708 - Add RBAC work in 2021 upstream investment opportunities https://review.opendev.org/c/openstack/governance/+/771709 # Other Reminders - Our next [TC] Weekly meeting is scheduled for January 28th at 1500 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, January 27th, at 2100 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

[kolla] Keycloak "More than one user" error
by Braden, Albert 26 Jan '21

26 Jan '21

We're running Train on Centos 7, and using Keycloak for auth. After I setup Keycloak, create a user in Keycloak, and then login to Horizon via Keycloak, a user is created in Keystone: | ccb276f4f507fd9f271d629d2ad896d2c97e04f81336cd8c1332f4b2df115ca2 | test | If I try to address that user by name, I get an error: (openstack) [root@chrnc-area51-build-01 our-ok-kolla-ansible]# os user show test More than one user exists with the name 'test'. I can address it by id. When I list users, I only see one "test" user." (openstack) [root@chrnc-area51-build-01 our-ok-kolla-ansible]# os user show ccb276f4f507fd9f271d629d2ad896d2c97e04f81336cd8c1332f4b2df115ca2 +---------------------+------------------------------------------------------------------+ | Field | Value | +---------------------+------------------------------------------------------------------+ | domain_id | 4678301ef9a24d54bcd2e87a8fbc6872 | | email | test(a)example.com | If I create a second user in Keycloak and login the same way, this doesn't happen: (openstack) [root@chrnc-area51-build-01 our-ok-kolla-ansible]# os user show test2 +---------------------+------------------------------------------------------------------+ | Field | Value | +---------------------+------------------------------------------------------------------+ | domain_id | 4678301ef9a24d54bcd2e87a8fbc6872 | | email | test2(a)example.com | These 2 users look identical in the database: user: | ccb276f4f507fd9f271d629d2ad896d2c97e04f81336cd8c1332f4b2df115ca2 | {"email": "test(a)example.com"} | 1 | NULL | 2021-01-22 18:33:20 | NULL | 4678301ef9a24d54bcd2e87a8fbc6872 | | f4287b6082b8f36048d052eaa3d35facb94e5eff598d59d2aee68252ddb13339 | {"email": "test2(a)example.com"} | 1 | NULL | 2021-01-22 21:01:54 | NULL | 4678301ef9a24d54bcd2e87a8fbc6872 | federated_user: | 6 | ccb276f4f507fd9f271d629d2ad896d2c97e04f81336cd8c1332f4b2df115ca2 | keycloak | openid | test | test | | 9 | f4287b6082b8f36048d052eaa3d35facb94e5eff598d59d2aee68252ddb13339 | keycloak | openid | test2 | test2 | Where should I be looking for the cause of this error? I apologize for the nonsense below. So far I have not been able to stop it from being attached to my external emails. I'm working on it. E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

2 2

Re: [nova][dev] Revisiting qemu emulation where guest arch != host arch
by Apsey, Christopher 26 Jan '21

26 Jan '21

Resurrecting this old thread… The first bits of work for this are starting to be submitted for review: https://review.opendev.org/c/openstack/nova/+/772156 The developer is going to go through the rest of the tcg guest supported architectures in QEMU and add them in (he only has aarch64 done right now) which will require a bit of time/testing, but we hope to have it ready to go for potential inclusion in wallaby. Any comments from nova team on approach/implementation are welcome. Chris Apsey GEORGIA CYBER CENTER From: Sean Mooney <smooney(a)redhat.com> Sent: Wednesday, July 15, 2020 10:37 AM To: Apsey, Christopher <CAPSEY(a)augusta.edu>; openstack-discuss(a)lists.openstack.org Cc: Belmiro Moreira <moreira.belmiro.email.lists(a)gmail.com> Subject: [EXTERNAL] Re: [nova][dev] Revisiting qemu emulation where guest arch != host arch CAUTION: EXTERNAL SENDER This email originated from an external source. Please exercise caution before opening attachments, clicking links, replying, or providing information to the sender. If you believe it to be fraudulent, contact the AU Cybersecurity Hotline at 72-CYBER (2-9237 / 706-722-9237) or 72CYBER(a)augusta.edu<mailto:72CYBER@augusta.edu> On Wed, 2020-07-15 at 14:17 +0000, Apsey, Christopher wrote: > All, > > A few years ago I asked a question[1] about why nova, when given a hw_architecture property from glance for an image, > would not end up using the correct qemu-system-xx binary when starting the guest process on a compute node if that > compute nodes architecture did not match the proposed guest architecture. As an example, if we had all x86 hosts, but > wanted to run an emulated ppc guest, we should be able to do that given that at least one compute node had qemu- > system-ppc already installed and libvirt was successfully reporting that as a supported architecture to nova. It > seemed like a heavy lift at the time, so it was put on the back burner. > > I am now in a position to fund a contract developer to make this happen, so the question is: would this be a useful > blueprint that would potentially be accepted? this came up during the ptg and the over all felling was it should really work already and if it does not its a bug. so yes i fa blueprint was filed to support emulation based on the image hw_architecture property i dont think you will get objection altough we proably will want to allso have schduler support for this and report it to placemnt or have a whigher of some kind to make it a compelte solution. i.e. enhance the virt driver to report all the achitecure it support via traits and add a weigher to prefer native execution over emulation. so placement can tell use where it can run and the weigher can say where it will run best. see line 467 https://etherpad.opendev.org/p/nova-victoria-ptg<https://protect-us.mimecast.com/s/2eFkClYVvJcywrxruqA7hQ> > Most of the time when people want to run an emulated guest they would just nest it inside of an already running > guest of the native architecture, but that severely limits observability and the task of managing any more than a > handful of instances in this manner quickly becomes a tangled nightmare of networking, etc. I see real benefit in > allowing this scenario to run natively so all of the tooling that exists for fleet management 'just works'. This > would also be a significant differentiator for OpenStack as a whole. > > Thoughts? > > [1] > http://lists.openstack.org/pipermail/openstack-operators/2018-August/015653…<https://protect-us.mimecast.com/s/_HyfCmZV2KiZoxzxiQsIGH> > > Chris Apsey > Director | Georgia Cyber Range > GEORGIA CYBER CENTER > > 100 Grace Hopper Lane | Augusta, Georgia | 30901 > https://www.gacybercenter.org<https://protect-us.mimecast.com/s/n5XeCn5VYLTzZEvEFEjrF-> >

1 0

[neutron] bug deputy report for week of 2021-01-18
by Bence Romsics 25 Jan '21

25 Jan '21

Hi Neutron Team, Last week's new bugs: High: * https://bugs.launchpad.net/neutron/+bug/1912359 [OVN] Add support for WSGI mod Lack of feature parity in OVN * https://bugs.launchpad.net/neutron/+bug/1912369 [FT] "test_gateway_chassis_rebalance" failing because lrp is not bound Rare gate failure, assigned to Rodolfo. * https://bugs.launchpad.net/neutron/+bug/1912450 flows on br-int wasn't been deleted completely Fix in progress: https://review.opendev.org/c/openstack/neutron/+/771903 * https://bugs.launchpad.net/neutron/+bug/1912779 [ovn-octavia-provider]: batch update fails when members to remove is empty Fix in progress: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/771971 Medium: * https://bugs.launchpad.net/neutron/+bug/1912320 TestTimer breaks VPNaaS functional tests Fix merged: https://review.opendev.org/c/openstack/neutron/+/771436 * https://bugs.launchpad.net/neutron/+bug/1912596 neutron-server report 500 error when update floating ip port forwarding Fix in progress: https://review.opendev.org/c/openstack/neutron/+/771776 * https://bugs.launchpad.net/neutron/+bug/1912651 ovs flows are not readded when ovsdb-server/ovs-vswitchd are restarted. Unassigned Low: * https://bugs.launchpad.net/neutron/+bug/1912948 Missing option for OSP16.2 OVN migration RFE: * https://bugs.launchpad.net/neutron/+bug/1912460 [RFE] [QoS] add qos rule type packet per second (pps) * https://bugs.launchpad.net/neutron/+bug/1912672 [RFE] Enable set quota per floating-ips pool. Incomplete: * https://bugs.launchpad.net/neutron/+bug/1912379 Neutron causes systemd to hang on Linux guests with SELinux disabled * https://bugs.launchpad.net/neutron/+bug/1912513 Port creation fails with error IP already allocated but the IP is available Cheers, Bence

1 0

Re: [openstack-dev] [neutron][taas] Proposal of Dashboard for TaaS
by Madhuwantha priyashan 25 Jan '21

25 Jan '21

Dear sir, I am an undergraduate student and I am doing a project using OpenStack now. I need to install tap as a service in OpenStack but I could not find any guideline for this. It is great full if u can provide guidelines for this task. Thank you

3 3

Syntribos
by Matei Goga 24 Jan '21

24 Jan '21

Hi, Was wondering if there was a replacement for Syntribos or some equivalent project that could be used to pentest an OpenStack deployment. Much thanks! ~ Matei

1 0

pip 21 heads-up (Python 2 support gone)
by Radosław Piliszek 24 Jan '21

24 Jan '21

Hello Fellow OpenStackers, Please notice pip 21 was released just yesterday. It means Python 2 is no longer supported. Upgrading pip to latest on Python 2 may render pip unusable (as ancient pip may not consider 21 an unsupported version and install it nonetheless). Similarly, using default get-pip.py on Python 2 no longer works. There is, however, https://bootstrap.pypa.io/2.7/get-pip.py for those that want to use get-pip.py on Python 2. Kind regards, -yoctozepto

1 0

Re: [tripleo][ussuri][centos8] overcloud deploy fails with no valid host was found, GRUB2 cannot mount with regular user
by Ruslanas Gžibovskis 24 Jan '21

24 Jan '21

Should i try keep only ironic-python-agent-ramdisk ? In my overcloud-image yaml? On Sat, 23 Jan 2021, 23:28 Julia Kreger, <juliaashleykreger(a)gmail.com> wrote: > I'm not so sure about that. Note the different > "ironic-python-agent-ramdisk" versus "ironic-agent" in > > https://github.com/openstack/tripleo-common/blob/stable/ussuri/image-yaml/o… > > On Fri, Jan 22, 2021 at 3:02 PM Ruslanas Gžibovskis <ruslanas(a)lpic.lt> > wrote: > > > > Hi all, > > > > I am trying to build some cloud again and failing with [1]. I think this > is a most critical line. It fails during GRUB2 deployment on overcloud > image, I believe main error message is: mount: only root can do that. I > used the following steps to create image: > > > > cp -ar /etc/yum.repos.d repos > > # enable: repos/CentOS-HA.repo > > sed -i "s/enabled=0/enabled=1/g" repos/CentOS-Linux-HighAvailability.repo > > sed -i "s/gpgcheck=1/gpgcheck=0/g" repos/*repo > > export DIB_YUM_REPO_CONF="$(ls $(pwd)/repos/*repo)" > > export STABLE_RELEASE="ussuri" > > source /home/stack/stackrc > > mkdir /home/stack/images > > cd /home/stack/images > > openstack overcloud image build --config-file > /home/stack/overcloud-images-python3.yaml > > openstack overcloud image upload --update-existing > > # openstack overcloud node configure --all-manageable > > > > overcloud-images-python3.yaml file content can be found here [2], just > added additional packages, such as tcpdump, iperf, iptraf and so on... > > And steps from link [3] to set root pass to troubleshoot if needed. > > > > any thoughts? Maybe there were some changes recently (from 22 of > December) PRevious images from there. Thank you for your thoughts and > attention. > > > > [1] http://paste.openstack.org/show/GDYriAXxQniZTPQGJGbH/ > > [2] http://paste.openstack.org/show/2tkVFdwSZ0QMjoJKmOrm/ > > [3] > https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16… > > > > > > -- > > Ruslanas Gžibovskis > > +370 6030 7030 >

1 0

[review] oslo.messaging patterns in various projects
by Erik Olof Gunnar Andersson 23 Jan '21

23 Jan '21

I was helping troubleshoot an issue with Magnum recently and found out that there was a minor issue with how they handle RPC connections, and decided to do an audit of all OpenStack projects and found a bunch that are likely to be experiencing similar issues. The gist of the issue is that most of these projects creates a new rpc transport on every API call. If someone has some time over to help review these fixes, I would be grateful. https://review.opendev.org/c/openstack/magnum/+/770707 - Re-use transport for rpc calls https://review.opendev.org/c/openstack/magnum/+/770720 - Re-use transport for rpc server https://review.opendev.org/c/openstack/blazar/+/771110 - Re-use rpc transport https://review.opendev.org/c/openstack/solum/+/771111 - Re-use rpc transport https://review.opendev.org/c/openstack/murano/+/771341 - Use common rpc pattern for all services https://review.opendev.org/c/openstack/watcher/+/771381 - Use common rpc pattern for all services I tried to use a standardized approach with all of these, but feel free to add any feedback.

1 0

[tripleo][ussuri][centos8] overcloud deploy fails with no valid host was found, GRUB2 cannot mount with regular user
by Ruslanas Gžibovskis 23 Jan '21

23 Jan '21

Hi all, I am trying to build some cloud again and failing with [1]. I think this is a most critical line. It fails during GRUB2 deployment on overcloud image, I believe main error message is: mount: only root can do that. I used the following steps to create image: cp -ar /etc/yum.repos.d repos # enable: repos/CentOS-HA.repo sed -i "s/enabled=0/enabled=1/g" repos/CentOS-Linux-HighAvailability.repo sed -i "s/gpgcheck=1/gpgcheck=0/g" repos/*repo export DIB_YUM_REPO_CONF="$(ls $(pwd)/repos/*repo)" export STABLE_RELEASE="ussuri" source /home/stack/stackrc mkdir /home/stack/images cd /home/stack/images openstack overcloud image build --config-file /home/stack/overcloud-images-python3.yaml openstack overcloud image upload --update-existing # openstack overcloud node configure --all-manageable overcloud-images-python3.yaml file content can be found here [2], just added additional packages, such as tcpdump, iperf, iptraf and so on... And steps from link [3] to set root pass to troubleshoot if needed. any thoughts? Maybe there were some changes recently (from 22 of December) PRevious images from there. Thank you for your thoughts and attention. [1] http://paste.openstack.org/show/GDYriAXxQniZTPQGJGbH/ [2] http://paste.openstack.org/show/2tkVFdwSZ0QMjoJKmOrm/ [3] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16… -- Ruslanas Gžibovskis +370 6030 7030

2 5

[SIG] [all] [TC] [Automation] [Cloud Research] [k8s] [Containers] [Multi Arch] [Packaging] [PowerVMStacker] [Public Cloud] [Resource Management] Updates Required?
by Kendall Nelson 22 Jan '21

22 Jan '21

Hello Everyone! I don't know if any of you have looked at the sigs governance[0] site lately, but there are a number of SIGs that seem to have out of date statuses and/or chairs listed that are no longer active in the community. >From what I can tell, the following list of SIGs could maybe use some updating. - Automation - Cloud Research - Containers - k8s - Multi Arch - Packaging - PowerVMStacker - Public Cloud - Resource Management I have created an etherpad[1] with all the SIGs for more cohesive discussion on changes. Please make comments there! I am happy to push the updates if things need to change; I just need to know what to change it to. Tangentially related, kudos Rico for chairing the most SIGs by far! -Kendall Nelson (diablo_rojo) [0] https://governance.openstack.org/sigs/ [1] https://etherpad.opendev.org/p/2021-SIG-Updates

1 0

Re: [nova] unit testing on ppc64le
by aditi Dukle 21 Jan '21

21 Jan '21

2 3

[infra][ci] no more 3rd party CI test result in gerrit
by Lu, Lianhao 21 Jan '21

21 Jan '21

Hi All, I noticed that we're no longer be able to see the 3rd party CI test results in most of the projects in openstack gerrit, such as nova, neutron. But we can still see them in the ci-sandbox project. I'm wondering how to see those test results in gerrit now? Thanks! BR, -Lianhao

1 0

[tempest] extending python-tempestconf
by Szabolcs Tóth 21 Jan '21

21 Jan '21

Hej! The official tool named python-tempestconf has a parameter named --create, which allows to create the following resources: * CirrOS image (uploads the image based on the location defined with --image parameter), * Flavors (based on default values - DEFAULT_FLAVOR_RAM, DEFAULT_FLAVOR_RAM_ALT, DEFAULT_FLAVOR_DISK - which can be changed with --flavor-min-mem and --flavor-min-disk). In order to verify our specific installation with Tempest, we need to create the basic resources as * Flavors (with extra-spec parameters like hw:mem_page_size). * Networks (one for fixed_network_name and one for floating_network_name). * python-tempestconf is able to find an already existing network created with router:external flag and set it as value for floating_network_name. * Router and port (for routing traffic between internal and external networks). I would like to ask the following: * Is there any particular reason why the basic resource create functionality is limited to the image and flavor? * Are there any plans to extend the basic resource create functionality? * Ability to set extra parameters for the flavors. * Creating networks, routers and ports (based on a user inputs, which can be separate parameters or a specific file). Would the community accept contributions extending python-tempestconf into this direction? -- BR, Szabolcs

3 2

[All] copyright
by Kanevsky, Arkady 21 Jan '21

21 Jan '21

We have in a few places openstack copyright: # Copyright (c) 2020 OpenStack Foundation Should we use OpenInfra copyright going forward? Something like # Copyright (c) 20XX Open Infrastructure Foundation Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell EMC office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

3 3

[barbican][release] Barbican deliverables questions
by Herve Beraud 21 Jan '21

21 Jan '21

Hi Barbican Team, The release team noticed some inconsistencies between the Barbican team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). First, we noticed that ansible-role-atos-hsm and ansible-role-thales-hsm are new barbican deliverables, and we would appreciate to know if we should plan to release them for Wallaby. The second thing is that barbican-ui (added in Oct 2019) was never released yet and was not ready yet for ussuri and victoria. maybe we should abandon this instead of waiting? Notice that Wallaby's milestone 2 is next week so it could be the good time to update all these things. Let us know your thoughts, we are waiting for your replies. Thanks for reading, [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-re… -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

2 2

[neutron]Drivers meeting agenda - 22.01.2021
by Slawek Kaplonski 21 Jan '21

21 Jan '21

Hi, Agenda for tomorrow's drivers meeting is at [1]. We have one RFE ready to discuss: - https://bugs.launchpad.net/neutron/+bug/1911126 We also have 2 new things which are now triaging, so please take a look at them if You have some time and ask questions if You have any: - https://bugs.launchpad.net/neutron/+bug/1912460 - https://bugs.launchpad.net/neutron/+bug/1911864 [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[Octavia] Network issue between amphora and health manager port
by CHANU ROMAIN 21 Jan '21

21 Jan '21

Hello, I try to install Octavia and i'm facing an issue with octavia-health- manager-listen-port interface. I use Openstack Ussuri on Ubuntu 18.04 with linuxbridge plugin I followed this procedure: https://docs.openstack.org/octavia/latest/install/install-ubuntu.html#insta… When I try to create my loadbalancer I got this error: WARNING octavia.amphorae.drivers.haproxy.rest_api_driver [-] Could not connect to instance. Retrying.: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='10.244.3.243', port=9443): Max retries exceeded with url: // (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7fe1ec077080>: Failed to establish a new connection: [Errno 113] No route to host',)) From my interface "o-hm0" I cannot ping 10.244.3.243 but if I try to ping from DHCP namespace it works fine. I think the problem is my "octavia-health-manager-listen-port" port appears "DOWN" when I list every ports. I figured out than Neutron didnt update iptables rules, probably because the interface is DOWN but if I add these rules: iptables -A neutron-linuxbri-FORWARD -m physdev --physdev-out o-bhm0 -- physdev-is-bridged -m comment --comment "Accept all packets when port is trusted." -j ACCEPT iptables -A neutron-linuxbri-FORWARD -m physdev --physdev-in o-bhm0 -- physdev-is-bridged -m comment --comment "Accept all packets when port is trusted." -j ACCEPT Amphora is able to communication with health manager port then the loadbalancer becomes UP but now I got this WARNING: 2021-01-21 15:27:21.230 2999834 WARNING octavia.amphorae.drivers.health.heartbeat_udp [-] Health Manager experienced an exception processing a heartbeat message from ('10.244.3.243', 30684). Ignoring this packet. Exception: 'NoneType' object has no attribute 'encode' I guess it's all about the port being stuck in DOWN state. Do you have any input how to configure this port? Best regards, Romain

2 1

[monasca][release] Abandoning monasca-ceilometer and monasca-log-api?
by Herve Beraud 21 Jan '21

21 Jan '21

Dear Monasca team, The release team noticed an inconsistency between the Monasca team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). Indeed, monasca-ceilometer and monasca-log-api were released in train but not released in ussuri nor victoria. Do you think that they should be deprecated (abandoned) in governance? Notice that Wallaby's milestone 2 is next week so maybe it could be a good time to update this. Let us know your thoughts, we are waiting for your replies. Thanks for reading, [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-re… -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

3 4

[tc] weekly meeting
by Mohammed Naser 21 Jan '21

21 Jan '21

Hi everyone, Here’s the agenda for our weekly TC meeting. It will happen tomorrow (Thursday the 21st) at 1500 UTC in #openstack-tc and I will be your chair. If you can’t attend, please put your name in the “Apologies for Absence” section https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting # ACTIVE INITIATIVES * Follow up on past action items * Audit SIG list and chairs (diablo_rojo) * Add Resolution of TC stance on the OpenStackClient (diablo_rojo) - https://review.opendev.org/c/openstack/governance/+/759904 * Gate performance and heavy job configs (dansmith) - http://paste.openstack.org/show/jD6kAP9tHk7PZr2nhv8h/ * Audit and clean-up tags (gmann) - 'supports-api-interoperability' tag - Manila request: https://review.opendev.org/c/openstack/governance/+/770859 * infra-core team (mnaser / diablo_rojo) - Stepping up to help with review load that will be new to everyone * Dropping lower-constraints testing from all projects (gmann) - http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019672.… * Decide on OpenSUSE in testing runtime (gmann) - https://review.opendev.org/c/openstack/devstack/+/769884 * Define 2021 upstream investment opportunities - https://review.opendev.org/c/openstack/governance/+/771707 * Open Reviews - https://review.opendev.org/q/project:openstack/governance+is:open Thank you Mohammed -- Mohammed Naser VEXXHOST, Inc.

1 0

[OpenStackSDK][release] Abandoning js-openstack-lib?
by Herve Beraud 21 Jan '21

21 Jan '21

Dear OpenStackSDK team, The release team noticed an inconsistency between the OpenStackSDK team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). Indeed, js-openstack-lib (added January 9, 2020) was never released yet and was not ready for ussuri or victoria. maybe we should abandon this instead of waiting? Notice that Wallaby's milestone 2 is next week so maybe it could be a good time to update this. Let us know your thoughts, we are waiting for your replies. Thanks for reading, [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-re… -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

2 2

[all][tc][goals] Migrate RBAC Policy Format from JSON to YAML: Week R-16 Update
by Ghanshyam Mann 20 Jan '21

20 Jan '21

Hello Everyone, Please find the week's R-16 updates on 'Migrate RBAC Policy Format from JSON to YAML' community-wide goals. Tracking: https://etherpad.opendev.org/p/migrate-policy-format-from-json-to-yaml Gerrit Topic: https://review.opendev.org/q/topic:%22policy-json-to-yaml%22+(status:open%2… Progress: ======= * Projects completed: 5 * Projects left to merge the patches: 25 * Projects left to push the patches: 2 (horizon and Openstackansible) * Projects do not need any work: 17 Updates: ======= * I have pushed the patches for all the required service projects. ** Because of many services gate is already broken for lower constraints job, these patches might not be green in the test results. I request projects to fix the gate so that we can merge this goal work before m-2. ** There are many project tests where CONF object was not fully initialized before the policy is init. This was working till now as policy init did not use the CONF object but oslo_policy 3.6.0 onwards it needs fully initialized CONF object during init only. ** Aodh work for this goal is blocked because it needs oslo_policy 3.6.0 but gnocchi is capped for oslo_policy 3.4.0 [1] - https://review.opendev.org/c/openstack/aodh/+/768499 * Horizon and Openstackansible work is pending to use/deploy the YAML formatted policy file. I will start exploring this next week or so. [1] https://github.com/gnocchixyz/gnocchi/blob/e19fda590c7f7f07f1df0ba93177df07… Merry Christmas and Happy Holidays! -gmann

6 11

[cinder] wallaby new driver status
by Brian Rosmaita 20 Jan '21

20 Jan '21

At today's Cinder meeting [0] we discussed the unmerged proposed drivers (3 volume drivers, 1 backup driver) in light of tomorrow's new driver merge deadline. Here's a summary of what we decided: 1. s3 cinder backup driver https://review.opendev.org/c/openstack/cinder/+/746561 The code looks basically OK but the driver hasn't been independently tested. There's a proposed CI job but it currently isn't passing. ==> plan: aim for two +2s on the patch before the merge deadline, but hold off on merging until we have confirmation that the driver works, hopefully but the CI working by next week (Thursday 28 January). 2. TOYOU ACS5000 driver https://review.opendev.org/c/openstack/cinder/+/767290/ Code is looking good and they've been good about quickly revising patches. The CI is running and driver is passing tempest and cinder-tempest-plugin tests, though it's not reporting reliably on patches. They've agreed to get their CI responding properly by milestone-3. ==> plan: the requested revisions haven't been major, so this is looking good for tomorrow's deadline. We anticipate that the CI situation will be corrected by M-3. 3. Ceph iSCSI driver https://review.opendev.org/c/openstack/cinder/+/662829 Code is looking good but the CI isn't passing yet. ==> plan: this is an important community driver so we're extending the deadline two weeks to 5 February. 4. Kioxia Kumoscale driver (and brick changes) https://review.opendev.org/c/openstack/cinder/+/768574 https://review.opendev.org/c/openstack/os-brick/+/768575 https://review.opendev.org/c/openstack/os-brick/+/768576 Kioxia reports that their CI is up though it's not reporting yet. This is a large change and the cinder team review bandwidth has been low this cycle, but with the other drivers (mostly) done at this point, we should be able to get faster reviews on these. ==> plan: new driver merge extension to 8 Feb, that is, code merged and CI running and reporting by that date to be included in wallaby. cheers, brian [0] http://eavesdrop.openstack.org/meetings/cinder/2021/cinder.2021-01-20-14.00…

1 0

Requesting help with OpenStack configuration files
by Bessghaier, Narjes 20 Jan '21

20 Jan '21

Dear OpenStack team, I’m a Ph.D. student in software engineering at the ETS Montreal, University of Quebec working on the quality and configuration of web-based software systems. I’m particularly interested in analyzing configuration files from different OpenStack files. One of the main challenges I am currently facing is the proper identification of configuration files. I’m mostly confused between the python files used for production and the python files used for configuration. I am kindly requesting your precious help with the following questions: 1- How to distinguish between python files used for configuration and python files used for production? It will be very helpful if there are some configuration-based patterns (eg, textual patterns or expressions) that we can find in python files to help us distinguish between source code and configuration files? 2- Certain python files use the oslo_config to access and define configuration options. Could "all" these python files be considered as configuration files? For example, the following python file of the keystone project: keystone/keystone/conf/auth.py, is it considered a source code or configuration file? 3- Why are there different source code and configuration repositories for OpenStack projects (eg, nova and puppet-nova)? For instance, does the OpenStack-nova service have some configuration files in its repository and have the puppet-nova as a separate configuration repository as well? Thank you very much in advance for your time and your help! Kind regards, Narjes Bessghaier Narjes Bessghaier Ph.D student in Software Engineering École de Technologie Supérieure (ETS)| University of Quebec Montreal, Canada narjes.bessghaier.1(a)ens.etsmtl.ca<mailto:yasmine.makroum.1@ens.etsmtl.ca>

3 4

[masakari] Masakari Team Meeting - the schedule
by Radosław Piliszek 20 Jan '21

20 Jan '21

Hello, Folks! I have realised the Masakari Team Meeting is to run on even weeks [1]. However, anyone who created the meeting record in their calendar (including me) has likely gotten the meeting schedule in odd weeks this year (because last year finished with an odd week and obviously numbering also starts on odd: the 1). So I have run the first meeting this year the previous week but someone came for the meeting this week. :-) According to the "new wrong" schedule, the next meeting would be on Jan 19, but according to the "proper" one it would be on Jan 26. I am available both weeks the same so can run either term (or both as well, why not). The question is whether we don't want to simply move to the weekly meeting schedule. We usually don't have much to discuss but it might be less confusing and a better way to form a habit if we met every week. Please let me know your thoughts. [1] http://eavesdrop.openstack.org/#Masakari_Team_Meeting -yoctozepto

2 2

[nova] Selecting PCI devices by their addresses
by Mauricio Tavares 20 Jan '21

20 Jan '21

Stupid question of the day: if I am not mistaken, I can ask nova[1] which pci/pcie devices it knows and where they are. And it will reply with the PCI address for each device it knows of. But, when I want to create flavours so I can create (libvirt-based) instances using them, I cannot tie an alias to a specific pci address; all I can do is say "this pci_alias is for all the pci devices with this vendor_id and product_id that I whitelisted already"[2]. Since libvirt allows me to feed a vm guest the exact pci device I want, could anyone point out which obvious step I am missing here? [1] https://wiki.openstack.org/wiki/Pci-api-support [2] https://docs.openstack.org/nova/latest/admin/pci-passthrough.html#configure…

2 1

[tc] weekly meeting summary (Jan 14)
by Mohammed Naser 20 Jan '21

20 Jan '21

Hi everyone, Here’s a summary of what happened in our TC weekly meeting last Thursday, Jan 14th. # ATTENDEES (LINES SAID) 1. mnaser (123) 2. gmann (56) 3. fungi (31) 4. rosmaita (19) 5. ricolin (11) 6. dansmith (9) 7. jungleboyj (8) 8. knikolla (6) 9. clarkb (3) 10. apevec (2) 11. slaweq (2) 12. belmoreira (1) # MEETING SUMMARY 1. Rollcall 2. Follow up on past action items - DONE: mnaser submit a patch to officially list no community goals for X cycle - DONE: diablo_rojo update resolution for tc stance on osc - IN PROGRESS: diablo_rojo complete retirement of karbor - ALMOST DONE - TBD: diablo_rojo reach out to SIGs/ML and start auditing states of SIGs - TBD: gmann continue to audit tags + outreach to community to apply for them 3. Write a proposed goal for X about stabilization/cooldown This topic mostly continues to live inside gerrit, so ti will be removed from the agenda. 4. Audit SIG list and chairs (diablo_rojo) No progress update, we'll keep an action item to keep up with it. 5. Annual report suggestions (diablo_rojo) Topic to be removed from the agenda as this is getting drafted already. 6. Add Resolution of TC stance on the OpenStackClient (diablo_rojo) dansmith will update osc change to include ci/docs commentary. 7. Audit and clean-up tags (gmann) gmann bumped the email with PTL tag for API interoperability tag, we’ll see how many projects start applying it. 8. infra-core additions (was Farewell Andreas) (diablo_rojo) The reposition is quiet for the moment and there is no backlog yet. We are bringing this up at the OpenDev infrastructure meeting on Tuesday the 19th, mnaser will add openstack/infra-core as a discussion topic in the OpenDev meeting. 9. Dropping lower-constraints testing from all projects (gmann) This is something projects asked TC for consensus and direction for all projects. l-c testing is not part of PTI but there should exist some direction for consistency testing and providing a lower bound to package maintainers. A few projects already started dropping l-c job, and it seems that our current l-c were not exactly testing in a valid way. Also, most testing (except for the l-c job) is being done with versions close to the upper-constraints. We will keep this an open topic for next week. 10. Decide on OpenSUSE in testing runtime (gmann) OpenSUSE distro job is broken for a month and DevStack team is approaching removing it as there is no investment from the company or the community. It was discussed to make the governance change and if that goes through the DevStack one, it will be merged. We’ll have an ML before and after moving testing/governance change, gmann will update supported distros to drop OpenSUSE. # ACTION ITEMS 1. diablo_rojo complete retirement of karbor 2. mnaser to remove proposed goal topic from agenda 3. diablo_rojo reach out to SIGs/ML and start auditing states of SIGs 4. mnaser remove annual report suggestions from agenda 5. dansmith update osc change to include ci/docs commentary 6. mnaser add openstack/infra-core as discussion topic in opendev meeting 7. gmann follow-up with zigo if debian uses l-c 8. gmann update supported distros to drop opensuse To read the full logs of the meeting, please refer to http://eavesdrop.openstack.org/meetings/tc/2021/tc.2021-01-14-15.00.log.html -- Mohammed Naser VEXXHOST, Inc.

1 0

[$nova] [$horizon] [$nova-scheduler] [$heat]
by Nagaraj Akkina 20 Jan '21

20 Jan '21

I think we have a big problem, scheduler is able to allocate more memory than actual physical memory in the compute node, the same statistics are also there in database. For example : if we have a physical memory of 125GB in a node, the total memory allocated to all the instances(virsh dommemstat of all vms) in that host is more than physical memory say around 147GB, being ram_allocation_ratio defined as 1 and reserve_host_memory_mb defined as required. How can nova allocates more memory than actual? Statistics from database +-----------+----------------+-------------+----------------------+ | memory_mb | memory_mb_used | free_ram_mb | ram_allocation_ratio | +-----------+----------------+-------------+----------------------+ | 128897 | 154624 | -25727 | 1 | +-----------+----------------+-------------+----------------------+ we are using openstack stein Regards, Akkina

2 1

[qa][release] Abandoning openstack-tempest-skiplist?
by Herve Beraud 20 Jan '21

20 Jan '21

Dear QA team, The release team noticed an inconsistency between the QA team's deliverables described in the governance’s reference and deliverables defined in the openstack/releases repo (c.f our related meeting topic [1]). Indeed, openstack-tempest-skiplist (added Mar 20, 2020) was never released yet, was not ready yet for ussuri and victoria. maybe we should abandon this instead of waiting? Notice that Wallaby's milestone 2 is next week so maybe it could be a good time to update this. Let us know your thoughts, we are waiting for your replies. Thanks for reading, [1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-re… -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

3 6

docs about ironic-inspector
by Ankele zhang 20 Jan '21

20 Jan '21

Hi, I have an rocky OpenStack platform, and I need openstack-ironic-inspector to inspect my baremetal node, but the documentation on the websit https://docs.openstack.org/ironic/rocky/admin/inspection.html is too concise, without a detailed configuration process. I need a link to documentation for detailed ironic-inspector configuration and usage. Looking forward to your help. Ankele

2 1

[TripleO] moving stable/rocky for tripleo repos to unmaintained (+ then EOL) OK?
by Marios Andreou 19 Jan '21

19 Jan '21

Hello TripleO I would like to propose that we move all tripleo stable/rocky repos [1] to "unmaintained", with a view to tagging as end-of-life in due course. This will allow us to focus our efforts on keeping the check and gate queues green and continue to deliver weekly promotions for the more recent and active stable/* branches train ussuri victoria and master. The stable/rocky repos have not had much action in the last few months - I collected some info at [2] about the most recent stable/rocky commits for each of the tripleo repos. For many of those there are no commits in the last 6 months and for some even longer. The tripleo stable/rocky repos were tagged as "extended maintenance" (rocky-em) [2] in April 2020 with [3]. We have already reduced our CI commitment for rocky - these [4] are the current check/gate jobs and these [5] are the jobs that run for promotion to current-tripleo. However maintaining this doesn’t make sense if we are not even using it e.g. merging things into tripleo-* stable/rocky. Please raise your objections or any other comments or thoughts about this. Unless there are any blockers raised here, the plan is to put this into motion early in January. One still unanswered question I have is that since there is no ‘unmaintained’ tag, in the same way as we have the <release>-em or <release-eol> for extended maintenance and end-of-life, do we simply _declare_ that the repos are unmaintained? Then after a period of “0 to 6 months” per [6] we can tag the tripleo repos with rocky-eol. If any one reading this knows please tell us! Thanks for reading! regards, marios [1] https://releases.openstack.org/teams/tripleo.html#rocky [2] http://paste.openstack.org/raw/800464/ [3] https://review.opendev.org/c/openstack/releases/+/709912 [4] http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&var-in… [5] http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&fullsc… [6] https://docs.openstack.org/project-team-guide/stable-branches.html#maintena…

3 5

Ironic Midcycle - Three time windows next week
by Julia Kreger 19 Jan '21

19 Jan '21

Greetings everyone, Given we have a global community, I think the statement "Scheduling is hard" is definitely one of those things that we've all had to learn over the years. Luckily we have some time slots where many of the participants have indicated they will be able to attend. From that, it appears that the following times seem in terms of trying to cover time zones as well as including participants that have expressed interest. Monday January 25th @ 5PM - 6PM UTC / 9AM - 10AM US Pacific Tuesday January 26th @ 8 PM - 9PM UTC / 12:00 PM - 1 PM Pacific Wednesday January 27th @ 3PM - 4PM UTC / 7AM - 8AM US Pacific We will meet in MeetPad[0], and the etherpad is still open if more topics wish to be added, although we cannot guarantee we will get to them. I've also tried to spread them up across days in order to try and make efficient use of the time. Thanks everyone, and see you there. -Julia [0]: https://meetpad.opendev.org/ironic [1]: https://etherpad.opendev.org/p/ironic-wallaby-midcycle

1 0

Openstack integration with NSX-T
by ali ali 18 Jan '21

18 Jan '21

Hi. I use Openstack train version and I want to integrate openstack with nsx-t. I only found the following documentation. https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.5/nsxt-openstack-plug… and at the start of integration, I install, following packages apt install python-vmware-nsxlib openstack-vmware-nsx python-neutron-fwaas outputs: E: Unable to locate package openstack-vmware-nsx The following packages have unmet dependencies: python-neutron-fwaas : Depends: python-neutron (>= 2:12.0.0~) but it is not going to be installed E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). when I checked there are no python-neutron packages but there was a python3-neutron package. I don't know what to do with this problem. I think if I delete python3-neutron and install python-neutron, everything will crash and mess up. is it basicly possible to integrate openstack train or ussuri or victoryia with nsx-t?

3 2

[tc] weekly update
by Mohammed Naser 18 Jan '21

18 Jan '21

Hi everyone, Here’s an update on what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # Patches ## Open Reviews - Setting Ke Chen as Watcher's PTL https://review.opendev.org/c/openstack/governance/+/770913 - Drop openSUSE from commonly tested distro list https://review.opendev.org/c/openstack/governance/+/770855 - [manila] add assert:supports-api-interoperability https://review.opendev.org/c/openstack/governance/+/770859 - Add Resolution of TC stance on the OpenStackClient https://review.opendev.org/c/openstack/governance/+/759904 - Define Xena release testing runtime https://review.opendev.org/c/openstack/governance/+/770860 - Cool-down cycle goal https://review.opendev.org/c/openstack/governance/+/770616 - Remove Karbor project team https://review.opendev.org/c/openstack/governance/+/767056 - WIP NO MERGE Move os-*-config to Heat project governance https://review.opendev.org/c/openstack/governance/+/770285 ## Project Updates - Setting Xinran Wang as Cyborg's PTL https://review.opendev.org/c/openstack/governance/+/770075 - Add glance-tempest-plugin to Glance https://review.opendev.org/c/openstack/governance/+/767666 - molteniron does not make releases https://review.opendev.org/c/openstack/governance/+/769805 ## General Changes - Add link to Xena announcement https://review.opendev.org/c/openstack/governance/+/769620 - Add doc/requirements https://review.opendev.org/c/openstack/governance/+/769696 # Other Reminders - Our next [TC] Weekly meeting is scheduled for January 21st at 1500 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, January 20th, at 2100 UTC. Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0