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

[neutron] neutron router gateway set will waste a public ip. How to avoid it?
by Zhengyu Pan 17 Jun '20

17 Jun '20

Hi, when i set a gateway for router,(neutron router-gateway-set router external-network), it will allocate a IP address for qg interface. For me, this IP address is useless. I use floatingip to connect external network. Is there a way to avoid allocating this gateway IP for router qg interface? --

3 2

Openstack user surver - questions
by Slawek Kaplonski 17 Jun '20

17 Jun '20

Hi, First of all sorry if I didn't look for it long enough but I have couple of questions about user surver and I couldn't find answer for them anywhere. 1. I was looking at [1] for some Neutron related data and I found only one questions about used backends in "Deployment Decisions". Problem is that this graph is for me a bit unreadable due to many things on x-axis which overlaps each other. Is there any place where I can find some "raw data" to check? 2. Another question about the same chart is: is there any way to maybe change possible replies in the surver for next years? I'm asking about that becasue I have a feeling that e.g. responses "Open vSwitch" and "ML2 - Open vSwitch" may be confusing for users. My understanding is that "Open vSwitch" means simply old "Open vSwitch" core plugin instead of ML2 plugin but this old plugin was removed around "Libery" cycle so I really don't think that still 37% of users are using it. 3. Is there any way to propose new, more detailed questions about e.g Neutron? For example what service plugins they are using. [1] https://www.openstack.org/analytics -- Slawek Kaplonski Senior software engineer Red Hat

2 4

[neutron] Failed to create a duplicate DefaultSecurityGroup
by Neil Jerram 17 Jun '20

17 Jun '20

With Ussuri I'm hitting this in the neutron server: Failed to create a duplicate DefaultSecurityGroup: for attribute(s) ['PRIMARY'] with value(s) 11447be9beda4bf78dab27cdb75058e2 pymysql.err.IntegrityError: (1062, "Duplicate entry '11447be9beda4bf78dab27cdb75058e2' for key 'PRIMARY'") oslo_db.exception.DBDuplicateEntry: (pymysql.err.IntegrityError) (1062, "Duplicate entry '11447be9beda4bf78dab27cdb75058e2' for key 'PRIMARY'") [SQL: INSERT INTO default_security_group (project_id, security_group_id) VALUES (%(project_id)s, %(security_group_id)s)] [parameters: {'project_id': '11447be9beda4bf78dab27cdb75058e2', 'security_group_id': '9f3a473c-b08a-4cf2-8327-10ecc8b87301'}] neutron_lib.objects.exceptions.NeutronDbObjectDuplicateEntry: Failed to create a duplicate DefaultSecurityGroup: for attribute(s) ['PRIMARY'] with value(s) 11447be9beda4bf78dab27cdb75058e2 (Those are all, I believe, reports of the same problem, at different levels of the stack.) IIUC, this is triggered by my Neutron driver calling rules = self.db.get_security_group_rules( context, filters={'security_group_id': sgids} ) where the context has project_id 11447be9beda4bf78dab27cdb75058e2. Deep down inside that call, Neutron tries to ensure that there is a default security group for that project, and somehow that hits the reported exception. Here's the code in securitygroups_db.py: def _ensure_default_security_group(self, context, tenant_id): """Create a default security group if one doesn't exist. :returns: the default security group id for given tenant. """ default_group_id = self._get_default_sg_id(context, tenant_id) if default_group_id: return default_group_id security_group = { 'security_group': {'name': 'default', 'tenant_id': tenant_id, 'description': _('Default security group')} } return self.create_security_group(context, security_group, default_sg=True)['id'] Obviously it checks first if the default SG already exists for the project, before creating it if not. So why would that code hit the duplicate exception as shown above? Any ideas welcome! Best wishes, Neil

2 4

[manila] Summary of the Victoria Cycle Project Technical Gathering
by Goutham Pacha Ravi 17 Jun '20

17 Jun '20

Hello Zorillas and other friendly animals of the OpenStack universe, The manila project community met virtually between 1st June and 5th June and discussed project plans for the Victoria cycle. The detailed meeting notes are in [1] and the recordings were published [2]. A short summary of the discussions and the action items is below: *== Ussuri Retrospective ==* - We lauded the work that Vida Haririan and Jason Grosso have put into making bug tracking and triaging a whole lot easier, and systematic. At the beginning of the cycle, we had roughly 250 bugs, and this was brought down to under 130 by the end of the cycle. As a community, we acted upon many multi-release bugs and made backports as appropriate. We've now automated the expiry of invalid and incomplete bugs thereby reducing noise. Vida's our current Bug Czar, and is interested in mentoring anyone that wants to contribute to this role. Please reach out to her if you're interested. - We also had two successful Outreachy internships (Soledad Kuczala/solkz, Maari Tamm/maaritamm) thanks to Outreachy, their sponsors, mentors (Sofia Enriquez/enriquetaso, Victoria Martinez de la Cruz/vkmc) and the OpenStack Foundation; and a successful Google Summer of Code internship (Robert Vasek/gman0) - many thanks to the mentor (Tomas Smetana/tsmetana), Google, Red Hat and other sponsoring organizations. The team learned a lot, and vkmc encouraged all of us to consider submitting a mentorship application for upcoming cycles and increase our involvement. Through the interns' collective efforts in Train and Ussuri development cycles: - manila CSI driver was built [3] - manilaclient now provides a plugin to the OpenStackClient - manila-ui has support for newer microversions of the manila API and, - manila documentation has gotten a whole lot better! - We made good core team improvements and want to continue to mentor new contributors to become maintainers, and folks felt their PTL was doing a good job (:D) - The community loved the idea of PTL docs (thanks Kendall Nelson/diablo_rojo) - a lot of tribal knowledge was documented for the first time! - We felt that "low-hanging-fruit" bugs [4] were lingering too long in some cases, and must have a "resolve-by" date. These are farmed for new contributors, and if they turn out to be annoying issues, the team may set a resolve-by date and close them out. However, we'll continue to make a concerted effort to triage "bugs that are tolerable" with nice-to-have fixes and keep them handy for anyone looking to make an initial contribution. *== Optimize query speed for share snapshots ==* Haixin (haixin) discovered that not all APIs are taking advantage of filtering and pagination via sqlalchemy. There's a list of APIs that he's compiled and would like to work on them; the team agreed that this is a valuable bug fix; and can be made available to Ussuri when the fixes land in this cycle. *== TC Goals for Victoria cycle ==* - We discussed a long list of items that were proposed for inclusion as TC goals [5]. The TC has officially picked two of them for this cycle [6]. - For gating manila project repos, we make heavy use of "legacy" DSVM jobs. We hadn't invested time and effort in converting these jobs in the past cycles; however, we have a plan [7] and have started porting jobs to "native" zuulv3 format already in the manila-tempest-plugin repository. Once these jobs are complete there, we'll switch over to using them on the main branch of manila. Older branches will get opportunistic updates beyond milestone-2. - Luigi Toscano (tosky) joined us for this discussion and asked us for the status of third party CI systems. The team hasn't mandated that third party CI systems move their testing to zuulv3-native in this cycle. However, the OpenStack community may drop support for devstack-gate in the Victoria release, and making things work with it will get harder - so it's strongly encouraged that third party vendor systems that are using the community testing infrastructure projects: zuul, nodepool and devstack-gate move away from devstack-gate in this cycle. An option to adopt Zuulv3 in third party CI systems could be via the Software Factory project [8]. The RDO community runs some third party jobs and votes on OpenStack upstream projects - so they've created a wealth of jobs and documentation that can be of help. Maintainers of this project hang out in #softwarefactory on FreeNode. - All of the new zuulv3 style tempest jobs inherit from devstack-tempest from the tempest repository, and changing the node-set in the parent would affect all our jobs as well - this would make the transition to Ubuntu 20.04 LTS/Focal Fossa easier. *== Secure default policies and granular policies ==* - Raildo Mascena (raildo) joined us and presented an overview this cross-community effort [9] - Manila has many assumptions of what project roles should be - and over time, we seem to have blended the idea of a deployer administrator and a project administrator - so there are inconsistencies when, even to perform project level administration, one needs excessive permissions across the cloud. This is undesirable - so, a precursor to supporting the new scoped policies from Keystone seems to be to: - eliminate hard coded checks in the code requiring an "admin" role and switch to performing policy checks - eliminating empty defaults which allow anyone to execute an API - manila has very few of these - supporting a "reader" role with the APIs - We can then re-calibrate the defaults to ensure a separation between cross-tenant administration (system scope) and per-tenant administration - following the work in oslo.policy and in keystone - gouthamr will be leading this in the Victoria cycle - other contributors are welcome to join this effort! *== Oslo.privsep and other manila TODOs ==* - We discussed another cross-community effort around transitioning all sudo actions from rootwrap to privsep - Currently no one in the manila team has the bandwidth to investigate and commit to this effort, so we're happy to ask for help! - If you are interested, please join us during one of the team meetings or start submitting patches and we can discuss with you via code reviews. - The team also compiled a list of backlog items in an etherpad [10]. These are great areas for new project contributors to help manila, so please get in touch with us if you would like to work on any of these items *== OSC Status/Completion ==* - Victoria Martinez de la Cruz and Maari Tamm compiled the status for the completion of the OSC plugin work in manilaclient [11] - There's still a lot of ground to cover to get complete parity with the manila command line client, and we need contributors - Maari Tamm (maaritamm) will continue to work on this as time permits. Spyros Trigazis (strigazi) and his team at CERN are interested to work on this as well. Thank you, Maari and Spyros! - On Friday, we were joined by Artem Goncharov (gtema) to discuss the issue of "common commands" - quotas, services, availability zones, limits are common concepts that apply to other projects as well - OSC has support to show you these resources for compute, volume and networking - gtema suggested we should approach this via the OpenStackSDK rather than the plugin since plugins are slow as is, and adding anything more to that interface is not desirable at the moment - There's planned work in the OpenStackClient project to work on the plugin loading mechanisms to make things faster *== Graduation of Experimental Features ==* - Last cycle Carlos Eduardo (carloss) committed the work to graduate Share Groups APIs from their "Experimental API" status - We have two more features behind experimental APIs: share replication and share migration - This cycle, carloss will work on graduating the share replication APIs to fully supported - Generic Share Migration still needs some work, but we've fleshed out the API and it has stayed pretty constant in the past few releases - we might consider graduating the API for share migration in the Wallaby release. *== CephFS Updates ==* - Victoria (vkmc) took us through the updates planned for the Victoria cycle (heh) - Currently all dsvm/tempest based testing in OpenStack (cinder, nova, manila) is happening on ceph luminous and older releases (hammer and jewel) - Victoria has a patch up [12] to update the ceph cluster to using Nautilus by default - This patch moves to using the packages built by the ceph community via their shaman build system [13] - shaman does not support building nautilus on CentOS 8, or on Ubuntu Xenial - so if older branches of the projects are tested with Ubuntu Xenial, we'll fall back to testing with Luminous - The Manila CephFS driver wants to take advantage of the "ceph-mgr" daemon in the Nautilus release and beyond - Maintaining support for "ceph-mgr" and "ceph-volume" clients in the driver will make things messy - so, the manila driver will not support Ceph versions prior to Nautilus in the Victoria cycle - If you're using manila with cephfs, please upgrade your ceph clusters to Nautilus or newer - We're not opposed to supporting versions prior to nautilus, but the community members cannot invest in maintaining support for these older releases of ceph for future releases of manila - With the ceph-mgr interface, we intend to support asynchronous create-share-from-snapshot with manila - Ramana Raja (rraja) provided us an update regarding the ceph-mgr and upcoming support for nfs-ganesha interactions via that interface (ceph pacific release) - Currently there's a ganesha interface driver in manila, and that can switch to using the ceph-mgr interface - Manila provides an "ensure_shares" mechanism to migrate share export locations when the NAS host changes - We'll need to work on that if we want to make it easier to switch ganesha hosts. - We also briefly discussed supporting manage and unmanage operations with the ceph drivers - that should greatly assist day 2 operations, and migration of shared file systems from the native cephfs protocol to nfs and vice-versa. *== Add/Delete/Update security services for in-use share networks ==* - Douglas Viroel (dviroel) discussed a change to manila to support share server modifications wrt security services - Security services are project visible and tenant driven - however, share servers are hidden away from project users by virtue of default policy - dviroel's idea is that, If a share network has multiple share servers, the share manager will enumerate and communicate with all share servers on the share network to update a security service - We need to make sure that all conflicting operations (such as creating new shares, changing access rules on existing shares) are fenced off when a share server security service is being updated - dviroel has a spec that he's working on - and would like feedback on his proposal [14] *== Create shares with two (or more) subnets ==* - dviroel proposed a design allowing a share network having multiple subnets in a given AZ (currently you can have utmost 1 subnet in an AZ for a given share network) - Allowing multiple NICs on a share server may be something most drivers can easily support - This change is identical to the one to update security services on existing share networks - in terms of user experience and expectations - The use cases here include dual IP support, share server network maintenance and migration, simultaneous access from disparate subnets - Feedback from this discussion was to treat this as two separate concerns for easier implementation - Supporting multiple subnets per AZ per share network - Supporting adding/removing subnets to/from a share network that is in-use - Currently, there's no way to modify an in-use share server - so adding that would be a precursor to allowing modification of share networks/subnets and security services *== Technical Committee Tags ==* - In the last cycle, the manila team worked with OpenStack VMT to perform a vulnerability disclosure and coordinate a fix across distributions that included manila. - The experience was valuable in gaining control of our own "coresec" team that had gone wayward on launchpad; and learning about VMT - Jeremy Stanley (fungi) and other members of the VMT have been supportive of having manila apply to the "vulnerability-managed" tag. We'll follow up on this soon - While we're on the subject, with Ghanshyam Mann (gmann) in the room, we discussed other potential tags that we can assert as the project team: - "supports-accessible-upgrade" - manila allows control plane upgrade without disrupting the accessibility of shares, snapshots, ACLs, groups, replicas, share servers, networks and all other resources [15] - "supports-api-interoperability" - manila's API is microversioned and we have hard tests that enforce backwards compatibility [16] - We discussed "tc:approved-release" tag a bit, and felt that we needed to bring it up in a TC meeting, and we did that with Ghanshyam's help - The view from the manila team is that we'd like to eliminate any misconception that the project is not mature, or ready for production use or that it isn't a part of a "core OpenStack" - At the TC meeting, Thierry Carrez (ttx), Graham Hayes (mugsie) and the others provided historic context for this tag: the tag was for a section from the OpenStack foundation bylaws that states that the Technical Committee must define what an approved release is (Article 4, section 4.1 (b) i) [17] - The TC's view was that this tag has outlived its purpose and core-vs-non-core discussions have happened a lot of times. Dropping this tag might require speaking with the Foundation and amending the bylaws and exploring what this implies. It's a good effort to get started on though. - For the moment, The TC was not opposed to the manila team requesting this change to include manila in the list of projects in "tc-approved-release". *== Share and share size quotas/limits per share server ==* - carloss shared his design for allowing share server limits being enforced via the quotas system where administrators could define project share server quotas that the share manager would enforce these by provisioning new servers when the quotas are hit - the quotas system is ill suited for this sort of enforcement, specially given that the share manager allows the share drivers to control what share server can be used to provision a share - it's possible to look for a global solution, like the one proposed for the generic driver in [18], or implement this at a backend level agnostic to the rest of manila - another reason not to use quotas is that manila may eventually do away with this home grown quota system in favor of oslo.limit enforced via keystone - another alternative to doing this is via share types, but, this really fits as a per-share-network limit rather than a global one *== Optimize the quota processing logic for 'manage share' ==* - haixin ran into a bug where quota operations are incorrectly applied for during a share import/manage operation such that a failed manage operation would cause incorrect quota deductions - we discussed possible solutions for the bug, but mostly, this can definitely be fixed - he opened a bug for this [19] *== Share server migration ==* - dviroel presented his thoughts around this new feature [20] which would be helpful for day 2 operations - he suggested that we should not provide for a generic mechanism to perform this migration, given that users would not need it especially if it is not 100% reliable - though there is a generic framework for provisioning share servers, it is only being used by the reference driver (Generic driver) and the Windows SMB driver - shooting for a generic solution would require us to solve SPOF issues that we currently have with the reference driver - and there is not much investment in doing so - dviroel's solution involves a multi-step migration, however relying on the share drivers to perform atomic migration of all the shares - you can think of this wrt the Generic driver as multi-attaching all the underlying cinder volumes and deleting the older nova instance. - manila's share migration is multi-step allowing for a data copy and a cutover phase - and is cancelable through the data copy phase and before the cutover phase is invoked - so there were some concerns if that two phased approach is required here, given that the operation may not be cancelable always, generically *== Manila Container Storage Interface ==* - Tom Barron (tbarron) presented a summary and demo of using the Manila CSI driver on OpenShift to provide RWX storage to containerized applications - Robert Vasek (gman0) explained the core design and the reasoning behind the architecture - Mikhail Fedosin (mfedosin) spoke about the OpenShift operator for Manila CSI and the ease of install and day two operations [21] - the CSI driver has support for snapshots, cloning of snapshots (nfs only at the moment) and topology aside from provisioning, access control and deprovisioning - the team's prioritizing supporting cephfs snapshots and creating shares from cephfs snapshots via subvolume clones in the Victoria cycle Thanks for reading this far! Should you have any questions, don't hesitate to pop into #openstack-manila on freenode.net. [1] https://etherpad.opendev.org/p/victoria-ptg-manila (Minutes of the PTG) [2] https://www.youtube.com/playlist?list=PLnpzT0InFrqBKkyIAQdA9RFJnx-geS3lp (YouTube playlist of the PTG recordings) [3] https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/usi… (Manila CSI driver docs) [4] https://bugs.launchpad.net/manila/+bugs?field.tag=low-hanging-fruit (Low hanging fruit bugs in Manila) [5] https://etherpad.opendev.org/p/community-goals (Community goal proposals) [6] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015459.html (Chosen TC Community Goals for Victoria cycle) [7] https://tree.taiga.io/project/gouthampacha-manila-ci-zuul-v3-migration/kanb… (Zuulv3-native CI migrations tracker) [8] https://www.softwarefactory-project.io/ (Software Factory project) [9] https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… (Policy effort across OpenStack) [10] https://etherpad.opendev.org/p/manila-todos (ToDo list for manila) [11] https://etherpad.opendev.org/p/manila-openstackclient-updates (OSC CLI catchup tracker) [12] https://review.opendev.org/#/c/676722/ (devstack-plugin-ceph support for Ceph Nautilus) [13] https://shaman.ceph.com (Shaman build system for Ceph) [14] https://review.opendev.org/#/c/729292/ (Specification to allow security service updates) [15] https://governance.openstack.org/tc/reference/tags/assert_supports-accessib… (TC tag for accessible upgrades) [16] https://governance.openstack.org/tc/reference/tags/assert_supports-api-inte… (TC tag for API interoperability) [17] https://www.openstack.org/legal/bylaws-of-the-openstack-foundation#ARTICLE_… (TC bylaws requiring "approved release") [18] https://review.opendev.org/#/c/510542/ (Limitting the number of shares per Share server) [19] https://bugs.launchpad.net/manila/+bug/1883506 (delete manage_error share will lead to quota error) [20] https://review.opendev.org/#/c/735970/ (specification for share server migration) [21] https://github.com/openshift/csi-driver-manila-operator

1 0

[cyborg]Cyborg Victoria Release Schedule and storyboard update for Contributors
by yumeng bao 17 Jun '20

17 Jun '20

Hi team and interested contributors! A detailed release schedule[1] is proposed according to all the goals[2] we've confirmed at Virtual PTG. These two materials will form the basis for our development throughout this cycle release. Goals with tag [open-to-all] are open to everyone to take, if you are interested, please feel free to ask questions directly here or ping Yumeng at IRC Channel #openstack-cyborg ! Another thing is about the storyboard. After Rocky, Cyborg has migrated from cyborg-launchpad to cyborg-storyboard to track bugs and features. But we were not using it very well. From Victoria, we will use it, use it well, and use it often. So please take some time to get familiar with the cyborg specific storyboard usage guide[3]. [1]https://wiki.openstack.org/wiki/Cyborg/Victoria_Release_Schedule#Blueprin… [2]https://etherpad.opendev.org/p/cyborg-victoria-goals [3]https://wiki.openstack.org/wiki/Cyborg/CyborgStoryboard Regards， Yumeng

1 0

[ironic] advanced partitioning discussion
by Dmitry Tantsur 17 Jun '20

17 Jun '20

Hi folks, As a follow up to the PTG discussion, I'd like to schedule a call about advanced partitioning in ironic. Please vote for the date and time next week: https://doodle.com/poll/5yg93gv7casu3ate Dmitry

2 3

[scientific-sig] IRC Meeting Wednesday 1100UTC - Supporting COVID workloads on OpenStack
by Stig Telfer 17 Jun '20

17 Jun '20

Hi all - We have a Scientific SIG meeting coming up on Wednesday at 1100 UTC in IRC channel #openstack-meeting. Everyone is welcome. In this week's agenda we are hoping to gather experiences from people working to support COVID-19 workloads on their OpenStack systems. This could be biochemistry simulations, or supporting contact tracing, or whatever. It would be interesting to hear what people are doing and share experiences if we can. The full agenda is available here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_June_17th_2020 Cheers, Stig

1 0

[all] oslotest removing mock as a dependency
by Ben Nemec 17 Jun '20

17 Jun '20

Hi all, In keeping with the move from the third-party mock library to the built-in unittest.mock module, oslotest is removing mock as a dependency (again). We tried this at the end of the last cycle, but it turned out a number of projects were relying on oslotest to pull in mock for them so in order to not hold up the release we reverted the change. We've un-reverted it and the release request is now merged, so if you were previously relying on oslotest to install mock in your tests you will now need to do one of the following: 1) Migrate to unittest.mock (preferred) or 2) Explicitly depend on mock in your test-requirements.txt. If you have any questions about this, let us know. Thanks. -Ben

1 0

RE: python-dracclient
by Christopher.Dearborn＠dell.com 16 Jun '20

16 Jun '20

My apologies if this email is a duplicate. Resending because I had some issues with my subscription and can’t tell if the original was actually delivered to the list or not. Thanks, Chris From: Dearborn, Chris Sent: Monday, June 15, 2020 4:52 PM To: 'Ewan Hamilton' Cc: 'openstack-discuss(a)lists.openstack.org' Subject: RE: python-dracclient Hey Ewan, Good to meet you! We’re thrilled that you are looking at using python-dracclient to work with your Dell EMC servers. Python-dracclient was originally developed for use by the iDRAC driver in the Ironic project. The iDRAC driver documentation needed quite a bit of work as well, and I’m happy to say that we did overhaul it in a recent release. Since python-dracclient has been a library primarily used by Ironic, the documentation for it has been overlooked up to this point. We instead have focused on adding new features and functionality, as well as fixing the occasional bug in both python-dracclient and the Ironic iDRAC driver. As a result of your email, we’re looking at updating the documentation for python-dracclient in our upcoming release. In the meantime, there are some great opensource examples that use python-dracclient, which will hopefully be helpful to you: * This is a simple utility that checks to see if the iDRAC is ready to receive commands: * https://github.com/dsp-jetpack/JetPack/blob/master/src/pilot/is_idrac_ready… * Note that this “is ready?” check is built into python-dracclient, so it’s not something you will need to do in your code. You could replace the call to is_idrac_ready() in the example with another call though. * This is a utility that resets the iDRAC, clears the job queue, then configures the boot mode, boot device, iDRAC settings, and it will even optionally change the iDRAC password. Note that this script works in a tripleo environment, so it will need some tweaking if you want to use it stand-alone: * https://github.com/dsp-jetpack/JetPack/blob/master/src/pilot/config_idrac.py * This is a utility that discovers iDRACs in an IP range that you provide including discovering the service tag and server model: * https://github.com/dsp-jetpack/JetPack/blob/master/src/pilot/discover_nodes… * And finally, the Ironic iDRAC driver makes extensive use of python-dracclient, but it is also probably the most complicated example: * https://github.com/openstack/ironic/tree/master/ironic/drivers/modules/drac As far as how python-dracclient originally got it’s name, I’m not really sure about that as we inherited the original repo from other developers who no longer work on the project. I suspect it was picked because it followed the naming conventions of at least some other library repos in OpenStack at that time. The WSManClient class is defined in https://github.com/openstack/python-dracclient/blob/master/dracclient/clien…, and it is a class that is only used internally to python-dracclient. To use python-dracclient, you should only have to: from dracclient import client Then, you can call any method in the DRACClient class here: https://github.com/openstack/python-dracclient/blob/master/dracclient/clien… If you want to view the python-dracclient code in a development environment editor, then you would need to modify the PYTHONPATH or equivalent in the dev environment to include the path to the directory containing python-dracclient/dracclient/client.py, and then it should be able to resolve everything. Feel free to reply on this list if you need a hand, or you can always email me directly. Thanks and happy hacking! Chris Dearborn Software Sr Principal Engr Dell EMC | Service Provider Engineering Christopher.Dearborn(a)Dell.com<mailto:Christopher.Dearborn@Dell.com> From: Ewan Hamilton <ewan.hamilton(a)managed.co.uk<mailto:ewan.hamilton@managed.co.uk>> Sent: Monday, June 15, 2020 1:43 PM To: openstack-discuss(a)lists.openstack.org<mailto:openstack-discuss@lists.openstack.org> Subject: python-dracclient [EXTERNAL EMAIL] Hi guys, Your documentation for python-dracclient begins here: https://docs.openstack.org/python-dracclient/latest/usage.html with Usage Create a client object by providing the connection details of the DRAC card: client = wsmanclient.client.DRACClient('1.2.3.4', 'username', 's3cr3t') There is no import statement – and when I have searched google and found “import dracclient” because the assumed “import python-dracclient” doesn’t work due to a hyphen (why would you name your module with a hyphen in the first place?!), it doesn’t recognise “wsmanclient” in the editor still. Can you see just how frustrating this is for someone who expects documentation that actually works and explains how to actually use the module?

1 0

[neutron][qos] Meeting cancelled
by Rodolfo Alonso Hernandez 16 Jun '20

16 Jun '20

Hello: Due to the lack of agenda, I'll cancel today's meeting. Regards.

1 0

Ceph Integration on Openstack Platform
by Merve ASLAN 16 Jun '20

16 Jun '20

Hi, I've wanted to use ceph storage as a backend for nova, glance and cinder. I've succeded to use ceph for cinder and glance but I couldn't at nova. I have seen this bug for "Stein" version ---> https://bugs.launchpad.net/nova/stein/+bug/1860990 Bug #1860990 “RBD image backend tries to flatten images even if ...” : Series stein : Bugs : OpenStack Compute (nova)<https://bugs.launchpad.net/nova/stein/+bug/1860990> bugs.launchpad.net When [DEFAULT]show_multiple_locations option is not set in glance, and both glance and nova use ceph as their backend, with properly configured accesses, nova will fail with the following exception: 2020-01-23 14:36:43.617 8647 ERROR nova.compute.manager [req-8021fd76-d5ab-4a9b-bd17-f5eb4d4faf62 0e96a04f360644818632b7e46fe8d3e7 ac01daacc7424a40b8b464a163902dcb - default default] [instance: fa9e4118-1bb1-4d52-a2e1-9f61b0e20dc6] Instance failed to spawn: rbd.InvalidArgument: [errno 22] error f... After that, I've entered the nova-compute pod and I've run below commands; apt install python-rbd apt install python3-rbd But it didn't work. I've gotten same error. A solution must be on the K8s side. error; 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager File "/var/lib/openstack/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 1216, in _get_rbd_driver 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager rbd_user=CONF.libvirt.rbd_user) 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager File "/var/lib/openstack/lib/python3.6/site-packages/nova/virt/libvirt/storage/rbd_utils.py", line 128, in __init__ 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager raise RuntimeError(_('rbd python libraries not found')) 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager RuntimeError: rbd python libraries not found Nova compute image; [cid:e78156d8-4edf-4abd-8585-7e346fb1f879] Do you have any of ideas about that? Best Regards, [cid:image100503.PNG@466e127b.4087c56f]<http://www.havelsan.com.tr> [cid:image9bdac0.JPG@2b00e707.4cb2e69f] Merve ASLAN SİSTEM MÜHENDİSİ Mustafa Kemal Mahallesi 2120 Cad. No:39 06510 Çankaya Ankara TÜRKİYE [cid:imagea7e2da.PNG@49bdc19b.4eabdf05] +90 312 219 57 87 [cid:imaged072fc.PNG@50ceb928.4cb632fd] +90 312 219 57 97 [cid:image987ca6.JPG@943a32e9.4ebc9425] YASAL UYARI: Bu elektronik posta işbu linki kullanarak ulaşabileceğiniz Koşul ve Şartlar dokümanına tabidir. <https://havelsan.com.tr/sabit-sayfalar/eposta-yasal-uyari> LEGAL NOTICE: This e-mail is subject to the Terms and Conditions document which can be accessed with this link. <https://havelsan.com.tr/sabit-sayfalar/eposta-yasal-uyari> Lütfen gerekmedikçe bu sayfa ve eklerini yazdırmayınız / Please consider the environment before printing this email

2 1

python-dracclient
by Ewan Hamilton 16 Jun '20

16 Jun '20

Hi guys, Your documentation for python-dracclient begins here: https://docs.openstack.org/python-dracclient/latest/usage.html with Usage Create a client object by providing the connection details of the DRAC card: client = wsmanclient.client.DRACClient('1.2.3.4', 'username', 's3cr3t') There is no import statement - and when I have searched google and found "import dracclient" because the assumed "import python-dracclient" doesn't work due to a hyphen (why would you name your module with a hyphen in the first place?!), it doesn't recognise "wsmanclient" in the editor still. Can you see just how frustrating this is for someone who expects documentation that actually works and explains how to actually use the module? This is a pathetic job here. Ewan Hamilton 3rd Line Networks Analyst t: 0800 033 4800 ext. 2212 | m: 07772 001 625 Technology House, 151 Silbury Boulevard, Milton Keynes, MK9 1LH managed. is a trading name of Managed247 Ltd Managed247 Ltd is a company registered in England and Wales under number 7019261

4 4

[tc][uc][all] Starting community-wide goals ideas for V series
by Ghanshyam Mann 15 Jun '20

15 Jun '20

Hello everyone, We are in R14 week of Ussuri cycle which means It's time to start the discussions about community-wide goals ideas for the V series. Community-wide goals are important in term of solving and improving a technical area across OpenStack as a whole. It has lot more benefits to be considered from users as well from a developers perspective. See [1] for more details about community-wide goals and process. We have the Zuulv3 migration goal already accepted and pre-selected for v cycle. If you are interested in proposing a goal, please write down the idea on this etherpad[2] - https://etherpad.openstack.org/p/YVR-v-series-goals Accordingly, we will start the separate ML discussion over each goal idea. Also, you can refer to the backlogs of community-wide goals from this[3] and ussuri cycle goals[4]. NOTE: TC has defined the goal process schedule[5] to streamlined the process and ready with goals for projects to plan/implement at the start of the cycle. I am hoping to start that schedule for W cycle goals. [1] https://governance.openstack.org/tc/goals/index.html [2] https://etherpad.openstack.org/p/YVR-v-series-goals [3] https://etherpad.openstack.org/p/community-goals [4] https://etherpad.openstack.org/p/PVG-u-series-goals [5] https://governance.openstack.org/tc/goals/#goal-selection-schedule -gmann

10 22

Fw: nova compute rbd backend error
by Nazan CENGİZ 15 Jun '20

15 Jun '20

I've wanted to use ceph storage as a backend for nova, glance and cinder. I've succeded to use ceph for cinder and glance but I couldn't at nova. I have saw this bug for "Stein" version ---> https://bugs.launchpad.net/nova/stein/+bug/1860990 After that, I've entered the nova-compute pod and I've run below commands; apt install python-rbd apt install python3-rbd But it didn't work. I've gotten same error. A solution must be on the K8s side. Do you have any of ideas about that? error; 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager File "/var/lib/openstack/lib/python3.6/site-packages/nova/virt/libvirt/driver.py", line 1216, in _get_rbd_driver 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager rbd_user=CONF.libvirt.rbd_user) 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager File "/var/lib/openstack/lib/python3.6/site-packages/nova/virt/libvirt/storage/rbd_utils.py", line 128, in __init__ 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager raise RuntimeError(_('rbd python libraries not found')) 2020-06-15 12:34:23.617 21543 ERROR nova.compute.manager RuntimeError: rbd python libraries not found Nova compute image; [cid:e78156d8-4edf-4abd-8585-7e346fb1f879] Best Regards, Nazan [cid:image179c53.PNG@04e4c522.47980262]<http://www.havelsan.com.tr> [cid:imagebda6b1.JPG@83e469a0.4b8f3b2e] Nazan CENGİZ AR-GE MÜHENDİSİ Mustafa Kemal Mahallesi 2120 Cad. No:39 06510 Çankaya Ankara TÜRKİYE [cid:image0a77f4.PNG@7b7ae2c0.4489d17b] +90 312 219 57 87 [cid:image1bd9c3.PNG@4ea6bc72.42af5879] +90 312 219 57 97 [cid:image7abae9.JPG@fff6a90f.4d8b49ff] YASAL UYARI: Bu elektronik posta işbu linki kullanarak ulaşabileceğiniz Koşul ve Şartlar dokümanına tabidir. <https://havelsan.com.tr/sabit-sayfalar/eposta-yasal-uyari> LEGAL NOTICE: This e-mail is subject to the Terms and Conditions document which can be accessed with this link. <https://havelsan.com.tr/sabit-sayfalar/eposta-yasal-uyari> Lütfen gerekmedikçe bu sayfa ve eklerini yazdırmayınız / Please consider the environment before printing this email

1 5

[kolla] Ussuri release
by Mark Goddard 15 Jun '20

15 Jun '20

Hi, I think it's time we made our Ussuri release. I've been through open bugs and patches to try to work out what are our release blockers. Remember that we can and will follow up with fixes, let's keep it to actual release blockers and release some code for people to use. I've started a list on the whiteboard [1] line 105. Please add items there that you think are release critical. [1] https://etherpad.opendev.org/p/KollaWhiteBoard Thanks, Mark

1 0

[ironic] code review jam - Thursday @ 4 PM UTC
by Julia Kreger 15 Jun '20

15 Jun '20

Greetings everyone, Ironic has a bit of a review backlog to work through, and in order to help facilitate getting through the backlog we're going to hold a review jam on Thursday of this week at 4 PM UTC. Everyone is welcome, but we're likely going to focus on the items needing review or quick discussion that are inside our review queue. For this, we will use meetpad [0]. Thanks everyone! -Julia 0: https://meetpad.opendev.org/ironic

1 0

Upstream Openstack Stein + Octavia - why is the installation procedure so different than other projects ?
by Alfia, Zion 15 Jun '20

15 Jun '20

Hello, Opposed to other Openstack Stein projects' installation procedure documentation - Octavia is no less than ... vague. https://docs.openstack.org/octavia/stein/contributor/guides/dev-quick-start… Why is that ? Kind Regards, Zion ________________________________ PRIVILEGED AND CONFIDENTIAL PLEASE NOTE: The information contained in this message is privileged and confidential, and is intended only for the use of the individual to whom it is addressed and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, or if any problems occur with transmission, please contact sender. Thank you.

2 2

nova compute rbd backend error
by Nazan CENGİZ 15 Jun '20

15 Jun '20

I've wanted to use ceph storage as a backend for nova, glance and cinder. I've succeded to use ceph for cinder and glance but I couldn't at nova. I have saw this bug for "Stein" version ---> https://bugs.launchpad.net/nova/stein/+bug/1860990 After that, I've entered the nova-compute pod and I've run below commands; apt install python-rbd apt install python3-rbd But it didn't work. I've gotten same error. A solution must be on the K8s side. Do you have any of ideas about that? Nova compute image; [cid:3132c647-854a-4414-b04c-d40d6637cfc3] Best Regards, Nazan [cid:image65cb84.PNG@b431e523.428f4649]<http://www.havelsan.com.tr> [cid:imagea0344c.JPG@58751da3.4a9c82d4] Nazan CENGİZ AR-GE MÜHENDİSİ Mustafa Kemal Mahallesi 2120 Cad. No:39 06510 Çankaya Ankara TÜRKİYE [cid:imageee2c6d.PNG@1c63e1af.47be051b] +90 312 219 57 87 [cid:image8666e0.PNG@d175d91d.47bf87e0] +90 312 219 57 97 [cid:image84a401.JPG@9630949c.47a4f234] YASAL UYARI: Bu elektronik posta işbu linki kullanarak ulaşabileceğiniz Koşul ve Şartlar dokümanına tabidir. <https://havelsan.com.tr/sabit-sayfalar/eposta-yasal-uyari> LEGAL NOTICE: This e-mail is subject to the Terms and Conditions document which can be accessed with this link. <https://havelsan.com.tr/sabit-sayfalar/eposta-yasal-uyari> Lütfen gerekmedikçe bu sayfa ve eklerini yazdırmayınız / Please consider the environment before printing this email

1 3

[openstack-ansible] Upstream contributions
by Dmitriy Rabotyagov 15 Jun '20

15 Jun '20

Hi there! We've accidentally noticed, that you have forked some of the openstack-ansible repositories and do have some fixes and commits to the forked versions. Additionally, you have adjutant role, which we don't have but was talking about creating it one day. We would really love to get your patches merged upstream and work together on making OSA better and that it would satisfy your requirements as well. As it's really better to work together on fixing things or implementing features, than doing exact same things on our own. I think that all parties would benefit from it. As a plus, in upstream we have CI resources, which means that we can test all patches, which should make them work for you as well in case of some updates or changes. So we'd really love to work with you and getting changes and features from your cloned repos to be implemented upstream. You can join us on IRC at #openstack-ansible channel on Freenode for further conversation and cooperation. -- Kind regards, Dmitriy Rabotyagov

1 0

[cyborg][kolla] OPAE & CentOS 8
by Mark Goddard 15 Jun '20

15 Jun '20

Hi, I asked in another thread, but didn't get a response. In the kolla cyborg-agent image we install OPAE. There is a comment claiming this is a required dependency. It doesn't seem to be available for CentOS 8. If that is the case, we will need to drop support for the cyborg-agent image from Ussuri. Could someone confirm if OPAE is a hard dependency or not? Thanks, Mark

4 5

[openstackl][cinder][nova] attacched volume retype error
by Ignazio Cassano 15 Jun '20

15 Jun '20

Hello All, I am facing an issue when I retype a volume attached to a vm from netapp nfs to ceph on stein. It work fron nfs to iscsi but not from nfs to ceph. It seems a nova issue. I got an error in nova compute log: Failed to swap volume 26add23f-d643-4020-9935-9e856a0e9d93 for 1a2edc3a-cc3e-4a92-9488-6e6fabd01825: NotImplementedError: Swap only supports host devices I read there is an old blueprint for this but I do know if it has been implemented. Any help, please? Ignazio

2 2

[ironic][centos]grubaa64.efi request different filename
by Jeffrey Zhang 15 Jun '20

15 Jun '20

hey guys, I am testing a standalone ironic node on arm64 node through centos 7. Then dnsmasq is configured as following ``` enable-tftp tftp-root=/var/lib/ironic/public/boot/tftp # dhcp-option=option:router,192.168.122.1 # use static dhcp-range=10.0.0.167,static,60s log-queries log-dhcp dhcp-match=set:efi-arm64,option:client-arch,11 dhcp-boot=tag:efi-arm64,grubaa64.efi ``` the grubaa64.efi file come from `/boot/efi/EFI/centos/grubaa64.efi` on centos 7 But seems grubaa64.efi file are trying different grub.cfg filename like `grub.cfg-xx-xx-xx-xx`( check bellow) Whereas ironic generate filename like `xx:xx:xx:xx:xx.conf`. Is this a bug in ironic? or I made something wrong? ``` dnsmasq-dhcp[1]: 140425456 vendor class: PXEClient:Arch:00011:UNDI:003000 dnsmasq-dhcp[1]: 140425456 DHCPREQUEST(eth1) 10.0.0.171 52:54:00:ea:56:f2 dnsmasq-dhcp[1]: 140425456 tags: known, efi-arm64, eth1 dnsmasq-dhcp[1]: 140425456 DHCPACK(eth1) 10.0.0.171 52:54:00:ea:56:f2 pxe-uefi dnsmasq-dhcp[1]: 140425456 requested options: 1:netmask, 2:time-offset, 3:router, 4, 5, dnsmasq-dhcp[1]: 140425456 requested options: 6:dns-server, 12:hostname, 13:boot-file-size, dnsmasq-dhcp[1]: 140425456 requested options: 15:domain-name, 17:root-path, 18:extension-path, dnsmasq-dhcp[1]: 140425456 requested options: 22:max-datagram-reassembly, 23:default-ttl, dnsmasq-dhcp[1]: 140425456 requested options: 28:broadcast, 40:nis-domain, 41:nis-server, dnsmasq-dhcp[1]: 140425456 requested options: 42:ntp-server, 43:vendor-encap, 50:requested-address, dnsmasq-dhcp[1]: 140425456 requested options: 51:lease-time, 54:server-identifier, 58:T1, dnsmasq-dhcp[1]: 140425456 requested options: 59:T2, 60:vendor-class, 66:tftp-server, 67:bootfile-name, dnsmasq-dhcp[1]: 140425456 requested options: 97:client-machine-id, 128, 129, 130, 131, dnsmasq-dhcp[1]: 140425456 requested options: 132, 133, 134, 135 dnsmasq-dhcp[1]: 140425456 next server: 10.0.0.167 dnsmasq-dhcp[1]: 140425456 broadcast response dnsmasq-dhcp[1]: 140425456 sent size: 1 option: 53 message-type 5 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 54 server-identifier 10.0.0.167 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 51 lease-time 2m dnsmasq-dhcp[1]: 140425456 sent size: 13 option: 67 bootfile-name grubaa64.efi dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 58 T1 1m dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 59 T2 1m45s dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 1 netmask 255.255.255.0 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 28 broadcast 10.0.0.255 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 3 router 10.0.0.167 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 6 dns-server 10.0.0.167 dnsmasq-dhcp[1]: 140425456 sent size: 8 option: 12 hostname pxe-uefi dnsmasq-tftp[1]: error 8 User aborted the transfer received from 10.0.0.171 dnsmasq-tftp[1]: failed sending /var/lib/ironic/public/boot/tftp/grubaa64.efi to 10.0.0.171 dnsmasq-tftp[1]: sent /var/lib/ironic/public/boot/tftp/grubaa64.efi to 10.0.0.171 dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-01-52-54-00-ea-56-f2 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A0000AB not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A0000A not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A0000 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A000 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A00 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A0 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-01-52-54-00-ea-56-f2 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A0000AB not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A0000A not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A0000 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A000 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A00 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A0 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/arm64-efi/command.lst not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/arm64-efi/fs.lst not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/arm64-efi/crypto.lst not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/arm64-efi/terminal.lst not found ``` --- Regards, Jeffrey Zhang Blog: http://xcodest.me

2 2

[Neutron] Neutron Bug Deputy report Jun 8-15
by Jakub Libosvar 15 Jun '20

15 Jun '20

Hi, I was bug deputy for the week of June 8, there are no critical bugs, which is good 🙂 Here is the summary: * Needs further triage * Improper routing between private networks * https://bugs.launchpad.net/neutron/+bug/1883288 * Needs more investigation * after FIP is assigned vm lost network connection * https://bugs.launchpad.net/neutron/+bug/1882860 * may be related to https://github.com/ovn-org/ovn/commit/fda9a1dd3c995f25cad9e828e701f8b41d347… * or DVR + VLAN provider network * internal server error on updating no-gateway on the dhcpv6 subnet * https://bugs.launchpad.net/neutron/+bug/1882873 * needs more info about reproducer * High * Fix flows l2 population related on br-tun being cleaned after RabbitMQ cluster has experienced a network partition * https://bugs.launchpad.net/neutron/+bug/1883071 * Triaged as High as it has an impact on tenant traffic because sometimes the flows related to tunnels in L2 pop gets cleaned * bagpipe: bagpipe-bgp does not start with EVPN and OVS driver * https://bugs.launchpad.net/neutron/+bug/1883102 * More options need to be passed to OVS in EVPN * Neutron OpenvSwitch DVR - connection problem * https://bugs.launchpad.net/neutron/+bug/1883321 * traffic of one VM on a compute node influences traffic of other VM, only on DVR ml2/ovs * Medium * [L3] floating IP failed to bind due to no agent gateway port(fip-ns) * https://bugs.launchpad.net/neutron/+bug/1883089 * Marked as Medium by reporter * Has a fix on review https://review.opendev.org/#/c/735432/ * Low * [neutron-tempest-plugin] "wait_for_interface_status" only retrieves the Nova server information, not the VM network * https://bugs.launchpad.net/neutron/+bug/1883095 * Fix proposed: https://review.opendev.org/#/c/735117/ * RFE * RFE: allow replacing the QoS policy of bound port * https://bugs.launchpad.net/neutron/+bug/1882804 * needs to be triaged by the drivers team

1 0

[glance] Victoria Virtual PTG
by Abhishek Kekane 15 Jun '20

15 Jun '20

Hi All, We had our first virtual summit last week from 1st June to 5th June 2020. Using meetpad we had lots of discussion around different topics for glance and glance + cinder. I have created etherpad [1] with Notes from session and which also includes the recordings of each discussion. Below is the list of what we discussed during PTG. 1. Image encryption (glance side work) 2. Unified Limits Integration with Glance 3. Calculate virtual_size during image creation 4. Remove usage of six library 5. Remove single store configuration from glance_store 6. Cluster awareness 7. Cache-API 8. Improve performance of ceph/rbd store of glance (multi-threaded rbd driver) 9. Duplicate downloads 10. Code cleanup, enhancements 11. Cinder/Glance creating image from volume with Ceph 12. Make a cinder store of glance compatible with multiple stores 13. Gate job for glance cinder store 14. Support for sparse image upload to ceph 15. Victoria priorities Kindly let me know if you have any questions about the same. [1] https://etherpad.opendev.org/p/glance-victoria-ptg Thank you, Abhishek

1 0

[all][infra] Upcoming removal of preinstalled pip and virtualenv from base images
by Ian Wienand 15 Jun '20

15 Jun '20

Hello, This is to notify the community of the planned upcoming removal of the "pip-and-virtualenv" element from our infra image builds. This is part of the "cleanup test node python" spec documented at [1]. tl;dr ----- - pip and virtualenv tools will no longer be pre-installed on the base images we use for testing, but will be installed by jobs themselves. - most current jobs will depend on common Zuul base jobs that have been updated to install these tools already *i.e. in most cases there should be nothing to do* - in general, jobs should ensure they depend on roles that install these tools if they require them - if you do find your job failing due to the lack of either of these tools, use the ensure-pip or ensure-virtualenv roles provided in zuul-jobs - we have "-plain" node types that implement this now. If you think there might be a problem, switch the job to run run against one of these node types described below for testing. History ------- The "pip-and-virtualenv" element is part of diskimage-builder [2] and installs the latest version of pip and virtualenv, and related tools like setuptools, into the system environment for the daily builds. This has a long history of working around various issues, but has become increasingly problematic to maintain. One of the more noticable effects is that to prevent the distribution packages overwriting the upstream installs, we put various pip, setuptools and virtualenv packages on "hold" in CI images. This prevents tests resinstalling packaged tools which can create, in short, a big mess. Both destroying the extant environment and having the tools on hold have been problems for various projects at various times. Another other problem is what happens when you call "pip" or "virtualenv" has diverged. It used to be that "pip" would install the package under Python2, while pip3 would install under python3. However, modern distributions now have "pip" installing under Python 3. To keep having "pip" install Python 2 packages on these platforms is not just wrong, but drags in Python 2 dependences to our images that aren't required. The addition of Python 3's venv and the split with virtualenv makes things even more confusing again. Future ------ As famously said "the only winning move is not to play". [3] By dropping this element, images will not have non-packaged pip/virtualenv/setuptools/etc. pre-installed. No packages will be on hold. The "ensure-pip" role [4] will ensure that dependencies for "pip:" commands will work. Because of the way base jobs are setup, it is most likely that this role has already run. If you wish to use a virtual environment to install a tool, I would suggest using the "ensure_pip_virtualenv_cmd" this role exports. This will default to "python3 -m venv". An example is [5]. In a Python 3 word, you probably do not *need* virtualenv; "python3 -m venv" is available and works after the "ensure-pip" role is run. However, if you require some of the features that virtualenv provides that venv does not (explained at [6]) there is a role "ensure-virtualenv" [7]. For example, we do this on the devstack branches because it is common to use "virtualenv" there due to the long history [8]. If you need specific versions of pip or virtualenv, etc. beyond the system-packaged versions installed with the above, you should have your job configure these. There is absolutely no problem with jobs installing differing versions of pip/virtuatlenv/etc in any way they want -- we just don't want the base images to have any of that by default. Of course, you should consider if you're building/testing something that is actually useful outside the gate, but that is a global concern. Testing ------- We have built parallel nodes with the suffix "-plain" where you can test any jobs in the new environment. For example [9] speculatively tests devstack. The node types available are centos-7-plain centos-8-plain ubuntu-xenial-plain ubuntu-bionic-plain The newer focal images do not have pip pre-installed, neither do the faster moving Fedora images, any SUSE images, or any ARM64 images. Rollout ------- We would like to make the switch soon, to shake out any issues early in the cycle. This would mean on or about the 8th June. Thanks, -i [1] https://docs.opendev.org/opendev/infra-specs/latest/specs/cleanup-test-node… [2] https://opendev.org/openstack/diskimage-builder/src/branch/master/diskimage… [3] https://en.wikipedia.org/wiki/WarGames [4] https://zuul-ci.org/docs/zuul-jobs/python-roles.html#role-ensure-pip [5] https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/bindep/tasks/ins… [6] https://virtualenv.pypa.io/en/latest/ [7] https://zuul-ci.org/docs/zuul-jobs/python-roles.html#role-ensure-virtualenv [8] https://opendev.org/openstack/devstack/commit/23cfb9e6ebc63a4da4577c0ef9e34… [9] https://review.opendev.org/#/c/712211/11/.zuul.yaml

3 3

[announce] [debian] New deb-status page and extrepo configuration available for OpenStack on Debian
by Thomas Goirand 14 Jun '20

14 Jun '20

Hi! We've just setup online a new deb-status system [2] to compare what's been released in OpenStack upstream and what has been packaged in Debian. This is an effort to keep each stable branch up-to-date in Debian. This has been possible thanks to Michal Arbet from ultimum.io who wrote os-version-checker [1]. So, a big up to him and ultimum technologies. Note that the Rocky page may not reflect reality, since most of the components are available directly in Debian Buster. Browsing this page, you will notice that both Train and Ussuri are pretty much in an up-to-date shape! :) Note that this page is updated every hours. Also, the Debian packages are now available using extrepo, to make it easier to install. Extrepo is an initiative from Wouter Verhelst to have something comparable to PPA, at least in the way to install the repositories (ie: super easy now...). For example, to install Ussuri in Buster, one can do: apt-get install -t buster-backports extrepo extrepo enable openstack_ussuri This will install the repository as: /etc/apt/sources.list.d/extrepo_openstack_train.sources then you can start using Ussuri using apt as usual. Last, we're searching for volunteers to mirror the osbpo.debian.net Buster backport repositories (to make sure it isn't only on the hands of me and my employer). The only thing that shall be done is to setup an rsync mirroring of the repositories. Best would be to have a mirror in north-America and in Asia. If you're volunteering for this, especially if you are administering a CDN, please get in touch. Hoping this will improve the OpenStack on Debian experience, Cheers, Thomas Goirand (zigo) [1] https://salsa.debian.org/openstack-team/debian/os-version-checker [2] http://osbpo.debian.net/deb-status/

1 0

[nova][doc] nova pdf building failing on new sphinx 3.1.0
by Ghanshyam Mann 13 Jun '20

13 Jun '20

Hello Everyone, With the new release of Sphinx 3.1.0, nova pdf-docs building started failing due to TeX memory issue (maybe this one - https://github.com/sphinx-doc/sphinx/issues/3099) I could not find the related changes in 3.1.0 which can cause this issue. The issue is to include the giant sample files(policy for now) in pdf doc. I am sure that was discussed previously also when we started pdf building in the Train cycle but do not know what was the solution? Luckily neutron is not facing this as their config sample files are as large as nova. I have logged bug[1] and provided the workaround[2] to unblock the nova gate. Workaround is to include the link to the sample file instead if its full content. Any thoughts on how to fix this? [1] https://bugs.launchpad.net/nova/+bug/1883200 [2] https://review.opendev.org/#/c/735279/ -gmann

1 1

Re: [Interop_WG] Today Fiday 6th June 10 AM PDT call
by prakash RAMCHANDRAN 12 Jun '20

12 Jun '20

Hi all, Can you help me on irc, should we be using #openstack-interop or #openstack-interopwgWHich of this we will be able to use the bit to record meetings besides the call? #topic 1 - Review of content for "OpenStack Powered DNS" and "OpenStack Powered Orchestration"#info We need to update the site https://www.openstack.org/brand/openstack-powered/ #topic 2 - Marketplace Vendors to validate their OpenStack Powered offers for Ussuri This can be tested on https://refstack.openstack.org/#/community_results I don't see any tests being made by any one on 11th or 12 th June, any reasons, is there a transition goin on or there is some issue with refstack-client? #action Prakash to follow up with Mark & Ghanshyam on both web site update for Logo add-on programs and refstack-client working wrt Refstack portal #topic 3 - Follow ups to close for Usuri actions items #action Seek help from Staff to update the formality to make "one or more co-chairs" in B192#link https://review.opendev.org/gitweb?p=openstack/interop.git;a=blob;f=doc/sour…... #info updated the googledocs for interops on CinderV2 apis being removed , correction it should have appeared as deprecated in 2019.11 , no issues as we have now dropped it out in 2020.11 approval#link https://docs.google.com/document/d/1vf8rxKxuFoXmZCxfMIIfHm4TzK1kuANktXyUHiu…... topic 4 - Formation new committee for Future Interop work - we discuss this before OpenDev June 29 and help get approvals next Board meeting #info consider Conformance vs Compliance to keep off legal part for new certifications or Logo programs Q1. Data points from MarketPlace?Please educate us how we collect Marketplace data - How customers use the Marketplace? Can we get Data points from Marketplace? If so How? Any answers from TC community or Users Community folks? Q2. Does Tempest testing Infra provider/Vendors offerings occur in real time or you run a batch and send report to interop and who receives this test results? Appreciate all the help from especially Mark, Ghanshyam and we like to have all support for community for interop continuation. ThanksPrakash On Thursday, June 11, 2020, 06:31:21 AM PDT, Ghanshyam Mann <gmann(a)ghanshyammann.com> wrote: Thanks Prakash for all your effort and energy. I can definitely help with guidelines and their testing part from Tempest point of view or you can count that as help from the community side. My concern is almost the same as Mark, I am involved in multiple areas so if interop requires more time then it might be an issue. As of now, I am ok to help to handle some code side part or as 2nd vice-chair hoping that would not take much bandwidth (i think we do not need 2nd vice-chair things as such :) but no strong opinion ). But the main issue for interop (i mentioned earlier also) is the maintainer for refstack and other repo. We really need some developers for that. -gmann ---- On Wed, 10 Jun 2020 21:07:13 -0500 prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote ---- > Mark, > OK let me handle it as chair, but let's refer or nominate Ghanshyam too as second vice chair and if needs to vote it lets do that. > I have submitted the change of irc channel to #openstack-interop as tested last week. and try pile all logs therein with startmeeting and endmeeting weekly to debate and arrive at how we proceed on this after tomorrows presentation which I like both of you to attend. > https://review.opendev.org/#/c/735034/1 > If we need anything to merge the above go ahead. > Arkady as usual is with me on Board is there to help us all, so we do have two from Board and two from TC and community. > So let me answer your latest email, and revise the presentation and web link for Board accordingly. > ThanksPrakash > > > > On Friday, June 5, 2020, 12:32:07 PM PDT, Mark Voelker <mvoelker(a)vmware.com> wrote: > > > So let us wait and check with OpenStack staff how they can help us if they can fix the web irc/time links, if not I will try fix it over week end. > Well, that’s sort of the point of having the meeting info housed in public repository: community members actually don’t need to go through the Foundation staff for things like this, they can just fix them with a few lines of text submitted via git! =) > If you’re not sure how to do that, let me know…it’ll only take a moment to submit a patch so I’m happy to help. > At Your Service, > Mark T. Voelker > > > On Jun 5, 2020, at 3:17 PM, prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote: > Mark, > I see that using irc does help take notes for weekly meetings, especially if there is frequent meetings weekly alternate week etc. > So let us wait and check with OpenStack staff how they can help us if they can fix the web irc/time links, if not I will try fix it over week end. > ThanksPrakash > On Friday, June 5, 2020, 11:49:22 AM PDT, Mark Voelker <mvoelker(a)vmware.com> wrote: > > Prakash, > Quick suggestion: since it looks you’re running these meetings on Zoom going forward, you may want to add the Zoom information to the upstream meetings calendar or alternately at least remove the old IRC meeting entry. See the "IRC meetings schedule” section here for information: > http://eavesdrop.openstack.org/ > The file that you’d want to submit a patch for is: > https://opendev.org/opendev/irc-meetings/src/branch/master/meetings/interop… > (Note that the times presented in the these files are in UTC rather than a local timezone.) > At Your Service, > Mark T. Voelker > > > On Jun 5, 2020, at 11:06 AM, prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote: > Hi all, > Prakash Ramchandran is inviting you to a scheduled Zoom meeting.To keep reliable zoom link have updated the weekly call to this one and see if you can join inspite of our ongoin PTG at 10 AM PDT. > Join from a browser: https://Dell.zoom.com/wc/join/99829924353 > Password: 101045 > Trying to consolidate what we got from PTG interactions to close the Draft updates. > https://etherpad.opendev.org/p/victoria-ptg-interop-wg > > > Closure in next week for Interop Guidline? > > What is the suggession for Board presentaion from team for Prakash on June 11th? > Anything you like to add on the call, we can keep it short and try close after PTG next week. > ThanksPrakash > > > > > > >

1 1

[release] Release countdown for week R-17, Jun 15 - Jun 19
by Sean McGinnis 12 Jun '20

12 Jun '20

Development Focus ----------------- The victoria-1 milestone is next week, on June 18! Project team plans for the Victoria cycle should now be solidified. General Information ------------------- If you planned to change the release model for any of your deliverables this cycle, please remember to do so ASAP, before milestone-1. Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the Ussuri release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Victoria-1 milestone: June 18 Victoria-2 milestone: July 30

1 0

[all][interopWG] Following up on approval of Interop Guidelines for Ussuri
by prakash RAMCHANDRAN 12 Jun '20

12 Jun '20

Hi all, This is a follow up to send feedback to all of core teams (Nova, Neutron, Cinder, Keystone, Glance) + (Swift) + (Add-ons DNS Designate & Orchestration Heat). This was the patch which Mark submitted to kickstart the next refstack test for https://www.openstack.org/brand/openstack-powered/ A. We need to decide on content for "OpenStack Powered DNS" and "OpenStack Powered Orchestration" to this site https://review.opendev.org/#/c/735159/ Community Reporting - Should start seeing program staring 2020.06 new ones and please let us know when you have something to share for Ussuri https://refstack.openstack.org/#/community_results B. We need Marketplace Vendors to validate their OpenStack Powered offers for Ussuri and send emails which we will discuss at tomorrows meeting. C. Meeting will be on irc Friday as usual weekly like #openstack-interopwg @17.00 UTC Friday (PDT 10 AM) Will plan on using zoom call after IRC logins if needed. Agenda we will take as what was discussed at Board and follow ups to close for Usuri and plan further for committee formation for future of interop. ThanksPrakash / Mrak/ GhanshyamFor interopwg

1 0

[glance] Weekly priorities
by Abhishek Kekane 11 Jun '20

11 Jun '20

Hi Glance Members, We are approaching milestone 1 which is just a week away. Before milestone 1 we need to review below specs on priority. sparse image upload - https://review.opendev.org/733157 Unified limits - https://review.opendev.org/729187 Image encryption - https://review.opendev.org/609667 Cinder store multiple stores support - https://review.opendev.org/695152 Kindly review the specs. Thanks & Best Regards, Abhishek Kekane

1 0

[neutron] Virtual PTG summary
by Slawek Kaplonski 11 Jun '20

11 Jun '20

# Day 1 (Tuesday) ## Retrospective >From the good things team mentioned that migration of the networking-ovn driver to the core neutron went well. Also our CI stability improves in the last cycle. Another good thing was that we implemented all required in this cycle community goals and we even migrated almost all jobs to Zuul v3 syntax already. Not so good was progress on some important Blueprints, like adoptoion of the new engine facade. The other thing mentioned here was activity in the stadium projects and in the neutron-lib. ## Support for the new oslo.policy Akihiro and Miguel volunteered to work on this in the Victoria if they will have some cycles. It is important feature from the Keystone team's point of view. Keystone and Nova teams already have some experience on that transition so they can help us with that. We need to ensure that new policies in neutron can works fine with e.g. old ones defined in the stadium projects. ## Adoption of new enginefacade We discussed how to finish this adoption of new enginefacade in Neutron in Victoria cycle. There is couple of people who volunteered to help with that. After it will be done in Neutron we need to check what changes are required in the stadium projects too. ## tenant_id/project_id transition Rodolfo raised this issue that in some places we may still have e.g. only tenant_id and miss project_id. We should all be aware of that and whenever we see something like that e.g. in neutron, neutron-lib, tempest or other repos, we should propose patch to change that. ## Neutronclient -> OSC migration We found out that the only blocker which prevents us to EOL python-neutronclient as a CLI tool is lack of possibility to pass custom arguments to the commands. As we know, OSC/SDK team don't have anything against adding support for that in OSC. It's actually already done for e.g. Glance. Slaweq volunteered to work on it this cycle and if that will be done, define final date of EOL for python-neutronclient for Victoria+2 cycle. ## RFEs review We reviewed about 10 old, stagnant RFEs. We decicded to close some of them as non relevant anymore. For others we discussed some details and we will continue this discussion on LP and on the drivers meetings. ## Review of stadium projects We needed to review list of stadium projects again. Conclusions are: * neutron-vpnaas, networking-odl, networking-bagpipe, networking-bgpvpn are in good shape and we can definitely keep them in stadium, * neutron-fwaas - we will delete all code from this repo now and mark it as deleted project, see [1] for example how this is done, * neutron-dynamic-routing - send email to call for maintainers, but don't consider it as deprecated yet in this cycle, maybe in the next one, * networking-midonet - this one is the problem currently as it isn't well tested with current neutron in u/s gate. # Day 2 (Wednesday) ## Meeting with Edge SIG During this call project [2] was mentioned. For now it was moved to unofficial projects namespace but maybe someone will revive this project if there is use case for it. We talked about [3] and doing it in Victoria cycle. After discussions about the same with Nova team on Friday (see below) we decided that as a first step Nova will work on changes on their side and those changes will not require anything from the Neutron. On our side, Miguel Lavalle volunteered tentatively that he can work on this on too. There was also question about support of IEEE 1588 (PTP) in Neutron - so far we don't have any support for it. But we are always welcome for new RFEs :) ## Future of metering agent Discussion was related to the spec [4]. General conclustion from the discussion is that we will work on this new L3 agent extension which will collect metering data but this will not be in any way replacement for the old metering agent. When this will be ready, we can start discussion about potential deprecation of the old metering agent and its API but that's nothing for the current cycle for sure. ## ML2/OVS and OVN feature gaps List of gaps between ML2/OVS and ML2/OVN backends is in [5]. We discussed how to maintain this list and make it smaller. Decision from this discussion is that we will try to remember to add new items to this list every time when some new feature will be added to Neutron and implemented in ML2/OVS. We will also open LP for such things to keep it tracked on OVN driver side and to implement that when it will be needed by community. ## OVN driver and agent API During this discussion we talked about Neutron agents API and two options in it: * setting admin to be disabled (admin_state_up = False) - we decided that this is really relevant only for L3 and DHCP agents. It's not really used for OVS or Linuxbridge agents and it shouldn't also have any effect for OVN drivers. So Kuba will propose RFE with description of what our API should return in case of setting this admin_state_up value for agents for which it doesn't makes sense, * deletion of agents - we decided that for ovn agents it should be possible to delete them in same way how it is done now for other agents. This has some downside when user will delete agent which is still alive. In such case agent will be deleted and immediatelly shown back in neutron agent list. That is because of how OVN is storing data about those "agents" internally and how Neutron OVN driver uses this data. This isn't however big issue because it may happend in exactly same way for example for OVS/DHCP/L3 agents if user will delete them just before it will send new heartbeat message to the Neutron server. ## Stateless security groups support for OVS firewall (and OVN?) Conclusion from this discussion is that there is need and use cases (DPDK, telco) to introduce stateless security groups in openvswitch and ovn firewall drivers. During the discussion we agreed that implementation shouldn't be really thought. Bernard volunteered to open LP to track it for both of those drivers. ## OVN concept of distributed localport ports used for Metadata agent and DHCP Maciek explained us limitations in current implementation of segments in Neutron and how it blocks OVN driver to support that. Basically the problem is that currently Neutron has limitation that one port can be only on one segment. OVN driver is using "special" ports (local ports in OVN) to handle metadata and dhcp. And such port has to have IP address from all segments which belongs to the network. We agreed to introduce new type of device_owner which will mean that port is "distributed". Such kind of port may then be in more than one segment at same time. Basically this concept is similar to how DVR router ports works currently. ## Switching default backend in Devstack to be OVN At the end of the day we discussed possibility to switch Devstack's default backend in Neutron to be OVN instead of OVS agent. We all agreed that this is big step forward and that we want to do that as Neutron team. We want to give with this change clear signal that we believe that OVN backend is future of the Neutron and we want to invest more in that. Hovewer we want to highlight that this means *nothing* for real production environments. We are *not* going to deprecate any backends. All existing drivers will be tested as they are tested now in the Neutron gate. Different deployment tools may still use different backends as default ones. This change will be however pretty big change for all OpenStack projects which will use OVN driver as Neutron's backend in their jobs. Such change was already done in TripleO in Stein cycle and it went pretty smooth so we are not expecting any serious issues there. We would like to do this change which we set for ourselves is Victoria-2 milestone. # Day 3 (Thursday) ## Deprecation of use_veth_interconnection in the ovs-agent It seems after discussion that this config option was introduced very long time ago and was probably related to something like descibed in [6] but later Open vSwitch introduced patch ports and there was another old LP [7] which was saying that ovs-agent should use patch ports instead of veth pairs. And that solution is still recommended today in the Neutron. So we agreed to deprecate this option in the Victoria cycle and remove it completly in W cycle. ## Loki service plugin Service plugin called "loki" is developed to be use in the CI jobs and to add DB deadlock errors to some random DB queries. But for now it's not used at all in the Neutron CI. During the discussion we decided to add new periodic Zuul job which will run neutron-tempest-plugin.api tests with enabled loki service plugin to check if Neutron still can handle properly such random DB Deadlocks. ## SR-IOV ML2 driver support for VLAN trunking Patch related to this discussion is [8] - it's big patch which introduces base trunk driver interface for SR-IOV agent but also implementation of this base driver for Intel cards. During the discussion we agreed that we shouldn't have such vendor specific code in the Neutron tree. Our suggestion was to split this patch into two pieces - base driver which will be in the Neutron repo and Intel specific driver which will be hosted in some other repository. ## Neutron-lib We were discussion couple of different issues related to the neutron-lib in general. * Nate started discussion about future of the neutron-lib and if this is still really needed. His proposal was to relax a bit policies about what should be re-homed from Neutron to the neutron-lib repository. Originally neutron-lib was introduced to help neutron stadium and 3rd-party projects to not import things from neutron but from the neutron-lib only and have less dependencies thanks to that. Currently development of neutron-lib is much slower than it was in the past and we don't see so much need to use neutron-lib from the developers of the stadium or 3rd-party projects. After some discussion we agreed that neutron-lib is still usefull and important to keep e.g. api definitions and highligh base generic interfaces for neutron and other related projects. So we will keep neutron-lib as it is now but we will relax a bit policy of what will be moved to this repo from the neutron. Second outcome from the same discussion was decision that we will change a bit our policy of updating every neutron-lib/neutron consumer when we will re-home things. We will be focused only on Neutron stadium projects. For other projects we will introduce 1 cycle deprecation period for things which are moved out from the neutron to neutron-lib repo. * Adam from the Octavia team started discussion about how to test neutron and neutron-lib changes. Currently all neutron CI jobs are using latest released neutron-lib version. But because of that developers can't use "Depends-On" to test some neutron change together with the related neutron-lib change. After discussion our final decision is that we will propose one additional CI job which will use neutron-lib from master branch. So this job can be used to check neutron and neutron-lib changes together before neutron-lib with required change will be released. # Day 4 (Friday) ## Nova-Neutron-Cyborg cross projects session This was long (2h) session where we discussed couple of important things. * First topic was about scheduling of the routed networks. After some discussion was that Nova team will work on something only on Nova's side as a first step. Later we will see how to move forward with integration of Nova and Neutron there. * Second topic was about updating minimum bandwdith for the ports. We agreed that this should be done on Neutron side and Neutron will update resource allocation directly in Placement. There is no need to involve Nova in this process. We also decided that we will not allow update values of the existing, already associated rules in the QoS Policy. The only possible way to change minimum bandwidth will be to update port to associate it with new QoS Policy. * Last topic on this meeting was related moslty to Cyborg and Nova cooperation. There will be required some changes on the Neutron side as well, like e.g. add new api extension which will add "device profile" to the port object. This new attribute will contain e.g. information about name of the device profile from Cyborg. Details are in doc: [9] ## Future of lib/neutron and lib/neutron-legacy in devstack In Devstack there are currently 2 modules which can configure Neutron. Old one called "lib/neutron-legacy" and the new one called "lib/neutron". It is like that since many cycles that "lib/neutron-legacy" is deprecated. But it is still used everywhwere. New module isn't still finished and isn't working fine. This is very confusing for users as really maintained and recommended is still "lib/neutron-legacy" module. During the discussion Sean Collins explained us that originally this new module was created as an attempt to refactor old module, and to make Neutron in the Devstack better to maintain. But now we see that this process failed as new module isn't still used and we don't have any cycles to work on it. So our final conclusion is to "undeprecate" old "lib/neutron-legacy" and get rid of the new module. ## OVN master and stable CI jobs Currently we are running all Neutron OVN related jobs with OVN installed from packages provided by operating system. Maciek explained us why we should also test it with OVN from master branch. It is like that because often new features added to the OVN driver in Neutron are really dependent on changes in the OVN project. And until such changes in OVN aren't really released we can't test if Neutron OVN changes really works with new OVN code as they should. So we deviced to change "neutron-ovn-tempest-full-multinode-ovs-master" that it will also install OVN from the source. ## CI Status During discussion about our CI jobs we decided to remove from the Neutron check queue 2 non-voting and still not stable jobs: "neutron-tempest-plugin-dvr-multinode-scenario" and "neutron-tempest-dvr-ha-multinode-full" and move those jobs to the experimental queue. This is temporary solution until we will fix those 2 jobs finally. # Team photo It wasn't as great as in other PTGs. But You can find our team photos in the current context at [10]. Credits for photos comes to Rodolfo and Jakub who made them :) Thx a lot! # Etherpads Etherpad from Neutron sessions can be found at [11]. Notes from the Nova-Neutron-Cyborg session can be found at [12]. [1] https://opendev.org/openstack/congress [2] https://opendev.org/x/neutron-interconnection [3] https://bugs.launchpad.net/neutron/+bug/1832526 [4] https://bugs.launchpad.net/neutron/+bug/1817881 [5] https://docs.openstack.org/neutron/latest/ovn/gaps.html [6] https://bugs.launchpad.net/neutron/+bug/1045613 [7] https://bugs.launchpad.net/neutron/+bug/1285335 [8] https://review.opendev.org/#/c/665467/72/ [9] https://docs.google.com/document/d/11HkK-cLpDxa5Lku0_O0Nb8Uqh34Jqzx2N7j2aDu… [10] http://kaplonski.pl/images/Virtual_PTG_2020/ [11] http://kaplonski.pl/images/Virtual_PTG_2020/ [12] https://etherpad.opendev.org/p/nova-victoria-ptg -- Slawek Kaplonski Senior software engineer Red Hat

2 3

[cinder] victoria virtual mid-cycle part 1 poll
by Brian Rosmaita 11 Jun '20

11 Jun '20

Hello Cinder team and fellow travelers, As discussed at today's Cinder meeting, we'll hold a virtual mid-cycle meeting in two two-hour sessions, at weeks R-16 and at R-8. Please indicate your availability to meet for the first session, which will be held during the week of June 22-26: https://doodle.com/poll/4vx4gavsewrkgbyh Please respond before 12:00 UTC on Monday 15 June. thanks, brian

1 0

Idempotency for multiple nics
by Nadarajah, Sathia 11 Jun '20

11 Jun '20

Hi All, We are facing the exact issue that is outlined here, “When a server is created with multiple nics which holds security groups, module was applying default SG to the server & remove SG on the nics.” https://github.com/ansible/ansible/pull/58509 https://github.com/ansible/ansible/issues/58495 And we are on the following version of openstacksdk (ansible) [root@ansnvlonls01 bin]# source /var/lib/awx/venv/mypy3/bin/activate (mypy3) [root@ansnvlonls01 bin]# pip show openstacksdk Name: openstacksdk Version: 0.46.0 Summary: An SDK for building applications to work with OpenStack Home-page: https://docs.openstack.org/openstacksdk/ Author: OpenStack Author-email: openstack-discuss(a)lists.openstack.org License: UNKNOWN Location: /var/lib/awx/venv/mypy3/lib/python3.6/site-packages Requires: netifaces, iso8601, keystoneauth1, os-service-types, PyYAML, cryptography, six, requestsexceptions, decorator, pbr, jmespath, appdirs, munch, jsonpatch, dogpile.cache When can we expect to have this fix factored into openstacksdk ? Thanks. Regards, Sathia Nadarajah Security and Enterprise Engineering CH2 Networks and IT, Telstra [Telstra] P 0386946619<tel:+61-3-8694-6446> M 0437302281<tel:+61-407-843-045> E Sathia.Nadarajah.2(a)team.telstra.com<mailto:Sathia.Nadarajah.2@team.telstra.com> W www.telstra.com<http://www.telstra.com>

2 2

[ops][telemetry] OpenInfra Labs discussion on cloud monitoring
by Jeremy Stanley 10 Jun '20

10 Jun '20

The OpenInfra Labs project is starting a discussion on their mailing list to try and find commonalities across open cloud monitoring approaches, beginning by assembling user stories and requirements from a diversity of organizations. If anyone has any feedback for them, I recommend following up to that ML thread (and subscribe even, their list is very low-volume). http://lists.opendev.org/pipermail/openinfralabs/2020-June/000061.html -- Jeremy Stanley

1 0

[oslo] PTG Wrapup
by Ben Nemec 10 Jun '20

10 Jun '20

I wrote up a slightly wordy summary of the Oslo PTG discussions: http://blog.nemebean.com/content/oslo-virtual-ptg-victoria Hopefully I didn't forget anything in the week+ since then, but if I did let me know. :-) -Ben

1 0

[kolla-ansible] Some proposals based on my work with kolla-ansible
by Klemen Pogacnik 10 Jun '20

10 Jun '20

HI! I’ve worked with kolla-ansible for over the year, currently on rocky version. I’ve done some work which can maybe be intersting to community. 1. Proposal - Adding additional functionality to kolla-ansible playbook For functionalities which are not officially supported by kolla-ansible group, but are done by any individual or a group and are interesting for a community. Each additional functionality has its own GIT project. It consists of one or more ansible roles. The structure of project is very similar to the kolla-ansible project. addfunct-name / README.md / etc / kolla / globals.yml / passwords.yml / ansible / inventory / all-in-one / multinode / group_vars / all.yml / roles / addmodule_role1 / … / addmodule_role2 / … / destroy.yml / kolla-host.yml / post-deploy.yml / site.yml / stop.yml Configuration parameters of functionality are put to globals.yml and all.yml. Passwords are put to passwords.yml. Inventory data are added to all-in-one and multinode files. Roles variables, tasks, handlers, templates are added to ansible/roles. Activation of roles are included to destroy.yml, kolla-host.yml, post-deploy.yml, stop.yml and/or site.yml. Not all steps are compulsory. Merging additional module project to kolla-ansible is quite simple with basic shell commands: cat $ADD_MODULE/etc/kolla/globals.yml >> $KOLLA_ANSIBLE/etc/kolla/globals.yml cat $ADD_MODULE/etc/kolla/passwords.yml >> $KOLLA_ANSIBLE/etc/kolla/passwords.yml cat $ADD_MODULE/ansible/group_vars/all.yml >> $KOLLA_ANSIBLE/ansible/group_vars/all.yml cat $ADD_MODULE/ansible/inventory/all-in-one >> $KOLLA_ANSIBLE/ansible/inventory/all-in-one cat $ADD_MODULE/ansible/inventory/multinode >> $KOLLA_ANSIBLE/ansible/inventory/multinode cat $ADD_MODULE/ansible/destroy.yml >> $KOLLA_ANSIBLE/ansible/destroy.yml cat $ADD_MODULE/ansible/kolla-host.yml >> $KOLLA_ANSIBLE/ansible/kolla-host.yml cat $ADD_MODULE/ansible/post-deploy.yml >> $KOLLA_ANSIBLE/ansible/post-deploy.yml cat $ADD_MODULE/ansible/site.yml >> $KOLLA_ANSIBLE/ansible/site.yml cat $ADD_MODULE/ansible/stop.yml >> $KOLLA_ANSIBLE/ansible/stop.yml cp -r $ADD_MODULE/ansible/roles/* >> $KOLLA_ANSIBLE/ansible/roles That way additional roles are executed together with other kolla-ansible roles on hosts which are specified in a common inventory. Tasks can use all available kolla-ansible variables, tools, ansible modules. 2. Proposal – building kolla-ansible container image kolla-ansible can be run in a container. Image is built together with other kolla containers and is available on docker hub. That way it would be easier for somebody to try kolla. It is also possible to build images, which have some interesting additional functionalities included. 3. Proposal – adding ceph as an additional functionality described in previous proposals Ansible roles are developed for external ceph deployment. Cephadm, kolla-ceph or any other tool can be used in role’s plays. Has somebody have a suggestion, what to use? A special kolla-ansible container image is built with included ceph roles. Merging is specified in Dockerfile. I’ve already included three additional functionalities: - docker_settings (docker_bip network is configurable) - resource_reservation (resources – cpu cores and memory can be limited for openstack services) - freeipa_client_install (freeipa client installation – done by my colleague, not finished yet) They are now all included in the same project and can be viewed on: https://gitlab.com/kemopq/addmodules-kolla-ansible/-/tree/master/ansible <http://gitlab.com/kemopq/addmodules-kolla-ansible/-/tree/master/ansible> I’m building kolla-ansible container with those functioanlities included and running kolla-ansible playbook in container. I’m planing to do external Ceph deployment that way in next weeks. I’m open to suggestions how this concept can be improved. Klemen

1 0

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

10 Jun '20

Hi everyone, The Large Scale SIG will have a meeting this week on Wednesday, June 10 at 8 UTC[1] in the #openstack-meeting-3 channel on IRC: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200610T08 Feel free to add topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting A reminder of the TODOs we had from last meeting, in case you have time to make progress on them: - masahito to post initial oslo.metrics code to openstack/oslo.metrics Talk to you all on Wednesday, -- Thierry Carrez

1 1

[cinder] Victoria Virtual PTG
by Brian Rosmaita 10 Jun '20

10 Jun '20

A summary of what happened at the Cinder part of the PTG is available: https://wiki.openstack.org/wiki/CinderVictoriaPTGSummary That page also contains links to the recordings. If you led a discussion, please take a look at your topic to make sure I captured all the important points correctly. cheers, brian

1 0

[all] Migrating upstream CI/CD jobs to Ubuntu Focal (20.04)
by Ghanshyam Mann 10 Jun '20

10 Jun '20

Hello Everyone, As per the victoria cycle testing runtime, we need to run upstream CI/CD jobs on Ubuntu Focal[1]. For better tracking and speeding up this work, TC is in the process of selecting this as 2nd goal for the Victoria cycle[2]. Plan: ------ * devstack will provide the WIP patch for devstack base job running on focal and all projects will test their jobs using the same[3]. * migrate projects side jobs to focal. This includes testing the jobs and fixing the failure if any or migrate jobs to run on focal nodeset if not automatically migrated by devstack job. * Once all projects are running successfully on focal, then merge the devstack base job. * Deadline: I am planning to finish this by m-2 (July 31st) but anytime before is always better. Current progress: ---------------------- * devstack base jobs migration on focal which can be used by project side testing is in progress. frickler patch failing with one nova test[4]. * As we have community goal to migrate all legacy jobs to zuulv3 native[5], migration to focal will only cover the devstack based or zuulv3 native jobs not the legacy jobs. All the legacy jobs will automatically be moved on focal distro during their migration to zuulv3 native. If anything failing and cannot be fixed immediately, then those legacy jobs can temporarily override the nodeset to bionic. * selecting this as community goal is also is in progress. [1] https://governance.openstack.org/tc/reference/runtimes/victoria.html [2] https://review.opendev.org/#/c/731213/ [3] https://review.opendev.org/#/c/731207/4 [4] https://review.opendev.org/#/c/734029/1 [5] https://governance.openstack.org/tc/goals/selected/victoria/native-zuulv3-j… -gmann

1 0

[tc][interop] Interop repos renaming from openstack/ to osf/ namespace
by Ghanshyam Mann 10 Jun '20

10 Jun '20

Hello Everyone, With OpenDev model, TC merged the resolution of keeping only openstack governance owned projects to 'openstack/' namespace[1]. Migration for other non-openstack-owned projects/repos have been done but Interop repos[1] are still under openstack/ namespace which is confusing. After discussing it in today interop meeting, it was agreed to move all the interop repos from 'openstack/' to 'osf/' namespace. I have proposed the changes to infra - https://review.opendev.org/#/c/734669/ Redirect will be provided for old url but few of the below things need to be taken care by interop team: - zuul jobs update to use the new url. I have proposed the changes which i found in my grep but if any job is missed, please update those with 734669 as Depends-On[3]. - github mirroring (if needed). After discussing it with clarkb,AJaeger, and fungi this needs to be done by osf github org admin. I am leaving that for now and something can be done once renaming is completed. [1] https://governance.openstack.org/tc/resolutions/20190322-namespace-unoffici… [2] https://opendev.org/openstack/interop https://opendev.org/openstack/refstack https://opendev.org/openstack/refstack-client https://opendev.org/openstack/python-tempestconf [3] https://review.opendev.org/#/q/topic:interop-repo-renaming+(status:open+OR+… -gmann

1 0

[tc][neutron] Victoria/Virtual PTG Summary
by Nate Johnston 09 Jun '20

09 Jun '20

As I sit down to describe the highlights of the virtual OpenDev PTG of June 2020, the first thing I have to say is that the virtual participation is a two edged sword. On one hand, the spontaneity of the hallway track and the ability to quickly drop in to another group's meeting were largely lost. But I think that there were some people in the Neutron room that would not have been able to make it if the event was held in Vancouver. Once the pandemic is in the rear view mirror, I hope that we can resume in-person events. But I think that there is potential value to interspersing virtual events with the in-person variety, to reach out to students, small companies, and ravel-averse companies or individuals. I'd also like to say that the Foundation staff did a great job with running an event that so completely broke from precedent. The choice of two videoconferencing platforms, with the ability of teams to select the one that matched their needs the best, was foresighted since certain areas had access issues with certain platforms. --- Technical Committee --- I felt that the TC sessions at this PTG were very productive and valuable. In particular, we used the 'raise hands' feature in Zoom to ensure an orderly exchange of views that gave everyone a chance to speak, and I felt that went very well. A few of the highlights of what the TC discussed and decided are: 1.) The TC decided to draft a policy change to provide a model for a project without a PTL. If an interested project was interested in changing to a PTL-less model they could opt-in to such a model, but for projects that do not opt in nothing would change. When imagining how a project could function without a PTL, we deconstructed the role into it's component parts, including: interfacing with the release, infrastructure, and security teams; doing the necessary prep work for PTG and summit events; acting as a public contact point for the project; acting as the bug resolver of last resort. Of these the only ones that are essential from a TC perspective are the release liaison and the infrastructure liaison (for CI issues); the VMT team already has a list of subject matter experts they consult for vulnerabilities. An events person may be called for on a per-event basis - and if no one steps forward for a project, then that project wouldn't be represented at that event. There's definitely more responsibility diffused within the project team in this model, without a "the buck stops here" PTL position. And not every question is answered - for example, who looks for potential cores to mentor and bring up to speed while still ensuring diversity in the core group over time? Look forward to a governance proposal in the coming month or so about this topic, and hopefully a lively discussion that will help us sort out the rough edges! 2.) There has been an increasing consensus that the division between the Technical Committee and the User Committee of OpenStack is an artificial one, a relic of the rapid-expansion phase of the OpenStack universe and not in keeping with the current OpenStack environment. In particular, with more operators contributing back and interested in guiding the technical evolution of OpenStack, the dichotomy between developers and operators/users seems false and sends the wrong message. To that end, the TC has formally proposed that the TC and UC should merge into a single body. Because changes to the Foundation bylaws are costly and slow, we would like to execute this merger without changes to the foundation bylaws. Since the TC is specified in greater detail than the UC in the bylaws, the merger would be accomplished by the UC becoming a subset of the TC. This change was anticipated by the higher rate of operators being nominated and elected to the TC this past election, and the proposed governance change [1] completes a merger that has been a long time in coming. 3.) There has been some feedback from operators that the unfinished migration from project-specific clients to the unified OpenStack client causes uncertainty and difficulty for both operators and users. Some have even created their own client that hides the difference between the unified client and the remaining project-specific clients. This is obviously a bad experience and something we can improve. Given this, the TC will place a greater emphasis on preparing the community to conclude the migration to OSC. 4.) The community goals for the V cycle have been selected, and they are to conclude the migration to Zuul v3, and to migrate the base Ubuntu image used in the upstream gates from Bionic 18.04 to Focal 20.04 [2]. 5.) In the U cycle the TC created the 'ideas' repository [3], which is a place for people to post ideas that they think would be great for the OpenStack community. We did this after reflecting that there are a lot of great ideas that are discussed on the mailing list that are perhaps a bit ahead of their time, and then get lost in the mailing list archives. Rather than forgetting about an idea, it could be posted to the ideas repo and then brought back when time is right. Rather than shifting the graveyard for ideas from the mailing list to this repo, the TC or a representative could review the tabulated ideas with an eye to what is ready for revival and discussion in a PTG or forum session. --- Neutron --- The Neutron community made good use of the Jitsi/Meetpad platform after a few opening hiccups. It handled the large number of people in the room well for the most part, and the etherpad integration was interesting. I think it was great how the Neutron team worked well with the Keystone, Nova, Cyborg, and Edge SIG teams and had great collaboration on each front. The themes in the Neutron community were the same as they have been before: stadium projects are increasingly being run by the Neutron core team, those that are not are entering hibernation, with networking-midonet currently at the most risk. The community slowly pushes forward with Engine Facade and is looking to fully deprecate python-neutronclient. We acknowledged that the neutron-lib migration has stalled and decided to make the process easier with debtcollector deprecations. The biggest thing for me in the summit was the decision to move forward with ML2/OVN as the default back end for Neutron, including in devstack. This will be proposed to the broader community and the Neutron team will work with everyone to make sure this is a success. In conclusion, I am as always grateful for the tremendous worldwide OpenStack community. I am proud of how much was accomplished, and I think this PTG sets the stage for a great Victoria cycle. Thanks, Nate [1] https://review.opendev.org/#/c/734074/ [2] Waiting on https://review.opendev.org/#/c/731213/ to be merged [3] https://governance.openstack.org/ideas/

1 0

[tripleo] Victoria TripleO PTG summary
by Wesley Hayutin 09 Jun '20

09 Jun '20

Greetings, Thanks to everyone who attended the OpenStack PTG last week! A special thanks to those who presented their topics and discussed work items with the folks in attendance. As you know the event was virtually hosted in a video conference and seemed quite busy and packed with great topics and conversations. As the current PTL for TripleO I will do my best here to summarize those conversations and items others should be made aware of. To review the topics and discussion please follow the links here [1]. The event was recorded, however the OpenStack foundation has not made any of the videos publicly available yet. Monday June 1st: Retrospective: The TripleO project started with a retrospective of the Ussuri cycle. I attempted to use OpenStack’s storyboard for the process, but had to revert to an etherpad for usability. Keep trying, Storyboard is getting there. The good news is that the good things outweighed the bad things [2], and the ideas for improvement were focused on making things faster \0/ TripleO Operator Ansible Status: by Alex Schultz Alex gave a nice overview of his hard work throughout Ussuri to make TripleO Operator Ansible a reality. TripleO Operator Ansible is the official way now to execute TripleO commands via ansible. The upstream ci and consultants in the field are all consolidating around the tool. The history of reviews to make this happen can be found [4], while Alex completed a lot of the work he also attracted a number of contributors that also completed a lot of work. One note that Alex wanted to emphasize was that while TripleO Operators are meant to be executed by customers, and consultants, TripleO-Ansible is NOT meant to be exposed or called directly. Slides are available here [3]. Thank you Alex! The Future of python-tripleoclient: by Rabi Mishra Rabi led a very interesting conversation about the steps the project would have to take to further simplify the stack of projects used in a TripleO deployment. Currently there are a number of layers in client calls to tripelo-operator-ansible, python-tripleoclient, tripleo-ansible playbooks/modules, tripleo-common library which is complex and not an ideal user experience in terms of logs, resolving bugs. Out of the gate Rabi discussed breaking down python-tripleoclient into something more basic and moving more functions to ansible modules. The proposal was to get rid of CLI or replace it with a very simple one and move all the logic in tripleoclient to ansible playbooks/modules. The top level playbooks would directly map to current cli actions and would be in tripleo-ansible repo. tripleo-operator-ansible can also change to use those playbooks directly and transparently under the hood. Details from the session can be found here [5]. Thanks Rabi! Ansible Strategies & us: by Alex Schultz Alex was up again to let us know what he’s been up to make Ansible more performant. Ansible offers several different kinds of “strategies” with regards to how tasks are executed across multiple hosts. The strategies are pluggable and Alex has built a custom strategy currently called “TripleO Free” that can be used across some but not all of TripleO’s tasks [7]. The performance enhancement is spectacular, reducing a 30 node deployment from almost 2 hours to under 50 minutes. Well done!!! I’ll note the strategy name will be changed to garner more community support and the performance gains are not as pronounced with fewer nodes. A standard CI like deployment ( 4-5 nodes ) can expect to see 20 minutes cut off the deployment Slides of Alex’s presentation can be found here [6]. Very well done! Thanks Alex! Mistral has been removed, so what is left to do? By Kevin Carter Kevin hit us next with what to expect now that mistral has been removed and what steps we need to take next to make the community successful. I’ll note the mistral container is still on the undercloud but inactive, and workflow processing has been converted directly to ansible. There is still some cleanup in tripleo-common and rpm dependencies to prune. A link to the conversation is available [8], and Kevin’s presentation is available [9]. Thank you Kevin! TripleO Operator Pipelines By Emilien Macchi Emilien walked us through what it would take to further consolidate on TripleO Operator Ansible based CI pipelines in TripleO, OSP and at customer sites. Breaking down the full workflow of a deployment and day two operations in CI was reviewed. The goal here is to replace as much CI as possible with TripleO Operator Ansible to have a standardized ansible interface with TripleO in any CI or customer environment. TripleO Operators are shipping in Ussuri and should be backwards compatible with earlier releases. There will be a major push upstream to further integrate TripleO Operator Ansible into every CI job. Notes and comments are published here [10]. Thanks a million! [1] https://etherpad.opendev.org/p/tripleo-ptg-victoria [2] https://etherpad.opendev.org/p/tripleo-ptg-retrospective [3] https://docs.google.com/presentation/d/1Oxs-sflnJd5KIMoY6e_mlfU2zK4QWqWSG7A… [4] https://etherpad.opendev.org/p/tripleo-operator-ansible [5] https://etherpad.opendev.org/p/tripleo-future-of-tripleoclient [6] https://docs.google.com/presentation/d/19mr3HyyYUUGcwbRHsy2-k-F4WNCYCoFvSPz… [7] https://review.opendev.org/#/q/topic:strategy-improvements [8] https://etherpad.opendev.org/p/tripleo-remove-mistral [9] https://docs.google.com/presentation/d/1iir7FA6YwBxRoU_SZJQ2H9Enbak4GAfBw73… [10] https://etherpad.opendev.org/p/tripleo-operator-pipelines Tuesday June 2nd CI updates: by Wes Hayutin In the CI update I mostly covered the new upstream Component Pipeline. The component pipeline has three major goals, the first is to enable us to release at any time with working components of OpenStack, secondly break down a large problem into smaller problems, and third reduce time to debug and fix. The presentation covers monolithic vs. components builds, the workflow and testing and monitoring of the pipeline. The presentation is available here [11] I also noted that the upstream CI executed 268,805 deployments of TripleO in the Ussuri cycle. Third party CI executed 132,853 deployments. Not to shabby. Details are here [12]. Thanks easter bunny! IPv6 and DCN (routed-networks) in upstream CI by Harald Jensas Harald kicked off the next topic about utilizing more advanced networking with OVB in our third party TripleO CI. The proposal is to update the CI with multiple network segments. Herald has been the primary of OVB ( openstack virtual baremetal ) and looks to be wrapping up this feature [13]. Documentation for the feature can be found here [14] and notes of the discussion are posted [15] Thank you Harald! Enable network isolation by default by Harald Jensas Harald continued the networking discussion by highlighting common mistakes made in the field with network isolation settings and TripleO. When customers or consultants accidentally forget to include network-isolation settings heat can be destructive to the production environment and delete networks during an update or upgrade. The discussion led to merged patches that already solve the issue, but catching it earlier in the process was still a concern and led to discussion around additional validations. The goal was also shifted to make network-isolation more approachable by our customers. A spec will be written to improve the customer experience here. Notes can be found [16] Thanks Harald! Future deprecation of tripleo-validations by Cedric Jeanneret Cedric led us through the current status and future of TripleO Validations. The deprecated version of the validations do not have clear ownership, and testing each validation has proved to be difficult. Enter the solution with the validation teams new framework of validations where the validation service is clearly delineated from the validations themselves. We discussed ownership, packaging, CI with the entire workflow of packaging and testing all have clear ownership and fits in very neatly with the component pipeline. Please read through the details of the discussion as this will impact several projects with a clean, exciting way to validate each service in OpenStack [17]. Thank you Cedric!! Container Image Build v2 by Emilien Macchi and Kevin Carter Kevin and Emilien have been putting in a lot of extra hours revamping the container build system for TripleO and have produced a much improved system in record time. TripleO will benefit from smaller containers, faster builds and the flexibility to handle upstream and downstream builds easily. If you haven’t seen the presentation please do have a look [18]. Notes on the topic can be found here [19]. Get involved if you can keep up, Thanks Emilien, Kevin! Ceph Integration w/ cephadm by Francesco Pantano, Giulio Fidente, John Fulton The storage trio walked us through details of cephadm and the ramifications of replacing ceph-ansible. We discussed a wide range of topics here including what features should be built into TripleO vs. handled directly by cephadmin like scale up/down, updates, upgrades. The team walked us through how they dissected the deployment and injected cephadmin as a proof of concept that everything works well and proved we’re in good hands on the storage front. There is a lot of detail in the notes, so please have a read through here [20]. Thank you Francesco, Giulio ( aka bob dylan ), John! Removal of Heat and Swift from Undercloud by Rabi Mishra Rabi continued from his earlier topic regarding the noble effort to further simplify the OpenStack deployment by removing heat and swift. Rabi articulately described how heat is currently used in the latest release and what would have to be done to remove both heat and swift, walking us through heat resources, extra config, IPAM etc and how each could potentially be replaced. I personally really enjoyed hearing this particular topic and how we can move forward making OpenStack less complex. This is an important topic and you should review Rabi’s clear strategy here [21]. Thanks Rabi! Database migrations - can we make them more friendly, or can we do them a better way? By Jesse Pretorius Jesse led us next and spoke to the hard and complex problem of database migrations across OpenStack projects. This session was more of a brainstorming exercise in discovering creative solutions to complex problems. Unfortunately the group felt the problem came down to governance of OpenStack itself in more uniformly enforcing migration details. It was concluded getting all the projects to agree on a standard for migrations would be quite the uphill climb. Notes on the subject can be found here [22]. Thanks Jesse! [11] https://drive.google.com/file/d/1rAohZ01BDFGBOjI3kS9jy-n-P1weQVIX/view [12] https://etherpad.opendev.org/p/tripleo-ptg-victoria-ci-updates [13] https://review.opendev.org/#/q/topic:ipv6-support+(status:open+OR+status:me… [14] https://openstack-virtual-baremetal.readthedocs.io/en/latest/deploy/quintup… [15] https://etherpad.opendev.org/p/tripleo-ipv6-and-routed-networks-in-upstream… [16] https://etherpad.opendev.org/p/tripleo-enable-net-iso-by-default [17] https://etherpad.opendev.org/p/tripleo-validations-future [18] https://docs.google.com/presentation/d/1l2RzL-hJ-fT9jzi2A7s8ladEumOvy8tDy7D… [19] https://etherpad.opendev.org/p/tripleo-container-image-tooling-victoria [20] https://etherpad.opendev.org/p/tripleo-ceph [21] https://etherpad.opendev.org/p/tripleo-heat-swift-removal-undercloud [22] https://etherpad.opendev.org/p/tripleo-ptg-victoria-better-db-sync Wednesday June 3rd Speeding up deployments, updates and upgrades by Jesse Pretorius Jesse had quite a few suggestions and proposals on how we may speed up updates and upgrades. Some of the highlights were building on top of Alex’s ansible strategy improvements and avoiding skipped tasks, avoiding unnecessary reboots etc. There was a lot discussed, please refer to the etherpad for details [23]. Thank you Jesse! Running validations from within a container by Cedric Jeanneret Cedric continued to walk us through the very near future of validations. Cedric wanted to discuss the delivery of validations and the implications of using a container to host the validations. Older non-containerized versions of TripleO were discussed, using an ansible collection and a container were discussed. There are multiple use cases for validations leading the group to not consolidate on a single delivery mechanism. More discussion was needed at the end of this topic. Notes are here [24]. Thanks Cedric! Auto --limit scale-up of Compute nodes by Luke Short Luke walked us through his auto scale up spec [25] in the following presentation [26]. Essentially this is customizing the scale up process to better match the ansible configuration for forked processes to make the scale up quicker. Luke was able to perform a 10 node scale up in 20 minutes. Nice presentation Luke! TripleO usability enhancements: by Wes Hayutin Initially there was not a lot of suggestions in this topic prior to PTG, however once we got started with usability improvements they started to roll in. Definitely check the etherpad [27], but I’ll list some here. - Fix “FAILED - RETRYING in stack status” - fixed already in https://review.opendev.org/#/c/725665/ - Network-Isolation user experience - linked back to Harold’s topic - Chem raised a number of update / upgrade improvements on line 25 [27] - Eliminate the need for customers to remove deprecated services from roles_data in upgrades - Improved logging - Block commands that require a previous actions - Prompt user prior to dangerous actions - Keep simplifying, e.g.’s Rabi’s proposals. Check the etherpad for more details [27] Improvements in TLS Everywhere/ CI Presenter by Ronelle Landy, Ade Lee At the last PTG in Shanghai Ade and I proposed a job that would setup IPA and a Standalone deployment of TripleO and configure it to work together upstream to check and GATE changes to TLS. I’m happy to report that Ade and Ronelle got the job done!! The presentation is available here [29]. This should go a very long way to help prevent TLS related bugs across upstream and internal testing. Thanks Ade, Thanks Ronelle! [23] https://etherpad.opendev.org/p/tripleo-ptg-victoria-speedups [24] https://etherpad.opendev.org/p/tripleo-validation-container [25] https://review.opendev.org/#/c/727768/1/specs/victoria/auto_scale_up_comput… [26] https://drive.google.com/file/d/1c2D67QZ5UGBYRONogZJKMief5wJxQAIt/view [27] https://etherpad.opendev.org/p/tripleo-usability-enhancements [28] https://etherpad.opendev.org/p/tripleo-tls-everywhere-ci [29] https://docs.google.com/presentation/d/1gruDzHIjZtPtUUYSRGIrJynTOt9bZP3W7TL… Thursday June 4th Config-download 2.0 by Luke Short Luke walked us through a proposal to build on config download and what steps could be taken further simplify the deployment using Ansible. Using idempotent tasks, static playbooks etc. The source of truth with regards customer environments was a tough nut to crack here and it was difficult to see a very clear and backwards compatible method to approach this. Notes are available here [30] Ansible logging within tripleoclient by Cedric Jeanneret Cedric proposed improvements to TripleO logging here [31]. Cedric walked the group through the spec. Logging is certainly an area we all want to see improvement on and we all have opinions about so this was a lively conversation. Cedric pointed out there are two main types of steps we need to go after which is any ansible task, and any tripleo cli command called need to be logged together in a human readable way. Very good points made and the conversation will continue in the TripleO spec. [31]. Thanks Cedric! Transitioning the underlying CentOS/RHEL - how can we improve this process? By Jesse Jesse spoke to the challenges facing upgrades with regards to the mix of host RHEL versions in a deployment. Several finer points were made with nuances of the upgrade with regards to HA, pacemaker, libvirt and ironic versions. It was a good troubleshooting session and a thoughtful dialogue with the group. Read the details here [33] Thanks Jesse! VxFlexOS integration within TripleO by Jean Pierre Roquesalane/Rajini Karthik The Tripleo team answered questions and walked the Dell team through the best practices with integrating a 3rd party service with TripleO. Details are here [34] TripleO CI - audit coverage for neutron, ovn, ovs, octavia by Brent Eagles, Slawek Kaplonski, Wes Hayutin This session was about reemphasizing the importance of the network scenarios and workflows that are critical to TripleO’s success in the field. Over the past year or so Brent and others have done a great job in adding additional upstream coverage but it’s now time to make sure this is everyone’s job as well. We discussed the challenges with upstream jobs, the neutron project and TripleO. We also spec’d out some idea on where to build on top of Brent and Slawek successes to reach greater upstream coverage of critical network features and workflows. Notes are available [35]. Really appreciate Brent and Slawek making time to attend, thank you!! tripleo-validations package future by Cedric Jeanneret Last but not least Cedric led a discussion on packaging for validations and how we can align responsibility of validations with rpms, git repos and CI. We spoke to how the packaging is related to the component pipeline. Designing this carefully so that the validation’s team and other projects can work together and independently with clear lines. Good stuff here, details [36] Thanks Cedric! openstack tripleo deploy (standalone) for multinode by James Slagle Please read through the blueprint and specs proposed by James with regards to utilizing the standalone deployment for multinode overcloud deployments. [37] Thanks James [30] https://etherpad.opendev.org/p/tripleo-ptg-victoria-config-download-two [31] https://review.opendev.org/#/c/733652/1/specs/victoria/ansible-logging-trip… [32] https://etherpad.opendev.org/p/tripleo-ptg-victoria-ansible-logging [33] https://etherpad.opendev.org/p/tripleo-ptg-victoria-distro-transition [34] https://etherpad.opendev.org/p/tripleo-ptg-victororia-VxFlexOS [35 https://etherpad.opendev.org/p/tripleo-network-coverage-audit [36] https://etherpad.opendev.org/p/tripleo-validations-future [37 https://etherpad.opendev.org/p/tripleo-ptg-tripleo-deploy Did you make it? Special thank you sincerely ( I know I never sound sincere ) to both Emilien and Alex throughout the cycle in helping me with my PTL responsibilities!! See you next PTG :)

1 0

[openstack-helm] Abandoning old patchsets
by Gage Hugo 09 Jun '20

09 Jun '20

Hello everyone. >From our discussions during the PTG and past meetings, it was brought up about openstack-helm's large number of old patchsets that are still active and have not been updated in a long time, some are several years old. Over the next few days we will be going through these changes and working to abandon anything that is older than 6-12 months, depending on any context if available. If anyone has a change they are still interested in and would like to pick back up, if it gets abandoned, please feel free to restore it and let us know that you intend to continue working on it.

1 0

OpenStack Glossary
by helena＠openstack.org 09 Jun '20

09 Jun '20

Greetings OpenStack Community! We are on a mission to create a glossary of OpenStack related terms and want your help! As the community grows and new contributors want to get involved, we hope to have a consistent definition to help familiarize them with the project. Similarly, having a glossary of terms has proven to be a good SEO tactic to gain more web traffic; by creating this glossary, we are hoping to have greater visibility to potential contributors, users, and supporting organizations. This is where you come in! We need your help to define the terms that we can use to educate future contributors. Below is an etherpad link. We ask that you add, edit, review, and collaborate on this etherpad to help us make the OpenStack community more accessible and understandable. If you think of more terms to add to the list, please do! As always, feel free to reach out with any questions. Cheers, Helena Spease OpenStack: [ https://etherpad.opendev.org/p/OpenStack_Glossary ]( https://etherpad.opendev.org/p/OpenStack_Glossary )

3 3

[ubuntu] Known that qemu 4.2 is incompatible with GCP instances?
by Neil Jerram 09 Jun '20

09 Jun '20

I run tests with GCP instances as the OpenStack hypervisors. Obviously it's better if those can use libvirt_type kvm, i.e. nested virtualization, and this has been possible prior to my current Ussuri upgrade work. With Ussuri on Ubuntu, IIUC, we get qemu 4.2 from cloud-archive:ussuri, but qemu 4.2 has a bug that was fixed by this commit prior to 5.0.0: https://github.com/qemu/qemu/commit/4a910e1f6ab4155ec8b24c49b2585cc486916985 target/i386: do not set unsupported VMX secondary execution controls Commit 048c951 ("target/i386: work around KVM_GET_MSRS bug for secondary execution controls") added a workaround for KVM pre-dating commit 6defc591846d ("KVM: nVMX: include conditional controls in /dev/kvm KVM_GET_MSRS") which wasn't setting certain available controls. The workaround uses generic CPUID feature bits to set missing VMX controls. [...] The bug manifests on a GCP instance with nested virtualization enabled [1], because such a GCP instance doesn't support MSR features. The OpenStack-level symptom is that a VM can't be scheduled onto that GCP instance. Is this a well-known problem? For CentOS/RHEL, [2] looks similar and maybe fixed, but it's difficult to be sure. Best wishes, Neil [1] https://cloud.google.com/compute/docs/instances/enable-nested-virtualizatio… [2] https://bugzilla.redhat.com/show_bug.cgi?id=1722360

2 3

[openstack-helm] No IRC Meeting Today 06/09
by Gage Hugo 09 Jun '20

09 Jun '20

Today's weekly IRC meeting will be cancelled since we just recently discussed topics during last week's PTG. We will continue as scheduled next week.

1 0

[qa] Virtual PTG Wrap-up and office hour was changed to Tue 1300 UTC
by Masayuki Igawa 09 Jun '20

09 Jun '20

Hi, Thank you for attending our sessions! We discussed many things during virtual PTG. Topics are the following. And as we discussed our office hour office time 30 minutes earlier than the current time. So, the office hour will start in 2 hours today. ========= Topics: Mon: @ bexar 13:00-13:30 Ussuri Retrospective (gmann) 13:30-14:00 Make tempest scenario manager a stable interface (kopecmartin/soniya) 14:00-14:30 tempest cleanup (kopecmartin) 14:30-15:00 Gates optimization by a better test schedulling (kopecmartin) Tue: @grizzly 13:00-13:30 Description for testcases as docstrings (kopecmartin) 13:30-14:00 Feature Freeze idea for new tests in Tempest and Patrole and other QA projects (gmann) 14:00-14:15 How to handle the tox.ini constarint for each Tempest new tag (gmann) 14:15-14:30 Migrating hacking checks from other projects to hacking itself(paras333) 14:30-15:00 Victoria Priority & Planning (30min) (masayukig) https://etherpad.opendev.org/p/qa-victoria-priority Etherpad: https://etherpad.opendev.org/p/qa-victoria-ptg You can find the recording video files on the etherpad. However, Monday's recording was disappeared somewhere in the cloud.. :( ========= -- Masayuki Igawa

1 0

[neutron] Drivers meeting on Friday 12.06.2020 cancelled
by Slawek Kaplonski 09 Jun '20

09 Jun '20

Hi Due to my day off this Friday I will not be able to attend and chair our drivers meeting. I know that also at least 2 other members of the drivers team will not be available this week so lets cancel this meeting and lets get back to it next week. Have a great week and see You all next week :) -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[neutron] CI meeting on Wednesday 10.06.2020 cancelled
by Slawek Kaplonski 09 Jun '20

09 Jun '20

Hi, I need to cancel tomorrows CI meeting due to conflicting internal meeting which I have. I will check our CI status and will ping You on IRC if there will be any need. See You on the meeting next week. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[all][InteropWG] Tuesday June 9, UTC 17 - Meeting Reminder to review OpenStack Powered Logo Guidelines and your feedback
by prakash RAMCHANDRAN 09 Jun '20

09 Jun '20

InteropWG is inviting you to a scheduled Zoom meeting Tuesday June 9th,10-10.45 AM PDT / 13-13.45 EDT / 17-17.45 UTC,Join from a browser: https://Dell.zoom.us/wc/join/99829924353 , Password: 101045 , orJoin Zoom Meeting: https://Dell.zoom.us/j/99829924353?pwd=bU9NTkZQVkd3SmIrVGErZWFGVnlmUT09 , and in paralle on irc ,irc: #openstack-interopwg or #openstack , For background review - 1. https://www.slideshare.net/markvoelker/interopwg-intro-vertical-programs-ja… , 2. https://opendev.org/openstack/interop/src/branch/master/2020.06.json , 3. https://etherpad.opendev.org/p/victoria-ptg-interop-wg , Agenda: 1. Agenda Bashing2. Presentation for comments on Ussuri Interop Draft Guidelines (Need - Verbage and logo for adding OpenStack Powered DNS & Orchetsration - -https://www.openstack.org/brand/interop/) Review Project APIs for Interop Ussuri cycle a. keystone , b. glance , c. nova , d. neutron , e. cinder , f. swift , g. designate (OpenStack powered DNS logo?) , h. heat (OpenStack powered Orchestrator Logo?) . 3. Feed back by contributors and any other PTG or representatiive from community 4. Conclusion by Mark Voelker for Ussuri Draft - Vice Chair (Market Place, logo, irc, conference-bridge, issues in refstack-client, tempest features,...) 5. Approval verbal or irc vote in Interop WG for Draft to Board for Thursday June 11 schedule - https://wiki.openstack.org/wiki/Governance/Foundation/11June2020BoardMeeting Finally Any suggestions for Victoria cycle to explore 1. Ironic or Bare metal (Open Infrastructure Powered Logo?)2. NFV (tacker? NFVi &/or VNF/CNF APIs?) (OpenStack NFV Logo?)3. Ideas needed for Heterogeneus Cloud compliance (suggest use cases) (OpenStack Compatible Hybrid Cloud Logo?) ThanksPrakash : Chair InteropWGMark : Vice Chair : Interop WG

1 0

[tripleo] no irc meeting tomorrow
by Wesley Hayutin 09 Jun '20

09 Jun '20

Greetings, As discussed at the PTG, there will only be one TripleO irc meeting every three weeks. I'll update the docs and schedule to reflect that. Thanks

1 0

[oslo] Ping List for Victoria
by Ben Nemec 09 Jun '20

09 Jun '20

Hi, With the start of a new cycle, we refresh our courtesy ping list for the start of the meeting. We do this to avoid spamming people who may no longer be working on Oslo but haven't explicitly removed their name from the ping list. To that end, I've added a new ping list above the agenda template[0]. If you wish to continue receiving courtesy pings, please add your name there. In a couple of weeks we will switch to using this new list. Thanks. -Ben 0: https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_Template

1 1

[keystone] No meeting June 9th
by Nikolla, Kristi 09 Jun '20

09 Jun '20

Hi all, Since we met during the PTG on Thu-Fri, I don't think it's necessary to have the weekly meeting this Tuesday on June 9th. Have 1 hour back :) Best, Kristi

1 0

OSF Community Meeting - June 25 & 26
by Allison Price 08 Jun '20

08 Jun '20

Hi everyone, On June 25 (1300 UTC) and June 26 (0200 UTC) , we will be holding the quarterly OSF community [1] that will cover project updates from all OSF-supported projects and events. The OpenStack community is encouraged to prepare a slide and present a 3-5 minute update on the project and community’s progress. The update should cover updates that have occurred since the last community meeting on April 2. If you would like to volunteer to present the OpenStack update for one meeting (or both!) please sign up here [1]. We are aiming to finalize the content by Friday, June 19. If you missed the Q1 community meeting, you can see how the upcoming meeting will be structured in this recording [2] and this slide deck [3]. If you have any questions, please let me know. Thanks! Allison [1] https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2 <https://etherpad.opendev.org/p/OSF_Community_Meeting_Q2> [2] https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb… <https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb…> [3] https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY… <https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY…>

1 0

[all][PTG] Feedback Etherpad
by Kendall Nelson 08 Jun '20

08 Jun '20

Hello Everyone! Thanks to everyone who made the first ever virtual PTG a success! Instead of doing a live feedback session, we are asking you to share your experiences with us in a feedback etherpad! We started circulating it even before the PTG, but wanted to make sure you all saw it and had a chance to voice your feedback. We really appreciate it! -the Kendalls (diablo_rojo & wendallkaters) [1] https://etherpad.opendev.org/p/June2020-PTG-Feedback

1 0

[baremetal-sig][ironic] Baremetal whitepaper: the final chapter
by Arne Wiebalck 08 Jun '20

08 Jun '20

Dear all, The bare metal white paper [0] is almost finished, thanks to everyone who helped during the past weeks! We plan to have a (hopefully final) session to address the remaining open issues and to round things off during one of slots proposed in the doodle available at https://doodle.com/poll/afwgy9zs8fi55wqe Everyone is still welcome to give input or feedback. Like before, I will send out the call details once we have settled on the time slot. Cheers, Arne [0] https://docs.google.com/document/d/1BmB2JL_oG3lWXId_NXT9KWcBJjqgtnbmixIcNsf… -- Arne Wiebalck CERN IT

1 1

[swift, interop] Swift API level changes to reflect in Interop
by Arkady.Kanevsky＠dell.com 08 Jun '20

08 Jun '20

As we create new guidelines for Interop, We need to see what changes needed for object storage guidelines. So a few specific questions for Swift team: 1. What new Tempest tests added for Ussuri release? a. APIs for query and accessing older versions? Is it for S3 APIs or for swift API also? b. Any new or modified Tempest test for Etags? c. Any SIGUSR1 test coverage? d. New tempest tests for swift-ring-builder? 2. What are tempest tests deprecated for Ussuri release? a. Any tempest tests removed for auto_create_account_prefix? Any other API test coverage tests missed above? Thanks, Arkady

3 6

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

08 Jun '20

Hi everyone, Here’s an update for what happened in the OpenStack TC this week. You can get more information by checking for changes in openstack/governance repository. # CHANGES PENDING - Select migrate-to-focal goal for Victoria cycle: https://review.opendev.org/#/c/731213/ - Propose Kendall Nelson for vice-chair: https://review.opendev.org/#/c/733141/ - Clarify the support for linux distro: https://review.opendev.org/#/c/727238/ - Add njohnston liaison preference: https://review.opendev.org/#/c/733269/ - Update joining-tc.rst to be general tc-guide.rst: https://review.opendev.org/#/c/732983/ - Remove tricircle project team: https://review.opendev.org/#/c/731566/ - Add diablo_rojo liaison preferences: https://review.opendev.org/#/c/733284/ - Rename ansible-role-lunasa-hsm deliverable: https://review.opendev.org/#/c/731313/ - Merging TC and UC into a single body: https://review.opendev.org/#/c/734074/ - Retire swift-specs: https://review.opendev.org/#/c/733901/ # RETIRED PROJECTS - Remove congress project team: https://review.opendev.org/#/c/728818/ # GENERAL CHANGES - Switch to newer openstackdocstheme version: https://review.opendev.org/#/c/733313/ Thanks! Regards, -- Mohammed Naser VEXXHOST, Inc.

1 0

[cinder][kayobe][kolla][OSA][tripleo] Ussuri cycle-trailing release deadline
by Sean McGinnis 08 Jun '20

08 Jun '20

Hello teams with deliverables following the cycle-trailing release model! This is just a reminder about wrapping those Ussuri trailing deliverables up. A few cycles ago we extended the deadline for cycle-trailing to give more time, so the actual deadline isn't until August 13: https://releases.openstack.org/victoria/schedule.html#v-cycle-trail If things are ready sooner than that though, all the better for our downstream consumers. Just for awareness, the following cycle-trailing deliverables will need their final releases at some point in the next few months: cinderlib kayobe kolla-ansible kolla-cli kolla openstack-ansible os-refresh-config Thanks! Sean

1 0

[nova] Runway for Victoria
by Balázs Gibizer 08 Jun '20

08 Jun '20

Hi, Runway etherpad [1] with 3 slots and and empty queue is open for Victoria. Cheers, gibi [1] https://etherpad.opendev.org/p/nova-runways-victoria

1 0

[doc] installation guide maintenance
by Akihiro Motoki 08 Jun '20

08 Jun '20

Hi, During the doc migration, the installation guide was moved to individual project repos. I see problems in installation guide maintenance after the migration. - The installation guide is not maintained well perhaps in many projects. AFAIK they are not verified well at least in horizon and neutron. - Even if we try to verify it, it is a tough thing because we need to prepare base distribution and setup other projects together (of course it depends on projects). This leads to a development bandwidth and priority issue. - We sometimes receive bug reports on the installation guide, but it is not easy for the upstream team confirm them and verify fixes. I guess the installation guides are not being maintained well from these reasons. Any thoughts on this situation? (This is my first question.) If a project team has no bandwidth to maintain it, what is a recommended way? I see several options: - Drop the installation guide (per OS or as a whole) -- If drop what should the criteria be? - Keep the installation guide with warnings like "the upstream team does not maintain it and just host it". - Keep it as-is (unmaintained) Finally, I am not sure we need to maintain step-by-step guides on installations and I wonder we need to drop them at some time. Most users deploy OpenStack using deployment projects (or their own deployment tools). Step-by-step guides might be useful from educational perspective but unmaintained guides are not useful. Thanks in advance, -- Akihiro Motoki (amotoki)

5 7

[neutron] Neutron Bug Deputy Report Jun 1-8
by Lucas Alvares Gomes 08 Jun '20

08 Jun '20

Hi, This is the Neutron bug report of week 23 (1 Jun - 8 Jun). Untriaged: - "Inconsistent coding while upgrading" * https://bugs.launchpad.net/neutron/+bug/1881685 - "Centralized SNAT failover does not recover until "systemctl restart neutron-l3-agent" on transferred node" * https://bugs.launchpad.net/neutron/+bug/1881995 - "Quality of Service (QoS) in neutron" * https://bugs.launchpad.net/neutron/+bug/1882072 Critical: - "[OVN]IPv6 hot plug tempest tests are failing with OVN backend" * https://bugs.launchpad.net/neutron/+bug/1881558 - "Neutron-vpnaas scenario tests are very unstable" * https://bugs.launchpad.net/neutron/+bug/1882220 High: - "[OVN] Virtual port type set while port has no parents" * https://bugs.launchpad.net/neutron/+bug/1881759 * Fix released * Assigned to Maciej Jozefczyk * Patch proposed: https://review.opendev.org/732690 - "neutron-ipset-cleanup fails with Traceback: Unhandled error: oslo_config.cfg.NoSuchOptError: no such option AGENT in group [DEFAULT]" * https://bugs.launchpad.net/neutron/+bug/1881771 * Fix released * Assigned to Frode Nordahl * Patch proposed: https://review.opendev.org/732701 - "neutron-ovn-db-sync-util fails with KeyError: 'port_security_enabled' when port security not enabled" * https://bugs.launchpad.net/neutron/+bug/1882061 * In-Progress * Assigned to Frode Nordahl * Patch proposed: https://review.opendev.org/733512 - "neutron-ovn-db-sync-util stops with Traceback due to L3 service plugin expecting ``ovn`` mech driver to be present while ``ovn-sync`` mech driver is loaded" * https://bugs.launchpad.net/neutron/+bug/1882202 * In-Progress * Assigned to Frode Nordahl * Patch proposed: https://review.opendev.org/733775 Medium: - "neutron-ovn-db-sync-util fails with Traceback when notify_nova config is present" * https://bugs.launchpad.net/neutron/+bug/1882020 * Fix released * Assigned to Frode Nordahl * Patch proposed: https://review.opendev.org/733481 Invalid: - "Neutron CI doesn't run tests that require advanced image" * https://bugs.launchpad.net/neutron/+bug/1882060

1 0

Re：[cyborg][ptg] Cyborg PTG Summary for the Day — Come in series
by yumeng bao 08 Jun '20

08 Jun '20

Hi all, All topics for cyborg PTG are done! Notes and comments are on the etherpad. Thank you all for the great topics, participation, discussion etc! Topics that have come to an conclusion are marked with [AGREE] or [ACTION], while topics that need further discussion are not. listed below are important topics that need further discussion either in the format of future meeting or maillist or a spec: 1. 3rd party CI support for new drivers * define which tempest tests need to be used in 3rd party CI. * 2. cyborg/neutron/nova sriov intigration * a spec in nova will be proposed to continue discussion If you have any feedbacks please reply here or in IRC. Regards, Yumeng

1 0

[puppet] puppet-openstack meeting
by Thomas Goirand 08 Jun '20

08 Jun '20

Hi guys! Wouldn't it be nice to organize some meet-up online, for example using the jitsi instance that the infra team built? I at least would enjoy a lot seeing you face-to-face (ie: Tobias, Takashi, Zheng, as I know already Emilien and Alex). Moreover, it'd be nice to discuss the plans for Victoria. Your thoughts? Cheers, Thomas Goirand (zigo)

1 0

[all][InteropWG] Last call for interop capabilities from OpenStack partciapting projects
by prakash RAMCHANDRAN 07 Jun '20

07 Jun '20

Hi all, We are happy to report that score of people turned up for Interop WG discussions on First call on Monday June1st.Friday 5th June we had a review call to consolidate and follow up on guidelines for the OpenStack Powered Trademark Program. https://etherpad.opendev.org/p/victoria-ptg-interop-wghttps://etherpad.open… Please note the terminology -https://github.com/openstack/interop/blob/master/doc/source/schema/2.0.rst#capabilities capabilities - required, advisory, deprecated, removed Stein Train /add Ussuri/delete Victoria KeystoneGlanceSwift Nova NA (Ironic BM) Neutron Cinder v2 Add-ons OpenStack Powered - Orchestration & DNSHeatDesignate Based on current review there are no net new APIs to be added to Ussuri cycle with respect to Stein that are eligible for Interop Programs.The above project teams can go through codeRefStack server guidelines page RefStack Client. Artem Goncharov (irc: gtema) - ANswers to Questions by Artem and follow up actions - refstack-client seems to be orphaned now and offered changes are not reviewed (gtema) - There is access failure and is being addressed by Mark, after that we will review this with help of gtema to file a ticket with bug details - link between guideline and required tempest is desired, since it requires currently effors to nail down failures by jumping between tempest versions (gtema) - This a feature add request, need a story or bug to aggressed in Tempest by gtema - network extensions api - does it make sense to include it? - Note any L2/L3 CRUD on network, subnet and ports and all their attributes are covered. The plug-ins and admin user requirements for extensions are out of scope and hence not considered. However you may verify with Neutron team as what is their proposal to this team? - resource tagging apis - does it make sense to include them? - Reosurce taggin again are optional attirbutes to reousrce ID and very speicifc to resource under trait libraray or ad-hoc to Vendor specific plugins and drivers and will not qualify for interoperability. You can still ask if any new resources that are used by any of core projects to propose and justify why tha'ts required for interop testing? Attached the current diff's for both 2020.06.json vs 2019.11.json and similar diff's for add-ons for Orchstration and DNS. Seeking volunteers to update web page write-up and logos to be proposed for "Openstack Powerd Orchestaion" & Openstack Powered DNS". Heat ans Designate teams can suggest what they would like to bring to table for draft and approval to board? ThanksPrakash

1 0

[nova][libvirt] Support for MIPS architecture?
by 赵晓琳 06 Jun '20

06 Jun '20

Hi I'm trying to run openstack on a host with MIPS architecture, but got some errors, and I have fixed them. Many people around me use hosts with MIPS architecture. We hope the official can add support for MIPS and we can maintain it. Thanks, xiaolin

4 5

[all][InteropWG] Please verify if Swift Project needs any updates for Interop testing of user APIs
by prakash RAMCHANDRAN 06 Jun '20

06 Jun '20

Hi Swift team core members, We are trying to run our ambassadors or volunteers to your meetings, but if we miss please reply with "Confirmed OK" to submit these draft to be merged for "OpenStack Powered Storage" approval. Please bring this to your PTG meetings if needed to assign a volunteer to complete the verification and patch if updates are needed. Swift: We test 20 capability with 60 tests -do you need any changes to 2020.06.json swift api draft before seeking approvals?https://docs.openstack.org/api-ref/object-store/ https://opendev.org/openstack/interop/src/branch/master/2020.06.json#L179Ch… Line 179-214 and confim that tests is capability tests 1-20 will suffcie or submit patch to inerop. - identity-v3-tokens-create [1/1] - identity-v3-tokens-delete [1/1] - objectstore-account-list [12/12] - objectstore-account-quotas [2/2] - objectstore-container-acl [2/2] - objectstore-container-create [2/2] - objectstore-container-delete [1/1] - objectstore-container-list [11/11] - objectstore-container-metadata [5/5] - objectstore-container-quotas [3/3] - objectstore-dlo-support [2/2] - objectstore-info-request [1/1] - objectstore-object-copy [4/4] - objectstore-object-create [2/2] - objectstore-object-delete [1/1] - objectstore-object-get [3/3] - objectstore-object-versioned [1/1] - objectstore-slo-support [4/4] - objectstore-temp-url-get [1/1] - objectstore-temp-url-put [1/1] ThanksInterop WG chai Prakash& Vice chair Mark

2 1

[kolla-ansible] Proposing Doug Szumski as Kolla Ansible core
by Radosław Piliszek 05 Jun '20

05 Jun '20

Hi Folks! This mail serves to propose Doug Szumski from StackHPC (dougsz @IRC, CC'ed) as Kolla Ansible core. Doug coauthored the Nova cells support and helps greatly with monitoring and logging facilities available in Kolla. Please give your feedback in this thread. If there are no objections, I will add Doug after a week from now (that is roughly when PTG is over). -yoctozepto

9 9

Networking-vpp 20.05 for VPP 20.05 is now available
by Naveen Joy (najoy) 05 Jun '20

05 Jun '20

Hello All, We'd like to invite you to try out Networking-vpp 20.05. As many of you may already know, VPP is a fast user space forwarder based on the DPDK toolkit. VPP uses vector packet processing algorithms to minimize the CPU time spent on each packet to maximize throughput. Networking-vpp is a ML2 mechanism driver that controls VPP on your control and compute hosts to provide fast L2 forwarding under Neutron. This latest version of Networking-vpp is updated to work with VPP 20.05. In this release, we've made the below changes: - We've added a class that defines network type APIs and implements them. The network types supported are VLAN, Flat and GPE. Our intent is to add support for pluggable network types without the need to modify code. We'll be continuing our work to enhance this feature in the next release. - We've updated the code to be compatible with VPP 20.05 API changes. - We've added code to deal with poorly formed security group subnets. For instance, 1.2.3.4/0 is completely acceptable in a security group rule. Previously, VPP accepted this in its API calls but this is not currently the case. We've fixed this up at the high level to be acceptable to VPP. - We've fixed an issue with missing package data required for VPP API message validation. - We've dropped VPP 19.04 compatibility code. - We've fixed an issue with the security group mechdriver code in which a SG rule is added but not pushed out to VPP until the next rule is added or the security group is changed. - We've moved VPP specific constants to a dedicated vpp_constants.py file. - Due to a VPP issue, GPE support will be deferred to the 20.05.1 release. - We've been doing the usual round of bug fixes, clean-ups and updates - the code will work with VPP 20.05, the OpenStack Stein release & Python 3. The README [1] explains how you can try out VPP with Networking-vpp using devstack: the devstack plugin will deploy the mechanism driver with VPP 20.05 and should give you a working system with a minimum of hassle. We will be continuing our development for VPP's 20.05.1 release. We welcome anyone who would like to come help us. -- Jerome, Ian & Naveen [1] https://opendev.org/x/networking-vpp/src/branch/master/README.rst

1 0

[openstack-ansible] PTG results
by Dmitriy Rabotyagov 05 Jun '20

05 Jun '20

Hi there, Sorry for the previous email - it has been sent accidentally - it was just at the draft stage... I did some formating afterwards:) Here are some of the decisions we come up with during the PTG week: * CentOS 8 topic. ** Install systemd-extras to get systemd-networkd ** Launch without LXC build at first because of the complexity of the solution. To implement LXC we would need the following: *** Replace what `machinectl` does with Ansible tasks, as it's not working properly without btrfs *** See how much it costs to implement lxd - that would not only resolve Centos 8 issue, but also is pretty appreciated among comunity. However, installing in with snapd will auto-update. it's possible to delay up to 60 days the updates but still needs to fix/clean ** Make nspawn unmaintained, because it mostly relies on machinectl. *** Remove nspawn from docs. *** Remove code in cycle afterwards. ** Backport CentOS 8 to Ussuri, drop CentOS 7 for Victoria afterwards. *** On Ussuri CentOS 7 is going to live without distro support *** write reno, that explains that distro installed OSA upgrade path might be tricky/broken for CentOS because of absent Centos7 packages for U. * Logs topic ** finish transition to journald *** check heat for logging *** check for ceph logs - see [1] but this may be a result of the way cephadm containerises all the ceph daemons ** Rewrite log collection script on python with systemd python bindings and get deprecated messages from services' journal into separate file ** Check where we don't use uwsgi role and see if we can use it there now (like designate) ** Check through the logs what roles are we covered with tempest, and what not. We have buch of roles that run tempest, but test like only keystone (but not itself). ** We add libvirtd_exporter [2] to ansible-role-requirements and offer it's deployments on users own prometheus. Offer prometheus deployment as step2. Document usage * Promote ELK stack to 1st class thing ** Create a separate repo and remove from openstack-ansible-ops ** provide out-of-the-box deployment with OSA. Model would be similar to ceph-ansible where deployment can be integrated or standalone * Work on speeding up OSA runtime: ** Fight with skipped tasks (ie by moving them to separate files that would be included) - most valid for systemd service, systemd_networkd and python_venv_build roles ** Try to split up variables by group_vars ** Try to use include instead of imports again * speedup ci ** try to speedup zuul required projects clone process - work with infra team ** Set *_db_setup_host across all roles to utility and adjust [7] * Build mariadb deps for focal (like 10.4.12 release). We can use repo.vexxhost.net for hosting it until mariadb 10.4.14 release. * In case having issues with distro jobs/support we don't hestitate remove it or setting to non-voting state * Remove SUSE support early in Victoria. We already have [4] for this - needs rebasing * Add neutron ovn to integrated tests (with perspective to make it default for new deployments). * Drop resource creation tasks out of os_tempest - OSA and TripleO manage resource creation themselves and pass required vars to os_tempest for config generation * Add support for zookeeper deployment for services coordination (like telemetry, designate, etc) * add tooling to bootstrap-ansible to apply provided gerrit patches for roles - start with this [3] * Try to add aarch64 jobs with separate pipeline once we have some python wheels built up * Migrate group names to remove underscores "The TRANSFORM_INVALID_GROUP_CHARS settings is set to allow bad characters in group names by default, this will change, but still be user configurable on deprecation. This feature will be removed in version 2.10" * add tooling to bootstrap-ansible to apply provided gerrit patches for roles - start with this [5] use it like this [6] * publish common roles (galera, haproxy, memcached, uwsgi, python_venv_build, etc...) to galaxy, rename them to ansible-role-* pattern. As a stage 2 consider publishing os roles. * add some check for repo server, to verify it's ok (lua linters check) instead of failing afterwards because of missing dev libraries for hosts [1] https://github.com/ceph/ceph/blob/be117b555fc1bba1048b87a624d542fd629d1ad1/… [2] https://github.com/jrosser/rd-ansible-libvirtd-exporter [3] http://paste.openstack.org/show/794258/ [4] https://review.opendev.org/#/c/725541/ [5] http://paste.openstack.org/show/794258/ [6] http://paste.openstack.org/show/794259/ [7] https://review.opendev.org/#/c/671454

1 1

[nova] running nova-scheduler in a container
by Jean-Philippe Méthot 05 Jun '20

05 Jun '20

Hi, I’ve been building my own docker images as a mean to both learn docker and to see if we can make our own images and run them in production. I’ve figured out how to make most services run fairly well. However, an issue remains with nova-scheduler and I can’t seem to figure out what’s going on. Essentially, when I try to create a VM it loops in a scheduling state and when I try to delete a VM, it loops forever in a deleting state. I’ve narrowed down the culprit to nova-scheduler. As far as I know, nothing appears in the debug logs of my containerized nova-scheduler whenever I do any kind of action, which forces me to believe that nova-scheduler is not receiving any command. From what I’ve always understood, nova-scheduler works through RPC and Rabbitmq. The fact that this nova-scheduler connects to rabbitmq without issue makes me believe that something else is missing from my container configuration. Does Nova-scheduler listen on network port? Does it listen on a socket? Is there any way that nova-scheduler could ignore requests sent to it? Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc.

2 2

[openstack-ansible] PTG results
by Dmitriy Rabotyagov 05 Jun '20

05 Jun '20

1 0

[nova][ptg] virtual PTG
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, I need to book slots for nova discussions on the official schedule[2] of the virtual PTG[1]. I need two things to do that: 1) What topics we have that needs real-time discussion. Please add those to the etherpad [3] 2) Who wants to join such real-time discussion and what time slots works for you. Please fill the doodle[4] Based on the current etherpad content we need 2-3 slots for nova discussion and a half slot for cross project (current neutron) discussion. Please try to provide your topics and options before the Thursday's nova meeting. Cheers, gibi [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014126.ht… [2] https://ethercalc.openstack.org/126u8ek25noy [3] https://etherpad.opendev.org/p/nova-victoria-ptg [4] https://doodle.com/poll/ermn3vxy9v53aayy

1 5

[nova][neutron][ptg] How to increase the minimum bandwidth guarantee of a running instance
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] As a next step in the minimum bandwidth QoS support I would like to solve the use case where a running instance has some ports with minimum bandwidth but then user wants to change (e.g. increase) the minimum bandwidth used by the instance. I see two generic ways to solve the use case: Option A - interface attach --------------------------- Attach a new port with minimum bandwidth to the instance to increase the instance's overall bandwidth guarantee. This only impacts Nova's interface attach code path: 1) The interface attach code path needs to read the port's resource request 2) Call Placement GET /allocation_candidates?in_tree=<compute RP of the instance> 3a) If placement returns candidates then select one and modify the current allocation of the instance accordingly and continue the existing interface attach code path. 3b) If placement returns no candidates then there is no free resource left on the instance's current host to resize the allocation locally. Option B - QoS rule update -------------------------- Allow changing the minimum bandwidth guarantee of a port that is already bound to the instance. Today Neutron rejects such QoS rule update. If we want to support such update then: * either Neutron should call placement allocation_candidates API and the update the instance's allocation. Similarly what Nova does in Option A. * or Neutron should tell Nova that the resource request of the port has been changed and then Nova needs to call Placement and update instance's allocation. The Option A and Option B are not mutually exclusive but still I would like to see what is the preference of the community. Which direction should we move forward? Both options have the limitation that if the instance's current host does not have enough free resources for the requested change then Nova will not do a full scheduling and move the instance to another host where resource is available. This seems a hard problem to me. Do you have any idea how can we remove / ease this limitation without boiling the ocean? For example: Does it make sense to implement a bandwidth weigher in the scheduler so instances can be spread by free bandwidth during creation? Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg

3 6

[nova][neutron][ptg] Future of the routed network support
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] There is only basic scheduling support in nova for the neutron routed networks feature (server create with port.ip_allocation=deferred seems to work). There was multiple attempts in the past to complete the support (e.g.server create with port.ip_allocation=immediate or server move operations). The latest attempt started by Matt couple of cycles ago, and in the last cycle I tried to push that forward[1]. When I added this topic to the PTG etherpad I thought I will have time in the Victoria cycle to continue [1] but internal priorities has changed. So finishing this feature needs some developers. If there are volunteers for Victoria then please let me know and then we can keep this as a topic for the PTG but otherwise I will remove it from the schedule. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://review.opendev.org/#/q/topic:routed-networks-scheduling

2 2

[nova][ptg] Can we close old bugs?
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] We have more than 800 open bugs in nova [1] and the oldest is 8 years old. Can we close old bugs? If yes, what would be the closing criteria? Age and status? Personally I would close every bug that is not updated in the last 3 years and not in INPROGRESS state. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://bugs.launchpad.net/nova/+bugs?field.searchtext=&orderby=-importance…

5 7

[nova][ptg] bumping compute RPC to 6.0
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] Do we want to bump the compute RPC to 6.0 in Victoria? We did not have the full view what we can gain[2] with such bump so Stephen and I searched through nova and collected the things we could clean up [1] eventually if we bump the compute RPC to 6.0 in Victoria. I can work on the RPC 6.0 patch during V and I think I can also help in with the possible cleanups later. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/compute-rpc-6.0 [2] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-04-16-16.00.log…

3 4

[manila][ptg] Minutes, recordings, final day items and Happy Hour!
by Goutham Pacha Ravi 05 Jun '20

05 Jun '20

Hello Zorillas and interested Stackers, It's Friday already, but it feels like we've been there every day this week! Thanks to note takers, we have the meeting etherpad up-to-date wrt the meetings we've had thus far. [1] Tomorrow, 5th June, Friday, we meet in the same room () between 1300 UTC and 1700 UTC - the schedule details are in the etherpad [1], however the main items are as below: - Optimize the quota processing logic for manage share (haixin) (1300-1330 UTC) - Share and share size quotas/limits per share server (carloss/dviroel) (1340-1410 UTC) - Share server migration (dviroel) (1420 - 1450 UTC) - Manila Container Storage Interface project update/roadmap/demo (tbarron) (1500-1530 UTC) - Manila OSC/CLI "common commands" discussion (maaritamm/vkmc) (1530-1550 UTC) - Virtual Happy Hour (all) (1600-1700 UTC) You'll find the recordings of our past discussions uploaded to YouTube [2]. Check the descriptions to skip ahead to specific topics. Please let me know if you have any difficulty accessing these videos. Hope to see you tomorrow! Thanks, Goutham Pacha Ravi [1] https://etherpad.opendev.org/p/victoria-ptg-manila [2] https://www.youtube.com/playlist?list=PLnpzT0InFrqBKkyIAQdA9RFJnx-geS3lp

1 0

[tripleo] Thanks for a great PTG :)
by Wesley Hayutin 04 Jun '20

04 Jun '20

Thanks all! Great topics, participation, discussion etc! Notes and a summary are in the works. And now your moment of zen.

1 0

[oslo][keystone][nova] Spec for moving policy format default to YAML
by Ben Nemec 04 Jun '20

04 Jun '20

One of the outcomes of the Oslo PTG session on Monday was that we need to make YAML the official default for olso.policy instead of just the unofficial default as it has been since policy-in-code happened. The reason this hasn't happened before now is that it is complex and fraught with security concerns, but the RBAC work going on now has made it clear that we need do it anyway. To that end, I've written a spec[0] that I believe captures the plan we outlined in the PTG session. If this is relevant to your interests, please take a look and leave feedback. Thanks. -Ben 0: https://review.opendev.org/733650

2 1

[ops] [cinder] [nova] How can I understand if "Delete volume on instance delete" was selected ?
by Massimo Sgaravatto 04 Jun '20

04 Jun '20

Hi I need to delete an instance created from volume, but I don't want to delete such volume. How can I know if the option "Delete volume on instance delete" was selected when creating such instance ? I can't find any information in openstack server/volume show outputs Thanks, Massimo

2 2

[Openstack] OpenStack Ussuri for Ubuntu 20.04 LTS and 18.04 LTS
by Corey Bryant 04 Jun '20

04 Jun '20

The Ubuntu OpenStack team at Canonical is pleased to announce the general availability of OpenStack Ussuri on Ubuntu 20.04 LTS and on Ubuntu 18.04 LTS via the Ubuntu Cloud Archive. Details of the Ussuri release can be found at: https://www.openstack.org/software/ussuri To get access to the Ubuntu Ussuri packages: == Ubuntu 20.04 LTS == OpenStack Ussuri is available by default for installation on Ubuntu 20.04. == Ubuntu 18.04 LTS == The Ubuntu Cloud Archive pocket for OpenStack Ussuri can be enabled on Ubuntu 18.04 by running the following commands: sudo add-apt-repository cloud-archive:ussuri The Ubuntu Cloud Archive for Ussuri includes updates for: aodh, barbican, ceilometer, ceph octopus (15.2.1), cinder, designate, designate-dashboard, dpdk (19.11.1), glance, gnocchi, heat, heat-dashboard, horizon, ironic, keystone, libvirt (6.0.0), magnum, manila, manila-ui, mistral, murano, murano-dashboard, networking-arista, networking-bagpipe, networking-bgpvpn, networking-hyperv, networking-l2gw, networking-mlnx, networking-odl, networking-sfc, neutron, neutron-dynamic-routing, neutron-fwaas, neutron-fwaas-dashboard, neutron-vpnaas, nova, octavia, octavia-dashboard, openstack-trove, trove-dashboard, openvswitch (2.13.0), ovn (20.03.0), ovn-octavia-provider, panko, placement, qemu (4.2), sahara, sahara-dashboard, senlin, swift, trove-dashboard, vmware-nsx, watcher, watcher-dashboard, and zaqar. For a full list of packages and versions, please refer to: http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/ussuri_ver… == Branch package builds == If you would like to try out the latest updates to branches, we deliver continuously integrated packages on each upstream commit via the following PPA’s: sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka sudo add-apt-repository ppa:openstack-ubuntu-testing/queens sudo add-apt-repository ppa:openstack-ubuntu-testing/rocky sudo add-apt-repository ppa:openstack-ubuntu-testing/stein sudo add-apt-repository ppa:openstack-ubuntu-testing/train sudo add-apt-repository ppa:openstack-ubuntu-testing/ussuri == Reporting bugs == If you have any issues please report bugs using the 'ubuntu-bug' tool to ensure that bugs get logged in the right place in Launchpad: sudo ubuntu-bug nova-conductor Thank you to everyone who contributed to OpenStack Ussuri. Enjoy and see you in Victoria! Corey (on behalf of the Ubuntu OpenStack Engineering team)

3 6

[nova] [ops] user_id based policy enforcement
by Massimo Sgaravatto 04 Jun '20

04 Jun '20

Hi In my Rocky installation I am preventing users from deleting instances created by other users of the same project. This was implemented setting in the nova policy file: "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s" This works, even if in the nova log file I see: The user_id attribute isn't supported in the rule 'os_compute_api:servers:delete'. All the user_id based policy enforcement will be removed in the future. Now I would also like preventing user to see the console log file of instances created by other users. I set in the nova policy file: "os_compute_api:os-console-output" : "rule:admin_api or user_id:%(user_id)s" but this doesn't work Any hints ? More in general: were the user_id based policy eventually removed in latest OpenStack releases ? Which are then the possible alternatives to implement my use case ? Thanks, Massimo

2 5

[nova][ptg] Runway process in Victoria
by Balázs Gibizer 04 Jun '20

04 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] In the last 4 cycles we used a process called runway to focus and timebox of the team's feature review effort. However compared to the previous cycles in ussuri we did not really keep the process running. Just compare the length of the Log section of each etherpad [1][2][3][4] to see the difference. So I have two questions: 1) Do we want to keep the process in Victoria? 2) If yes, how we can make the process running? 2.1) How can we keep the runway etherpad up-to-date? 2.2) How to make sure that the team is focusing on the reviews that are in the runway slots? Personally I don't want to advertise this process for contributors if the core team is not agreed and committed to keep the process running as it would lead to unnecessary disappointment. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/nova-runways-rocky [2] https://etherpad.opendev.org/p/nova-runways-stein [3] https://etherpad.opendev.org/p/nova-runways-train [4] https://etherpad.opendev.org/p/nova-runways-ussuri

3 4

[nova][ptg] Feature Liaison
by Balázs Gibizer 04 Jun '20

04 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] Last cycle we introduced the Feature Liaison process [1]. I think this is time to reflect on it. Did it helped? Do we need to tweak it? Personally for me it did not help much but I think this is a fairly low cost process so I'm OK to keep it as is. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://review.opendev.org/#/c/685857/

5 6

[ops][ptg] Virtual Ops Meetup at the PTG
by Erik McCormick 04 Jun '20

04 Jun '20

Hello all, Your friendly neighborhood Ops Meetup Team is hosting a first ever (and very experimental) Virtual Ops Meetup Wednesday, June 3rd at 13:00 UTC on the foundation Jitsi server. You can find us here: https://meetpad.opendev.org/victoria-ptg-ops-meetup Meetpad will open an integrated Ehterpad to go along with the meeting, but if you'd prefer to have it separate, just replace "meetpad" with "etherpad" in the URL. We recommend using Chrome wherever possible. If you're on a mobile device, there is also a Jitsi Meet app for iOS and Android that work pretty well. The schedule has us going until 15:00 UTC, but we'll continue as long as people are around and want to keep it going. I look forward to seeing a few (or many!) of you in a few hours! Cheers, Erik

2 3

[cinder] retrospective survey
by Brian Rosmaita 04 Jun '20

04 Jun '20

We're scheduled to hold our Cinder team Ussuri cycle retrospective tomorrow (Thursday, 4 June, see the etherpad for details and projected time): https://etherpad.opendev.org/p/victoria-ptg-cinder I posted a brief survey to help get you thinking. It's optional, but like I said, it may stimulate the thought process. Or if you won't be able to attend the retrospective, you can fill out the survey and we'll still be able to take your feedback into account. Here it is: https://rosmaita.wufoo.com/forms/cinder-ussuri-retrospective/ The survey is "sort of" anonymous (it collects your IP number). cheers, brian

1 0

[all][InteropWG] Please verify if Desigane+Heat Project needs any updates for Interop testing of user APIs
by prakash RAMCHANDRAN 03 Jun '20

03 Jun '20

HI all, This is second call to OpenStack Project Teams Core member for identfying any user APIs needed to submit patches for Brnading program.https://www.openstack.org/brand/interop/ Can Designate, Heat PTLs confirm that add-ons listed are all you need for add-on Branding programs for Orchestartion and DNS respetcively. Hi Designate & Heat Core team members, Hi add-ons (Heat + Designate teams) We are trying to run our ambassadors or volunteers to your meetings, but if we miss please reply with "Confirmed OK" to submit these draft to be merged for "OpenStack Powered Storage" approval. Please bring this your PTG meetings if needed to assign a volunteer to complete the verification and submit patch (if updates are needed). Add-ons: DNS: designate - Release notes - https://docs.openstack.org/releasenotes/designate/ussuri.htmladd-on program codes - https://opendev.org/openstack/interop/src/branch/master/add-ons/dns.2020.06… Confirmed OK - ? patch? Orchestration: heat - Release notes - https://docs.openstack.org/api-ref/orchestration/v1/index.htmladd-on program codes - https://opendev.org/openstack/interop/src/branch/master/add-ons/orchestrati… Confirmed OK - ? Patch? ThanksInterop Chair: PrakashVice Chair: Mark

1 0

Fw: [all][InteropWG] Please verify if Core Project needs any updates for Interop testing of user APIs
by prakash RAMCHANDRAN 03 Jun '20

03 Jun '20

Hi OpenStack Core team members, Please bring this to your PTG meetings if needed. Aassign a volunteer to complete the verification and/or submit patch (if updates are needed). We are trying to run our ambassadors or volunteers to your meetings, but if we miss please reply with "Confirmed OK" to submit these draft to be merged for "OpenStack Powered Compute" approval. Drfat to patch if you need updates is shown below.https://opendev.org/openstack/interop/src/branch/master/2020.06.json Line 100-178 (has all core API capability listed for you to verify)https://opendev.org/openstack/interop/src/branch/master/2020.06.json… All API Ussuri Release notes available on - https://docs.openstack.org/api-ref/ Following Core Team members can Confirm OK? Yes if you do not have any updatex Keystone:ConfirmOK ? or Submit patch for 2020.06.json ? Glance:ConfirmOK ? or Submit patch for 2020.06.json ? Nova:ConfirmOK ? or Submit patch for 2020.06.json ? Neutron:ConfirmOK ? or Submit patch for 2020.06.json ? Cinder:ConfirmOK ? or Submit patch for 2020.06.json ? We are trying to run our ambassadors to your meetings, but if we miss please reply with "Confirmed OK - Yes" to submit these draft for approvals to merge asap. ThanksInterop WG chair: Prakash& Vice chair: Mark

1 0

[kolla] voting on Victoria priorities
by Mark Goddard 03 Jun '20

03 Jun '20

Hi, Thanks to everyone who attended the Kolla PTG sessions, we covered a lot of ground. The Etherpad is available at [1]. At the end of the sessions we agreed on some candidate features for prioritisation during the Victoria cycle. I have moved these across to a second Etherpad [2]. Now is the time to vote! Please add your name against a maximum of 12 items across the 3 deliverables (kolla, kolla-ansible, kayobe) in the priorities [2] Etherpad. [1] https://etherpad.opendev.org/p/kolla-victoria-ptg [2] https://etherpad.opendev.org/p/kolla-victoria-priorities Thanks, Mark

1 0

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

03 Jun '20

Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure --- ### Summary ### This vulnerability is present when using Cinder with a Dell EMC ScaleIO or VxFlex OS storage backend. Note: The Dell EMC "ScaleIO" driver was rebranded as "VxFlex OS" in the Train release. ### Affected Services / Software ### Cinder / Ocata, Pike, Queens, Rocky, Stein, Train, Ussuri This vulnerability applies only when using a Dell EMC ScaleIO/VxFlex OS Backend with Cinder. Other drivers are not impacted. ### Discussion ### When using Cinder with the Dell EMC ScaleIO or VxFlex OS backend storage driver, credentials for the entire backend are exposed in the ``connection_info`` element in all Block Storage v3 Attachments API calls containing that element. This enables an end user to create a volume, make an API call to show the attachment detail information, and retrieve a username and password that may be used to connect to another user's volume. Additionally, these credentials are valid for the ScaleIO or VxFlex OS Management API, should an attacker discover the Management API endpoint. This issue was reported by David Hill and Eric Harney of Red Hat. ### Recommended Actions ### Remediation of this issue consists of the following: 1. Patching the ScaleIO or VxFlex OS Cinder driver so that it no longer provides the password to Cinder when a Block Storage v3 Attachments API response is constructed. 2. Patching the ScaleIO connector in the os-brick library so that it retrieves the password from a configuration file readable only by root. (Note: the connector was not rebranded; both ScaleIO and VxFlex OS backends use the 'scaleio' os-brick connector.) 3. Patching the ScaleIO os-brick privileged file that allows the scaleio connector to escalate privileges for specific operations; this is necessary to allow the connector process to access the configuration file that is readable only by root. 4. Deploying a configuration file containing the password (and replication password, if applicable) to all compute nodes, cinder nodes, and anywhere you would perform a volume attachment in your deployment. To refresh database information, all volumes should be detached and reattached. Because this remediation consists of deploying credentials in a root-readable-only file, it is not suitable for the use case of attaching a volume to a bare metal host. Thus, the Dell EMC ScaleIO/VxFlex OS storage backend for Cinder is *not recommended* for use with bare metal hosts. Note: The Ocata, Pike, Queens, and Rocky branches of OpenStack are in the Extended Maintenance phase. Point releases are no longer made from these branches and security patches are produced only on a reasonable effort basis. Patches for Queens and Rocky are provided as a courtesy. Patches for Ocata and Pike are not available. #### Patches #### Both cinder and os-brick must be patched. Documentation is provided as part of the cinder patch concerning the new configuration file that must be deployed to all compute nodes, cinder nodes, and anywhere you would perform a volume attachment in your deployment. Queens * cinder: https://review.opendev.org/733110 * os-brick: https://review.opendev.org/733104 Rocky * cinder: https://review.opendev.org/733109 * os-brick: https://review.opendev.org/733103 Stein * cinder: https://review.opendev.org/733108 * os-brick: https://review.opendev.org/733102 Train * cinder: https://review.opendev.org/733107 * os-brick: https://review.opendev.org/733100 Ussuri * cinder: https://review.opendev.org/733106 * os-brick: https://review.opendev.org/733099 Alternatively, point releases for Stein, Train, and Ussuri will be made as soon as possible. These will be: Stein: cinder 14.0.5, requires os-brick 2.8.5 Train: cinder 15.1.1, requires os-brick 2.10.3 Ussuri: cinder 16.0.1, requires os-brick 3.0.2 ### Contacts / References ### Author: Brian Rosmaita, Red Hat This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0086 Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1823200 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg CVE: CVE-2020-10755

1 0

[all] OpenStack versions that can't practically be run with Python 3 ?
by Neil Jerram 03 Jun '20

03 Jun '20

Does anyone know the most recent OpenStack version that _can't_ easily be run with Python 3? I think the full answer to this may have to consider distro packaging, as well as the underlying code support. For example, I was just looking at switching an existing Queens setup, on Ubuntu Bionic, and it can't practically be done because all of the scripts - e.g. /usr/bin/nova-compute - have a hashbang line that says "python2". So IIUC Queens is a no for Python 3, at least in the Ubuntu packaging. Do you know if this is equally true for later versions than Queens? Or alternatively, if something systematic was done to address this problem in later releases? E.g. is there a global USE_PYTHON3 switch somewhere, or was the packaging for later releases changed to hardcode "python3" instead of "python2"? If so, when did that happen? Many thanks for any information around this! Best wishes, Neil

6 7

[keystone] Keystone PTG Schedule
by Nikolla, Kristi 03 Jun '20

03 Jun '20

Hi all, The Keystone team will be meeting Thursday and Friday 1300-1700 UTC. The schedule[0] can be found below and provides information on how to register and attend. In addition, I'm hoping to organize a team meetup Wednesday, Thursday or Friday on 1700UTC. Please fill in the doodle at [1]. More general PTG information can be found at [2]. [0]. https://etherpad.opendev.org/p/victoria-ptg-keystone [1]. https://doodle.com/poll/z7diwe6qyq4mbghe [2]. http://lists.openstack.org/pipermail/openstack-discuss/2020-May/015054.html

1 1

[cyborg][nova][neutron]Summaries of Smartnic support integration
by yumeng bao 03 Jun '20

03 Jun '20

Hi all, In cyborg pre-PTG meeting conducted last week[0],shaohe from Intel introduced SmartNIC support integrations,and we've reached some initial agreements: The workflow for a user to create a server with network acceleartor(accelerator is managed by Cyborg) is: 1. create a port with accelerator request specified into binding_profile field NOTE: Putting the accelerator request(device_profile) into binding_profile is one possible solution implemented in our POC. Another possible solution,adding a new attribute to port object for cyborg specific use instead of using binding_profile, is discussed in shanghai Summit[1]. This needs check with neutron team, which neutron team would suggest? 2.create a server with the port created Cyborg-nova-neutron integration workflow can be found on page 3 of the slide[2] presented in pre-PTG. And we also record the introduction! Please find the pre-PTG meeting vedio record in [3] and [4], they are the same, just for different region access. [0]http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014987.ht… [1]https://etherpad.opendev.org/p/Shanghai-Neutron-Cyborg-xproj [2]pre-PTG slides:https://docs.qq.com/slide/DVm5Jakx5ZlJXY3lw [3]pre-PTG vedio records in Youtube:https://www.youtube.com/watch?v=IN4haOK7sQg&feature=youtu.be [4]pre-PTG vedio records in Youku:http://v.youku.com/v_show/id_XNDY5MDA4NjM2NA==.html?x&sharefrom=iphon… Regards， Yumeng

5 7

[nova][neutron][cyborg][ptg] Nova changing from Jitsi to Zoom
by Balázs Gibizer 03 Jun '20

03 Jun '20

Hi, As multiple people reported problem with Jitsi from PRC [1][2] the Nova team is switching back to Zoom. We will use the Juno Zoom room [3] during this week. Cheers, gibi [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015207.html [2] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.… [3] https://www.openstack.org/ptg/rooms/juno

1 0

[all] Week Out PTG Details & Registration Reminder
by Kendall Nelson 03 Jun '20

03 Jun '20

Hello Everyone! We are so excited to see you next week at our first virtual PTG! Below are all the details you need to have a fun and successful event. First and foremost: PLEASE REGISTER; https://virtualptgjune2020.eventbrite.com/ If you don't register for the event, we have no way of sending you information about the event, specifically the passwords that we will have set on the zoom rooms. Registration is free. =Final Schedule= The final schedule for the event is available here[1] and in the PTGBot[2]. =Tooling & Passwords= For each virtual PTG meeting room, we will provide an official Zoom videoconference room, which will be reused by various groups across the day. Please make sure to leave the room at the end of your team meeting! We will be setting passwords on the rooms to prevent vandalism/harassment, and we will send those out 24 hours before the start of the event. OpenDev's Jitsi Meet instance is also available at https://meetpad.opendev.org as an alternative tooling option to create team-specific meetings. This is more experimental and may not work as well for larger groups, but has the extra benefit of including etherpad integration (the videoconference doubles as an etherpad document, avoiding jumping between windows). PTGBot can be used to publish the chosen meeting URL if you decide to not use the official Zoom one. The OpenDev Sysadmins can be reached in the #opendev IRC channel if any problems arise. We recommend you try out Zoom and Meetpad ahead of the PTG to solve audio/video issues. =IRC= The main form of synchronous communication between attendees during the PTG is on IRC. If you are not on IRC, learn how to get started here [3]. The main PTG IRC channel is #openstack-ptg on Freenode, and it's used to interact with the PTGbot. The OpenStack Foundation (OSF) staff will be present to help answer questions. =PTGbot= The PTGbot[2] is an open source tool that PTG room moderators use to surface what's currently happening at the event. Room moderators will send messages to the bot via IRC, and from that information the bot publishes a webpage with several sections of information: - The discussion topics currently discussed in the room ("now") - An indicative set of discussion topics coming up next ("next") - The schedule for the day with available extra slots you can book Learn more about the PTGbot via the documentation here [4]. =Help Desk= We are here to help! If you have any questions during the event week, we will have a dedicated Zoom room where an OSF staff member will be available to answer your event related questions. If a staff member is not there to help, you can always reach someone at ptg(a)openstack.org or on IRC in the #openstack-ptg channel. =Feedback= We have created an etherpad[5] to collect all of your feedback throughout the event. Please add your thoughts so we can continue improving our virtual events! =Virtual Event Best Practices= Check out our list of virtual event best practices[6] prior to the event to help make the most of your time at the PTG. =Code of Conduct= The PTG is for everyone. We have zero tolerance for harassment and other violations of the OSF Community Code of Conduct. Before the PTG begins, please review the Code of Conduct[7] and know how to report an issue. -The Kendalls (diablo_rojo & wendallkaters) [1] Schedule: https://www.openstack.org/ptg#tab_schedule [2] Live PTGBot: http://ptg.openstack.org/ptg.html [3] IRC Setup: https://docs.openstack.org/contributors/common/irc.html [4] PTGBot Documentation: https://github.com/openstack/ptgbot/blob/master/README.rst [5] Feedback Etherpad: https://etherpad.opendev.org/p/June2020-PTG-Feedback [6] PTG Best Practices: https://etherpad.opendev.org/p/virtual-ptg-best-practices [7] Code of Conduct: https://www.openstack.org/legal/community-code-of-conduct/

11 18

[cinder] virtual happy hour on Thursday 4 June
by Brian Rosmaita 03 Jun '20

03 Jun '20

The People have spoken and they have said that Thursday is the day we should hold the virtual happy hour. It's therefore scheduled for 15:30 UTC in the "Diablo room" (which is what I'm now calling my BlueJeans room): https://bluejeans.com/3228528973 This is an opportunity for us to have some informal virtual face-to-face time. Since the virtual drinks are unlimited, everyone is welcome, even if you don't contribute to cinder in the course of your normal work activities. The event will *not* be recorded :) See you there! brian

1 0

[tripleo] PTG day 3
by Emilien Macchi 03 Jun '20

03 Jun '20

Hi Folks For day 3, we'll stay on Zoom, it seems like the best option for our group so far. The agenda looks like it: 13:00 UTC Topic: Speeding up deployments, updates and upgrades Presenter: Jesse Pretorius (odyssey4me), Sofer Athlan (chem) 13:30 UTC Topic: Ceph requirements Presenter: fmount, fultonj, gfidente 14:00 UTC Topic: Running validations from within a container Presenter: cjeanneret (Tengu) 14:30 UTC Topic: Auto --limit scale-up of Compute nodes Presenter: Luke Short (ekultails) 15:00 UTC Topic: TripleO usability enhancements Presenter: Wes Hayutin 15:30 UTC Topic: Improvements in TLS Everywhere/ CI Presenter: rlandy, alee 16:00 UTC Topic: Container Security in TripleO Presenter: Grzegorz Grasza (xek), alee 16:30 UTC free slot Since we have a free slot, feel free to propose any new topic otherwise we'll finish earlier (could also be appreciated, specially for folks in EMEA/APAC). Thanks and see you tomorrow! -- Emilien Macchi

1 0

[diversity] Hour of Healing
by Amy Marrich 02 Jun '20

02 Jun '20

The OSF Diversity and Inclusion Working Group recognizes that this is a trying time for our communities and colleagues. We would like to invite you to 'An Hour of Healing' on Thursday (June 4th at 17:30 - 18:30 UTC) where you can talk to others in a safe place. We invite you to use this time to express your feelings, or to just be able to talk to others without being judged. This session will adhere to the OSF Code of Conduct <https://www.openstack.org/legal/community-code-of-conduct/>and zero tolerance for harassment policy, which means we will not be judging or condemning others (individuals or groups) inside OR outside of our immediate community. We will come together to heal, in mutually respectful dialogue, keeping in mind that while there are many different individual viewpoints, we all share pain collectively and can heal together. We will be using https://meetpad.opendev.org/PTGDiversityAndInclusion for this gathering. The OSF Diversity and Inclusion WG

1 0