- openstack-discuss - lists.openstack.org

[Cinder]
by Marek Lyčka 09 Jul '20

09 Jul '20

Hi all, I'm currently looking into extending Nova API to allow on-demand VM quiescing with the ultimate goal being improved Cinder snapshot creation. The spec is undergoing review at the moment and I was wondering if someone from Cinder would be kind enough to look it over and give their thoughts on it: https://review.opendev.org/#/c/702810/ Thanks in advance. -- Marek Lyčka Linux Developer Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic marek.lycka(a)ultimum.io <stanislav.ulrych(a)ultimum.io> *https://ultimum.io <https://ultimum.io/>*

2 1

July OSF Community Meeting - 10 Years of OpenStack
by Sunny Cai 08 Jul '20

08 Jul '20

Hello everyone, You might have heard that OpenStack is turning 10 this year! On Thursday, July 16 at 8am PT (1500 UTC), we will be holding the 10 years of OpenStack virtual celebration in the July OSF community meeting. I have attached the calendar invite for the July OSF community meeting below. Grab your favorite OpenStack swag and bring your favorite drinks of choice to the meeting on July 16. Let’s do a virtual toast to the 10 incredible years! Please see the etherpad for more meeting information: https://etherpad.opendev.org/p/tTP9ilsAaJ2E8vMnm6uV <https://etherpad.opendev.org/p/tTP9ilsAaJ2E8vMnm6uV> If you have any questions, please let me know. P.S. To add more fun, feel free to try out the virtual background feature in Zoom. The 10 years of OpenStack virtual background is attached below. Thanks, Sunny Cai OpenStack Foundation sunny(a)openstack.org <mailto:sunny@openstack.org>

1 0

[neutron][lbaas][octavia] How to implement health check using 100.64.0.0/10 network segments in loadbalancer?
by Zhengyu Pan 08 Jul '20

08 Jul '20

There are some private cloud or public cloud introduction: They use 100.64.0.0/14 network segments to check vm's health status in load balancer. In Region supporting VPC, load balancing private network IP and health check IP will be switched to 100 network segment. I can't understand how to implement it. How to do it? --

2 1

[tripleo] updating the language we use in our code base
by Wesley Hayutin 08 Jul '20

08 Jul '20

Greetings, At this moment in time we have an opportunity to be a more open and inclusive project by eliminating outdated naming conventions from our code base [1]. We should take the opportunity and do our best to replace outdated terms with their more inclusive alternatives. Chris Wright wrote a nice blog post on the subject [2], please take a second to review Bogdan's spec and Chris's blog post. Also a thank you to Emilien, Alex and Bogdan for already getting started. In other news Arx Cruz will be starting a similar thread for the tempest project. Thanks Arx! [1] https://review.opendev.org/#/c/740013/1/specs/victoria/renaming_rules.rst [2] https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicatin… Patches to be aware of: https://review.opendev.org/#/c/738858/ https://review.opendev.org/#/c/738894/ <https://review.opendev.org/#/c/738894/1> https://review.opendev.org/#/c/740013 Thanks for your time!

1 0

[Neutron] GRE network MTU
by Budai Laszlo 08 Jul '20

08 Jul '20

Dear all, what is the maximum MTU value for a GRE network? How is that related to the physical interfaces' MTU? Thank you, Laszlo

1 0

[largescale-sig] Next meeting: July 8, 8utc
by Thierry Carrez 08 Jul '20

08 Jul '20

Hi everyone, Hot on the heels of the OpenDev event on Large scale deployments, the Large Scale SIG will have a meeting this week on Wednesday, July 8 at 8 UTC[1] in the #openstack-meeting-3 channel on IRC: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200708T08 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: - amorin to add some meat to the wiki page before we push the Nova doc patch further - all to describe briefly how you solved metrics/billing in your deployment in https://etherpad.openstack.org/p/large-scale-sig-documentation - ttx to produce a draft of the 10th birthday slide for the SIG Talk to you all on Wednesday, -- Thierry Carrez

1 1

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

07 Jul '20

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

2 4

[keystone][zun] Choice between 'ca_file' and 'cafile'
by Hongbin Lu 07 Jul '20

07 Jul '20

Hi all, A short question. I saw a few projects are using the name 'ca_file' [1] as config option, while others are using 'cafile' [2]. I wonder what is the flavorite name convention? I asked this question because Kolla developer suggested Zun to rename from 'ca_file' to 'cafile' to avoid the confusion [3]. I want to confirm if this is a good idea from Keystone's perspective. Thanks. Best regards, Hongbin [1] http://codesearch.openstack.org/?q=cfg.StrOpt%5C(%27ca_file%27&i=nope&files… [2] http://codesearch.openstack.org/?q=cfg.StrOpt%5C(%27cafile%27&i=nope&files=… [3] https://review.opendev.org/#/c/738329/

4 3

[openstack-helm] Proposing Andrii Ostapenko for core of OpenStack-Helm
by Gage Hugo 07 Jul '20

07 Jul '20

Hello everyone, Andrii Ostapenko (andrii_ostapenko) has been very active lately in the openstack-helm community, notably his efforts in driving loci forward as well as him maintaining a lot of our images and providing great in-depth reviews. Due to these reasons, I am proposing Andrii as a core reviewer for OpenStack-Helm. If anyone has any feedback, please feel free to reply here by the end of the week!

1 0

[nova] Changes for out-of-tree drivers
by Stephen Finucane 07 Jul '20

07 Jul '20

I have a change proposed [1] as part of the work to add vTPM support to nova that will modify the arguments for the 'unrescue' function. As noted in the commit message, this is expected to gain a 'context' argument and lose the currently unused 'network_info' argument. If you maintain an out-of-tree driver, you will need to account for this change. Cheers, Stephen [1] https://review.opendev.org/#/c/730382/

1 0

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

07 Jul '20

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

2 2

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

06 Jul '20

Hello all, Following on from my recent mail about the stable/ocata branch of the openstack/nova project now being unmaintained [1] I'd also like to move the stable/pike [2] branch formally into this phase of maintenance [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`` [4]. Again hopefully this isn't taking anyone by surprise but please let me know if this is going to be an issue! Regards, [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015747.html [2] https://review.opendev.org/#/q/project:openstack/nova+branch:stable/pike [3] https://docs.openstack.org/project-team-guide/stable-branches.html#unmainta… [4] 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 2

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