- openstack-discuss - lists.openstack.org

removing use of pkg_resources to improve command line app performance
by Doug Hellmann 06 Jul '20

06 Jul '20

We have had a long-standing issue with the performance of the openstack command line tool. At least part of the startup cost is the time taken in scanning for all of the plugins that are installed, which is a side-effect of importing pkg_resources. To fix that, we need to eliminate all use of pkg_resources in code that would be used by a command line application (long-running services are candidates, too, but the benefit is bigger in short-lived command line apps). Python 3.8 added a new library importlib.metadata, which also has an entry points API. It is more efficient, and produces data in a format that can be cached to make it even faster. I have started adding support for that caching to stevedore [0], which is the Oslo library for managing application plugins. For version of python earlier than 3.8, the same library is available on PyPI as “importlib_metadata”. A big part of the implementation work will actually be removing the use of pkg_resources in places other than stevedore. We have a couple of different use patterns to consider and replace in different ways. First, anything using iter_entry_points() should use a stevedore extension manager instead. There are a few of them to choose from, based on how the plugins will be used. The stevedore docs [1] include a tutorial and documentation for all of the classes and their uses. Most calls to iter_entry_points() can be replaced with a stevedore.ExtensionManager directly, but the other managers are meant to implement common access patterns like selecting a subset (or just one) of the available plugins by name. Second, we have a few places where pkg_resources.get_distribution(name).version is used to discover a package’s installed version. Those can be changed to use importlib.metadata.version() instead, as in [2]. This is *much* faster because importlib goes directly to the metadata file for the named package instead of looking through all of the installed packages. Finally, any code using any properties of the EntryPoint returned by stevedore other than “name” and “load()” may need to be updated. The new EntryPoint class in importlib.metadata is not 100% compatible with the one from pkg_resources. The same data is there, but sometimes it is named differently. If we need a compatibility layer we could put that in stevedore, but it is unusual to need access to any of the internals of EntryPoint and it’s typically better to use the manager abstractions in stevedore instead of manipulating EntryPoint instances directly. I have started making some of the changes [3], but I’m doing this in my quarantine-induced spare time so it’s likely to take a while. If you want to pitch in, I would appreciate it. I am using the topic “osc-performance”, since the work is related to making python-openstackclient faster. Feel free to tag me for reviews on your patches. Doug [0] https://review.opendev.org/#/c/739306/ [1] https://docs.openstack.org/stevedore/latest/ [2] https://review.opendev.org/#/c/739379/2 [3] https://review.opendev.org/#/q/topic:osc-performance

4 8

[tc] weekly update
by Mohammed Naser 06 Jul '20

06 Jul '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. We've also included a few references to some important mailing list threads that you should check out. # Patches ## Open Review - Cleanup the remaining osf repos and their data https://review.opendev.org/739291 - Update goal selection docs to clarify the goal count https://review.opendev.org/739150 - Add legacy repository validation https://review.opendev.org/737559 - Add "tc:approved-release" tag to manila https://review.opendev.org/738105 - Create starter-kit:kubernetes-in-virt tag https://review.opendev.org/736369 - [draft] Add assert:supports-standalone https://review.opendev.org/722399 ## Project Updates - Add deprecated cycle for deprecated deliverables https://review.opendev.org/737590 - No longer track refstack repos in governance https://review.opendev.org/737962 - Add Neutron Arista plugin charm to OpenStack charms https://review.opendev.org/737734 ## General Changes - Add links to chosen release names https://review.opendev.org/738867 - Add storyboard link to migrate-to-focal goal https://review.opendev.org/738129 - TC Guide Follow Ups https://review.opendev.org/737650 # Email Threads - New Office Hours: http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015761.html - OSU Intern Work: http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015760.html - Summit Programming Committee Nominations Open: http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015756.html - Summit CFP Open: http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015730.html # Other Reminders - OpenStack's 10th anniversary community meeting should be happening July 16th: more info coming soon! - If you're an operator, make sure you fill out our user survey: https://www.openstack.org/user-survey/survey-2020/ Thanks for reading! Mohammed & Kendall -- Mohammed Naser VEXXHOST, Inc.

1 0

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

06 Jul '20

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

4 10

[python-openstackclient] microversion support
by jayaditya gupta 06 Jul '20

06 Jul '20

Hi , we discussed the microversion support in PTG meeting .I would like to get started with it. How can I help with this? Currently OpenStack CLI is defaulting to nova api V2, we want to change it so it takes latest version. for issue reference see this : https://storyboard.openstack.org/#!/story/2007727 Best Regards Jayaditya Gupta

1 0

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

06 Jul '20

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

4 6

[cyborg] Incomplete v2 API in Train
by Ildiko Vancsa 05 Jul '20

05 Jul '20

Hi Cyborg Team, I’m working with the CNTT community[1], they are working on building reference architecture for telecom workloads. Cyborg is important for their work to be able to utilize hardware acceleration resources. We are planning to use the Train version of OpenStack projects including Cyborg and it would be great to be able to switch to the v2 API as v1 is deprecated now. If my understanding is correct the v2 API implementation in Train is partial, but the documentation[2] doesn’t give accurate view about what is included. The CNTT team would like to be able to integrate and access the whole v2 API if that is possible. It would be great to discuss the options that we could use on the way forward. Would it be possible to bring this up and discuss on an upcoming Cyborg team meeting? Thanks, Ildikó [1] https://www.lfnetworking.org/about/cntt/ [2] https://docs.openstack.org/cyborg/train/api/api.html#v2-0

2 2

Re: [cyborg] Incomplete v2 API in Train
by yumeng bao 05 Jul '20

05 Jul '20

Hi Ildikó, > Hi Cyborg Team, > I’m working with the CNTT community[1], they are working on building reference architecture for telecom workloads. Cyborg is important for their work to be able to utilize hardware acceleration > resources. > We are planning to use the Train version of OpenStack projects including Cyborg and it would be great to be able to switch to the v2 API as v1 is deprecated now. If my understanding is correct > the v2 API implementation in Train is partial, but the documentation[2] doesn’t give accurate view about what is included. Yes,your understanding is correct,the v2 API implementation in Train is partial. I would update the documentation soon. I would recommend you to use the stable/ussuri version(instead of train release) of cyborg for two reasons: 1) API V2 in ussuri is complete while that of train is incomplete 2)the nova-cyborg integration[3] was not landed until Ussuri[4],so the integration in Train is also partial[5]. So if CNTT wants the complete accelerator management function,it would be better to use cyborg ussuri. > The CNTT team would like to be able to integrate and access the whole v2 API if that is possible. It would be great to discuss the options that we could use on the way forward. Would it be > possible to bring this up and discuss on an upcoming Cyborg team meeting? Yes, sure. We can bring this up on the next weekly meeting on this Thursday 03:00 UTC at #openstack-cyborg, I have added this to meeting agenda[6]. > Thanks, > Ildikó > [1] https://www.lfnetworking.org/about/cntt/ > [2] https://docs.openstack.org/cyborg/train/api/api.html#v2-0 [3]https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented… [4]https://releases.openstack.org/ussuri/highlights.html#cyborg [5]https://releases.openstack.org/train/highlights.html#cyborg [6]https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting#Agenda Regards， Yumeng

2 1

[Neutron] Bug Deputy Report (June 29 - July 05)
by Hongbin Lu 05 Jul '20

05 Jul '20

Hi all, Below is the bug deputy report for last week. Critical: * https://bugs.launchpad.net/neutron/+bug/1885900 test_trunk_subport_lifecycle is failing in ovn based jobs * https://bugs.launchpad.net/neutron/+bug/1885899 test_qos_basic_and_update test is failing High: * https://bugs.launchpad.net/neutron/+bug/1886116 slaac no longer works on IPv6 tenant subnets * https://bugs.launchpad.net/neutron/+bug/1885898 test connectivity through 2 routers fails in neutron-ovn-tempest-full-multinode-ovs-master job * https://bugs.launchpad.net/neutron/+bug/1885897 Tempest test_create_router_set_gateway_with_fixed_ip test is failing often in dvr scenario job * https://bugs.launchpad.net/neutron/+bug/1885695 [OVS] "vsctl" implementation does not allow empty transactions Medium: * https://bugs.launchpad.net/neutron/+bug/1885891 DB exception when updating a "ml2_port_bindings" object * https://bugs.launchpad.net/neutron/+bug/1885758 RPCMessage timeouts when ovs agent is reporting status about many ports Low: * https://bugs.launchpad.net/neutron/+bug/1886216 keepalived-state-change does not format correctly the logs * https://bugs.launchpad.net/neutron/+bug/1885547 [fullstack] OVS interface events isolation error with more than one OVS agent RFE: * https://bugs.launchpad.net/neutron/+bug/1885921 [RFE][floatingip port_forwarding] Add port ranges

1 0

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

05 Jul '20

Hello Everyone, Please find the week R-15 updates on 'Ubuntu Focal migration' community goal. Tracking: https://storyboard.openstack.org/#!/story/2007865 Progress: ======= * I have prepared the patched to migrate the unit/functional/doc/cover tox jobs to focal which are WIP till we finish the project side testing. This and its base patches - https://review.opendev.org/#/c/738328/ * devstack and tempest base patches are changed with Depends-On on 738328 tox job patch. This way we can test the complete gate (integration + unit +functional + doc + cover +pep8 + lower-constraint) jobs with a single testing patch by doing Depends-On: https://review.opendev.org/#/c/734700/ (or devstack base patch or tox one if you do not have tempest jobs to test) * I have started a few more project testing and found bugs on the incompatible deps versions for Focal. Please refer to the 'Bugs Report' section for details. Bugs Report: ========== Summary: Total 4 (1 fixed, 3 in-progress). 1. Bug#1882521. (IN-PROGRESS) There is open bug for nova/cinder where three tempest tests are failing for volume detach operation. There is no clear root cause found yet -https://bugs.launchpad.net/cinder/+bug/1882521 We have skipped the tests in tempest base patch to proceed with the other projects testing but this is blocking things for the migration. 2. We encountered the nodeset name conflict with x/tobiko. (FIXED) nodeset conflict is resolved now and devstack provides all focal nodes now. 3. Bug#1886296. (IN-PROGRESS) pyflakes till 2.1.0 is not compatible with python 3.8 which is the default python version on ubuntu focal[1]. With pep8 job running on focal faces the issue and fail. We need to bump the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8. As of now, many projects are using old hacking version so I am explicitly adding pyflakes>=2.1.1 on the project side[2] but for the long term easy maintenance, I am doing it in 'hacking' requirements.txt[3] nd will release a new hacking version. After that project can move to new hacking and do not need to maintain pyflakes version compatibility. 4. Bug#1886298. (IN-PROGRESS) 'Markupsafe' 1.0 is not compatible with the latest version of setuptools[4], We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it work. There are a few more issues[5] with lower-constraint jobs which I am debugging. What work to be done on the project side: ================================ This goal is more of testing the jobs on focal and fixing bugs if any otherwise migrate jobs by switching the nodeset to focal node sets defined in devstack. 1. Start a patch in your repo by making depends-on on either of below: devstack base patch if you are using only devstack base jobs not tempest: https://review.opendev.org/#/c/731207/ OR tempest base patch if you are using the tempest base job (like devstack-tempest): https://review.opendev.org/#/c/734700/ Example: https://review.opendev.org/#/c/738126/ 2. If none of your project jobs override the nodeset then above patch will be testing patch(do not merge) otherwise change the nodeset to focal. Example: https://review.opendev.org/#/c/737370/ 3. If the jobs are defined in branchless repo and override the nodeset then you need to override the branches variant to adjust the nodeset so that those jobs run on Focal on victoria onwards only. If no nodeset is overridden then devstack being branched and stable base job using bionic/xenial will take care of this. Once we finish the testing on projects side and no failure then we will merge the devstack and tempest base patches. Important things to note: =================== * Do not forgot to add the story and task link to your patch so that we can track it smoothly. * Use gerrit topic 'migrate-to-focal' * Do not backport any of the patches. References: ========= Goal doc: https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-j… Storyboard tracking: https://storyboard.openstack.org/#!/story/2007865 [1] https://github.com/PyCQA/pyflakes/issues/367 [2] https://review.opendev.org/#/c/739315/ [3] https://review.opendev.org/#/c/739334/ [4] https://github.com/pallets/markupsafe/issues/116 [5] https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032 -gmann

1 0

Re: [loci][helm][k8s] When do images on docker.io get updated
by Andrii Ostapenko 03 Jul '20

03 Jul '20

Hello Corne, OSH uses images built using gates in openstack/openstack-helm-images repository, not in loci itself. You may want to add a definition for watcher image similar to [0] and then refer to it in the corresponding release job, e.g. for Stein [1]. After your commit to openstack-helm-images is merged, new images will be published to docker.io/openstackhelm/watcher repository and can be used in the way you referenced them in your OSH commit [2]. [0] https://opendev.org/openstack/openstack-helm-images/src/branch/master/zuul.… [1] https://opendev.org/openstack/openstack-helm-images/src/branch/master/zuul.… [2] https://review.opendev.org/#/c/720140/

3 2

[TC] Monthly Meeting Summary
by Mohammed Naser 03 Jul '20

03 Jul '20

Hi everyone, Here’s a summary of what happened in our TC monthly meeting last Thursday, July 2nd. # ATTENDEES (LINES SAID) - mnaser (106) - gmann (43) - evrardjp (32) - diablo_rojo (32) - njohnston (11) - jungleboyj (8) - openstack (7) - ricolin (6) - fungi (4) - ttx (2) - clarkb (2) - belmoreira (1) - knikolla (1) - AJaeger (1) # MEETING SUMMARY - Rollcall (mnaser, 14:00:40) - Follow up on past action items (mnaser, 14:04:59) - OpenStack Foundation OSU Intern Project (diablo_rojo) (mnaser, 14:26:55) - W cycle goal selection start (mnaser, 14:36:02) - https://governance.openstack.org/tc/goals/#goal-selection-schedule (gmann, 14:37:37) - Completion of retirement cleanup (gmann) (mnaser, 14:48:36) - https://etherpad.opendev.org/p/tc-retirement-cleanup is a scratch pad; nothing pushed out towards the community (mnaser, 14:48:59) # ACTION ITEMS - evrardjp & njohnston to start writing resolution about how deconstructed PTL role - mnaser to find the owner to start using facing API pop-up team over ML - gmann update goal selection docs to clarify the goal count - gmann start discussion around reviewing currenet tags - mnaser propose change to implement weekly meetings - diablo_rojo start discussion on ML around potential items for OSF funded intern - njohnston and mugsie to work on getting goals groomed/proposed for W cycle - TC and community to help finish properly and cleanly retiring projects To read the full logs of the meeting, please refer to http://eavesdrop.openstack.org/meetings/tc/2020/tc.2020-07-02-14.00.log.html. -- Mohammed Naser VEXXHOST, Inc.

1 0

[TC] [all] OSU Intern Work
by Kendall Nelson 03 Jul '20

03 Jul '20

Hello! As you may or may not know, the OSF funded a student at Oregon State University last year to work on OpenStack part time. He did a lot of amazing work on Glance but sadly we are coming to the end of his internship as he will be graduating soon. I'm happy to report that we have the budget to fund another student part time to work on OpenStack again and I wanted to collect suggestions of projects/areas that a student could be helpful in. It is important to note, that they will only be working part time and, while I will be helping to mentor them, I will likely need a co-mentor in the area/topic to help me get them going, get their patches reviewed, answer questions as they go etc. Originally, I had thought about assigning them to Glance (like this past year) or Designate (like we had considered last year), but now I am thinking the User Facing API work (OpenStackSDK/OSC/et al) might be a better fit? If you are interested in helping mentor a student in any of those areas or have a better idea I am all ears :) I look forward to your suggestions. -Kendall (diablo_rojo)

2 3

[Telemetry] Error when sending to prometheus pushgateway
by Samuel Mutel 03 Jul '20

03 Jul '20

Hello, I have two questions about ceilometer (openstack version rocky). - First of all, it seems that ceilometer is sending metrics every hour and I don't understand why. - Next, I am not able to setup ceilometer to send metrics to prometheus pushgateway. Here is my configuration: > sources: > - name: meter_file > interval: 30 > meters: > - "*" > sinks: > - prometheus > > sinks: > - name: prometheus > publishers: > - prometheus://10.60.4.11:9091/metrics/job/ceilometer > Here is the error I received: > vcpus{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 2 > # TYPE memory gauge > memory{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 2048 > # TYPE disk.ephemeral.size gauge > disk.ephemeral.size{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 0 > # TYPE disk.root.size gauge > disk.root.size{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 0 > : HTTPError: 400 Client Error: Bad Request for url: > http://10.60.4.11:9091/metrics/job/ceilometer > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http Traceback > (most recent call last): > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http File > "/usr/lib/python2.7/dist-packages/ceilometer/publisher/http.py", line 178, > in _do_post > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http > res.raise_for_status() > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http File > "/usr/lib/python2.7/dist-packages/requests/models.py", line 935, in > raise_for_status > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http raise > HTTPError(http_error_msg, response=self) > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http HTTPError: > 400 Client Error: Bad Request for url: > http://10.60.4.11:9091/metrics/job/ceilometer > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http > Thanks for your help on this topic.

2 1

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

03 Jul '20

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

3 3

[oslo] PTO on Monday
by Ben Nemec 03 Jul '20

03 Jul '20

Hi Oslo, I'm making this a four day weekend (Friday is a US holiday), so I won't be around for the meeting on Monday. If someone else wants to run it then feel free to hold it without me. Otherwise we'll return to the regular schedule the following week. -Ben

2 1

[neutron] Drivers meeting agenda - 03.07.2020
by Slawek Kaplonski 03 Jul '20

03 Jul '20

Hi, For tomorrows drivers meeting we have 1 RFE to discuss: https://bugs.launchpad.net/neutron/+bug/1885921 - [RFE][floatingip port_forwarding] Add port ranges See You all on the meeting tomorrow. — Slawek Kaplonski Senior software engineer Red Hat

2 2

[Diversity] Diversity & Inclusion WG Meeting 7/6
by Amy Marrich 02 Jul '20

02 Jul '20

The Diversity & Inclusion WG invites members of all OSF projects to our next meeting Monday, July 6th, at 17:00 UTC in the #openstack-diversity channel. The agenda can be found at https://etherpad.openstack.org/p/diversity -wg-agenda. We will be discussing changing our Wiki page to reflect the broader OSF projects and communities so that the page reflects our mission. Please feel free to add any other topics you wish to discuss at the meeting. Thanks, Amy (spotz)

1 0

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

02 Jul '20

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

1 1

[glance] Weekly review priorities
by Abhishek Kekane 02 Jul '20

02 Jul '20

Hi Team, We are 3 weeks away from the Victoria milestone 2 release and already our review stack is increasing day by day. We need to get below important specs reviewed and merged in the next couple of weeks. Also we need some reviews on backports as well as important fixes. I have sorted down some patches which need reviews for this week. Specs: 1. sparse image upload - https://review.opendev.org/733157 2. Unified limits - https://review.opendev.org/729187 3. Image encryption - https://review.opendev.org/609667 4. Cinder store multiple stores support - https://review.opendev.org/695152 5. Duplicated image downloads - https://review.opendev.org/734683 6. Add copy-unowned-image spec https://review.opendev.org/739062 Backports: 1. Add lock per share for cinder nfs mount/umount - https://review.opendev.org/#/c/726650/ (stable/train) 2. Add lock per share for cinder nfs mount/umount - https://review.opendev.org/#/c/726914/ (stable/ussuri) 3. zuul: switch to the "plain" grenade job here too - https://review.opendev.org/739056 4. Use grenade-multinode instead of the custom legacy job - https://review.opendev.org/738693 Bug fixes on master: 1. Add image_set_property_atomic() helper - https://review.opendev.org/737868 2. Fix race condition in copy image operation - https://review.opendev.org/737596 3. Don't include plugins on 'copy-image' import - https://review.opendev.org/738675 4. Fix: Interrupted copy-image leaking data on subsequent operation - https://review.opendev.org/737867 Cleanup patches: 1. Removal of 'enable_v2_api' - https://review.opendev.org/#/c/738672/ (review dependency chain as well) Happy reviewing!! Abhishek

1 0

[nova][stable] The openstack/nova stable/ocata branch is currently unmaintained
by Lee Yarwood 02 Jul '20

02 Jul '20

Hello all, A quick note to highlight that the stable/ocata branch of openstack/nova [1] is formally in the ``Unmaintained`` [2] phase of maintenance will be moved on to the final ``EOL`` phase after a total of 6 months of inactivity. I'm going to suggest that we ignore the following change as this only attempted to remove a job from the experimental queue and doesn't constitute actual maintenance of the branch IMHO. Remove exp legacy-tempest-dsvm-full-devstack-plugin-nfs https://review.opendev.org/#/c/714958/ As a result I consider the branch to have been inactive for 3 of the required 6 months before it can be marked as ``EOL`` [3]. Volunteers are welcome to step forward and attempt to move the branch back to the ``Extended Maintenance`` phase by proposing changes and fixing CI in the next 3 months, otherwise the branch will be marked as ``EOL``. Hopefully this isn't taking anyone by surprise but please let me know if this is going to be an issue! Regards, [1] https://review.opendev.org/#/q/project:openstack/nova+branch:stable/ocata [2] https://docs.openstack.org/project-team-guide/stable-branches.html#unmainta… [3] https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-l… -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

2 1

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

02 Jul '20

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

8 12

[tripleo][update][blueprint] Update refactor: more feedback, more control, more speed.
by Sofer Athlan-Guyot 02 Jul '20

02 Jul '20

Hi, hope you liked the title, I find it catchy. Update is mainly an afterthought that needs to work. So we mainly fix "stuff" there. No major change happened there since a long time. Following the PTG, I'm proposing a new blueprint and a bug: 1. Refactor tripleo update to offer the user more feedback and control[1]. 2. Registering node and repos can happen after some module check for packages[2]. I'm pretty new to this so I would need feedback about the form and content. For instance, point 2. could be a blueprint instead of a bug, tell me what you think. 1. refactor update step to load step playbook instead of looping over the steps: - this will speed up update (no more skipped tasks) - this will offer point of recovery when the update fails (by doing something like in named debug[3] for deployment) 2. refactor/fix? host-prep-tasks to include two steps: - step0 to add pre-update in-flight validation to the update process and rhosp registration; - step1 to all other tasks; - make sure it run in parallel on all nodes Point 1. would be a catch up with deployment. It offers speed improvement as we wouldn't skip tasks anymore. We could notify the user of what we are doing: "I'm removing the node from the cluster" instead of "step1". It would offer the user the hook to be able to restart a failed update from any step. Overall a big win, I think. Point 2. is newer, I filled it as a bug because I bumped into it as an issue when trying to add validation for subscription. It opens some possibilities for the update: - in-flight validation at the beginning of the update process that would be skipped during deployment using tag - using tags we could also run specific day 2 action outside of the update window: openstack overcloud update run --tags 'pre-update-validation' (with pre-update-validation in host-prep-tasks step0) openstack overcloud update run --tags 'rhsm-subscription' Well, it looked promising to me. Now, tell me what you think, but please, be nice, I'm old and susceptible. I have more coming, sorted by order of though I put into it, starting with the ones I though about more: - Check if we need a reboot of the server and notify the user. - Gain some more speed and clarity by having a running-on-all-host-in-parallel-host-update-prep-tasks new step. For instance all HA image tagging magic could go in there. - Investigate converge and check if we still could not further optimize it for update. I would like to gain more experience with the process before I filled those new blueprints. I'm going to draft a spec for the proposed blueprint and then I'll push some WIP code. Thanks, [1] https://blueprints.launchpad.net/tripleo/+spec/tripleo-update-smart-steps [2] https://bugs.launchpad.net/tripleo/+bug/1886028 [1] https://review.opendev.org/#/c/636731/ -- Sofer Athlan-Guyot chem on #irc DFG:Upgrades

1 0

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

01 Jul '20

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

1 2

[cinder] spec freeze now in effect
by Brian Rosmaita 01 Jul '20

01 Jul '20

The Cinder spec freeze is now in effect. Here is the rundown on how the specs that have not yet been accepted for Victoria stand: The following specs have a spec freeze exception. Specs must be merged by 1600 UTC on 10 July. (Ideally, you'll have your revisions completed before next week's Cinder meeting on 8 July so we can discuss any issues at the meeting and give you time in case you need to make a final revision.) Remove quota usage cache https://review.opendev.org/#/c/730701/ - need to address some comments on the spec Support modern compression algorithms in cinder backup https://review.opendev.org/#/c/726307/ - needs a requirements change analysis; see comments on the review Reset state robustification https://review.opendev.org/#/c/682456/ - just needs to make moving the "force" option to cinder-manage explicit Default volume type overrides https://review.opendev.org/#/c/733555/ - need some tiem to work out the REST API change more carefully The following spec has been rejected for Victoria, but the team is OK with this being clarified (suggestions are in the comments on the review) and proposed for Wallaby: Support revert any snapshot to the volume https://review.opendev.org/#/c/736111/ The following spec has been rejected for Victoria, but because it's really a bug: volume list query optimization https://review.opendev.org/#/c/726070/ - it's been turned into https://bugs.launchpad.net/cinder/+bug/1885961 and the proposer can submit patches that address the bug. cheers, brian

1 0

[all][summit][cfp] 2020 Open Infrastructure Summit Call for Presentations Open!
by Ashlee Ferguson 01 Jul '20

01 Jul '20

We’re excited to announce that the Call for Presentations [1] for the 2020 Open Infrastructure Summit is now open until August 4! During the Summit, you’ll be able to join the people building and operating open infrastructure. Submit sessions featuring projects including Airship, Ansible, Ceph, Kata Containers, Kubernetes, ONAP, OpenStack, OPNFV, StarlingX and Zuul! 2020 Tracks • 5G, NFV & Edge • AI, Machine Learning & HPC • CI/CD • Container Infrastructure • Getting Started • Hands-on Workshops • Open Development • Private & Hybrid Cloud • Public Cloud • Security Types of sessions Presentations; demos encouraged Panel Discussions Lightning Talks If your talk is not selected for the official track schedule, we may reach out to have you present it as a Lightning Talk during the Summit in a shorter 10-15 minute format SUBMIT YOUR PRESENTATION [1] - Deadline August 4, 2020 Summit CFP is only for presentation, panel, and workshop submissions. The content submission process for the Forum and Project Teams Gathering (PTG) will be managed separately in the upcoming months. Programming Committee nominations are also now open. The Programming Committee helps select sessions from the CFP for the Summit schedule. Nominate yourself or or someone else for the Programming Committee [2] before July 10, 2020 and help us program the Summit! Registration and sponsorship coming soon! For sponsorship inquiries, please email kendall(a)openstack.org <mailto:kendall@openstack.org>. Please email speakersupport(a)openstack.org with any CFP questions or feedback. Thanks, Ashlee [1] cfp.openstack.org [2] https://openstackfoundation.formstack.com/forms/programmingcommitteenom_sum… <https://openstackfoundation.formstack.com/forms/programmingcommitteenom_sum…> Ashlee Ferguson Community & Events Coordinator OpenStack Foundation

1 0

[CEILOMETER] Error when sending to prometheus pushgateway
by Samuel Mutel 01 Jul '20

01 Jul '20

Hello, I have two questions about ceilometer (openstack version rocky). - First of all, it seems that ceilometer is sending metrics every hour and I don't understand why. - Next, I am not able to setup ceilometer to send metrics to prometheus pushgateway. Here is my configuration: > sources: > - name: meter_file > interval: 30 > meters: > - "*" > sinks: > - prometheus > > sinks: > - name: prometheus > publishers: > - prometheus://10.60.4.11:9091/metrics/job/ceilometer > Here is the error I received: > vcpus{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 2 > # TYPE memory gauge > memory{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 2048 > # TYPE disk.ephemeral.size gauge > disk.ephemeral.size{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 0 > # TYPE disk.root.size gauge > disk.root.size{resource_id="7fab268b-ca7c-4692-a103-af4a69f817e4"} 0 > : HTTPError: 400 Client Error: Bad Request for url: > http://10.60.4.11:9091/metrics/job/ceilometer > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http Traceback > (most recent call last): > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http File > "/usr/lib/python2.7/dist-packages/ceilometer/publisher/http.py", line 178, > in _do_post > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http > res.raise_for_status() > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http File > "/usr/lib/python2.7/dist-packages/requests/models.py", line 935, in > raise_for_status > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http raise > HTTPError(http_error_msg, response=self) > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http HTTPError: > 400 Client Error: Bad Request for url: > http://10.60.4.11:9091/metrics/job/ceilometer > 2020-07-01 17:00:12.272 11375 ERROR ceilometer.publisher.http > Thanks for you help on this topic.

1 0

[scientific-sig] No IRC meeting today
by Stig Telfer 01 Jul '20

01 Jul '20

Hi All - Unfortunately I am not available to help with today’s Scientific SIG IRC meeting. However, if you haven’t done so already I recommend signing up for the OpenDev virtual event - https://www.openstack.org/events/opendev-2020/ - today it’s bare metal and edge use cases. The last two days have been very useful sessions. Cheers, Stig

1 0

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

01 Jul '20

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

6 6

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

30 Jun '20

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

1 0

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

30 Jun '20

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

1 0

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

30 Jun '20

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

2 1

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

30 Jun '20

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

2 2

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

30 Jun '20

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

3 6

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

30 Jun '20

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

1 0

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

30 Jun '20

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

1 0

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

30 Jun '20

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

1 0

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

29 Jun '20

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

2 2

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

29 Jun '20

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

1 0

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

29 Jun '20

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

1 0

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

29 Jun '20

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

4 8

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

29 Jun '20

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

1 0

Monasca duplicate metrjcs
by junaid soomro 29 Jun '20

29 Jun '20

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

2 1

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

28 Jun '20

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

1 0

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

28 Jun '20

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

3 11

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

28 Jun '20

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

1 0

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

26 Jun '20

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

1 0

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

26 Jun '20

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

1 0

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

26 Jun '20

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

1 0

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

26 Jun '20

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

2 1

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

26 Jun '20

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

5 9